Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
←
→
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
Sviluppo di strumenti di web scraping per il
miglioramento dei processi di data enrichment
Relatore
Luigi De Giovanni
Laureando
Daniele Penazzo
Mat: 1007651
Anno Accademico 2017/2018
Daniele Penazzo: Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment,
Tesi di laurea triennale, © Settembre 2018.
Perseverance is the backbone of success.
Anonymous
Alla mia famiglia
Ai miei amici, nazionali e non
A coloro che non si arrendono maiSviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
Indice
1 Introduzione 6
1.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 L’idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Organizzazione del testo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Introduzione al progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 Pianificazione delle attività 8
2.1 Obiettivi fissati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Pianificazione temporale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Analisi preventiva 10
3.1 Analisi preventiva dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Piano di contingenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Analisi dell’architettura esistente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Analisi dei siti internet esplorati dal sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1 Criticità rilevate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.2 Estrazione dei loghi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.3 Estrazione delle informazioni testuali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Analisi dei requisiti 17
4.1 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Tracciamento dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.1 Requisiti Funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Requisiti di Qualità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3 Requisiti di Vincolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.4 Riepilogo Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Progettazione 27
5.1 Tecnologie e strumenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.1 Python 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.2 Flake8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.3 Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.1.4 DjangoREST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.5 Celery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.6 Swagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.7 Vagrant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.8 VirtualBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.9 BeautifulSoup4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.10 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.11 Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.12 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.13 NeoVIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.14 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.15 ESLint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.16 ReactJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.17 Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.18 Bundle-js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.19 Scrapy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Ciclo di vita del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 Design Pattern utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3.1 Chain of Responsibility Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . 33
INDICE IIISviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
5.3.2 Pipeline design pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4 Altre scelte di design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4.1 Interfacce fluide per la costruzione della pipeline . . . . . . . . . . . . . . . . . . . . . 34
5.5 Progettazione dell’architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5.1 Classi e moduli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.6 Punti di estensione dell’architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6 Codifica 39
6.1 Norme di codifica seguite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2 Gestione del repository Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3 Implementazione della pipeline di web scraping . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4 Creazione della pagina di amministrazione Django . . . . . . . . . . . . . . . . . . . . . . . . 40
6.5 Implementazione della pipeline di scraping del catasto . . . . . . . . . . . . . . . . . . . . . . 42
6.6 Implementazione front-end Django per lo scraping dal catasto . . . . . . . . . . . . . . . . . . 42
6.7 Implementazione delle chiamate REST per gli scraper . . . . . . . . . . . . . . . . . . . . . . 43
6.8 Implementazione del front-end React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7 Verifica e Validazione 45
7.1 Analisi Statica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.2 Analisi Dinamica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.3 Specifica dei test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.4 Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8 Conclusioni 52
8.1 Consuntivo dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.2 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
8.3 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.4 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.4.1 Valutazione del progetto di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
8.4.2 Valutazione dello stage e del progetto RiskApp . . . . . . . . . . . . . . . . . . . . . . 54
8.4.3 Valutazione finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Glossario 56
INDICE IVSviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment Elenco delle tabelle 1 Obiettivi fissati nel piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2 Pianificazione del lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4 Descrizione dei rischi, con probabilità ed incidenza. . . . . . . . . . . . . . . . . . . . . . . . . 10 5 Piano di contingenza dei rischi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6 Tabella di tracciamento dei requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7 Tabella di tracciamento dei requisiti di qualità . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8 Tabella di tracciamento dei requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9 Riepilogo dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10 Specifica dei test automatici implementati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 11 Consuntivo dei rischi rilevati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 12 Raggiungimento degli obiettivi di progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Elenco delle figure 1 Diagramma dei casi d’uso per la componente WebScraper . . . . . . . . . . . . . . . . . . . . 17 2 Diagramma dei casi d’uso per la componente LRScraper . . . . . . . . . . . . . . . . . . . . 18 3 Schema del ciclo di vita incrementale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4 Esempio di lavagna Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5 Esempio di chain of responsiblity pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6 Struttura del pipeline pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7 Schema esemplificativo del funzionamento dell’architettura . . . . . . . . . . . . . . . . . . . 35 8 Schema di gestione del repository Git [31] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 9 I nuovi modelli nella pagine di amministrazione Django . . . . . . . . . . . . . . . . . . . . . 41 10 Ricerca nel pannello amministrativo Django . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 11 Modifica di un dato dal pannello amministrativo . . . . . . . . . . . . . . . . . . . . . . . . . 41 12 Schermata di ricerca dello scraper del catasto . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 13 Scelta dell’omonimo catastale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 14 Avvio di un nuovo scraping da front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 15 Visualizzazione risultati o riavvio di uno scraping . . . . . . . . . . . . . . . . . . . . . . . . 43 16 Visualizzazione dello stato dello scraping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 17 Visualizzazione dei risultati dello scraping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 ELENCO DELLE FIGURE V
Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment Sommario Il presente documento descrive il lavoro svolto durante il periodo di stage, della durata di 312 ore, dal laureando Daniele Penazzo presso l’azienda RiskApp S.r.l. Gli obiettivi da raggiungere erano molteplici. In primo luogo era richiesto lo sviluppo di una componente di web scraping da integrare alla piattaforma esistente, tale componente doveva effettuare ricerche ed esplorare siti internet alla ricerca di informazioni che possano ritenersi interessanti a fini assicurativi. Tale componente inoltre doveva avere determinate caratteristiche di modularità, estensibilità ed autonomia. In secondo luogo era richiesto lo sviluppo di una componente di scraping specifica per il catasto, da integrare ancora una volta sulla stessa piattaforma, allo scopo di ricavare ulteriori informazioni di interesse dal catasto nazionale, eventualmente richiedendo una visura catastale. Successivamente è stato richiesto di implementare delle componenti di front-end, degli endpoint REST per l’applicazione web ed una suite di test che garantisse una buona copertura del codice scritto. Oltre a ciò è stata richiesta l’integrazione delle componenti esposte nella piattaforma RiskApp. ELENCO DELLE FIGURE 2
Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
Ringraziamenti
As we express our gratitude, we must never forget that the highest
appreciation is not to utter words but to live by them.
John F. Kennedy
Vorrei ringraziare il Prof. Luigi De Giovanni, relatore della mia tesi, per l’aiuto datomi durante la stesura del
lavoro.
Desidero inoltre ringraziare i miei genitori per il sostegno e pazienza portati in questi anni.
Ho desiderio di ringraziare i miei amici più vicini per il sostegno morale e l’aiuto offerti oltre alla loro
vicinanza nei momenti più duri.
Padova, Settembre 2018 Daniele Penazzo
ELENCO DELLE FIGURE 4Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
1 Introduzione
1.1 L’azienda
RiskApp S.r.l. è una start-up che si occupa dello sviluppo di un sistema all-in-one di gestione e valutazione
dei rischi per l’industria assicurativa.
Tale sistema offre supporto ai player assicurativi e bancari che desiderano offrire soluzioni per la copertura
delle piccole e medie imprese, sviluppando modelli di calcolo per l’analisi dei rischi che un’eventuale compagnia
assicurativa vuole coprire.
Il prodotto offre inoltre strumenti per stimare eventi negativi, valutare rischi, aiutare le assicurazioni ad
effettuare decisioni informate e ricevere un rapporto dettagliato e chiaro dei rischi, così da mitigarli o assicurarli.
1.2 L’idea
Internet è un luogo ricco di informazioni e notizie che possono risultare utili per arricchire il profilo di
un’azienda ed aumentare la precisione di un’eventuale valutazione dei rischi. Tali informazioni e notizie si
presentano nella forma di “dati non strutturati” che dovranno essere elaborati per poter essere utilizzati in
modo proficuo all’interno di un sistema informatico.
L’idea è creare un’architettura che permetta di estrarre, in forma maggiormente strutturata e con minimo
intervento da parte dell’utente finale, tali dati in modo da arricchire lo screening informativo delle aziende
analizzate.
1.3 Organizzazione del testo
Il testo è organizzato in sezioni tematiche, nel seguente modo:
• Introduzione: contenente le informazioni riguardanti l’azienda ospitante, l’idea, l’organizzazione del
testo ed una breve introduzione al progetto di stage;
• Pianificazione: dove sono inseriti gli obiettivi accordati con l’azienda e l’organizzazione del lavoro;
• Analisi Preventiva: per acquisire maggiore conoscenza del dominio di applicazione e dell’architettura
esistente, esponendo eventuali criticità che possono rendere difficoltoso lo svolgersi del progetto;
• Analisi dei requisiti: contenente i compiti svolti durante l’attività di analisi dei requisiti;
• Progettazione: in cui sono presenti tutti i dettagli dell’attività di progettazione dell’architettura;
• Codifica: contenente le norme di codifica, la gestione del repository [g] GIT ed una visuale retrospettiva
dell’attività di codifica;
• Verifica e validazione: in cui sono presenti i dettagli concernenti i test, le attività di verifica e
validazione finale;
• Conclusioni: a chiusura del testo.
Per quanto concerne la stesura del testo, sono state le seguenti convenzioni tipografiche:
• acronimi, abbreviazioni e termini di uso non comune o ambigui vengono definiti nel glossario, situato in
appendice al presente documento;
• la prima occorrenza dei termini riportati nel glossario saranno evidenziati nel seguente modo: parola [g] ;
• i termini in lingua straniera o facenti parte del gergo tecnico sono evidenziati con carattere corsivo.
1 INTRODUZIONE 6Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
1.4 Introduzione al progetto
RiskApp è un software mirato alla gestione e valutazione dei rischi per l’industria assicurativa, una parte
importante del processo di valutazione di un cliente è l’estrazione di dati, la loro trasformazione e successiva-
mente il loro caricamento sulla piattaforma (procedura detta ETL[g] ). Tale procedura sta alla base di un
processo chiamato data enrichment [g] , nel quale questo progetto di stage si inserisce.
Lo scopo del progetto di stage è creare un’architettura in grado di estrarre autonomamente (o con intervento
dell’utente estremamente limitato) dati non strutturati [g] e semi-strutturati [g] da diverse fonti sul web, tra cui:
• Google Places;
• Google StreetView;
• Siti internet aziendali;
• Siti web appartenenti a testate giornalistiche;
• Il registro dei dati catastali.
L’architettura da costruire deve essere inoltre in grado di superare eventuali ostacoli che solitamente derivano
da una costruzione dei siti web non corretta oppure portata a compimento tramite uso di tecniche obsolete.
Avvenuto il processo di estrazione, l’architettura deve salvare i dati in modo strutturato, facendo eventualmente
uso di campi semi-strutturati come JSON [g] e visualizzarli in una componente front-end creata ad-hoc.
L’architettura deve offrire garanzie di solidità agli errori esterni, così da poter operare in autonomia, e di
alta estensibilità e flessibilità così da poter aggiungere, togliere o riorganizzare stadi di scraping [g] in maniera
semplice e veloce con minime modifiche al codice esistente.
1 INTRODUZIONE 7Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
2 Pianificazione delle attività
2.1 Obiettivi fissati
Nel piano di lavoro sono state pianificati alcuni obiettivi di massima che l’architettura prodotto dell’esperienza
di stage dovrà andare a soddisfare con diverse priorità. Si farà riferimento a tali obiettivi secondo le seguenti
notazioni:
• OB#: Obiettivo obbligatorio, vincolante in quanto obiettivo primario richiesto dal committente;
• D#: Obiettivo desiderabile, non vincolante o strettamente necessario, ma dal riconoscibile valore
aggiunto;
• OP#: Obiettivo opzionale, rappresentante un valore aggiunto non strettamente competitivo.
Si riporta qui la tabella degli obiettivi posti nel piano di lavoro:
Tabella 1: Obiettivi fissati nel piano di lavoro
Codice Descrizione
OB1 Progettazione ed implementazione di una componente di scraping di dati anagrafici testuali
da Google Places
OB2 Progettazione ed implementazione di una componente per lo scraping di dati anagrafici
testuali dato un URL[g] aziendale
OB3 Progettazione ed implementazione di una componente di scraping per il recupero di loghi di
aziende
OB4 Progettazione ed implementazione di chiamate REST per l’uso da parte del sistema della
nuova componente
OB5 Progettazione ed implementazione della componente di Front-end
OB6 Implementazione dei test automatici di unità per le componenti di scraping da Google
Places e dai siti web aziendali
D1 Implementazione dello scraping di dati dal catasto
D2 Conoscenza dell’impianto esistente
D3 Implementazione di un sistema per l’acquisizione di screenshot della home page dei siti web
aziendali
OP1 Implementazione di test di unità delle componenti non testate in OB6
OP2 Implementazione di test di integrazione
OP3 Integrazione dei test nella suite esistente
2 PIANIFICAZIONE DELLE ATTIVITÀ 8Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
2.2 Pianificazione temporale
Per quanto riguarda la pianificazione temporale si è deciso di dedicare il seguente ammontare di ore ad ogni
attività svolta:
Tabella 2: Pianificazione del lavoro
Durata Attività
Formazione
• Apprendimento di Python avanzato
72 Ore • Apprendimento di Scrapy
• Apprendimento di Django
• Apprendimento di Swagger
Analisi ed apprendimento delle tecnologie usate per la gestione del sistema preesistente
• Analisi del sistema preesistente
8 Ore
• Creazione della macchina virtuale a supporto dello sviluppo della componente
• Creazione dell’ambiente virtuale ed installazione delle dipendenze necessarie allo sviluppo
Attività di analisi
• Analisi dei requisiti
25 Ore
◦ Analisi della natura dei dati da raccogliere tramite *scraping*
◦ Analisi delle tecnologie alternative (Google APIs for Python)
Progettazione della componente:
• Strutturazione delle chiamate *REST*
30 Ore
• Strutturazione delle modalità di *scraping*
• Strutturazione della componente di front-end
Implementazione della componente:
• Implementazione della componente di *scraping* di dati testuali
• Implementazione della componente di *scraping* di dati grafici
147 Ore
• Implementazione delle chiamate *REST*
• Implementazione della componente di front-end
• Implementazione dello *scraping* di dati del catasto
30 Ore Implementazione dei test
312 Ore Totale ore pianificate
2 PIANIFICAZIONE DELLE ATTIVITÀ 9Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
3 Analisi preventiva
A good programmer is someone who looks both ways before crossing
a one-way street.
Doug Linder
3.1 Analisi preventiva dei rischi
Per assicurare uno svolgersi del progetto quanto più possibile privo di inconvenienti, ho provveduto ad
analizzare i rischi che possono verificarsi durante lo svolgersi dello stage.
I rischi sono classificati in forma tabellare, evidenziando:
• Un codice identificativo univoco;
• La denominazione del rischio, la quale fornisce un’idea di base del rischio stesso;
• Una descrizione estesa del rischio;
• La probabilità di occorrenza;
• L’ incidenza del rischio sullo svolgersi del progetto.
I rischi si suddividono in quattro categorie principali:
• RT: Rischi legati alle tecnologie usate;
• RP: Rischi personali;
• RS: Rischi strumentali;
• RR: Rischi riguardanti i requisiti.
Tabella 4: Descrizione dei rischi, con probabilità ed incidenza.
Codice Denominazione Descrizione Probabilità Incidenza
RT1 Inesperienza Alcune tecnologie adottate potrebbero non Media Alta
Tecnologica essere conosciute o di difficile comprensione.
RT2 Problemi La strumentazione può essere soggetta a Bassa Bassa
Hardware e malfunzionamenti ed il software può avere
Software problemi di compatibilità, con possibili
perdite di dati e difficoltà nell’avanzamento
del progetto
RP1 Problemi In un progetto su che ha lunga durata, Bassa Bassa
personali possono verificarsi problemi personali che
costringono a rallentare o sospendere
temporaneamente il progetto di stage
RS1 Regressioni nel È possibile che alcune correzioni apportate Bassa Media
codice in itinere al codice creato possano far
sorgere bachi nel software
RR1 Errata Durante l’analisi è possibile che si possano Media Alta
comprensione avere fraintendimenti sulla natura dei
dei requisiti requisiti da coprire e tali requisiti possono
essere a loro volta studiati in modo erroneo
o incompleto
3 ANALISI PREVENTIVA 10Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
Codice Denominazione Descrizione Probabilità Incidenza
RR2 Variazioni dei Vi è la possibilità che i requisiti subiscano Media Alta
requisiti variazioni nel tempo a causa di idee
proposte, novità nel dominio di
applicazione o cattiva organizzazione da
parte del proponente del progetto
3.2 Piano di contingenza
È stato quindi posto in essere un piano di contingenza proponente soluzioni che permettano di annullare o
mitigare quanto più possibile le conseguenze collegate ai rischi analizzati.
Il piano di contingenza è descritto in forma tabellare e riporta:
• Il codice del rischio considerato;
• La strategia di rilevazione di tale rischio;
• Una serie di contromisure suggerite per la mitigazione di tale rischio.
Tabella 5: Piano di contingenza dei rischi.
Codice Strategia di Rilevazione Contromisure suggerite o attuate
RT1 Stilare un elenco delle tecnologie usate e da In caso di conoscenza scarsa o assente di una
usare ed effettuare una valutazione sul livello determinata tecnologia, sarà necessario
di conoscenza di tali tecnologie procedere ad una documentazione al riguardo,
facendo uso di risorse gratuite disponibili
on-line e comunicando strettamente con il capo
programmatore del progetto.
RT2 Verificare periodicamente lo stato di Prima di ogni spostamento o chiusura dello
manutenzione degli strumenti di lavoro e porre strumento di lavoro, si dovrà effettuare una
un’adeguata cura nei confronti degli stessi push [g] sul repository GitHub messo a
disposizione dall’azienda. Inoltre in caso di
malfunzionamento della postazione di lavoro
personale, l’azienda mette a disposizione una
postazione di lavoro alternativa da cui è
possibile proseguire il progetto di stage.
RP1 Si dovrà avvisare il personale aziendale con Successivamente al verificarsi del rischio, sarà
congruo anticipo in caso di problemi personali. necessario pianificare nuovamente il lavoro così
da poter recuperare il tempo perso ed
eventualmente avvisare l’Ufficio Stage della
variazione. Nei documenti ufficiali è già stato
posto un periodo di slack [g] di sette giorni.
RS1 Per rilevare possibili regressioni nel codice si Ogniqualvolta si verifica un bug, si andrà a
farà uso di un sistema di continuous creare un nuovo test in grado di evitare che
integration [g] tale bug sorga nuovamente senza essere notato.
3 ANALISI PREVENTIVA 11Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
Codice Strategia di Rilevazione Contromisure suggerite o attuate
RR1 Per tutta la durata dello stage si manterrà In caso di divergenza tra requisiti rilevati e
contatto con i proponenti del progetto di stage quanto richiesto dai proponenti dello stage, si
dovranno effettuare correzioni all’analisi e si
discuteranno con il proponente stesso le
strategie di mitigazione più consone.
RR2 Per tutta la durata dello stage si manterrà Si dovrà analizzare quali requisiti portano
contatto con i proponenti del progetto di stage maggior valore aggiunto al progetto esistente
ed in caso di variazioni si dovrà prontamente
discutere con il proponente per mediare una
soluzione ideale.
3.3 Analisi dell’architettura esistente
L’architettura esistente si presenta suddivisa in due parti principali, distribuite su due macchine separate:
• Ayako: che si occupa dei calcoli e degli algoritmi;
• Noriko: che si occupa della persistenza dei dati.
Il progetto oggetto dello stage sarà contenuto nella sua integrità all’interno di Ayako, quindi quest’ultima
parte sarà oggetto dell’analisi.
L’analisi è stata effettuata studiando il codice esistente, ponendo domande sull’architettura stessa e sulle
motivazioni delle decisioni intraprese oltre all’analisi ed esecuzione della suite di test per poter verificare lo
stato di copertura del codice.
Dall’analisi sono emerse alcune criticità che elenco qui sotto:
• Debito tecnologico: Nonostante il software sia ancora nella forma di progetto pilota [g] , è possibile
notare che viene fatto uso di una versione obsoleta di Django, che presenta falle di sicurezza conosciute;
questo è dovuto a due fattori principali:
– Uso di campi deprecati: “MoneyField”, usato in alcuni punti del progetto è un campo che non fa
parte dei campi offerti da Django e nemmeno tra i campi mantenuti dalla comunità. Questo rende
complessa la manutenzione e gli aggiornamenti riguardanti il modulo che offre tale campo non sono
garantiti;
– Uso di EAV: Il progetto correntemente fa uso di un fork [g] di Django-EAV per il supporto al
modello di conservazione dati di tipo Entity-Value-Attributeˆ[g], oltre tutto si è inserito come
dipendenza una precisa commit [g] di tale fork, bloccandone così gli aggiornamenti.
• Coverage[g] falsata: Il file di configurazione di coverage era impostato in modo tale da includere file
che a mia modesta opinione vanno a falsare la copertura del codice, tali files includono:
– Migrazioni: che sono usate per propagare le modifiche fatte sui modelli verso lo schema di database,
solitamente queste sono eseguite ad ogni avvio dei test, comportando una loro copertura del 100%;
– File di configurazione: L’unico file di configurazione usato durante i test è settings_test.py,
mentre gli altri file di configurazione (configurazione in produzione, per lo sviluppo su macchina
virtuale, . . . ) riporteranno una copertura dello 0%;
– I test stessi: Dato che sono eseguiti integralmente, questi files riporteranno una copertura del 100%,
falsando la metrica.
• Copertura dei test bassa: Dopo una riconfigurazione dell’analizzatore di copertura dei test, la
coverage si è abbassata di 20 punti percentuali, attestandosi poco sopra il 40%, una percentuale molto
bassa per un sistema così ampio. Ciò dimostra come piccole differenze nella configurazione di una
componente facente parte del cruscotto informativo di un progetto possano eventualmente arrivare a
falsare le prospettive di solidità di un sistema software;
3 ANALISI PREVENTIVA 12Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
• Test di unità: Sembra che la maggior parte dei test vada a coprire gruppi di funzionalità, mentre i
test di unità veri e propri sembrano essere veramente esigui;
• Doppio front-end: Il sistema, nonostante sia in fase di progetto pilota, sembra stia già subendo una
migrazione da un front-end basato su template [g] e view [g] Django ad un front-end basato su React,
questo comporta la presenza di una possibilmente grande quantità di codice legacy [g] che riduce la
manutenibilità dell’architettura;
• Comunicazione front-end e back-end basata su polling[g] : La comunicazione tra il front-end ed
il back-end è basata su un polling periodico del database ogni 5 secondi, questa forma di comunicazione
può provocare rallentamenti del sistema, appesantimento del codice, difficoltà di lettura del codice stesso
e difficoltà nel testing. Nel caso di una re-ingegnerizzazione del sistema, un’alternativa più moderna
potrebbe essere una comunicazione basata su websockets;
• Cattiva gestione del polling: Il front-end inizia la propria procedura di polling al caricamento
delle componenti React e non quando strettamente necessario (ad esempio quando si è in attesa del
completamento di un’operazione asincrona), questo provoca la creazione di traffico non necessario sulla
rete e carico sul client a causa delle funzioni in esecuzione ad intervalli regolari. Inoltre il polling provoca
un aggiornamento di molte componenti alla volta, a causa di Redux, appesantendo ulteriormente la
web-app;
• Architettura “database-centric”: Come conseguenza dell’uso di polling, è necessario fare uso di
un sistema che consenta di memorizzare lo stato delle eventuali elaborazioni in corso; nell’architettura
corrente il database fornisce tale funzionalità. Questo ha come conseguenza un appesantimento delle
strutture dati, con l’aggiunta di campi che memorizzino lo stato delle elaborazioni, così da evitare di
leggere dati parziali. Inoltre il database potrebbe essere un collo di bottiglia, limitando le prestazioni
del sistema. Usare il database in questo modo costringe inoltre a far ricorso a test fixture [g] aggiuntive
rendendo difficoltosa la lettura del codice. A tutto questo si aggiunge la necessità di gestire la scrittura
su database ad ogni passaggio, aumentando gli assi di cambiamento delle componenti sviluppate, a
discapito del principio di Single Responsibility [g] ;
• Front-end privo di documentazione: Il front-end è stato appaltato ad un’azienda esterna, il codice
JavaScript risulta completamente privo di commenti, estremamente complesso e senza alcun tipo di
documentazione. Questo lo rende difficilmente ispezionabile e non è possibile fare affidamento sul team
che ha proposto lo stage per eventuali chiarimenti su di esso;
• Uso di metodi obsoleti nel front-end: Il front-end fa uso di una serie di metodi che sono dichiarati
come obsoleti in fase di build [g] , questo limita la manutenibilità del front-end stesso, dato che un
aggiornamento potrebbe portare con sé la rimozione dei metodi obsoleti usati;
• Ciclo di build del front-end troppo lungo: Il front-end subisce una procedura di build tramite
uno script apposito, ma ogni build richiede circa 15 minuti, a causa della gestione di tutti i file statici,
reinstallazione tutte le dipendenze, build dei progetti collegati e costruzione di un bundle (cioè un unico
file JavaScript contenente l’intero front-end), anche quando non necessario. Questo tempo è troppo
lungo per uno sviluppo efficiente, soprattutto dato che il front-end non è molto esteso;
• Uso di bundle-js: L’uso di bundle.js forza la creazione di un unico file JavaScript minificato[g] a cui
tutto il progetto fa riferimento, questo rende il debugging estremamente complesso.
3.4 Analisi dei siti internet esplorati dal sistema
3.4.1 Criticità rilevate
Durante l’analisi dei siti web sono stati rilevate alcune criticità che potrebbero mettere in crisi un motore di
scraping automatizzato come quello oggetto del progetto di stage:
1. Redirect [g] HTTP: Alcuni URL potrebbero portare ad una risposta del server con codici 301
(permanentemente spostato) o 302 (ridirezione temporanea);
3 ANALISI PREVENTIVA 13Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
2. Redirect creati con script JavaScript: alcuni siti, invece di far uso dei redirect interni al server
web, inseriscono una pagina contenente un solo script che forza il browser a cambiare pagina, verso un
dominio diverso;
3. Frame HTML [g] : contenenti componenti derivanti da un altro dominio o pagina, che potrebbero
rendere difficoltosa l’ispezione del codice;
4. Link diversi da ancore HTML standard: Alcuni siti fanno uso di immagini di sfondo e tag per la costruzione di siti web, questi link potrebbero sfuggire ai motori più semplici.
Queste criticità sono state gestite nel corso del progetto, come si vedrà in seguito.
3.4.2 Estrazione dei loghi
L’idea alla base della funzionalità di estrazione dei loghi è l’uso di diverse metodologie euristiche [g] , basate sui
siti messi a disposizione dall’azienda proponente e sulla mia esperienza personale nell’uso, studio, creazione di
siti internet ed interesse nelle metodologie SEO [g] .
Qui di seguito riporto una lista ordinata delle metodologie euristiche implementate nell’architettura, ordinate
per quella che ritengo essere la loro affidabilità nel restituire un logo aziendale:
1. Analisi dei microdata [g] Ld+Json [1, 2]
2. Analisi delle Twitter Cards [3] e dei meta tag collegati;
3. Analisi dei tag Facebook/OpenGraph [4], anche se oramai sono considerati obsoleti;
4. Analisi dell’attributo id dei tag : molte aziende usano l’id “logo” (o che comunque contengono
la parola “logo”) per identificare il proprio logo aziendale in un sito internet;
5. Analisi dell’attributo class dei tag : molte aziende fanno uso della class “logo” (o che
comunque contengono la parola “logo”) per identificare il proprio logo aziendale all’interno del sito;
6. Analisi dei fogli stile CSS del sito: alcune aziende usano attributi id e class contenenti la parola “logo”
all’interno di contenitori come per poi fare uso delle proprietà background-image di CSS per
visualizzare il logo;
7. Analisi dell’attributo src dei tag : molte aziende semplicemente danno al file contenente il
logo aziendale il nome “logo”;
8. Analisi dell’attributo alt dei tag : alcune aziende, più raramente, inseriscono “logo” come
descrizione testuale all’immagine del proprio logo aziendale;
9. Analisi dell’attributo alt dei tag : alcune aziende, seppur molto raramente, inseriscono la
ragione sociale all’interno dell’attributo alt del proprio logo aziendale;
10. Analisi dei tag : questo però potrebbe restituire buone immagini (soprattutto
con i siti più moderni che supportano loghi fino a 192x192 pixel [g] ) oppure immagini di qualità molto
scarsa (le prime favicon [g] erano grandi 16x16 pixel).
3.4.3 Estrazione delle informazioni testuali
Nonostante siano espresse in linguaggio naturale, le informazioni testuali da ricavare hanno comunque una
struttura piuttosto definita e possono essere ricavate in modo sufficientemente preciso tramite ricerca con
regular expression [g] o tramite altre metodologie euristiche, senza dover necessariamente ricorrere a strumenti
di elaborazione del linguaggio naturale, i quali possono risultare pesanti in termini di prestazioni e di difficile
apprendimento, comprensione e manutenzione.
3.4.3.1 Indirizzi Email
Gli indirizzi email sono ricavabili tramite due metodologie:
• Ricerca dei link html con prefisso mailto: Usati per richiamare da browser il software usato per
la gestione della propria casella di posta e comporre una nuova email con destinatario precompilato [5];
3 ANALISI PREVENTIVA 14Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
• Ricerca tramite regular expression: Avendo una struttura ben definita, gli indirizzi email si prestano
bene alla ricerca tramite espressioni regolari.
3.4.3.2 Link ai social media
Analizzando i siti web proposti, ho potuto ricavare quattro diverse metodologie per estrarre link ai social
media dai siti aziendali:
• Analisi degli attributi class dei tag: Molte aziende inseriscono link o testo facente riferimento ai
propri social media all’interno di tag o contenitori con class contenente la parola “social”;
• Analisi degli attributi id dei tag: Similmente alle class, molte aziende inseriscono link o testo
facente riferimento ai propri social media all’interno di tag o contenitori con id contenente la parola
“social”;
• Analisi dei microdata Ld+Json: I microdata possono contenere un campo “sameAs” che identifica
siti collegati alla stessa azienda, solitamente questo campo è usato per i social media;
• Analisi dei link: È possibile analizzare l’attributo href di tutti i link, alla ricerca di possibili social
media, filtrandoli per dominio, i domini più usati sono Facebook, Instagram, YouTube e LinkedIn.
3.4.3.3 Partite IVA/Codici Fiscali
Le partite IVA in Italia hanno una struttura ben precisa composta da un eventuale codice nazione (IT) ed un
numero ad 11 cifre.
Nei siti web questo pattern può essere preceduto da vari prefissi tra cui “P.I.”, “C.F” e “P.Iva”, quindi ho
deciso di usare una lista dalla quale ricaverò una serie di alternative da inserire in un’espressione regolare.
Tale lista è simile alla seguente:
PARTITA_IVA_PREFIX = ["PI", "P.I", "P.I.", "CF",
"C.F.", "C.F", "P.Iva", "PIva",
"Partita IVA", "VAT", "UID"]
Tale lista andrà poi a generare il prefisso di un’altra espressione regolare atta a rilevare il resto del codice
fiscale o partita IVA.
Questo permette di estendere facilmente i prefissi senza dover andare a modificare direttamente l’espressione
regolare stessa.
3.4.3.4 Numeri telefonici
I numeri telefonici possono avere strutture molto diversificate, contenenti caratteri di separazione diversi in
diverse posizioni, precedute da diversi prefissi e con una lunghezza che va dalle 6 alle 10 cifre.
È stata quindi costruita un’espressione regolare che possa accettare la maggior parte dei numeri di telefono
incontrati finora.
3.4.3.5 Indirizzi geografici
Gli indirizzi geografici possono avere strutture estremamente eterogenee e non è possibile rappresentare tali
strutture con un linguaggio regolare, ma è comunque possibile estrarne un sottoinsieme molto limitato che in
molti casi può risultare soddisfacente.
Per questo sono state create due espressioni regolari per ricercare i due formati di indirizzo più comune, cioè
quelli nei formati:
• prefisso strada numero località CAP paese provincia nazione
3 ANALISI PREVENTIVA 15Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
• CAP paese prefisso strada numero
Eventuali elementi non presenti sono stati gestiti all’interno dell’espressione, aumentando la probabilità di
trovare una corrispondenza.
3 ANALISI PREVENTIVA 16Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
4 Analisi dei requisiti
Walking on water and developing software from a specification are
easy if both are frozen.
Edward Berard
4.1 Casi d’uso
Dato che il sistema è quasi completamente automatico, e l’unico attore coinvolto è l’utente autenticato, i
diagrammi dei casi d’uso sono pochi e molto semplici.
I dati necessari per l’esecuzione dello scraping sono automaticamente ricavati dallo stato della web-app, in
modo che l’interazione dell’utente sia minima o nulla.
In Figura 1 si riportano i casi d’uso riguardanti l’obiettivo obbligatorio di creazione di una componente di
Web Scraping.
Figura 1: Diagramma dei casi d’uso per la componente WebScraper
ID UC1.
Titolo Avvio dello web scraper.
Attori primari Utente Autenticato.
Pre-condizione L’attore è autenticato presso il sistema e visualizza il pulsante "Avvia Scraping".
Post-condizione Il sistema salva il risultato dello scraping in database.
Scenario principale
1. L’attore clicca sul pulsante "Avvia Scraping";
2. Il sistema avvia un task [g] in background [g] che effettua lo scraping;
3. Alla fine del task, il sistema salva in database i risultati dello scraping.
4 ANALISI DEI REQUISITI 17Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
ID UC2.
Titolo Visualizzazione dei risultati dello scraping.
Attori primari Utente Autenticato.
Pre-condizione L’utente è autenticato presso il sistema, il task di scraping è terminato e visualizza
il pulsante "Visualizza Risultati".
Post-condizione Il sistema visualizza una finestra modale [g] con i risultati dello scraping.
Scenario principale
1. L’attore clicca sul pulsante "Visualizza Risultati";
2. Il sistema recupera i dati dal database;
3. Il sistema visualizza a schermo una finestra modale con i risultati dello
scraping.
ID UC3.
Titolo Riavvio di uno scraping completato.
Attori primari Utente Autenticato.
Pre-condizione L’utente è autenticato presso il sistema, il task di scraping è terminato e visualizza
il pulsante "Riavvia Scraping".
Post-condizione Il sistema cancella i dati salvati, esegue un nuovo scraping e salva il risultato in
database.
Scenario principale
1. L’attore clicca sul pulsante "Riavvia Scraping";
2. Il sistema avvia un task in background che elimina i dati esistenti ed effettua
un nuovo scraping;
3. Alla fine del task, il sistema salva in database i risultati del nuovo scraping.
È stato inoltre pianificato un obiettivo desiderabile consistente nell’implementazione di una componente di
scraping dal catasto, i cui casi d’uso sono esposti in Figura 2.
Figura 2: Diagramma dei casi d’uso per la componente LRScraper
4 ANALISI DEI REQUISITI 18Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
ID UC4.
Titolo Avvio dello scraper catasto.
Attori primari Utente Autenticato.
Pre-condizione L’utente è autenticato presso il sistema e visualizza il pulsante "Avvia Scraping
del Catasto".
Post-condizione Il sistema salva in database la lista degli omonimi in catasto corrispondenti alla
ragione sociale del cliente cercato.
Scenario principale
1. L’utente clicca sul pulsante "Avvia Scraping del Catasto";
2. Il sistema avvia un task in background per ricercare gli omonimi del cliente
cercato nei registri catastali;
3. Il sistema salva in database la lista degli omonimi trovati.
ID UC5.
Titolo Scelta dell’omonimo catastale da elaborare.
Attori primari Utente Autenticato.
Pre-condizione L’utente è autenticato presso il sistema e visualizza un elenco di omonimi catastali
tra cui scegliere.
Post-condizione Il sistema salva in database i risultati dello scraping dell’omonimo catastale scelto.
Scenario principale
1. L’utente clicca su un omonimo catastale da elaborare;
2. Il sistema avvia un task in background per ricavare informazioni sull’omonimo
scelto;
3. Il sistema salva in database il risultato dello scraping.
ID UC6.
Titolo Visualizzazione dei risultati dello scraping del catasto.
Attori primari Utente Autenticato.
Pre-condizione L’utente è autenticato presso il sistema, il task di scraping è terminato e l’utente
visualizza il pulsante "Visualizza Risultati".
Post-condizione Il sistema visualizza una finestra modale contenente i risultati dello scraping
effettuato.
Scenario principale
1. L’utente clicca sul pulsante "Visualizza Risultati";
2. Il sistema recupera dal database i dati corrispondenti allo scraping del cliente
ricavato dal contesto;
3. Il sistema visualizza una finestra modale contenente i risultati dello scraping
effettuato;
4 ANALISI DEI REQUISITI 19Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
ID UC7.
Titolo Riavvio di uno scraping del catasto completato.
Attori primari Utente Autenticato.
Pre-condizione L’utente è autenticato presso il sistema, il task di scraping è terminato e l’utente
visualizza il pulsante "Riavvia Scraping del Catasto".
Post-condizione Il sistema elimina i dati dello scraping precedente, e riavvia la procedura di
scraping degli omonimi catastali.
Scenario principale
1. L’utente clicca sul pulsante "Riavvia Scraping del Catasto";
2. Il sistema elimina i dati dello scraping precedente per il cliente;
3. Il sistema avvia nuovamente il task di scraping degli omonimi catastali.
4.2 Tracciamento dei requisiti
Si riportano a seguire i requisiti in dettaglio, comprensivi di tracciamento ai rispettivi casi d’uso e decisioni, i
requisiti sono classificati in forma tabellare e sono legati ad un codice così costituito:
R[Tipo Requisito][Priorità requisito] - [Identificativo Univoco]
Il tipo di requisito è rappresentato da uno dei seguenti codici:
• F: Requisito Funzionale;
• Q: Requisito di Qualità;
• V: Requisito di Vincolo.
La priorità di un requisito è rappresentata da uno dei seguenti codici:
• 0: Obbligatorio, necessario per considerare il progetto completato con esito positivo;
• 1: Desiderabile, non necessario per completare con successo il progetto, ma che apporta ad esso un
valore aggiunto notevole;
• 2: Facoltativo, non necessario per il completamento del progetto e che apporta dei benefici limitati ad
esso.
L’identificativo univoco avrà forma numerica, nel formato [Padre].[Figlio].[Nipote].[. . . ].
4.2.1 Requisiti Funzionali
Tabella 6: Tabella di tracciamento dei requisiti funzionali
ID Descrizione Fonti Stato
RF0 - 1 Il sistema deve effettuare lo scraping di dati anagrafici da UC1, Soddisfatto
Google Places API. UC3
RF0 - 1.1 Il sistema deve ricercare una ragione sociale su Google Places UC1, Soddisfatto
API in maniera diretta. UC3
RF0 - 1.2 Il sistema deve ricercare una ragione sociale su Google Places UC1, Soddisfatto
API tramite ricerca fuzzy [g] . UC3
RF0 - 1.3 Il sistema deve ricavare dati dettagliati sull’azienda cercata UC1, Soddisfatto
da Google Places API. UC3
4 ANALISI DEI REQUISITI 20Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
ID Descrizione Fonti Stato
RF0 - 1.3.1 Il sistema deve ricavare l’indirizzo dell’azienda cercata su UC1, Soddisfatto
Google Places API. UC3
RF0 - 1.3.2 Il sistema deve ricavare le coordinate geografiche dell’azienda UC1, Soddisfatto
cercata su Google Places API. UC3
RF0 - 1.3.3 Il sistema deve ricavare l’URL del sito web dell’azienda UC1, Soddisfatto
cercata su Google Places API. UC3
RF0 - 1.3.4 Il sistema deve ricavare il nome dell’azienda trovato su UC1, Soddisfatto
Google Places API. UC3
RF0 - 1.3.5 Il sistema deve ricavare il “Place ID” di Google Places API UC1, Soddisfatto
per l’azienda cercata. UC3
RF0 - 1.3.6 Il sistema deve ricavare le categorie di cui l’azienda cercata UC1, Soddisfatto
su Google Places API fa parte. UC3
RF0 - 1.4 Il sistema deve essere in grado di salvare i dati ricavati da UC1, Soddisfatto
Google Places nel database UC3
RF0 - 2 Il sistema deve cercare il logo dell’azienda cercata, UC1, Soddisfatto
analizzando il sito web aziendale UC3
RF0 - 2.1 Il sistema deve cercare il logo dell’azienda analizzando i fogli UC1, Soddisfatto
stile CSS del sito web aziendale UC3
RF0 - 2.2 Il sistema deve cercare il logo dell’azienda analizzando UC1, Soddisfatto
l’attributo alt dei tag , nel caso questi UC3
contengano la ragione sociale dell’azienda (fuzzy search)
RF0 - 2.3 Il sistema deve cercare il logo dell’azienda analizzando UC1, Soddisfatto
l’attributo alt dei tag , nel caso questi UC3
contengano la parola “logo”
RF0 - 2.4 Il sistema deve cercare il logo aziendale analizzando UC1, Soddisfatto
l’attributo class dei tag , nel caso questi UC3
contengano la parola “logo”
RF0 - 2.5 Il sistema deve cercare il logo aziendale analizzando UC1, Soddisfatto
l’attributo id dei tag , nel caso contengano la UC3
parola “logo”
RF0 - 2.6 Il sistema deve cercare il logo aziendale analizzando UC1, Soddisfatto
l’attributo src dei tag , nel caso il nome del file UC3
contenga la parola “logo”
RF0 - 2.7 Il sistema deve cercare il logo aziendale analizzando i UC1, Soddisfatto
microdata Ld+JSON del sito web aziendale alla ricerca del UC3
campo “logo”
4 ANALISI DEI REQUISITI 21Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
ID Descrizione Fonti Stato
RF0 - 2.8 Il sistema deve cercare il logo aziendale analizzando i meta UC1, Soddisfatto
tag Facebook/OpenGraph del sito web aziendale UC3
RF0 - 2.9 Il sistema deve cercare il logo aziendale analizzando i meta UC1, Soddisfatto
tag Twitter del sito web aziendale UC3
RF0 - 2.10 Il sistema deve cercare il logo aziendale analizzando la UC1, Soddisfatto
favicon del sito web aziendale UC3
RF0 - 2.11 Il sistema deve essere in grado di salvare il logo aziendale UC1, Soddisfatto
trovato su disco UC3
RF0 - 2.12 Il sistema deve essere in grado di salvare il percorso del logo UC1, Soddisfatto
scaricato nel database UC3
RF0 - 3 Il sistema deve ricavare dati anagrafici testuali dal sito web UC1, Soddisfatto
aziendale UC3
RF0 - 3.1 Il sistema deve analizzare il file robots.txt per cercare una UC1, Soddisfatto
possibile sitemap XML del sito web aziendale UC3
RF0 - 3.2 Il sistema deve analizzare la sitemap XML del sito web UC1, Soddisfatto
aziendale alla ricerca di una pagina contatti UC3
RF0 - 3.2.1 Il sistema deve essere in grado di gestire sitemap XML UC1, Soddisfatto
annidate all’interno di altre sitemap XML UC3
RF0 - 3.3 Il sistema deve essere in grado di effettuare un crawling [g] del UC1, Soddisfatto
sito web alla ricerca di una pagina contatti UC3
RF0 - 3.3.1 Il sistema deve essere in grado di rispettare i limiti al UC1, Soddisfatto
crawling imposti dal file robots.txt UC3
RF0 - 3.4 Il sistema deve essere in grado di ricavare indirizzi email dal UC1, Soddisfatto
sito web aziendale UC3
RF0 - 3.5 Il sistema deve essere in grado di ricavare indirizzi geografici UC1, Soddisfatto
dal sito web aziendale UC3
RF0 - 3.6 Il sistema deve essere in grado di ricavare numeri di telefono UC1, Soddisfatto
dal sito web aziendale UC3
RF0 - 3.7 Il sistema deve essere in grado di ricavare numeri di partita UC1, Soddisfatto
IVA dal sito web aziendale UC3
RF0 - 3.8 Il sistema deve essere in grado di ricavare indirizzi ai social UC1, Soddisfatto
media [g] dal sito web aziendale UC3
4 ANALISI DEI REQUISITI 22Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
ID Descrizione Fonti Stato
RF0 - 3.9 Il sistema deve essere in grado di salvare i dati ricavati dai UC1, Soddisfatto
siti web in database UC3
RF0 - 4 Il sistema deve mettere a disposizione una componente UC1, Soddisfatto
front-end per l’utente UC3
RF0 - 4.1 Il sistema deve mettere a disposizione dell’utente un pulsante UC1, Soddisfatto
per avviare la procedura di scraping UC3
RF0 - 4.2 Il sistema deve mettere a disposizione dell’utente un pulsante UC3 Soddisfatto
per riavviare una procedura di scraping già completata
RF0 - 4.3 Il sistema deve mettere a disposizione dell’utente un pulsante UC2 Soddisfatto
per visualizzare i risultati di uno scraping già eseguito
RF0 - 4.4 Il sistema deve visualizzare all’utente una finestra modale UC2 Soddisfatto
contenente i risultati dello scraping effettuato
RF0 - 5 Il sistema deve mettere a disposizione un pannello Decisione Soddisfatto
amministrativo per la gestione dei modelli di database Interna
RF1 - 1 Il sistema deve essere in grado di scaricare gli omonimi UC4, Soddisfatto
catastali dal catasto nazionale UC7
RF1 - 2 Il sistema deve mettere a disposizione dell’utente la UC5 Parzialmente
possibilità di scegliere di quale quale omonimo catastale Soddisfatto
vuole fare lo scraping
RF1 - 3 Il sistema deve essere in grado di scaricare i dati catastali di UC6 Soddisfatto
un omonimo scelto
RF1 - 3.1 Il sistema deve essere in grado di scaricare i dati presenti UC6 Soddisfatto
nelle tabelle del sito dell’Agenzia delle Entrate, contenenti
informazioni limitate sugli edifici cercati
RF1 - 3.2 Il sistema deve essere in grado di scaricare fogli XML UC6 Non
contenenti le visure catastali degli edifici cercati Soddisfatto
RF1 - 3.3 Il sistema deve essere in grado di estrarre il Foglio XML dai UC6 Parzialmente
documenti firmati p7m scaricati dall’Agenzia delle entrate Soddisfatto
RF1 - 3.4 Il sistema deve essere in grado di salvare i dati estratti dalle UC6 Soddisfatto
tabelle del catasto in database
RF1 - 3.5 Il sistema deve essere in grado di salvare i dati estratti dai UC6 Non
file XML del catasto in database Soddisfatto
RF1 - 4 Il sistema deve essere in grado di visualizzare i risultati dello UC6 Non
scraping del catasto in una finestra modale Soddisfatto
4 ANALISI DEI REQUISITI 23Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
ID Descrizione Fonti Stato
RF1 - 5 Il sistema deve mettere a disposizione dell’utente la UC7 Parzialmente
possibilità di riavviare uno scraping dal catasto già Soddisfatto
completato
RF1 - 6 Il sistema deve poter salvare un’immagine della home page [g] UC1, Soddisfatto
del sito web aziendale UC3
RF1 - 6.1 Il sistema deve poter salvare un’immagine della home page UC1, Soddisfatto
del sito web aziendale su disco UC3
RF1 - 6.2 Il sistema deve poter salvare il percorso dell’immagine della UC1, Soddisfatto
home page del sito web aziendale scaricata all’interno del UC3
database
4.2.2 Requisiti di Qualità
Tabella 7: Tabella di tracciamento dei requisiti di qualità
ID Descrizione Fonti Stato
RQ0 - 1 Ogni componente dello scraping da Google Places API deve Piano di Soddisfatto
essere coperta da test automatici di unità Lavoro
RQ0 - 2 Ogni componente dello scraping dal sito web aziendale deve Piano di Soddisfatto
essere coperta da test automatici di unità Lavoro
RQ1 - 1 Ogni componente deve contenere al proprio interno dei Decisione Soddisfatto
commenti di documentazione in stile PyDoc Interna
RQ1 - 2 La copertura del codice da parte dei test deve essere Decisione Soddisfatto
superiore al 75% Interna
RQ2 - 1 Ogni componente dello scraper del catasto deve essere Piano di Non
coperto da test automatici di unità Lavoro Soddisfatto
RQ2 - 2 Ogni componente deve essere coperta da test automatici di Piano di Parzialmente
integrazione Lavoro Soddisfatto
RQ2 - 3 I test automatici del sistema creato devono integrarsi nella Piano di Soddisfatto
suite di test esistente in Ayako Lavoro
4 ANALISI DEI REQUISITI 24Sviluppo di strumenti di web scraping per il miglioramento dei processi di data enrichment
4.2.3 Requisiti di Vincolo
Tabella 8: Tabella di tracciamento dei requisiti di vincolo
ID Descrizione Fonti Stato
RV0 - 1 Il sistema deve mettere a disposizione degli endpoint [g] REST Piano di Soddisfatto
per il web scraper Lavoro
RV0 - 1.1 Il sistema deve mettere a disposizione un endpoint REST per Piano di Soddisfatto
un sottoinsieme delle normali operazioni CRUD [g] sui Lavoro
risultati dello scraping tramite UUID [g]
RV0 - 1.1.1 Il sistema deve mettere a disposizione un endpoint REST per Piano di Soddisfatto
il recupero dei risultati dello scraping tramite UUID Lavoro
RV0 - 1.1.2 Il sistema deve mettere a disposizione un endpoint REST per Piano di Soddisfatto
la cancellazione dei risultati dello scraping tramite UUID Lavoro
RV0 - 1.1.3 Il sistema deve mettere a disposizione un endpoint REST per Piano di Soddisfatto
l’aggiornamento manuale dei risultati dello scraping tramite Lavoro
UUID
RV0 - 1.2 Il sistema deve mettere a disposizione un endpoint REST per Piano di Soddisfatto
un sottoinsieme delle normali operazioni CRUD [g] sui Lavoro
risultati dello scraping tramite UUID del cliente
RV0 - 1.2.1 Il sistema deve mettere a disposizione un endpoint REST per Piano di Soddisfatto
il recupero dei risultati tramite UUID del cliente Lavoro
RV0 - 1.2.2 Il sistema deve mettere a disposizione un endpoint REST per Piano di Soddisfatto
la cancellazione dei risultati tramite UUID del cliente Lavoro
RV0 - 1.3 Il sistema deve mettere a disposizione un endpoint REST per Piano di Soddisfatto
l’avvio della procedura di scraping tramite UUID del cliente Lavoro
da ricercare
RV0 - 2 L’architettura deve essere costruita facendo uso di Python 3.5 Decisione Soddisfatto
Interna
RV0 - 3 L’architettura deve essere costruita facendo uso di Django 1.9 Decisione Soddisfatto
Interna
RV1 - 1 Il sistema deve mettere a disposizione un endpoint REST per Piano di Soddisfatto
l’avvio della procedura di scraping degli omonimi catastali, Lavoro
data la ragione sociale
RV1 - 2 Il sistema deve mettere a disposizione un endpoint REST per Piano di Soddisfatto
il recupero degli omonimi catastali scaricati, data la ragione Lavoro
sociale
4 ANALISI DEI REQUISITI 25Puoi anche leggere
