Analisi dei requisiti e specifiche tecniche
a cura di Antonio Candiello1
DIPARTIMENTO
DI
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
SCIENZE AMBIENTALI,
INFORMATICA
E
STATISTICA
Deliverable D1 per l’Unità Complessa eGovernment, Direzione Sistema
Informatico, Regione Veneto, Rif. Progetto “SmeD”.
Task #1: Ideazione, definizione e specifica del sistema tecnologico SmeD.
Analisi dei requisiti del sistema SmeD. Tale analisi potrà costituire la base per
l’eventuale predisposizione di un Bando di Concorso del sistema di produzione..
Griglia (storica) di approvazione (nominativo, data e firma):
Revisioni
Descrizione
1.0 del 30/06/2013
Prima emissione
Emissione
Validazione
Accettazione
Approvazione
Antonio Candiello
Agostino Cortesi
Antonino Mola
Andrea Boer
1
In coerenza con i rispettivi obiettivi didattici connessi alle tesi di laurea hanno collaborato: Antonio De
Faveri e Massimo Stefani – sperimentazione e validazione indicatori ex webbots & adapters; Stefano
Garavello, Eric Boscaro.
Via Torino 155
30172 Venezia Mestre
Italy
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Indice
Executive Summary................................................................................................................3
Glossario.....................................................................................................................................4
1
Analisi del Sistema..............................................................................................................6
1.1
2
3
4
Processi e fasi del ciclo di innovazione.......................................................................7
1.1.1
Vincoli di funzionamento dei moduli software...................................................9
1.1.2
PLAN, ACT: modulo “Policy Manager” ............................................................9
1.1.3
DO: modulo “Engine Manager”........................................................................11
1.1.4
CHECK: modulo “View Manager”...................................................................12
Architettura del Sistema Informativo SmeD.....................................................................14
2.1
Engine Manager ........................................................................................................14
2.2
Policy Manager .........................................................................................................17
2.3
View Manager ...........................................................................................................18
2.4
Data Manager ............................................................................................................25
2.5
Motori ed indicatori: ciclo di vita..............................................................................26
Casi d’Uso .........................................................................................................................34
3.1
Attori del sistema ......................................................................................................34
3.2
Policy Maker – definizione politiche & obiettivi......................................................37
3.3
Utente (View Manager).............................................................................................39
3.4
Analista......................................................................................................................45
3.5
Engine Administrator – gestione motori & istanze...................................................58
3.6
Policy Administrator .................................................................................................71
3.7
View Administrator...................................................................................................73
3.8
Data Administrator....................................................................................................76
Requisiti Funzionali ..........................................................................................................79
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 1 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
5
Unità complessa eGovernment
4.1
Funzioni di Raccolta Dati – Engine Manager ...........................................................79
4.2
Funzioni di Amministrazione....................................................................................82
4.3
Analista......................................................................................................................83
4.4
Funzioni di Output – View Manager.........................................................................86
4.5
Funzioni di Programmazione – Policy Manager ......................................................92
Requisiti Non Funzionali ..................................................................................................95
5.1
Requisiti di Prodotto..................................................................................................95
5.2
Requisiti di Processo .................................................................................................96
5.3
Esterni........................................................................................................................97
5.3.1
Requisiti normativi (Agenda Digitale Italiana).................................................97
6
Cenni alla struttura dati .....................................................................................................99
7
Appendice........................................................................................................................111
7.1
Indicatori Smart Cities ............................................................................................111
7.1.1
Smart Economy – Competitiveness: ability to transform ..............................111
7.1.2
Smart People – Social & Human Capital ......................................................112
7.1.3
Smart Governance – Participation: political strategies & perspectives.......113
7.1.4
Smart Mobility – Transport and ICT ............................................................113
7.1.5
Smart Environment – Natural Resources.....................................................114
7.1.6
Smart Living – Quality of Life.......................................................................114
7.2
Benchmarking Digital Europe.................................................................................115
7.2.1
ICT Sector .......................................................................................................116
7.2.2
Broadband and Connectivity...........................................................................116
7.2.3
ICT usage by Households and Individuals......................................................116
7.2.4
ICT usage by Enterprises ................................................................................118
7.2.5
e-Public Services .............................................................................................118
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 2 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Executive Summary
Nel seguito verrà fornita specifica per un sistema tecnologico denominato Smart
eGovernment Dashboard (SmeD), un “cruscotto intelligente per l’eGovernment”, per rilevare
oggettivamente l’efficacia degli interventi di Regione Veneto con particolare enfasi su eGovernment ed ICT.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 3 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Glossario
AAA: Autenticazione, Accounting ed Autorizzazione.
Adapter: trattasi di automa specializzato per banche dati accessibili su web o con altre
modalità.
BES: Benessere Equo e Sostenibile, si inquadra nel dibattito internazionale sul cosiddetto
“superamento del Pil”, stimolato dalla convinzione che i parametri sui quali valutare il progresso
di una società non debbano essere solo di carattere economico, ma anche sociale e ambientale,
corredati da misure di diseguaglianza e sostenibilità
Bot: vedasi webbot
Crawler: una forma di bot specializzata nel rastrellamento di informazioni. Il termine si
applica generalmente ai bot dei motori di ricerca.
Cruscotto: elemento grafico/dinamica in grado di rappresentare sinteticamente un insieme di
informazioni.
Dashboard: vedasi cruscotto
Data Manager: modulo di SmeD per la gestione dei dati, delle autorizzazioni,
dell’accounting e di eventuali sistemi distribuiti territoriali di supporto.
eGovernment: si intende, il sistema di gestione digitalizzata per i servizi della Pubblica
Amministrazione. Con l’intento di gestire i procedimenti con sistemi informatici con migliore
efficienza ed efficacia.
Engine Manager: modulo di SmeD per la gestione dei motori (engines).
Engine: vedasi motore
ICT: Information & Communication Technology, tecnologie dell’informazione e della
comunicazione.
KPI: Key Performance Indicator, indicatori principali di prestazione
MDI: Multiple Devices Interface, sistema di interfacce adattabili a diverse periferiche.
Motore: un motore (engine) è un webbot, crawler, spider o adapter. O anche un sottosistema
per la somministrazione automatizzata di questionari (survey).
PDCA (ciclo di Deming): il ciclo che include le fasi: Plan, Do, Check Act
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 4 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Policy Manager: modulo di SmeD per la gestione delle Politiche e correlati Azioni e
Progetti.
Scheduler: componente software che gestisce la pianificazione
SmeD: Smart eGovernment Dashboard, un “cruscotto intelligente per l’eGovernment”, per
rilevare oggettivamente l’efficacia degli interventi di Regione Veneto con particolare enfasi su eGovernment ed ICT.
Spider: una forma di bot in grado di navigare autonomamente sugli hyperlinks (“ragno” che
si muove sulla ragnatela del world wide web) al fine di ricercare le informazioni desiderate.
Use Case: vedasi casi d’uso
View Manager: modulo di SmeD per la gestione delle visualizzazioni (views).
Webbot: trattasi della forma semplice di automa (bot) che naviga il web. Il webbot è in grado
di estrarre ripetutamente dati da una fonte web con un meccanismo iterativo.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 5 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
1 Analisi del Sistema
La collaborazione DAIS/ACADIA con Regione Veneto prevede l’ideazione, la definizione e
la specifica di un sistema tecnologico denominato Smart eGovernment Dashboard (SmeD), che
richiama l’idea di un “cruscotto intelligente per l’eGovernment”, per rilevare oggettivamente
l’efficacia degli interventi di Regione Veneto con particolare enfasi su e-Government ed ICT.
Il Sistema SmeD dovrà essere lo strumento tecnologico alla base del processo di
eGovernment Intelligence. Secondo tale processo, la Pubblica Amministrazione (PA) potrà
adottare una specifica declinazione del modello PDCA di Deming applicato alle politiche di
intervento territoriale della PA (cfr. Figura 1).
Plan
Act
Do
Check
Definizione
Intervento
Verifica
Riesame
Politiche Locali
per l’Innovazione
in ambito ICT
I Progetti di
Innovazione ICT
hanno inizio
Analisi di Impatto
dei Progetti di
Innovazione ICT
Riesame delle
Politiche di
Innovazione ICT
Targeting
Monitoraggio
Analisi
Scelta Indicatori e
definizione obiettivi
programmati
Misurazione degli
Indicatori di
Innovazione ICT
Geovisualizzazione
e Analisi Statistica
dei dati
Valutazione
Identificazione dei
punti critici
Figura 1 – Il modello PDCA di Deming è alla base del processo di gestione degli indicatori di SmeD.
Il sistema di produzione, totalmente gestibile in modalità cloud computing, dovrà consentire
un’appropriata qualificazione e quantificazione di parametri territoriali socio-economici
(indicatori statistici classici) ma anche dei valori ambientali e di mobilità ove disponibili
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 6 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
(indicatori smart cities). La raccolta degli indicatori rilevanti potrà avvenire per via automatica
(via webbot / scrapers) e semi-automatica (via estrattori / wrapper), con la possibilità di
completare i dati ove necessario con campagne di indagine focalizzate. Gli indicatori, disponibili
esternamente in open data, dovranno essere rappresentati su diverse dimensioni di analisi e
messi a relazione georeferenziata con il territorio al fine di evidenziare il rapporto esplicito con
i progetti di innovazione e le aree da questi interessate.
L’analisi dei requisiti e le specifiche potranno consentire l’eventuale predisposizione di un
bando di concorso per le fasi di realizzazione, che prevedono progettazione tecnica,
realizzazione e test dello stesso e messa a disposizione finale della Regione Veneto del sistema
in produzione. Questo documento ha proprio questo obiettivo.
1.1
Processi e fasi del ciclo di innovazione
SmeD deve dare visibilità e trasparenza al ciclo di innovazione. Tale sistema dovrà pertanto
prevedere le seguenti fasi (cfr. Figura 2):
•
Gestione delle Politiche e Pianificazione [PLAN],
•
Attuazione Progetti [DO],
•
Monitoraggio [CHECK],
•
Assestamento /Riesame delle Politiche [ACT].
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 7 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
Dai Moduli SW alle Interfacce Utente
Plan
Act
Do
Check
Policy
Manager
Def. Politica
Def. Azioni
Def. Progetti
Def. Obiettivi
Def. Indicatori
Engine
Manager
View
Manager
Policy
Manager
Vis. Politiche
Vis. Progetti
Ver. Obiettivi
Ver. Indicatori
webbots
adapters
surveys
Data & Infrastructure Manager
Figura 2 – Il modello di SmeD ed i connessi moduli software.
Il sistema SmeD potrà quindi rendere operativo il ciclo PDCA secondo la seguente modalità
applicativa:
a) PLAN, gestito dal politico/funzionario tramite l’immissione di politiche, azioni e
progettualità di intervento: Policy Manager – da associarsi a specifici indicatori che
espone l’Engine Manager;
b) DO, per la pianificazione periodica della raccolta dati via webbots, adapters e spiders; i
motori renderanno disponibili al sistema ciascuno uno specifico set di indicatori: Engine
Manager;
c) CHECK, per la gestione delle visualizzazioni dei dati e delle politiche: View Manager;
d) ACT, per la revisione delle politiche di intervento pubblico a fronte delle risultanze di
misura degli indicatori: Policy Manager.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 8 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
1.1.1 Vincoli di funzionamento dei moduli software
Il modello ciclico PDCA è previsto “a regime”. Vi sono però alcuni vincoli nel
funzionamento iniziale dei tre moduli indicati:
View
View Manager
Policy
Manager
View
Engine
Manager
Figura 3 – Interrelazioni dei tre moduli principali di SmeD.
•
È necessario come primo step configurare l’Engine Manager con un set di motori in
grado di esporre una lista di indicatori. I motori andranno quindi lanciati per un periodo
di tempo sufficiente per avere una prima rilevazione oggettiva di tali indicatori (snapshot
run);
•
solo in seguito si potrà dare attivazione al Policy Manager, per definire, oltre a
politiche/progetti/azioni, anche gli indicatori target e per ciascuno dei specifici
obiettivi/soglia, che andranno definiti sulla base della raccolta dati iniziale (prima
approssimazione);
•
a sua volta, il View Manager, nella componente di visualizzazione indicatori ha come
prerequisito il popolamento dei valori numerici degli indicatori. Quindi, potrà essere
eseguito solo dopo lo snapshot run.
1.1.2 PLAN, ACT: modulo “Policy Manager”
Il modulo in oggetto consente l’inserimento di Politiche di intervento per l’innovazione
territoriale. In relazione alle Politiche sarà possibile inserire i Progetti di intervento.
Per ogni Progetto dovrà essere infatti possibile dichiarare ex-ante su quali indicatori questo
potrà incidere, di quanto potrà essere il miglioramento e con che tempi questo potrà avvenire.
Le fasi sono:
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 9 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
Plan
Act
Do
Check
Obiettivi
Indicatori
Territoriali
d’Impatto
Politiche di
Innovazione ICT
Azioni
Polit. 5
Progetti
Azione # 4
Proj. 1
Proj. 2
Proj. 3
Tempo
Milestones
Check Indicatori
Figura 4 – PLAN: Pianificazione delle Politiche.
-
messa in atto delle politiche, azioni e progetti per modalità di interevento, si dà il via
libera al sistema per il monitoraggio tramite indicatori;
-
attivazione dell’Engine Manager per agganciare nuovi motori (webbots / survey /
estrattori) e relativa misurazione degli indicatori correlati.
Gli indicatori saranno quelli per i quali si sono predisposte le logiche di raccolta dati.
Più in dettaglio, avremo:
-
individuazione e dichiarazione politiche, azioni e progetti a seconda delle possibilità
di intervento, definizione delle condizioni finanziarie per la realizzazione delle
politiche e azioni progettuali;
-
dichiarazione degli indicatori (tra quelli esposti dall’Engine Manager) su cui si
interviene; questa dichiarazione è relativa agli ambiti d’azione e specifica quali
indicatori potranno essere associati ai progetti, successivamente si dichiareranno gli
indicatori relativi ai progetti in base agli ambiti;
-
definizione obiettivi strategici della politica in merito alle finalità dell’intervento sul
territorio, definizione delle soglie per ogni indicatore selezionato ed associato ai
singoli progetti;
-
in questa fase interviene il modulo Policy Manager: si inseriscono o si modificano
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 10 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
politiche, azioni, progetti. A questi si associano quindi indicatori, relativi obiettivi e
soglie che si intendono raggiungere nei tempi stabiliti.
Tramite questo Modulo, potrò infine chiudere il ciclo e, a fronte di politiche o progetti non
particolarmente efficaci, consentirà di modificare politiche e progetti e ripartire con il PLAN.
In dettaglio:
-
revisione (Policy Manager) delle politiche sulla base delle valutazioni fatte nelle fasi
precedenti, in maniera tale da poter correggere il piano d’intervento sul territorio se
opportuno per ottenere un raggiungimento degli obiettivi in maniera ottimale;
-
visualizzazione degli indicatori (View Manager).
Plan
Act
Do
Check
Riesame delle Politiche di Innovazione ICT
Azioni
Ok
Ko
Azione # 4
Proj. 1
Politiche di
Innovazione
ca
ifi
od
Progetti
m
Polit. 5
Proj. 2
Proj. 3
Figura 5 – ACT: Riesame delle Politiche.
1.1.3 DO: modulo “Engine Manager”
La fase di pianificazione ed analisi prevede le seguenti funzionalità:
a) visualizzazione delle mappe con la rappresentazione degli indicatori;
b) raccolta dei dati connessi agli indicatori con meccanismi di schedulazione programmata
differenziata a seconda dell’indicatore;
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 11 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
c) inserimento ed attivazione indicatori e connessi script / programmi di raccolta dati (parte
di editing & modifica).
Plan
Act
Do
Check
Indicato
re #1
Indicator
e #1survey #1
data
adapters
online DBs
spiders &
webbots
canale BF
sources
canale AF
bassa frequenza
direct feed
campagne
di indagine
raw web
alta frequenza
keywords
indirect feed
ritorni dei cittadini
su ICT & servizi surveys su ICT
consolidamento progressivo dei dati
DB
indicatori
Figura 6 – DO: attuazione delle politiche.
la raccolta dai dati potrà essere in tre forme:
a) via crawlers/webbots/spiders, ovvero raccogliendo i dati direttamente dal web
“destrutturato”,
b) per tramite di opportuni adattatori (adapters) in grado di interfacciarsi con banche dati
interne regionali o esterne pubbliche (come Eurostat), con la capacità di raccogliere dati
via file di testo, file xml, file pdf, o dati accessibili via web,
c) attraverso la somministrazione e relativa raccolta delle risposte a survey/questionari.
1.1.4 CHECK: modulo “View Manager”
In questo caso la domanda di riferimento è nella sostanza: “quale è l’impatto della Politica sul
territorio?”. Tramite un menu di scelta potrò selezionare la politica da validare, quindi si dovrà
prevedere una efficace di modalità di rappresentazione che metta insieme mappe territoriali e
successioni temporali.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 12 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
In dettaglio:
-
rilevazione sistematica ad intervalli temporali definiti dagli indicatori con l’attributo
periodicità, verifica del raggiungimento delle soglie stabilite per indicatore e progetto,
con la possibilità di verificare gli obiettivi intermedi della politica;
-
visualizzazione degli indicatori secondo diverse modalità: su mappa (georeferenziata),
tramite istogrammi, grafici, diagrammi a torta, a bolle;
-
analisi temporale/trend con strumenti grafici paragonabili a Google Motion Charts;
-
confronti di specifiche selezione degli indicatori tra territori;
-
analisi delle aggregazioni di più comuni;
-
analisi di impatto delle politiche/azioni/progetti sui territori interessati.
Plan
Act
Do
Check
Web Adapters
Webbots & Scrapers
Questionari Online
canale semiautomatico:
canale automatico:
canale manuale/web
Bassa Frequenza (BF),
Alta Affidabilità
Alta Frequenza (AF),
Bassa Affidabilità
Frequenza Personalizzabile,
Media Affidabilità
geo-referenziazione
modello a strati
business
intelligence
dbms indicatori
Figura 7 – CHECK: Controllo delle Politiche.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 13 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
2 Architettura del Sistema Informativo SmeD
Il Sistema Informativo SmeD si dovrà comporre (cfr. Figura 8) di quattro moduli principali:
1.
2.
3.
4.
l’Engine Manager,
il View Manager,
il Policy Manager,
il Data Manager.
View Manager
Multiple Devices Interface
Politiche
Risultati
Policy
Manager
Raccolta
Engine
Manager
Data Manager
DBMS
Infrastruttura (distribuita)
Figura 8 – Architettura del sistema informativo SmeD.
2.1
Engine Manager
L’Engine Manager (cfr. Figura 9) rappresenta il sottosistema che fornisce l’input al sistema
SmeD. Ha natura modulare, sulla base di opportuni “motori” (engines) che possono essere
aggiunti/rimossi. Al suo interno sono presenti uno scheduler per la programmazione
temporizzata delle esecuzioni, un sistema per l’inserimento e la rimozione dei motori, una
console/monitor per la visualizzazione della coda di esecuzioni, e lo “store” di gestione dei
motori stessi.
I motori sono predisposti dagli sviluppatori appoggiandosi ad alcune APIs di SmeD che sono
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 14 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
utilizzate per interagire con l’Engine Manager, che potrà così caricarli, rimuoverli, istanziarli,
sospenderli, riattivarli. Il componente engine loader si occupa di caricare i motori (di fatto,
caricarne il codice sorgente), lanciare una batteria di self-test e metterli a disposizione degli altri
componenti; ove necessario (ad esempio per una sostituzione/evoluzione dei motori), potrà
rimuoverli – disattivando tutte le istanze.
L’engine scheduler è il componente per l’esecuzione pianificata dei motori. Questi vengono
“istanziati” scegliendo determinati parametri di configurazione: un motore potrà generare diverse
istanze differenti a seconda di tali parametri, che determinano in tal modo la natura degli
indicatori che vengono raccolti dalla particolare istanza.
L’engine monitor è un’interfaccia che consente il controllo e la gestione manuale delle istanze
dei motori.
Struttura DB del
motore specifico
start
stop
susp
istanza
engine
loader
sviluppatori
resume
istanza
motore
engine monitor
engine
scheduler
istanza
istanza
motore
motore
indicatori
Figura 9 – Il modulo Engine Manager e sue sottocomponenti.
I motori, quando vengono istanziati, rendono disponibili gli indicatori (i Key Performance
Indicators, indicatori di misura d’impatto/performance), che a questo punto appaiono nel sistema
e divengono selezionabili negli altri moduli del sistema (in particolare: nel Policy Manager di
pianificazione dei desiderati impatti delle politiche nei confronti di specifici indicatori
territoriali). I motori di estrazione degli indicatori sono essenzialmente di tre categorie:
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 15 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
1. adattatori/estrattori (adapters) predisposti per banche dati ufficiali accessibili in
forma libera o riservata via web o attraverso specifiche interfacce accessibili alla
Regione Veneto.
Caratteristiche: alta affidabilità del dato estratto, ma generalmente bassa frequenza
(tipicamente annuale), bassa granularità territoriale, piena copertura territoriale;
2. web-robots ripetitivi (webbots), navigatori del web (spider web), ricercatori di dati a
largo spettro (crawlers), in grado di utilizzare il web indifferenziato quale fonte di dati
sulla cui base costruire indicatori misurabili. L’indicazione è quella di identificare in
questo ambito degli adeguati proxies di dati ufficiali in grado di “estendere” gli
indicatori di cui alla categoria 1 nelle componenti ad alta frequenza e granularità
territoriale fine.
Caratteristiche: medio-bassa affidabilità del dato estratto (con problemi di bias ove
l’aggancio territoriale avvenga per parole chiave con significati nel linguaggio
comune), alta/altissima frequenza, alta granularità del dato, piena copertura territoriale
(al netto del bias sui nomi di località);
3. somministratori (semi-)automatici di questionari online (survey engines), per la
gestione di campagne mirate di raccolta dei ritorni dei cittadini su aspetti specifici.
Tipicamente operanti sul doppio canale email (push) e web (pull).
Caratteristiche: bassissima frequenza, bassa copertura territoriale, alta affidabilità del
dato raccolto.
Tali indicatori, ora disponibili, non sono però a questo punto ancora misurati. La misura
avverrà nel momento in cui lo scheduler completerà l’esecuzione programmata delle relative
istanze oppure quando dall’engine monitor il motore verrà manualmente istanziato e completerà
la sua esecuzione. Gli indicatori saranno inoltre suscettibili di più misure su base temporale, a
seconda della modalità desiderata e programmata nello scheduler. Gli indicatori misurati
vengono denominati “risultati” e quando raggiungono questo stato possono alimentare il View
Manager per la produzione di grafici, mappe e tabelle.
Gli indicatori misurati dall’Engine Manager sono essenzialmente di due categorie:
(a) indicatori ICT che misurano lo stato della digitalizzazione nei territori osservati;
(b) indicatori più generali, in grado di misurare lo stato complessivo dei territori dal punto di
vista sociale, economico, ambientale, etc.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 16 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
Si farà riferimento all’Agenda Digitale Europea e Nazionale, per quanto riguarda gli
indicatori ICT di qui al punto (a); agli indicatori Smart Cities e BES, per quanto riguarda gli
indicatori di cui al punto (b).
Un aspetto di rilievo del sistema SmeD è la possibilità di acclarare le eventuali correlazioni
esistenti tra gli indicatori ICT (come “vettore di cambiamento/evoluzione”) e gli indicatori più
generali del territorio. Queste analisi competono al View Manager, componente “Analisi”.
2.2
Policy Manager
Il Policy Manager (cfr. Figura 10) è il sottosistema che consente agli amministratori pubblici
di mantenere un sistematico monitoraggio sull’effetto delle politiche di intervento ICT sul
territorio.
Il componente policy editor consente l’immissione nel sistema delle politiche di intervento,
quindi, per ciascuna di queste, le azioni e per ogni azione i relativi progetti. Politiche/azioni e
progetti sono interventi pubblici che richiedono risorse economiche e di altra natura per la loro
esecuzione; vi è quindi un significativo interesse nel mantenere un monitoraggio programmato
sull’effetto che queste hanno in termini di impatto misurabile sugli indicatori che misurano lo
stato di salute socio-economico sui territori di destinazione.
policy
editor
politica
progetti
policy obiettivi
goals
azioni
soglie
intervallo
policy scheduler
gestore avvisi /
notifiche
politica
azioni
progetti
obiettivi
politica
azioni
progetti
obiettivi
politica
azioni
progetti
obiettivi
soglie
soglie
intervallo
soglie
soglie
intervallo
soglie
soglie
intervallo
alert
indicatori
Figura 10 – Modulo Policy Manager e sue sottocomponenti.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 17 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
Con il componente policy goals i soggetti che rappresentano la Pubblica Amministrazione
hanno la possibilità di dichiarare/stabilire gli obiettivi e, ove gli indicatori abbiano già uno
storico sufficiente, sarà loro possibile anche stabilire le soglie di raggiungimento desiderate per
gli indicatori disponibili a sistema (esposti dall’Engine Manager). Il Policy Manager per operare
ha la necessità di accedere all’elenco degli indicatori disponibili e misurati che sono esposti
nell’Engine Manager grazie ai motori caricati ed istanziati.
Le immissioni ex ante potranno essere monitorate nel tempo e quindi verificate ex post
durante ed alla fine del periodo di attuazione, grazie al policy scheduler. Il gestore di avvisi e
notifiche potrà allertare i referenti politici ed amministrativi quando gli indicatori conseguano gli
andamenti desiderati (o non desiderati).
2.3
View Manager
Il View Manager (cfr. Figura 11) gestisce le interfacce sul Policy Manager e le viste sui dati
(ex Engine Manager). Anche questo sottosistema è modulare, sulla base del Multiple Devices
Interface (MDI) che dovrà poter gestire le interfacce con i principali apparati PC/Web via
browsers (Windows, Mac, Linux) e tablet/mobile via apps dedicate (IOS, Android, Windows 8).
Il sottosistema view loader consente l’estensibilità del sistema in collegamento con gli
sviluppatori: ogniqualvolta si rende disponibile una nuova interfaccia, questa può venire caricata
ed aggiunta al sistema.
interfacce
remove
view
loader add
Multiple Devices Interface
Politiche
Interfaccia al
gestore delle
politiche
Risultati
Interfaccia di presentazione dei
KPI x mappe/grafici
sviluppatori
Raccolta
Interfaccia al
sistema di raccolta
Analisi
Correlazioni & def. KPI secondari motori/indicatori
Policy
Manager
Engine
Manager
Figura 11 – Modulo View Manager e relative sottocomponenti.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 18 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Il View Manager espone alcuni pannelli, collegati ai tre moduli Policy Manager, Engine
Manager e Data Manager:
-
il pannello Politiche, per l’inserimento, la gestione e la pianificazione di politiche,
azioni, progetti, il collegamento con gli indicatori presenti a sistema e la definizione
delle soglie desiderate di raggiungimento nei tempi stabiliti; tale pannello è gestito
dal politico/funzionario locale ed è supportato da un insieme di meccanismi di alert
automatico; [vedasi: Policy Manager]
-
il pannello Risultati, per la rappresentazione dei dati raccolti dai motori dell’Engine
Manager. Tale pannello dovrà consentire la visualizzazione dei dati in forma grafica
ad istogrammi 2D, 3D, torte, grafici semplici a punti, a linee, a bolle, etc come nei
principali sistemi di Business Intelligence. Dovrà essere possibile una
visualizzazione nel tempo (stile Google Motion Charts), e le viste georeferenziate
dovranno essere supportate con possibilità di assegnare automaticamente gradienti di
texture/colori alle aree visualizzate;
-
il pannello Raccolta, per l’interazione con il sistema di motori gestito dall’Engine
Manager (caricamento e rilascio dei motori, schedulazione, sospensione, stop,
resume, etc). Il sistema dovrà essere multithreading per garantire la massima
flessibilità. E dovrà essere in grado di gestire un elevato numero (migliaia) di motori
senza problemi di interruzione e garantendone la corretta esecuzione programmata
per anni interi; [vedasi: Engine Manager]
-
il pannello Analisi, per consentire agli analisti di rilevare le correlazioni tra gli
indicatori misurati, ovvero tra indicatori specifici ICT ed indicatori generali Smart
Cities, e definire indicatori secondari calcolati in base agli indicatori primari.
2.3.1 Pannello Risultati
Il pannello risultati è sostanzialmente diviso in tre modalità di visualizzazione:
1. Visualizzazione di un indicatore su un gruppo di comuni (da uno o a cinque comuni)
in funzione del tempo,
2. Visualizzazione complessiva, ovvero su tutti i comuni disponibili, di un indicatore
(ad una data scelta),
3. Confronto / benchmark generale tra comuni (su una lista di indicatori).
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 19 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Nel seguito riportiamo un maggiore dettaglio di ciascuna visualizzazione avvalendoci quale
esempio di grafica generata nell’ambiente Google Charts.
Modalità 0: il mio comune
Con questa modalità, sono esposti i dati rilevanti di un solo comune. Indicatori, storico.
Modalità 1: un indicatore su un gruppo di comuni
Dopo aver selezionato un particolare indicatore, sarà possibile scegliere, attraverso un menù
a scelta multipla, una lista di comuni (fino a cinque) di cui si vuole visualizzare l’andamento in
funzione del tempo. Una lista di grafici metteranno in evidenza tale trend in maniera differente
per rendere la visualizzazione più efficace.
Figura 12 - Istogramma
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 20 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Figura 13 - Diagramma ad area
Figura 14 - Diagramma "annotated line"
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 21 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Figura 15 - Diagramma combinato
Figura 16 - Grafica in movimento, primo esempio
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 22 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Figura 17 - Grafica in movimento, secondo caso
Figura 18 - Diagramma in movimento, terzo caso
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 23 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Figura 19 - Diagramma a mappa geo-referenziata
Modalità 2: un indicatore su tutti i comuni
Tale modalità permette di avere un ‘idea complessiva dell’andamento di un indicatore a
scelta, per far ciò verrà visualizzato una mappa più generale (con presenti i valori di tutti i
comuni della regione o di una provincia) con evidenziati i comuni con colori diversi a seconda
dell’andamento dell’indicatore. Sarà inoltre presente una classifica con presenti i comuni ordinati
(in ordine crescente o decrescente) in base al valore dell’indicatore.
Classifica
1. Venezia 25660
2. Verona 22556
3. Treviso 19888
4. Vicenza 18555
5. …
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 24 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
Modalità 3: confronto / benchmark tra 2-3 comuni di più indicatori
Con questa modalità, si potranno confrontare un gruppo ristretto di comuni (fino a 3) sulla
totalità o un sottoinsieme di indicatori.
Per far ciò sarà visualizzata una tabella organizzata in modo tale da avere posti sulle colonne i
comuni e sulle righe invece la lista degli indicatori per poter effettuare un confronto avendo
sottomano direttamente i valori degli indicatori e non una rappresentazioni degli stessi.
Tabella 1 - Benchmark di confronto tra comuni
Reddito Medio
Investimento Banda
Larga
Tasso Disoccupazione
Num_Twit_Elezioni
…
VENEZIA
22225
100000
TREVISO
24555
120000
PADOVA
25651
95000
10%
1536
…
5%
5252
…
8%
3333
…
2.3.2 Pannello Analisi
2.4
Data Manager
Il Data Manager (cfr. Figura 20) si compone invece del database e dell’infrastruttura dati
distribuita di supporto. Si presuppone infatti che il sistema possa essere strutturato in coerenza
con gli ambiti territoriali (province, comuni). In tale modulo sono anche incluse le funzioni di
autenticazione, accounting ed autorizzazione (AAA).
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 25 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
Elaborazione Risultati
Analisi IP
DBMS
Indicatori
& Politiche
bot locali
DB
locale
Analisi IB
Risultati
Misure
bot locali
DB
locale
Indicatori
& Bots
bot locali
DB
locale
Engine Manager
Policy Manager
View Manager
bot locali
DB
locale
Infrastruttura Distribuita di Dati
Autenticazione, Accounting ed Autorizzazioni (AAA)
Figura 20 – Modulo Data Manager e relative sottocomponenti.
2.5
Motori ed indicatori: ciclo di vita
Gli indicatori – ed i motori (bots) che li generano – rappresentano l’elemento centrale attorno
al quale ruota tutto il sistema SmeD. In questa sezione ne verranno illustrate brevemente
proprietà, modalità di utilizzo e transizioni di stato al fine di chiarire gli obiettivi desiderati.
Di seguito (cfr. Figura 21) illustriamo il ciclo di vita dei motori.
Un motore viene sviluppato dagli Engine Developers esponendo un set di APIs predefinito
che consenta a SmeD di gestirne le istanze. Una volta caricato, subisce una serie di test che, se
superati, lo portano nello stato “disponibile”. Sarà quindi l’analista ad attivare, per lo specifico
motore, le desiderate istanze pianificate, che a quel punto passeranno da schedulate ad avviate, in
pausa, fermate a seconda delle necessità del sistema.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 26 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Figura 21 – Diagramma di stato dei motori (bots).
Gli indicatori sono direttamente collegati alle istanze di bots, che li espongono a sistema e
(una volta completate le esecuzioni programmate) li rendono disponibili come valori misurati.
Nei bot “sperimentali” gli indicatori sono correlati a specifiche stringhe di ricerca che
parametrizzano l’istanza del bot.
Attraverso un esempio è possibile comprendere meglio quanto appena descritto. Ipotizziamo
di dover ricercare nel web la partecipazione all’attività politica; ecco dunque che le stringhe
immesse nei vari bot potranno essere: “politica”, “partecipazione politica”, “elezioni”,
“referendum”, “congressi politici”, “assemblee politiche”, “tasso di partecipazione femminile”,
“consiglieri”, ecc, e tutte le ulteriori parole chiave che possono essere utilizzate dall’analista per
ricercare nel web la partecipazione della popolazione all’attività politica. Ciò che si otterrà, alla
fine di questa ricerca, sarà un indicatore costituito dalla somma di tutti gli esiti parametrizzati
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 27 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
prodotti dai vari bot accesi, in modo da ottenere un risultato consistente, pronto per essere
utilizzato e sottoposto ad ulteriori fasi di analisi.
Nel nostro esempio, attraverso opportune statistiche, l’analista unirà tutto ciò che è riuscito ad
estrapolare dai vari bot (ossia quanto sono presenti nel web i parametri ricercati), ed in questo
modo riuscirà ad avere con una certa approssimazione un risultato sulla partecipazione
all’attività politica.
A questo punto possono delinearsi due situazioni, in base al fatto che ci troviamo di fronte ad
un indicatore primario o ad un indicatore derivato, come riportato nelle figure sottostanti:
Nel primo caso (cfr. Figura 22) l’indicatore primario viene a crearsi proprio attraverso il
metodo sopra descritto, ovvero dopo aver lanciato un bot. In questo modo, infatti, una volta che
l’indicatore viene raccolto, deve essere validato dall’analista, se il risultato a cui si è arrivati è
consistente. Nell’esempio a cui facciamo riferimento, questa situazione la possiamo trovare nel
caso in cui abbiamo acceso un bot “elezioni” ed il risultato ottenuto sia conforme con quello
atteso. Nel caso in cui invece il dato raccolto venga invalidato, il dato stesso verrà scartato e si
tornerà alla precedente fase di ricerca tramite webbots.
Successivamente, (se veda sempre la Figura 22), passiamo alla fase di aggregazione dei vari
indicatori validati, in modo da ottenere un indicatore derivato; questo indicatore è costituito
proprio dalla somma dei risultati ottenuti dai vari bot, ognuno dei quali deve essere validato ed
aggregato agli altri. Il risultato a cui andremo incontro sarà, dunque, un indicatore costituito dalla
somma di tutti gli indicatori validati, ottenuti dai vari bot accesi.
Tornando al nostro esempio, l’indicatore derivato sarà la “partecipazione all’attività politica”,
costituito dalla somma dei vari bot “politica”, “partecipazione politica”, “elezioni”,
“referendum”, “congressi politici”, “assemblee politiche”, “tasso di partecipazione femminile”,
“consiglieri”, ecc. dopo che questi sono stati validati.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 28 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Figura 22 – Diagramma di stato: indicatore primario.
Nel secondo caso (cfr. Figura 23) viene definita ed evidenziata la creazione di un indicatore
derivato; come si può vedere dal diagramma di stato, e come precedentemente ribadito,
l’indicatore derivato altro non è che l’aggregazione degli indicatori primari validati. Una volta
completata l’aggregazione degli indicatori primari, l’uscita del nuovo indicatore derivato
venutosi a creare si allaccia alla validazione dell’indicatore derivato del primo diagramma.
Ultimata questa operazione, l’indicatore ottenuto passa all’analista che continuerà la sua analisi.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 29 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Figura 23 – Diagramma di stato: indicatore derivato.
La fase successiva nella “vita” di questi indicatori, sarà quella della visibilità: infatti l’analista
dovrà rendere visibile all’utente finale ciò che è stato creato e prodotto, attraverso apposite
interfacce che rendano facilmente consultabile il risultato ricercato ed ottenuto.
Accanto a tutte queste fasi della “vita” degli indicatori, è necessario ricordare ed evidenziare
quali sono le caratteristiche che gli indicatori stessi devono avere, così come gli eventuali limiti e
le eventuali complessità a cui si va incontro nella gestione del processo sopra descritto.
Una caratteristica fondamentale degli indicatori, a cui bisogna dare notevole importanza, è il
territorio. Gli indicatori, durante tutto il loro percorso, e soprattutto durante la prima fase di
ricerca nel web attraverso i bot, devono essere georeferenziati: devono cioè essere estrapolati
attraverso particolari impostazioni che consentano di poter visualizzare i risultati in aree ben
distinte e facilmente intuibili (ad esempio regioni, province, comuni, ecc.).
Una seconda caratteristica fondamentale è quella del tempo. Soprattutto l’analista e tutti
coloro che entrano in contatto con gli indicatori stessi, devono tener conto della variazione degli
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 30 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
indicatori nel tempo.
E’ proprio per questo che tutto il progetto è basato non su semplici rilevazioni istantanee,
bensì su rilevazioni perduranti nel tempo (settimane, mesi, trimestri, anni, ecc.) in modo da poter
analizzare i dati raccolti in base al loro trend, per poter osservare e valutare come essi cambiano,
e cercare di capire i motivi di queste variazioni temporali.
Inoltre risulta di vitale importanza riuscire ad avere uno storico nel database, per tutte le
analisi da effettuare, e la pianificazione di nuove politiche da attuare.
Una terza caratteristica, non meno importante rispetto alle altre, è la classificabilità. Gli
indicatori, per una questione di efficacia ed efficienza nel loro utilizzo devono essere
classificabili. Questa condizione fa si che l’analista, prima di un’accensione di un bot, individui
il genere di indicatore che sta cercando: le categorie su cui ci siamo maggiormente soffermati
sono le seguenti.
Indicatori BES (Bilancio Equo Sostenibile). Il progetto per misurare il benessere equo e
sostenibile – nato da un’iniziativa del Cnel e dell’Istat – si inquadra nel dibattito internazionale
sul cosiddetto “superamento del Pil”, stimolato dalla convinzione che i parametri sui quali
valutare il progresso di una società non debbano essere solo di carattere economico, ma anche
sociale e ambientale, corredati da misure di diseguaglianza e sostenibilità.
Vengono forniti una serie di “macroindicatori” all’interno dei quali si sviluppano una
moltitudine di altri semplici indicatori che, secondo appositi studi, garantiscono una notevole
copertura di “tutto ciò che conta davvero per la popolazione. Questi macroindicatori sono:
Salute, Istruzione e Formazione, Lavoro e conciliazione tempi di vita, Benessere Economico,
Relazioni Sociali, Politica ed Istituzioni, Sicurezza, Benessere Soggettivo, Paesaggio e
Patrimonio Culturale, Ambiente, Ricerca e Innovazione, Qualità dei servizi.
Indicatori Smart Cities: in questo caso invece vengono fornite sei categorie di
macroindicatori, suddivisi al loro interno in una moltitudine di indicatori, con un elevato grado di
granularità. Le sei categorie sono: Smart Economy, Smart People, Smart Governance, Smart
Mobility, Smart Environment, Smart Living.
Al fine di adottare efficacemente questi indicatori è necessario un duplice adattamento in
termini di:
-
granularità: applicare gli indicatori ai comuni veneti (che non sono small-medium
cities),
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 31 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
-
frequenza: rilevare gli indicatori a periodicità ravvicinate (mese / settimana, fino al
giorno).
Smart People
En
vir
on
me
nt
y
9 KPIs
9 KPIs
y
ilit
Smart Living
Sm
art
b
Mo
art
Sm
KPIs
Smart City
12 KPIs
om
Sm
art
Go
v
on
Ec
art
Sm
9 KPIs
ern
an
ce
15 KPIs
20 KPIs
2
Figura 24 – Le sei famiglie dei 74 indicatori Smart Cities.
Accanto alle precedenti due categorie di macroindicatori, troviamo tutta una serie di altri
indicatori, parametri e statistiche, complementari o sostitutivi di quelli appena elencati.
Per reperire questi indicatori risultano di notevole importanza le fonti di dati: esse sono
innumerevoli (ad esempio: Istat, Arpav, Camere di Commercio, dati relativi ai singoli comuni,
ecc.) e spetta all’analista riuscire ad individuarle con tempestività ed efficacia, ai fini della
ricerca.
Passando ora ad analizzare una criticità di cui è necessario tener conto nell’affrontare tutto il
processo di analisi, ossia la stabilità degli indicatori, si può notare come essa sia strettamente
correlata alla variabile temporale sopra descritta.
Per stabilità degli indicatori intendiamo quella particolare situazione in cui i bot “modificano”
il loro stato d’essere.
Attraverso un esempio possiamo spiegare meglio la criticità in questione: supponiamo di
2
Vedasi: “Smart cities Ranking of European medium-sized cities”, Ottobre 2007, www.smart-cities.eu.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 32 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
effettuare una particolare istanza nel web, attraverso webbot, per un periodo di tempo di circa un
anno; nel caso in cui io decida di bloccare l’istanza stessa, per un periodo di tempo di sei mesi, il
problema si manifesta quando io, trascorsi i sei mesi, voglio riprenderla e mandarla nuovamente
in esecuzione.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 33 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
3 Casi d’Uso
In questa sezione sono riportati gli use case che esprimono le funzioni ed i servizi offerti da
un sistema, così come sono percepiti e utilizzati dagli attori che interagiscono col sistema stesso
del sistema SmeD.
3.1
PM
Attori del sistema
Policy Maker (PM)
È responsabile della definizione delle politiche e conseguenti azioni e progetti.
Definisce e (in collaborazione con i Policy Administrators) mantiene controllati gli
obiettivi e le corrispondenti soglie di raggiungimento pianificate per gli indicatori.
UV
Utente (Views, UV)
\
Rappresenta l’attore più comune per SmeD – si tratta di coloro che interagiscono con
il sistema per visualizzare gli indicatori per ambito territoriale e verificare il
raggiungimento degli obiettivi prestabiliti.
AD
Analista (Dati, AD)
È un ruolo “centrale” che si occupa di gerarchizzare e gestire gli indicatori che vengono
esposti dai motori “istanziati”.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 34 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
EA
Unità complessa eGovernment
Engine Administrator (EA)
È il ruolo che si occupa di gestire il sistema dei motori (bots, survey engines,
adapters) – inserimenti, rimozioni, manutenzione. Trattasi di un ruolo tecnico che
lavora in interazione con gli Engine Developers (sviluppatori dei motori).
PM
Policy Administrator (PA)
Gestisce i sottosistemi relativi agli avvisi e mantiene il monitoraggio delle politiche /
azioni / progetti.
VA
View Administrator (VA)
È il ruolo che si occupa di gestire il sistema delle viste – inserimenti, rimozioni,
manutenzione. Trattasi di un ruolo tecnico che lavora in interazione con i View
Developers (sviluppatori delle viste).
VA
Data Administrator (DA)
È il ruolo che si occupa di gestire il database. Sono di competenza del DA anche
autenticazione, autorizzazioni, accounting (AAA).
ED
Engine Developer (ED)
È responsabile dello sviluppo dei motori (bots, survey engines, adapters). Sviluppa i
motori seguendo lo schema di APIs prestabilite che espongono metodi per il
funzionamento dei motori all’interno di SmeD.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 35 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
View Developer (VD)
VD
È responsabile dello sviluppo delle viste adatte a specifiche piattaforme (browser web,
tablet, smartphones, …). Sviluppa le viste mantenendo operativo un set di APIs
minime prestabilite per il funzionamento delle viste in SmeD.
Tabella 2 – Tabella autorizzazioni per ruolo.
Sigla Ruolo ↓ / Modulo →
Policy
Manager
Engine
Manager
View
Manager
PM
Policy Maker
X
X
UV
Utente Viste
X
X
AD
Analista Dati
X
X
EA
Engine Administrator
X
X
PM
Policy Administrator
X
VA
View Administrator
X
DA
Data Administrator
ED
Engine Developer
VD
View Developer
Data
Manager
X
X
X
X
X
X
X
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 36 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
3.2
Unità complessa eGovernment
Policy Maker – definizione politiche & obiettivi
UC1. Definizione gerarchia Politiche/Azioni/Progetti
Scope: Policy Editor
Goal: inserimento a sistema di una Politica di cui valutare poi l’impatto, insieme con le
conseguenti Azioni (con qualificatori di spesa, e data di inizio) e per ciascuna azione di Progetti
(con indicazione di tempi di attuazione e milestones attese in date specificate).
Dipendenze: la valutazione dell’impatto richiederà in seguito il collegamento con gli
indicatori esposti dall’Engine Manager.
Attori: Policy Maker
Precondizioni: Nessuna
Trigger: L’utente seleziona la voce “definizione politica”.
Descrizione:
a) si presenta un form con una lista di caselle di testo (nome, descrizione) ed una lista di
parametri ed indicatori;
b) compilando i form e scegliendo i parametri della lista l’utente definisce politica, azioni e
progetti.
Postcondizioni: politica, azioni e progetti sono stati definiti.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 37 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
UC2. Definizione Obiettivi/Soglie
Scope: Policy Editor
Goal: In relazione ad una gerarchia Politica/Azioni/Progetti, il policy maker definisce gli
obiettivi (qualitativi) e per ciascuno le soglie corrispondenti ad un determinato insieme di
indicatori che siano già presenti nel sistema. quali indicatori compongono le politiche e gli
obiettivi, definisce la base territoriale sulla quale vengono raccolti i dati e la frequenza di
aggiornamento degli stessi
Dipendenze: Nessuna
Attori: Policy Maker
Precondizioni: E’ stato definita una gerarchia politica/azioni/progetti
Trigger: L’utente preme sul tasto “Obiettivi” dalla schermata principale
Descrizione:
a) l’utente compila i form che definiscono i parametri;
b) seleziona gli indicatori dalla lista;
c) in tal modo definisce le metriche che riguardano una politica.
Postcondizioni: Il Policy maker definisce le metriche di un progetto o politica
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 38 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
3.3
Unità complessa eGovernment
Utente (View Manager)
UC3. Selezione comune
Scope: View Manager
Goal: L’utente sceglie il comune di cui vuole avere le informazioni
Dipendenze: Nessuna
Attori: Utente
Precondizioni: Nessuna
Trigger: Dal menu a scelta multipla l’utente seleziona il comune desiderato
Descrizione:
a) l’utente sceglie il comune desiderato da una lista oppure effettuando una ricerca;
b) l’utente viene indirizzato sulla pagina Selezione Indicatori.
Alternative: Nessuna
Postcondizioni: L’utente visualizza la lista di indicatori
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 39 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
UC4. Selezione Indicatori
Scope: View Manager
Goal: L’utente sceglie uno o più indicatori di cui vuole avere le informazioni
Dipendenze: Nessuna
Attori: Utente
Precondizioni: Avviene dopo che l’utente sceglie il comune
Trigger: Dal menu a scelta multipla l’utente seleziona gli indicatori desiderati
Descrizione:
a) l’utente sceglie gli indicatori desiderati dalla lista;
b) l’utente viene indirizzato sulla pagina di Visualizzazione.
Alternative: Nessuna
Postcondizioni: L’utente visualizza la lista degli indicatori presenti per quel comune
UC5. Visualizza Informazioni
Scope: View Manager
Goal: L’utente visualizza le informazioni su comune ed idicatori scelti
Dipendenze: Nessuna
Attori: Utente
Precondizioni: Avviene dopo che l’utente sceglie comune ed indicatori
Trigger: Dal menu a scelta multipla l’utente seleziona gli indicatori desiderati
Descrizione: Dopo aver scelto comune ed indicatori vengono visualizzate sullo schermo le
informazioni sul comune e sugli indicatori scelti organizzate su una linea temporale.
Alternative: Cambia il metodo di visualizzazione, Cambia l’intervallo di tempo,
Confronta con altri comuni
Postcondizioni: L’utente visualizza le informazioni come richiesto
UC6. Cambia metodo di visualizzazione
Scope: View Manager
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 40 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Goal: L’utente può cambiare il metodo di visualizzazione
Dipendenze: Nessuna
Attori: Utente
Precondizioni: Avviene dopo il caso d’uso “Visualizza informazioni”
Trigger: Dalla schermata “Visualizza informazioni”l’utente preme sul tasto “cambia”
Descrizione:
a) l’utente preme sul tasto;
b) la rappresentazione delle informazioni cambia tra istogramma, grafico a barre,
rappresentazione georeferenziata (cartina geografica con colori diversi).
Postcondizioni: L’utente cambia il metodo di visualizzazione
UC7. Cambia intervallo temporale
Scope: View Manager
Goal: L’utente cambia l’intervallo di tempo dei dati scelti
Dipendenze: Nessuna
Attori: Utente
Precondizioni: Avviene dopo il caso d’uso “Visualizza informazioni”
Trigger: L’utente opera sui campi “inizio” e “fine”
Descrizione:
a) l’utente modificando i valori di inizio fine, o sullo slide;
b) l’intervallo di tempo sul quale vengono presi i dati da rappresentare viene modificato.
Postcondizioni: L’utente cambia l’intervallo temporale
UC8. Confronto
Scope: View Manager
Goal: L’utente sceglie di confrontare il comune scelto con uno o più comuni
Dipendenze: Nessuna
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 41 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Attori: Utente
Precondizioni: Avviene dopo il caso d’uso “Visualizza informazioni”
Trigger: L’utente sceglie un altro comune dalla lista
Descrizione:
1. L’utente sceglie uno o più comuni dalla lista
2. la modalità di visualizzazione si modificherà in modo da aggiungere i comuni scelti
per effettuare il confronto
Postcondizioni: L’utente aggiunge comuni alla visualizzazione
UC9. Esporta i dati
Scope: View Manager
Goal: L’utente sceglie di esportare su foglio elettronico i dati visualizzati
Dipendenze: Nessuna
Attori: Utente
Precondizioni: Avviene dopo il caso d’uso “Visualizza informazioni”
Trigger: L’utente preme sul tasto “esporta”
Descrizione: Premendo sul tasto esporta sarà possibile esportare i dati al momento visualizzati
in un file di tipo foglio elettronico sul client dell’utente per una sua successiva fruizione
Postcondizioni: L’utente esporta i dati correttamente
UC10. Impostazione “sotto controllo”
Scope: View Manager
Goal: L’utente sceglie di settare alcuni indicatori come “sotto controllo”
Dipendenze: Nessuna
Attori: Utente
Precondizioni: Avviene dopo il caso d’uso “Visualizza informazioni”
Trigger: L’utente preme sul tasto “sotto controllo”
Descrizione:
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 42 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
1. Pressione sul tasto “sottocontrollo”
2. Viene richiesto in un form l’indicazione di una soglia numerica
3. Indicatore comune e soglia vengono impostati come “sotto controllo”
Postcondizioni: L’utente imposta un indicatore “sotto controllo”
UC11. Impostazione “preferiti”
Scope: View Manager
Goal: L’utente sceglie di settare alcuni indicatori come “preferito”
Dipendenze: Nessuna
Attori: Utente
Precondizioni: Avviene dopo il caso d’uso “Visualizza informazioni”
Trigger: L’utente preme sul tasto “preferito”
Descrizione: Premendo sul tasto l’utente imposterà le informazioni visulizzate come preferito e
potrà raggiungerle rapidamente dalla schermata principale
Postcondizioni: L’utente imposta un indicatore “preferito”
UC12. Modifica “preferiti”
Scope: View Manager
Goal: L’utente sceglie di modificare un indicatore precedentemente settato come “preferito”
Dipendenze: Nessuna
Attori: Utente
Precondizioni: Nessuna
Trigger: L’utente preme sul tasto “gestione preferiti”
Descrizione: l’utente potrà modificare e/o rimuovere gli indicatori impostati precedentemente
come preferiti
Postcondizioni: L’utente modifica un “preferito”
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 43 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
UC13. Modifica “sotto controllo”
Scope: View Manager
Goal: L’utente
sceglie di modificare un indicatore precedentemente settato come “sotto
controllo”
Dipendenze: Nessuna
Attori: Utente
Precondizioni: Nessuna
Trigger: L’utente preme sul tasto “gestione sotto controllo”
Descrizione: l’utente potrà modificare e/o rimuovere gli indicatori impostati precedentemente
come “sotto controllo”
Postcondizioni: L’utente modifica un “sotto controllo”
UC14. Visualizza “avvisi”
Scope: View Manager
Goal: L’utente sceglie di visualizzare gli avvisi del sistema
Dipendenze: Nessuna
Attori: Utente
Precondizioni: Nessuna
Trigger: L’utente preme sul tasto “avvisi” dalla schermata principale
Descrizione: l’utente visualizza gli avvisi riguardanti i “sotto controllo” impostati
precedentemente o altre modifiche nel sistema
Postcondizioni: L’utente visualizza gli avvisi
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 44 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
3.4
Unità complessa eGovernment
Analista
UC15. Acquisire dati da Motori / Basi di dati.
Goal: Poter fornire all’Analista la possibilità di acquisire dati dal Web tramite motori
(istanziabili dall’Engine Manager) come spiders, crawlers, adapters per banche dati.
Attori: Analista.
Precondizioni: Devono essere già presenti dei motori che devono essere già stati personalizzati
e istanziati dall’Engine Administrator grazie all’appoggio dell’Analista che ne fornisce gli
indicatori per personalizzarlo (Vedi caso d’uso Personalizzare Motori).
Trigger: Richiesta da parte del Policy maker di aggiornare i dati relativi ad una o più politiche.
Descrizione:
a) l’analista si autentica tramite form su pagina Web;
b) l’analista accede alla pagina Web dei risultati dei Motore istanziati e schedulati;
c) in alternativa può acquisire dati da una banca dati tramite query.
Alternative:
1) L’analista non riesce ad autenticarsi
2) L’analista non ha dati sui motori (perché non istanziati)
3) Non può acquisire dati da Banche dati (perché non ve ne sono o sono irragiungibili)
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 45 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Postcondizioni: L’analista è ora in grado di elaborare i dati acquisiti.
UC16. Personalizzare Motori (Specificare come raccogliere i dati).
Goal: Permettere all’Engine Administrator di istanziare nuovi motori definendone i criteri di
ricerca dati tramite l’uso di indicatori primari.
Attori: Analista (e in parte l’Engine Administrator che istanzia i motori).
Precondizioni: Deve essere già presente un motore da poter personalizzare e istanziare e dei
requisiti per la raccolta dati.
Trigger: Istanziazione di un nuovo motore che richiede una personalizzazione
Descrizione:
a) L’analista si informa sul funzionamento del motore da personalizzare.
b) L’analista definisce (o raccoglie) dei requisiti per la raccolta dati da associare al Motore.
c) L’analista insieme all’Engine Administrator istanziano il motore dall’apposita pagina Web di
gestione dello scheduling dei motori.
Alternative:
1) L’analista non ha motore da personalizzare.
2) L’analista non ha requisiti per la raccolta dati.
Postcondizioni: L’analista è ora in grado di acquisire dati da motori aventi dei criteri di ricerca
più accurati.
UC17. Definire i requisiti per la raccolta dati.
Goal: Acquisire dei criteri di ricerca per personalizzare i motori (o almeno quelli che possono
essere personalizzabili).
Attori: Analista.
Precondizioni: Avere una politica di cui si vogliono avere delle informazioni inerenti o
acquisire nuovi dati da aggregare a quelli già esistenti, sempre tramite motori.
Trigger: Personalizzare un motore da istanziare.
Descrizione:
a) l’analista fa una analisi sui dati che devono essere raccolti.
b) l’analista sceglie un Motore da personalizzare e istanziare.
c) nel caso, l’analista adatta i propri requisiti di ricerca alla struttura del motore da
personalizzare.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 46 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
d) l’analista crea o sceglie degli indicatori primari da utilizzare nel motore.
Alternative:
1) l’analista non ha abbastanza informazioni per definire tale requisiti;
2) l’analista non ha motori da personalizzare.
Postcondizioni: L’analista è ora in grado di personalizzare un nuovo motore.
UC18. Accesso ai dati.
Goal: Permettere all’analista di accedere ai dati contenuti nella banca dati della struttura dati del
sistema (Struttura dei Motori personalizzati, ecc...) e a quella relativa ai dati raccolti (ed, nel
caso, elaborati).
Attori: Tutti gli attori del sistema (ognuno con i propri diritti), ma in particolar modo
all’Analista per poterli poi elaborare.
Precondizioni: Avere entrambe le banche dati già popolate.
Trigger: Effettuare una modifica, un inserimento o una lettura sui dati.
Descrizione:
a) l’analista si autentica tramite form su pagina Web;
b) l’analista potrà scegliere a quale base di dati accedere;
c) l’analista accederà al contenuto dei dati tramite query (visuali E NON?).
Alternative:
a’) l’analista non riesce ad autenticarsi;
b’) non esistono basi di dati nel sistema;
c’1) le basi di dati sono vuote;
c’2) le basi di dati sono irraggiungibili;
c’3) non è stato creato un sistema di gestione delle query.
Postcondizioni: L’analista può elaborare e classificare i dati.
UC19. Elaborazione dei dati
Goal: Permettere all’analista di elaborare (e salvare?) i dati a cui ha acceduto (vedi caso d’uso
precedente).
Attori: Analista.
Precondizioni: Aver già acceduto ai dati (vedi caso d’uso precedente).
Trigger: Effettuare una elaborazione dettata da una intenzione dell’Analista o del Policy Maker.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 47 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Descrizione:
a) l’analista accederà ai dati (vedi caso d’uso precedente);
b) l’analista potrà gestire gli indicatori (vedi più avanti il caso d’uso);
c) l’analista potrà aggregare i dati raccolti su base territoriale (vedi più avanti il caso d’uso);
d) l’analista potrà validare/invalidare i dati raccolti (vedi più avanti il caso d’uso).
Alternative:
a’) l’analista non può accedere ai dati;
b’) l’analista non ha le informazioni per gestire gli indicatori;
c’) l’analista non ha dati da aggregare su base territoriale;
d’) non vi sono motori che acquisiscono dati da poter validare o invalidare.
Postcondizioni: Il sistema sarà molto più evoluto in seguito alle elaborazioni dati dell’analista.
UC20. Gestione degli indicatori.
Goal: Permettere all’analista di creare e gestire degli indicatori che sono una delle componenti
fondamentali del sistema. Infatti gli indicatori servono sia per rappresentare l’andamento di una
politica, sia come chiavi di ricerca per i Motori.
Attori: Analista.
Precondizioni: Avere una o più politiche o Motori su cui gestire gli indicatori.
Trigger: Gestire gli indicatori per mantenere aggiornati, mantenibili e tracciabili i dati raccolti
ed elaborati.
Descrizione:
a) l’analista gestirà nuovi o vecchi indicatori per rappresentare una nuova politica o una già
esistente;
b) in alternativa a ciò, l’analista gestirà nuovi o vecchi indicatori per definire delle chiavi di
ricerca più raffinate per nuovi Motori (o Motori già esistenti).
Alternative:
a’) l’analista non ha politiche da rappresentare tramite indicatori;
b’) l’analista non ha Motori su cui definire degli indicatori.
Postcondizioni: Con la definizione e la gestione di nuovi indicatori sarà possibile rappresentare
nel dettaglio e in maniera più accurata le politiche adottate dai vari Policy Maker, oltre che a
fornire all’Engine Administrator dei criteri di ricerca per ogni qualvolta esso deve istanziare un
nuovo Motore.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 48 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
UC21. Ridefinire la gerarchia di un indicatore.
Goal: In vista di una modifica (legata alla politica o ad un motore) è possibile ridefinire un
indicatore come primario o derivato.
Attori: Analista.
Precondizioni: Avere già degli indicatori.
Trigger: Una evoluzione del sistema, di uno o più indicatori, o di una o più politiche.
Descrizione:
a) all’analista viene notificato un cambio di politica o una nuova politica dal Policy Maker;
b) in alternativa all’analista viene notificata la modifica o l’introduzione di un nuovo motore;
c) l’analista dovrà ridefinire uno o più indicatori come primario (nel caso si tratti di indicatori
derivati) oppure come secondario (nel caso contrario), per poterli adattare ai casi descritti in
precedenza.
Alternative:
a’1) bn avviene nessun cambio di politica che richieda il cambio gerarchico di uno o più
indicatori;
a’2) non vengono introdotte nuove politiche che richiedano il cambio gerarchico di uno o più
indicatori;
b’) non vengono modificati motori che richiedano il cambio gerarchico di uno o più indicatori;
c’) non vengono introdotti nuovi motori che richiedano il cambio gerarchico di uno o più
indicatori.
Postcondizioni: Adattare gli indicatori a ogni eventuale evoluzione di una o più politiche e
Motori.
UC22. Invalidazione a cascata di un indicatore su tutti gli indicatori derivati da
esso.
Goal: Nel caso in cui un indicatore debba essere eliminato, allora gli indicatori che sono derivati
da esso devono essere invalidati.
Attori: Analista e il sistema (se configurato per effettuare la modifica in maniera automatica).
Precondizioni: Avere degli indicatori derivati da eliminare (e non primari!).
Trigger: Mantenere consistenti i dati.
Descrizione:
a) in vista di una modifica legata ad una politica o ad un motore (e/o al sito ad esso legato, come
ad esempio il fatto che sia in disuso), l’analista eliminerà un indicatore a cui ne derivano degli
altri;
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 49 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
b) in seguito all’eliminazione, all’analista dovrà essere consentita la possibilità di invalidare in
maniera automatica tutti gli indicatori derivati da quello eliminato o in maniera manuale (avendo
l’occasione in ogni caso di avere una lista di tali indicatori).
Alternative:
a’) non esistono indicatori con indicatori derivati;
b’1) il sistema non è in grado di fornire una lista degli indicatori da invalidare;
b’2) il sistema non è in grado di invalidare tutti gli indicatori derivati;
b’3) alcuni indicatori non sono invalidabili, perché lo sono già.
Postcondizioni: Viene mantenuta coerenza e affidabilità nella gestione degli indicatori durante
la loro evoluzione.
UC23. Associare ad un indicatore la sua classe di appartenenza
Goal: Risalire al tipo di dati che l’indicatore rappresenta (es: indicatore per rappresentare le
Smart Cities o l’ICT).
Attori: Analista.
Precondizioni: Avere degli indicatori e delle classi da associare.
Trigger: Rendere tracciabili gli indicatori.
Descrizione:
a) definire quali sono i dati che l’indicatore rappresenta;
b) scegliere (e quindi associare all’indicatore) la classe che più rappresenta i dati rappresentati
dall’indicatore.
Alternative:
1) non avere indicatori;
2) non avere classi da associare;
3) non avere le informazioni per effettuare l’associazione.
Postcondizioni: Viene mantenuta la rintracciabilità degli indicatori.
UC24. Creazione di nuovi indicatori
Goal: Per ogni nuova politica o motore (ed eventuale modifica) deve essere definito un nuovo
indicatore che verrà rispettivamente usato come valore di rappresentazione di una politica (es:
dato statistico) o come chiave di ricerca nel Web.
Attori: Analista.
Precondizioni: Avere una politica da rappresentare o un motore da personalizzare.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 50 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Trigger: Introduzione di un nuovo Motore o di una nuova politica.
Descrizione:
a) ricevere una notifica, un alert o una comunicazione dal Policy Maker su una nuova politica da
rappresentare;
b) in alternativa ricevere una notifica, un alert o una comunicazione dall’Engine Administrator o
dal proprietario di un motore, riguardo ad una modifica o all’introduzione di un motore che
richiede una specifica chiave di ricerca;
c) in base alle richieste, l’analista dovrà formulare un nuovo indicatore per rappresentare al
meglio la politica o per rendere più performante la ricerca effettuata del motore.
Alternative:
a’) non avere politiche da rappresentare,
B’) non avere motore da personalizzare.
Postcondizioni: Avere dei punti riferimento sull’acquisizione e l’elaborazione dei dati.
UC25. Creazione di indicatori primari
Goal: Inserire degli indicatori di basso livello, che rappresentano dati semplici e non elaborati
(a differenza degli indicatori derivati), utilizzati al più come chiavi di ricerca per i motori.
Attori: Analista.
Precondizioni: Avere una politica da rappresentare o un motore da personalizzare.
Trigger: Rendere tracciabili i dati di basso di livello (quelli grezzi raccolti dai Motori o dagli
Adapter per le Basi di dati).
Descrizione:
a) ricevere una notifica, un alert o una comunicazione dall’Engine Administrator o dal
proprietario di un motore , riguardo ad una modifica o all’introduzione di un Motore che richiede
una specifica chiave di ricerca;
b) in base alle richieste, l’analista dovrà formulare un nuovo indicatore per rappresentare al
meglio la politica e per rendere più performante la ricerca effettuata del Motore.
Alternative:
a’) non avere politiche da rappresentare;
b’) non avere Motore da personalizzare.
Postcondizioni: Avere delle chiavi di ricerca per i Motori che soddisfino le politiche definite dai
Policy Maker.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 51 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
UC26. Creazione di indicatori derivati.
Goal: Creare degli indicatori che siano il risultato della combinazione di altri indicatori (sia
primari che derivati), utilizzati al più per meglio definire l’andamento di una politica.
Attori: Analista.
Precondizioni: Avere una politica da rappresentare o un Motore da personalizzare.
Trigger: Rendere tracciabili i dati calcolati sulla base di indicatori primari e/o derivati.
Descrizione:
a) ricevere una notifica, un alert o una comunicazione dal Policy Maker su una nuova politica da
rappresentare;
b) in base alle richieste, l’analista dovrà formulare un nuovo indicatore, aggregando fra loro
quelli già esistenti, per rappresentare al meglio la politica o per rendere più performante la
ricerca effettuata del motore.
Alternative:
a’) non avere politiche da rappresentare;
b’) non avere motore da personalizzare.
Postcondizioni: Avere dei punti di riferimento per rappresentare in maniera dettagliata una o più
politiche definite dai Policy Maker.
UC27. Definire la qualità/bontà di un dato.
Goal: Definire per un dato quanto esso sia affidabile e riutilizzabile nel tempo.
Attori: Analista.
Precondizioni: Avere dei dati (all’interno del Database relativo ai dati raccolti) non ancora
analizzati.
Trigger: Associare un indicatore di utilizzo per un dato.
Descrizione:
a) l’analista si dovrà autenticare all’interno del sistema;
b) l’analista dovrà accedere ai dati e visualizzare i dati che non sono ancora stati marcati come
dati analizzati;
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 52 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
c) l’analista per ogni dato, deciderà se definirlo come dato sperimentale o dato affidabile (vedi i
prossimi casi d’uso);
d) in alternativa l’analista potrà anche ridefinire lo stato di un dato; cambiarlo dallo stato
sperimentale allo stato affidabile (e/o viceversa), o modificarne il punteggio associato (che va da
0 a 1).
Alternative:
a’) l’analista non riesce ad autenticarsi;
b’) non avere dati;
c’) il database è irraggiungibile.
Postcondizioni: Avere dei dati per cui è possibile sapere se potranno essere utilizzati senza
problemi (dati affidabili) o se hanno bisogno di ulteriori analisi (dati sperimentali).
UC28. Definire un dato come sperimentale
Goal: Definire un dato come non ancora affidabile, assegnandoli un valore (da 0 a 1) che indichi
quanto probabilmente esso lo possa diventare nel tempo.
Attori: Analista.
Precondizioni: Avere un dato su cui definire lo stato e il punteggio.
Trigger: Definire quali sono i dati da analizzare a fondo.
Descrizione:
L’analista si dovrà autenticare all’interno del sistema.
L’analista dovrà scegliere il dato da definire come sperimentale e, in base alle sue conoscenze e
alle politiche definite nel sistema, associarvi un valore di approssimazione compreso tra 0 e 1
inclusi.
Alternative:
L’analista non riesce ad autenticarsi.
Non avere dati.
Il database è irraggiungibile.
Postcondizioni: Avere maggiore tracciabilità sui dati da analizzare più affondo.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 53 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
UC29. Definire un dato come affidabile
Goal: Definire un dato come affidabile, e quindi utilizzabile per inferenze statistiche (vedi caso
d’uso più avanti), per aggregarlo su base territoriale (vedi caso d’uso più avanti), o più in
generale, per qualsiasi elaborazione; assegnandoli, inoltre, un valore che ne indichi l’affidabilità
(da 0 a 1).
Attori: Analista.
Precondizioni: Avere un dato su cui definire lo stato e il punteggio.
Trigger: Definire quali sono i dati da poter già utilizzare per la loro elaborazione.
Descrizione:
L’analista si dovrà autenticare all’interno del sistema.
L’analista dovrà scegliere il dato da definire come affidabile e, in base alle sue conoscenze e alle
politiche definite nel sistema, associarvi un valore di affidabilità compreso tra 0 e 1 inclusi.
Alternative:
L’analista non riesce ad autenticarsi.
Non avere dati.
Il database è irraggiungibile.
Postcondizioni: Avere maggiore tracciabilità sui dati da poter utilizzare per elaborazioni e
rappresentazioni delle politiche.
UC30. Effettuare delle inferenze statistiche sui dati.
Goal: Permettere all’analista l’elaborazione dei dati raccolti da Motori e dai Database esterni,
per poterli analizzare e/o rappresentare.
Attori: Analista.
Precondizioni: Avere un dato su cui definire lo stato e il punteggio.
Trigger: Elaborare i dati per poter rappresentare una o più politiche.
Descrizione:
L’analista si dovrà autenticare all’interno del sistema.
L’analista dovrà, in base alle sue conoscenze e ai suoi obbiettivi, scegliere dei dati da poter
elaborare grazie a funzioni matematico/statistiche.
L’analista potrà salvare i dati così elaborati.
Alternative:
L’analista non riesce ad autenticarsi.
Non avere dati.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 54 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Il database è irraggiungibile.
Postcondizioni: Avere dei dati molto più malleabili per effettuare analisi, ricerche e
rappresentazioni sulle politiche definite nel sistema.
UC31. Aggregare i dati su base territoriale.
Goal: Associare i dati (acquisiti o elaborati) ad un contesto territoriale, che può essere:
internazionale, nazionale, regionale, provinciale o comunale.
Attori: Analista (con l’appoggio dell’Engine Administrator e di alcuni Motori che possono
effettuare ricerche con chiavi di ricerca legate al territorio).
Precondizioni: Avere i dati e le informazioni per poterli associare al contesto territoriale.
Trigger: Voler rendere tracciabili i dati a livello territoriale.
Descrizione:
L’analista si dovrà autenticare all’interno del sistema.
L’analista potrà per ogni dato raccolto o elaborato, scegliere a quale contesto territoriale (la cui
lista dei luoghi sarà già messa a disposizione dal sistema) a esso appartiene.
Alternative:
L’analista non riesce ad autenticarsi.
Non avere dati.
Il database è irraggiungibile.
Non è presente nessuna lista dei luoghi disponibili.
Postcondizioni: Capire il contesto territoriale dei dati.
UC32. Validare/Invalidare i dati acquisiti.
Goal: Rendere validi (o no) i dati raccolti da Motori o da Banche dati esterne.
Attori: Analista.
Precondizioni: Avere dati raccolti da Motori e Database esterni, che non sono ancora stati
analizzati.
Trigger: Effettuare un controllo sui dati raccolti.
Descrizione:
a) ricevere una notifica, un alert o una comunicazione dall’Engine Administrator o dal
proprietario di un Motore o di un adapter per un Database esterno o dallo scheduler dei Motori (o
anche dallo scheduler degli Adapter dei Database esterni ???), riguardo alla raccolta di nuovi
dati;
b) associare per ognuno di questi dati, un valore che indichi se essi sono validi oppure no.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 55 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Alternative:
a’) l’analista non riceve notifiche, alert o comunicazioni che sono state effettivamente inviate;
b’) non avere nuovi dati da analizzare;
c’) il database è irraggiungibile.
Postcondizioni: Avere dei dati che possono considerarsi validi (e quindi definibili in seguito
come sperimentali o affidabili) o no.
UC33. Ricevere Alert.
Goal: Ricevere comunicazioni importanti da altri attori.
Attori: Tutti.
Precondizioni: Essere autenticati e ricevere un messaggio (legato ad una azione svolta sul
sistema o ad un suo stato) d’alta priorità da a uno o più attori.
Trigger: Informare gli attori di ogni importante azione nel sistema.
Descrizione:
Collegarsi alla propria area riservata.
Visualizzare nella propria area gli alert ricevuti.
Alternative:
L’attore non riesce ad autenticarsi.
L’attore non riceve alert che sono state effettivamente inviate.
Postcondizioni: Informare gli attori di ogni modifica (o stato) ritenuta importante all’interno del
sistema.
UC34. Inviare Alert.
Goal: Inviare comunicazioni importanti (relative o ad una azione importante svolta nel sistema o
ad uno stato del sistema) ad uno o più attori.
Attori: Tutti.
Precondizioni: Essere autenticati e per ogni azione ritenuta importante, decidere se inviare o no
un alert ad altri attori.
Trigger: Informare gli attori di ogni importante azione nel sistema.
Descrizione:
Collegarsi alla propria area riservata.
Svolgere un’azione d’alta criticità nel sistema.
In seguito all’azione, il sistema invierà (sempre e in maniera automatica) l’alert agli altri attori.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 56 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Alternative:
L’attore non riesce ad autenticarsi.
L’attore invia l’alert, ma esso non viene effettivamente inviato al/ai mittenti.
Postcondizioni: Informare gli attori di ogni modifica (o stato) ritenuta importante all’interno del
sistema.
UC35. Ricevere delle notifiche.
Goal: Ricevere comunicazioni di media importanza da altri attori.
Attori: Tutti.
Precondizioni: Essere autenticati e ricevere un messaggio (legato ad una azione svolta sul
sistema o ad un suo stato) di media priorità da a uno o più attori.
Trigger: Informare gli attori di ogni eventuale azione nel sistema.
Descrizione:
Collegarsi alla propria area riservata.
Visualizzare nella propria area le notifiche ricevute.
Alternative:
L’attore non riesce ad autenticarsi.
L’attore non riceve le notifiche che sono state effettivamente inviate.
Postcondizioni: Informare gli attori di ogni modifica (o stato) ritenuta di media importanza
all’interno del sistema.
UC36. Inviare notifiche.
Goal: Inviare comunicazioni di media importanza (relative o ad una azione svolta nel sistema o
ad uno stato del sistema) ad uno o più attori.
Attori: Tutti.
Precondizioni: Essere autenticati e per ogni azione, decidere se inviare o no una notifica ad altri
attori.
Trigger: Informare gli attori di ogni eventuale azione nel sistema.
Descrizione:
Collegarsi alla propria area riservata.
Svolgere un’azione nel sistema.
Prima di completare l’azione (o all’inizio di essa), l’attore deve avere la possibilità di avvisare
uno o più attori riguardo all’azione che sta per svolgere.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 57 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Alternative:
L’attore non riesce ad autenticarsi.
L’attore invia la notifica, ma essa non viene effettivamente inviata al/ai mittenti.
Postcondizioni: Informare gli attori di ogni modifica (o stato) ritenuta di media importanza
all’interno del sistema.
3.5
Engine Administrator – gestione motori & istanze
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 58 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
UC37. Login (autenticazione)
Goal: Effettuare l’accesso al sistema
Attori: Engine Administrator
Precondizioni: L’utente non deve ancora aver effettuato l’accesso
Descrizione:
a) l’amministratore inserisce le proprie credenziali di accesso (nome utente e password);
b) l’amministratore clicca sul tasto per avviare la procedura di accesso;
c) il sistema tiene traccia dell’accesso.
Alternativa:
a’1) se l’amministratore non possiede le credenziali necessarie, l’accesso fallisce;
a’2) se le credenziali inserite sono errate, l’accesso fallisce.
Postcondizioni: L’amministratore ora risulta collegato al sistema e può accedere alle
funzionalità che gli sono state assegnate
UC38. Logout (uscita dal sistema)
Goal: L’amministratore deve poter uscire dal sistema (la sessione di lavoro viene conclusa)
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 59 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Attori: Engine Administrator
Precondizioni: L’amministratore è collegato al sistema
Descrizione:
a) l’amministratore invoca la funzionalità di logout;
b) Il sistema tiene traccia della fine della sessione di lavoro.
Alternativa: nessuna
Postcondizioni:
a’1) l’amministratore ora non può più operare sul sistema (è un utente non autenticato);
a’2) l’amministratore vede la schermata di login al sistema, che gli permette di iniziare una
nuova sessione.
UC39. Inserimento nuovo motore
Goal: espandere il parco di sorgenti da cui acquisire dati
Attori: Engine Administrator
Precondizioni: il motore non deve essere già presente a sistema, l’amministratore deve aver
effettuato l’accesso
Descrizione:
a) l’amministratore richiama la funzionalità per l’inserimento di un nuovo modello di motore;
b) il sistema controlla le credenziali dell’autore della richiesta;
c) l’amministratore seleziona il motore da inserire;
d) l’amministratore clicca sul pulsante di inizio inserimento;
e) il sistema verifica che il motore non sia già presente nel sistema;
f) Se tutte le condizioni per l’inserimento del nuovo motore sono soddisfatte, il sistema procede
all’inserimento.
Alternativa:
1) l’autore della richiesta di inserimento non ha le credenziali necessarie, la procedura viene
interrotta con un errore;
2) il motore è già presente a sistema, il caricamento fallisce ed il sistema suggerisce all’utente di
usare la funzione aggiornamento;
3) L’inserimento fallisce per altri motivi, il sistema visualizza le motivazioni all’amministratore.
Postcondizioni: Il motore è ora disponibile nell’elenco dei motore istanziabili.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 60 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
UC40. Aggiornamento motore
Goal: mantenere il motore correttamente funzionante
Attori: Engine Administrator
Precondizioni: Il motore deve essere presente a sistema
Descrizione:
a) l’amministratore richiama la funzionalità per l’aggiornamento di un modello di motore;
b) il sistema controlla le credenziali dell’autore della richiesta;
c) l’amministratore seleziona il file di aggiornamento;
d) l’amministratore clicca sul pulsante di inizio aggiornamento;
e) il sistema verifica che il motore sia già presente nel sistema (cioè che il file da caricare
corrisponda con quello che si vuole aggiornare);
f) il sistema verifica che la nuova versione del motore sia più recente di quella presente a
sistema;
g) se tutte le condizioni per l’inserimento del nuovo motore sono soddisfatte, il sistema procede
all’inserimento (invoca la procedura di aggiornamento motore).
Alternativa:
1) l’autore della richiesta di aggiornamento non ha le credenziali necessarie, la procedura viene
interrotta con un errore;
2) il motore non è già presente a sistema, il caricamento fallisce ed il sistema suggerisce
all’utente di usare la funzione installazione;
3) se la versione che si sta caricando non è più recente di quella a sistema, la procedura fallisce;
4) se la procedura di aggiornamento (sostituzione del vecchio motore) fallisce, il sistema effettua
un rollback alla precedente versione del motore.
Postcondizioni: Il motore è ora aggiornato all’ultima versione disponibile
UC41. Creazione nuova istanza di motore
Goal: mettere in essere una nuova ricerca dati
Attori: Engine Administrator
Precondizioni: il modello del motore deve essere presente a sistema.
Descrizione:
a) l’amministratore richiama la funzionalità per creare una nuova istanza del motore;
b) il sistema controlla le credenziali dell’autore della richiesta;
c) l’amministratore seleziona un modello di motore;
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 61 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
d) l’amministratore clicca sul tasto per passare alla configurazione del motore (nb: il tasto
diventa attivo solo dopo aver selezionato un modello di motore);
e) l’amministratore definisce i parametri che verranno usati dal motore;
f) l’amministratore clicca sul tasto per passare alla schedulazione del motore;
g) l’amministratore decide la schedulazione del motore;
h) l’amministratore conferma la schedulazione.
Alternativa:
1) l’autore della richiesta di creazione di una nuova istanza non ha le credenziali necessarie, la
procedura viene interrotta con un errore;
2) se l’amministratore clicca sul tasto annulla, la procedura di inserimento si interrompe senza
conseguenze (in qualsiasi punto della procedura);
3) l’istanziazione del motore non è andata a buon fine poiché l’amministratore ha inserito una
parametrizzazione non supportata;
4) l’istanziazione del motore non è andata a buon fine poiché l’amministratore ha inserito una
schedulazione non valida.
Postcondizioni:
una nuova istanza del motore è ora presente a sistema, pronta ad estrarre dati
ci sarà una schedulazione con lo stato “attiva”
UC42. Marcatura di un’istanza di motore come “non valida”
Goal: Scartare un’istanza di un motore nel caso non sia valida, ad esempio nel caso sia stata
parametrizzata in modo errato e non abbia senso far proseguire l’esecuzione
Attori: Engine Administrator
Precondizioni: Esiste un’istanza di un motore
Descrizione:
a) l’amministratore richiama la funzionalità su un’istanza del motore;
b) il sistema controlla le credenziali dell’autore della richiesta;
c) l’utente conferma la volontà di marcare l’istanza come non valida;
d) il sistema interrompe l’esecuzione del motore portandolo ad uno stato “concluso - non
valido”.
Alternativa:
1) l’autore della richiesta non ha le credenziali necessarie, la procedura viene interrotta con un
errore;
2) se l’amministratore clicca sul tasto annulla, la procedura di marcatura si interrompe senza
conseguenze.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 62 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Postcondizioni:
- L’istanza del motore è marcata come non valida
- L’istanza del motore non è più in esecuzione
- I risultati eventualmente raccolti sono marcati come non validi.
UC43. Modifica schedulazione istanza motore
Goal: modificare la schedulazione con cui il motore andrà in esecuzione
Attori: Engine Administrator
Precondizioni: esiste almeno un’istanza di motore schedulata
Descrizione:
a) l’amministratore richiama la funzionalità su un’istanza del motore o su una voce nell’elenco
delle schedulazioni;
b) il sistema controlla le credenziali dell’autore della richiesta;
c) l’amministratore modifica (a propria discrezione) i giorni, le ore e la frequenza con cui il
motore va in esecuzione;
d) l’amministratore conferma le modifiche.
Alternativa:
1) l’autore della richiesta di modifica della schedulazione non ha le credenziali necessarie, la
procedura viene interrotta con un errore;
2) se L’amministratore clicca sul tasto annulla, la procedura di modifica si interrompe senza
conseguenze.
Postcondizioni: Le successive esecuzioni del motore riflettono la nuova schedulazione
UC44. Rimozione di un’istanza di motore dallo schedulatore
Goal: Togliere un’istanza del motore dallo scheduler
Attori: Engine Administrator
Precondizioni: esiste almeno un’istanza di motore schedulata, in stato di pausa
Descrizione:
a) l’amministratore richiama la funzionalità su un’istanza del motore o su una voce nell’elenco
delle schedulazioni;
b) il sistema controlla le credenziali dell’autore della richiesta;
c) il sistema controlla che l’istanza del motore sia in stato di pausa;
d) l’amministratore conferma l’intenzione di rimuovere la schedulazione.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 63 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Alternativa:
1) l’autore della richiesta di rimozione della schedulazione non ha le credenziali necessarie, la
procedura viene interrotta con un errore;
2) se l’istanza del motore non è in stato di pausa, la procedura di rimozione si interrompe con un
errore (senza modifiche allo stato del sistema);
3) se l’amministratore clicca sul tasto annulla, la procedura di rimozione si interrompe senza
conseguenze.
Postcondizioni:
1 - Il motore non andrà più in esecuzione (in modo definitivo!)
2 - Eventuali esecuzioni in corso non verranno interrotte prematuramente
UC45. Sospensione di un’istanza di motore
Goal: interrompere temporaneamente la schedulazione
Attori: Engine Administrator
Precondizioni: esiste almeno un’istanza di motore schedulata per l’esecuzione
Descrizione:
a) l’amministratore richiama la funzionalità su un’istanza del motore o su una voce nell’elenco
delle schedulazioni;
b) il sistema controlla le credenziali dell’autore della richiesta;
c) l’amministratore conferma l’intenzione di mettere in pausa la schedulazione.
Alternativa:
1) l’autore della richiesta di sospensione della schedulazione non ha le credenziali necessarie, la
procedura viene interrotta con un errore;
2) se l’amministratore clicca sul tasto annulla, la procedura di sospensione si interrompe senza
conseguenze.
Postcondizioni:
1) il motore non andrà più in esecuzione finché non verrà riattivato;
2) la schedulazione avrà lo stato “in pausa”.
UC46. Riattivazione di un’istanza di motore
Goal: riattivare il normale svolgimento di una schedulazione in stato di pausa
Attori: Engine Administrator
Precondizioni: esiste almeno un’istanza di motore schedulata ma in pausa
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 64 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Descrizione:
a) l’amministratore richiama la funzionalità su un’istanza del motore o su una voce nell’elenco
delle schedulazioni;
b) il sistema controlla le credenziali dell’autore della richiesta;
c) l’amministratore conferma l’intenzione di rimettere in esecuzione la schedulazione.
Alternativa:
1) l’autore della richiesta di riattivazione della schedulazione non ha le credenziali necessarie, la
procedura viene interrotta con un errore;
2) se l’amministratore clicca sul tasto annulla, la procedura di riattivazione si interrompe senza
conseguenze.
Postcondizioni:
1) il motore torna in esecuzione come da schedulazione;
2) la schedulazione avrà lo stato “attiva”.
UC47. Visualizzazione dell’elenco dei motori
Goal: L’Engine Administrator deve poter visualizzare una lista dei modelli di motore esistenti
nel sistema, al fine di poterli gestire (es: aggiornamento)
Attori: Engine Administrator
Precondizioni: nessuna
Descrizione:
a) l’amministratore richiama la funzionalità di visualizzazione;
b) il sistema controlla le credenziali dell’autore della richiesta.
Alternativa:
1) l’autore della richiesta di visualizzazione non ha le credenziali necessarie, la procedura viene
interrotta con un errore.
Postcondizioni:
1) l’amministratore visualizza la lista dei modelli di motore attualmente esistenti a sistema.
UC48. Visualizzazione delle istanze di motore esistenti
Goal: L’Engine Administrator deve poter visualizzare quali motori sono attualmente i stanziati,
al fine di poterne gestire il ciclo di vita
Attori: Engine Administrator
Precondizioni: nessuna
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 65 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Descrizione
a) l’amministratore richiama la funzionalità di visualizzazione;
b) il sistema controlla le credenziali dell’autore della richiesta.
Alternativa:
1) l’autore della richiesta di visualizzazione non ha le credenziali necessarie, la procedura viene
interrotta con un errore.
Postcondizioni:
L’amministratore visualizza la lista delle istanze di motore attualmente esistenti (schedulati o
meno) sul sistema.
NOTE: la differenza tra questo caso d’uso e quello relativo alla schedulazione dei motore è che
questo visualizza tutti i bot, anche quelli non più schedulati (ma che, in passato, sono stati
eseguiti).
UC49. Visualizzazione della schedulazione dei motore
Goal: L’amministratore deve poter visualizzare l’elenco dei motore schedulati al fine di poterne
gestire la programmazione.
Attori: Engine Administrator
Precondizioni: nessuna
Descrizione:
a) l’amministratore richiama la funzionalità di visualizzazione;
b) il sistema controlla le credenziali dell’autore della richiesta.
Alternativa:
1) l’autore della richiesta di visualizzazione non ha le credenziali necessarie, la procedura viene
interrotta con un errore.
Postcondizioni: L’amministratore visualizza la lista delle istanze di motore attualmente schedati
sul sistema.
UC50. Impostazione dell’orario di self test
Goal: L’amministratore deve poter decidere l’orario in cui avverrà il self test di tutti i modelli di
motore, rivolto a controllarne lo stato di salute (cioè se, per qualche motivo, un modello di
motore smette di funzionare)
Attori: Engine Administrator
Precondizioni: nessuna
Descrizione:
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 66 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
a) l’amministratore richiama la funzionalità di modifica dell’orario di self test;
b) il sistema controlla le credenziali dell’autore della richiesta;
c) l’amministratore modifica l’orario di self test;
d) l’amministratore conferma la modifica.
Alternativa:
1) l’autore della richiesta non ha le credenziali necessarie, la procedura viene interrotta con un
errore;
2) l’orario inserito non è valido, la procedura fallisce e non avviene alcun cambiamento della
schedulazione;
3) l’amministratore decide di annullare la modifica (non conferma la modifica), non avviene
alcun cambiamento della schedulazione.
Postcondizioni: L’esecuzione dei self test avviene nel nuovo orario stabilito.
UC51. Avvio manuale del self test
Goal: L’amministratore deve poter testare liberamente lo stato di salute dei modelli di motore
(potrebbe sentirne la necessità nel caso si segnalino dei problemi improvvisi)
Attori: Engine Administrator
Precondizioni: il modello del motore da testare deve essere installato nel sistema
Descrizione:
a) l’amministratore richiama la funzionalità di avvio del self test;
b) il sistema controlla le credenziali dell’autore della richiesta;
c) avviene il self test.
Alternativa:
1) l’autore della richiesta non ha le credenziali necessarie, la procedura viene interrotta con un
errore.
Postcondizioni: L’amministratore visualizza l’esito del self test.
UC52. Visualizzazione esiti self test (vista generale)
Goal: Fornire all’amministratore un elenco (raggruppato per modello di motore o per data di
esecuzione del self test) degli esiti delle procedure di self test, al fine di poter monitorare
l’andamento nel dettaglio e poter invocare la procedura di visualizzazione dell’esito di un self
test specifico (in altre parole, la funzionalità è una sorta di cruscotto generale che poi permette di
scendere ad un livello più basso)
Attori: Engine Administrator
Precondizioni: nessuna
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 67 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Descrizione:
a) l’amministratore richiama la funzionalità;
b) il sistema controlla le credenziali dell’autore della richiesta.
Alternativa:
a’) l’autore della richiesta non ha le credenziali necessarie, la procedura viene interrotta.
Postcondizioni: L’amministratore visualizza l’elenco completo di tutti i self test.
UC53. Visualizzazione dell’esito di self test
Goal: L’amministratore deve poter visualizzare l’esito dei self test
Attori: Engine Administrator
Precondizioni: è stato eseguito un self test (avvio manuale), oppure l’Engine Administrator sta
visualizzando gli esiti di tutti i self test (“schermata generale”).
Descrizione:
a) l’amministratore richiama la funzionalità di visualizzazione dell’esito di un self test, oppure il
sistema la invoca automaticamente a seguito di un avvio manuale del self test;
b) il sistema controlla le credenziali dell’autore della richiesta.
Alternativa:
1) l’autore della richiesta non ha le credenziali necessarie, la procedura viene interrotta con un
errore.
Postcondizioni: L’amministratore visualizza l’esito del self test.
UC54. Visualizzazione notifiche del sistema
Goal: L’Engine Administrator deve visualizzare gli avvisi del sistema che gli sono stati inviati
dalle componenti del sistema, in ordine cronologico inverso (prima le più recenti)
Attori: Engine Administrator
Precondizioni: nessuna
Descrizione:
a) l’amministratore richiama la funzionalità di visualizzazione degli avvisi;
b) il sistema controlla le credenziali dell’autore della richiesta.
Alternativa:
1) l’autore della richiesta non ha le credenziali necessarie, la procedura viene interrotta con un
errore.
Postcondizioni: L’amministratore visualizza le segnalazioni.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 68 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
UC55. Visualizzazione informazioni motore
Goal: Visualizzare le informazioni associate ad un modello di motore (o ad una sua istanza), ad
esempio il nome e la revisione
Attori: Engine Administrator
Precondizioni: il modello di motore è installato nel sistema, esiste un’istanza del motore (solo
nel caso si intenda invocare la funzionalità a partire da un’istanza!)
Descrizione:
a) l’amministratore richiama la funzionalità di visualizzazione delle informazioni associate al
motore;
b) il sistema controlla le credenziali dell’autore della richiesta.
Alternativa:
1) l’autore della richiesta non ha le credenziali necessarie, la procedura viene interrotta con un
errore.
Postcondizioni: L’amministratore visualizza le informazioni associate al modello di motore per
il quale ha invocato la procedura.
UC56. Visualizzazione parametri istanza motore
Goal: L’amministratore deve poter visualizzare i parametri con cui è stata personalizzata
un’istanza di un motore
Attori: Engine Administrator
Precondizioni: Esiste un’istanza del motore (anche solo schedulata ma non ancora eseguita)
Descrizione:
a) l’amministratore richiama la funzionalità di visualizzazione dei parametri di personalizzazione
associate all’istanza del motore;
b) il sistema controlla le credenziali dell’autore della richiesta.
Alternativa:
1) l’autore della richiesta non ha le credenziali necessarie, la procedura viene interrotta con un
errore.
Postcondizioni: L’amministratore visualizza i parametri di personalizzazione associati
all’istanza del motore sul quale ha invocato la procedura di visualizzazione.
UC57. Ricerca dei motori per nome/descrizione/altro
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 69 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Goal: L’amministratore deve avere uno strumento per individuare rapidamente un modello di
motore, senza essere costretto a scorrere l’elenco completo
Attori: Engine Administrator
Precondizioni: L’amministratore sta visualizzando l’elenco completo dei motore
Descrizione:
a) l’amministratore inserisce la stringa di ricerca;
b) l’amministratore sceglie i campi di ricerca (es: nome motore, descrizione motore,
sviluppatore, tutto, ecc);
c) l’amministratore lancia la ricerca.
Alternativa: nessuna
Postcondizioni: L’amministratore visualizza l’elenco dei modelli di motore che soddisfano i
criteri della propria ricerca.
UC58. Ricerca delle istanze di motore per nome/descrizione/altro
Goal: L’amministratore deve avere uno strumento per individuare rapidamente le istanze di
motore che rispondono ad alcuni requisiti (ad esempio appartengono allo stesso modello di
motore), senza essere costretto a scorrere l’elenco completo.
Attori: Engine Aministrator
Precondizioni: L’amministratore sta visualizzando l’elenco completo delle istanze di motore,
oppure sta visualizzando la schedulazione .
Descrizione:
a) l’amministratore inserisce la stringa di ricerca;
b) l’amministratore sceglie i campi di ricerca (es: nome motore, descrizione motore,
sviluppatore, stato di esecuzione [pronto, in esecuzione, in pausa, concluso, ecc], parametri di
personalizzazione, tutto, eccetera eccetera);
c) l’amministratore lancia la ricerca.
Alternativa: nessuna
Postcondizioni: L’amministratore visualizza l’elenco delle istanze di motore che soddisfano i
criteri della propria ricerca.
UC59. Ritorno alla visualizzazione precedente dopo una ricerca/filtro
Goal: dopo aver eseguito una o più ricerche, l’amministratore deve poter tornare alla
visualizzazione completa senza dover uscire e rientrare nella funzionalità di visualizzazione da
cui è stata richiamata la funzionalità di ricerca.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 70 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Attori: Engine Administrator
Precondizioni: L’amministratore sta visualizzando i risultati di una ricerca
Descrizione:
a) l’amministratore preme sul tasto che disattiva il filtro/ricerca.
Alternativa: nessuna
Postcondizioni: L’amministratore ritorna alla visualizzazione completa precedente (es:
visualizza l’elenco completo dei motore esistenti a sistema).
3.6
Policy Administrator
UC60. Visualizzazione politiche
Scope: Policy Editor
Goal: Il Policy Administrator deve poter visualizzare l’insieme delle politiche per controllare
che non ci siano contrasti tra gli obiettivi delle stesse
Dipendenze: Nessuna
Attori: Policy Administrator
Precondizioni: Nessuna
Trigger: Nessuno
Descrizione: Il Policy Administrator visualizza una lista di politiche ed obiettivi
Postcondizioni: Il Policy Administrator visualizza tutte le politiche
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 71 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
UC61. Visualizzazione avvisi
Scope: Policy Console
Goal: Il Policy Administrator ed i policy maker devono poter visualizzare gli avvisi che
riguardano il sistema
Dipendenze: Nessuna
Attori: Policy Administrator, Policy Maker
Precondizioni: Nessuna
Trigger: Pressione del tasto “avvisi”
Descrizione: l’utente visualizza una lista di avvisi
Postcondizioni: l’utente visualizza gli avvisi
UC62. Invio avviso
Scope: Policy Console
Goal: Il Policy Administrator deve poter inviare un avviso ai policy maker quando lo ritiene
necessario
Dipendenze: Nessuna
Attori: Policy Administrator
Precondizioni: Nessuna
Trigger: Pressione del tasto “Invia avviso”
Descrizione:
a) il Policy Administrator compila un form con il messaggio da inviare;
b) sceglie uno o più Policy Maker destinatari;
c) preme sul tasto “Invia avviso”.
Postcondizioni: Il Policy Administrato invia una avviso
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 72 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
3.7
Unità complessa eGovernment
View Administrator
UC63. Aggiunta Interfaccia
Scope: Multiple Devices Interface
Goal: Il View Administrator abilita una nuova interfaccia di visualizzazione
Dipendenze: Nessuna
Attori: View Administrator
Precondizioni: Nessuna
Trigger: Nessuno
Descrizione: Il View Administrator aggiunge un nuovo tipo di interfaccia di visualizzazione che
potrà essere usato da una nuova categoria di utenti
Postcondizioni: Il View Administrator aggiunge una nuova interfaccia
UC64. Aggiorna “interfaccia”
Scope: Multiple Devices Interface
Goal: Il view administrator aggiorna e modifica un’ interfaccia di visualizzazione
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 73 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Dipendenze: Nessuna
Attori: View Administrator
Precondizioni: Nessuna
Trigger: Nessuno
Descrizione: Il View Administrator modifica aggiornandola ai nuovi standard tecnologici una
interfaccia di visualizzazione del sistema
Postcondizioni: Il View Administrator aggiorna un’ interfaccia
UC65. Abilita/Disabilita “funzione”
Scope: Multiple Devices Interface
Goal: Il View Administrator abilita/disabilita una determinata funzione in un’ interfaccia di
visualizzazione
Dipendenze: Nessuna
Attori: View Administrator
Precondizioni: Nessuna
Trigger: Nessuno
Descrizione:
1. Il View Administrator visualizza una lista di possibili funzioni abilitate o meno
2. Spuntando una casella il View Administrator può scegliere di abilitare una funzione
3. La funzione viene abilitata
Alternative: se la funzione è già abilitata, spuntando la casella verrà disabilitata
Postcondizioni: Il View Administrator abilita/disabilita una funzione di un interfaccia
UC66. Visualizza periferiche
Scope: Multiple Devices Interface
Goal: Il View Administrator deve poter visualizzare la lista delle periferiche supportate
Dipendenze: Nessuna
Attori: View Administrator
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 74 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Precondizioni: Nessuna
Trigger: Pressione tasto “lista periferiche”
Descrizione:
1. Il View Administrator preme su “lista periferiche”
2. Compare una lista delle periferiche supportate
Postcondizioni: La lista delle periferiche supportate viene visualizzata
UC67. Visualizza Avvisi
Scope: Multiple Devices Interface
Goal: Il View Administrator deve poter visualizzare la lista degli avvisi riguardanti nuove
funzionalità implementate o modifiche alle interfacce
Dipendenze: Nessuna
Attori: View Administrator
Precondizioni: Nessuna
Trigger: Pressione tasto “avvisi”
Descrizione:
1. Il View Administrator preme su “avvisi”
2. Compare una lista degli avvisi
Postcondizioni: La lista degli avvisi viene visualizzata
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 75 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
3.8
Unità complessa eGovernment
Data Administrator
UC68. Gestire il Database.
Goal: Mantenere attivi i database a fronte di modifiche, crash e nuovi inserimenti.
I database che si avranno sono:
Database struttura: Contiene la struttura dei dati, quindi conterrà al suo interno la definizione
dei Motori, degli indicatori, del tipo e della gerarchia degli indicatori, e nel caso altre strutture
dati.
Database dati: Contiene i dati raccolti da Motori e da Banche dati esterne e quelli elaborati da
essi.
Attori: Amministratore.
Precondizioni: Installare i database relativi alla struttura dati (es: definizione indicatori) e ai dati
raccolti (es: dati raccolti da un certo Motore).
Trigger: Qualsiasi richiesta relativa ad una modifica o alla manutenzione dei database.
Descrizione:
Ricevere una richiesta di manutenzione.
In alternativa ricevere un alert su uno stato critico dei database
Rispondere facendo della manutenzione ai database
Alternative:
Non avere accessi al sistema
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 76 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Postcondizioni: Mantenere sempre accessibili i database.
UC69. Backup delle basi di dati
Goal: Effettuare una copia reperibile dei dati
Attori: Amministratore.
Precondizioni: Installare i database relativi alla struttura dati (es: definizione indicatori) e ai dati
raccolti (es: dati raccolti da un certo Motore).
Trigger: Una richiesta di backup (scatenata da un attore o da un piano di backup).
Descrizione:
Ricevere una richiesta di backup per una particolare base di dati.
Effettuare un backup della base di dati, secondo una certa tipologia (backup totale o parziale o
incrementale o differenziale).
Alternative:
Non avere accessi al sistema
Postcondizioni: Mantenere delle copie dei dati per ogni eventuale ripristino dei database.
UC70. Ripristino delle basi di dati
Goal: Ripristinare i dati in seguito ad un errore.
Attori: Amministratore.
Precondizioni: Installare i database relativi alla struttura dati (es: definizione indicatori) e ai dati
raccolti (es: dati raccolti da un certo Motore).
Trigger: Un errore che provoca la perdita dei dati.
Descrizione:
Ricevere una notifica di errore relativa alla perdita o alla compromissione dei dati.
Caricare l’ultimo backup (uno di quelli a disposizione).
Alternative:
Non avere accessi al sistema.
Non avere backup.
Postcondizioni: Ripristino dello stato delle basi di dati i cui dati erano compromessi.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 77 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
UC71. Gestire gli utenti
Goal: Avere degli utenti, ognuno con i propri diritti. Essi apparteranno ad un certo gruppo (che
rappresenta uno degli attori qui definiti) avente un ambito territoriale (es: si potranno avere utenti
del gruppo analisti di sistema e utenti del gruppo analisti della regione Veneto).
Attori: Amministratore.
Precondizioni: Avere la necessita di inserire e gestire nuovi e vecchi utenti.
Trigger: Una richiesta di un attore o relativa all’evoluzione del sistema.
Descrizione:
L’Amministratore riceve una richiesta relativa alla creazione o modifica di utente (modifica dei
diritti o delle credenziali).
L’amministratore effettua la richiesta.
Alternative:
Non avere accessi al sistema.
Postcondizioni: Avere degli utenti che possono operare in maniera limitata e localizzata
all’interno dello stesso sistema.
UC72. Gestire i gruppi del sistema
Goal: Avere dei gruppi che rappresentano gli autori descritti in questo documento, aventi dei
diritti limitati al contesto territoriale (es: analisti di sistema, amministratori di sistema,
amministratori di sistema della regione Veneto).
Sarà possibile inoltre creare dei sottogruppi che hanno diritti simili ma limitati rispetto al gruppo
di riferimento (es: il gruppo “Analisti della provincia di Venezia” saranno un sottogruppo, e
avranno quindi diritti simili ma limitati, del gruppo “Analisti della regione Veneto”).
Attori: Amministratore.
Precondizioni: Avere la necessita di inserire, gestire e gerarchizzare nuovi e vecchi gruppi.
Trigger: Una richiesta di un attore o relativa all’evoluzione del sistema.
Descrizione:
L’Amministratore riceve una richiesta relativa alla creazione o modifica di un gruppo (modifica
dei diritti o delle credenziali o della gerarchia).
L’amministratore effettua la richiesta.
Alternative:
Non avere accessi al sistema.
Postcondizioni: Avere dei gruppi che rappresentano gli attori del progetto, con i loro limiti e
diritti.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 78 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
4 Requisiti Funzionali
4.1
Funzioni di Raccolta Dati – Engine Manager
L’Engine Manager è il “cuore” del sistema SmeD. In esso sono agganciati i software di
raccolta dati (“bots”, che denomineremo motores se operanti su una fonte dati non strutturata,
spiders se dotati di funzionalità di navigazione sui links, crawlers se operanti su più fonti dati,
adapters se agenti su fonti dati strutturate). Il sistema SmeD dovrà prevedere un set di
classi/APIs per la rapida creazione “industrializzata” dei bots da parte e l’inserimento
nell’Engine Manager. Alla base dell’Engine Manager vi è uno schedulatore che opera con unità
temporale minima giornaliera ed un database (condiviso con tutti i sottosistemi di SmeD) in
grado di accogliere le rilevazioni sistematiche degli indicatori. L’unità territoriale di raccolta
minima per l’Italia è il comune (e per l’Europa la corrispondente unità nel contesto NUTS di
Eurostat).
RF1. Inserimento nuovi indicatori per la raccolta tramite motori
Attori: Engine Administrator.
Dettagli: il sistema dovrà permettere all’Engine Administrator (con il supporto dell’analista) di
poter inserire nuovi indicatori per la raccolta dati via motori.
Motivazione: per rendere più efficienti le campagne raccolte date dovranno predisporre
l’inserimento di nuovi indicatori tecnologici ad ogni momento.
RF2. Avvio e chiusura campagna raccolta dati tramite motori
Attori: Engine Administrator, Analista
Dettagli: il sistema dovrà permettere agli Engine Administrator, con il supporto degli analisti, di
poter avviare o chiudere le campagne raccolta dati.
Motivazione: si predisporrà una data di inizio e una data di fine per ogni campagna raccolta dati.
RF3. Inserimento nuovi indicatori per la raccolta tramite motori
Attori: Engine Administrator
Dettagli: il sistema dovrà permettere all’Engine Administrator di poter inserire gli indicatori
definiti dall’analista per la raccolta dati via motori.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 79 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Motivazione: per rendere più efficienti le campagne raccolte date dovranno predisporre
l’inserimento di nuovi indicatori tecnologici ad ogni momento.
RF4. Selezione fonte banca dati
Attori: Engine Administrator.
Dettagli: il sistema dovrà offrire un’interfaccia per poter selezionare la banca dati da cui
attingere i dati.
Motivazione: per migliorare le ricerche ed aggiungere più dati al sistema si potranno selezionare
opportunamente le fonti per le banche dati.
RF5. Interazione con un modulo per la raccolta dati tramite adapter
Attori: Sistema, Engine Administrator
Dettagli: il sistema dovrà fornire un modulo per collegare il cruscotto con il software che andrà
ad accedere direttamente nelle banche dati fornite da imprese/enti/aggregatori.
Motivazione: la scalabilità rende più robusto e facilmente modificabile il codice sorgente, dovrà
quindi essere predisposto un modulo per l’interazione cruscotto-banche dati.
RF6. Avvio e chiusura campagna raccolta dati tramite adapter
Attori: Engine Administrator.
Dettagli: il sistema dovrà permettere a funzionari e in particolar modo all’Engine Administrator,
di poter avviare o chiudere le campagne raccolta dati su specifiche banche dati.
Motivazione: si predisporrà una data di inizio e una data di fine per ogni campagna raccolta dati.
RF7. Inserimento nuove banche dati
Attori: Engine Administrator
Dettagli: il sistema dovrà permettere agli Engine Administrator e/o agli amministratori di poter
associare nuove banche dati a cui poter accedere
Motivazione: non vi è un numero limitato di banche dati da cui fruire informazioni, quindi sarà
necessario predisporre il collegamento con nuove banche dati.
RF8. Interazione con un modulo per la raccolta dati tramite survey
Attori: Engine Administrator
Dettagli: il sistema dovrà creare un apposito modulo per poter inserire i questionari e raccogliere
le risposte date.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 80 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Motivazione: il sistema sarà predisposto per raccoglie dati in modo automatico e
semiautomatico.
RF9. Inoltro automatico dei questionari ad imprese/cittadini
Attori: Policy Maker, Imprese, Cittadini (esterni)
Dettagli: il sistema permetterà ai funzionari di poter inoltrare i questionari ad un set di
destinatari predefinito.
Motivazione: una volta creato il questionario potrà essere inoltrato al numero più ampio di utenti
in modo agevole da parte del funzionario.
RF10. Inserimento nuovi destinatari per la compilazione dei questionari
Attori: Policy Maker
Dettagli: il sistema permetterà ai funzionari di poter inserire nuovi destinatari a cui
somministrare il questionario scelto.
Motivazione: in caso di necessità il funzionario potrà aggiungere nuovi destinatari per la
compilazione dei questionari
RF11. Gestione Set destinatari a cui somministrare i questionari
Attori: Funzionario/ Policy Maker
Dettagli: il sistema consentirà al funzionario di poter creare o rimuovere un set di destinatari a
cui somministrare i questionari.
Motivazione: vi sarà la necessità di creare nuove liste di destinatari e questa operazione spetterà
al funzionario.
RF12. Inserimento dei dati del questionario all’interno del database
Attori: Policy Maker, Amministratore
Dettagli: il sistema fornirà un’interfaccia al funzionario per poter inserire in modo semplice i
dati raccolti dai questionari
Motivazione: per usufruire del più ampio numero d’informazioni si utilizzerà anche la
somministrazione di questionari cartacei cui implica l’inserimento manuale al sistema.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 81 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
4.2
Unità complessa eGovernment
Funzioni di Amministrazione
RF13. Accesso ad un sistema di gestione degli account
Attori: Amministratore
Dettagli: il sistema dovrà fornire un’interfaccia di accesso per la gestione degli account del
sistema interno
Motivazione: permettere all’amministratore di gestire gli utenti
RF14. Creazione di nuovi account
Attori: Amministratore
Dettagli: il sistema dovrà fornire la possibilità all’amministratore di poter creare nuovi account
con diversi proprietà d’accesso per ogni utente.
Motivazione: permettere all’amministratore di gestire gli utenti
RF15. Modifica account
Attori: Amministratore
Dettagli: il sistema dovrà fornire la possibilità all’amministratore di poter modificare gli account
Motivazione: permettere all’amministratore di modificare attributi, privilegi e caratteristiche
degli utenti in caso di cambiamenti
RF16. Cancellazione account
Attori: Amministratore
Dettagli: il sistema dovrà fornire la possibilità all’amministratore di poter cancellare
eventualmente gli account
Motivazione: permettere all’amministratore di cancellare uno o più utenti.
RF17. Schedulazione processi
Attori: Amministratore
Dettagli: il sistema dovrà fornire uno schedulatore per poter sincronizzare e schedulare i distinti
processi per la raccolta dati
Motivazione: viste le moltitudini di campagne raccolta dati e le diverse tipologie per il
reperimento delle informazioni è necessario l’utilizzo di uno schedulatore.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 82 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
RF18. Sistema di Login
Attore: *
Dettaglio: Ci devono essere una funzionalità per consentire l’accesso al sistema da parte dei
soggetti autorizzati e le funzionalità disponibili devono essere differenziate in base al ruolo
assegnato all’utente
Motivazione: Le informazioni disponibili nel sistema, nonché le funzionalità di gestione del
sistema, devono essere accessibili solo a persone che abbiano competenze e titoli necessari.
RF19. Sistema di Logout
Attore: *
Dettaglio: Ci deve essere una procedura che consenta agli utenti di uscire dal sistema, al fine di
rendere inaccessibili a terzi le funzionalità del sistema.
Motivazione: È necessario impedire che soggetti non autorizzati accedano alle funzionalità del
sistema.
RF20. Logout automatico dopo timeout inattività
Attore: *
Dettaglio: Questa funzionalità deve revocare l’accreditamento dell’utente al sistema dopo che è
trascorso un tempo di inattività da parte dell’utente. L’utente potrà successivamente effettuare un
nuovo accesso al sistema per ricominciare a lavorare.
Motivazione: È necessario garantire che l’accesso alle funzionalità del sistema avvenga solo da
parte delle figure autorizzate; è necessario gestire la situazione in cui l’utente si allontani dalla
macchina su cui sta lavorando senza aver effettuato il logout.
Post: L’utente (l’Engine Manager) non ha più accesso alle funzionalità del sistema, fino al
successivo login
4.3
Analista
RF21. Aggregazione dati
Attori: Policy Maker, Analista
Dettagli: il sistema dovrà fornire la possibilità di raccogliere diverse tipologie di dato ma dovrà
uniformarli per poi poterli aggregare
Motivazione: al fine di analizzare e confrontare più dati distinti si avrà la necessità di aggregare
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 83 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
dati secondo criteri preattribuiti.
RF22. Generazione report campagna
Attori: Funzionario/Policy Maker, Analista
Dettagli: il sistema dovrà fornire la possibilità creare report per ogni singola campagna
Motivazione: i risultati ottenuti dovranno essere catalogati in diversi report al fine di non
perdere le informazioni acquisite. L’Analista deve poter avere una visione d’insieme della
campagna
RF23. Compilazione query
Attori: Analista
Dettagli: il sistema dovrà permettere l’inserimento e la memorizzazione di apposite query
Motivazione: l’analista dovrà avere la possibilità di creare query personalizzate.
RF24. Modifica/Eliminazione query
Attori: Analista
Dettagli: il sistema dovrà permettere la modifica e l’eliminazione di query memorizzate nel
database.
Motivazione: l’analista dovrà avere la possibilità di modificare e cancellare query
personalizzate.
RF25. Visualizzazione risultato della query
Attori: Analista
Dettagli: il sistema dovrà permettere all’analista di poter consultare il risultato di una query
Motivazione: per poter interpretare al meglio i risultati della campagna raccolta dati, l’analista
dovrà appunto avere la possibilità di visualizzare liberamente i singoli risultati.
RF26. Elaborazione statistica dei dati
Attori: Analista
Dettagli: il sistema dovrà fornire un backend di calcolo all’analista per poter elaborare ed
interpretare il dato.
Motivazione: per una efficace reportistica vi dovrà essere un’ adeguata elaborazione da parte del
personale analista.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 84 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
RF27. Rappresentazione grafica del dato
Attori: Analista
Dettagli: il sistema dovrà rappresentare i dati inseriti all’interno di un template del database in
una mappa geo-referenziata.
Motivazione: il sistema in questo modo farà emergere in modo intuitivo le zone con più alto
interesse.
RF28. Gestione degli indicatori
Attori: Analista.
Dettagli: Definire degli indicatori che permettano o di rappresentare una politica o di ricercare
dei dati tramite Motore (o Adapter per Database esterni).
Più in generale, sono usati per rappresentare o dei dati acquisiti dal Web (o da banche dati
esterne) o dei dati calcolati tramite funzioni matematico/statistiche.
Essi possono essere di due tipi:
•
Primari: Rappresentano i dati che sono stati acquisiti o da un Motori o da un Database
esterno (alcuni sono usati come chiavi di ricerca nel Web).
•
Derivati: Rappresentano i dati che sono stati calcolati da dati primari o da altri dari
derivati (al più vengono utilizzati come dati statistici per rappresentare una o più
politiche).
Inoltre gli indicatori possono appartenere a due classi di appartenenza: Smart Cities e ICT.
Per ulteriori informazioni, vedere l’introduzione di questo documento inerente agli indicatori.
Motivazione: Permettere l’acquisizione dati, la rappresentazione delle politiche, la
categorizzazione ed elaborazione ed categorizzazione dei dati in maniera semplice e flessibile,
formulando dei punti di incontro tra la definizione e l’analisi delle politiche e l’acquisizione dei
dati da parte del sistema.
RF29. Definire la qualità di un dato
Attori: Analista.
Dettagli: Per ogni dato acquisito da fonti esterne (Motori/Adapter Database), dovrà essere
associato un fattore di qualità, che indichi se esso è:
•
Sperimentale: Se il dato non è ancora da considerarsi affidabile, ed è ancora in fase di
studio.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 85 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
•
Unità complessa eGovernment
Affidabile: Se il dato è attendibile e può essere utilizzato senza alcun problema
dall’Analista per poterlo elaborare secondo le sue esigenze (definizioni politiche, calcoli
statistici, ecc...).
Infine, per ogni dato (sia esso sperimentale che affidabile) sarà definito un indicatore (con valore
da 0 a 1 inclusi) che indichi quanto “buono” sia il dato stesso.
Motivazione: Rendere tracciabili e mantenibili i dati, a fronte di possibili cambiamenti interni ed
esterni al sistema.
RF30. Aggregazione dei dati su base territoriale
Attori: Analista, Sistema (tramite Motori).
Dettagli: Associare per ogni dato la relativa regione spaziale, definibile o dal Motori (in questo
caso sarà stato chiesto al Motore di cercare i dati per una certa chiave di ricerca geografica, es:
comune di Musile di Piave o regione Veneto) o dall’analista stesso.
Motivazione: Rendere tracciabili i dati a livello territoriale per poter rappresentare l’andamento
di una politica in un determinato luogo.
4.4
Funzioni di Output – View Manager
Il componente View Manager dovrà gestire le visualizzazioni geo-referenziate, tabellari e
grafiche secondo un modello di estensibilità di tipo territoriale (tramite le opportune mappe). La
modularità va intesa anche nel senso di un supporto a diverse modalità di rappresentazione ed a
diverse periferiche, quali specifiche piattaforme hardware (PC, tablet, smartphone) e software
(Apple Ios, Google Android, Microsoft Windows, etc).
RF31. Visualizzazione mappe
Attori: Utente
Dettagli: il sistema dovrà dare la possibilità ai diversi utenti di poter visualizzare le mappegeoreferenziali a seconda dei privilegi assegnati.
Motivazione: lo scopo finale del progetto è proprio quello di poter interpretare in modo facile i
dati raccolti ed elaborati senza alcun prerequisito.
RF32. Trasmissione risultati ottenuti
Attori: Utente
Dettagli: il sistema trasmetterà al funzionario/policy maker i risultati ottenuti per ogni singola
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 86 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
campagna.
Motivazione: una volta raccolti i dati, conseguentemente elaborati il report finale verrà
opportunamente trasmesso agli attori interessati.
RF33. Visualizzazione delle proposte d’azione
Attori: Utente
Dettagli: il sistema darà la possibilità di individuare proposte d’azioni per recuperare le zone
individuate come critiche.
Motivazione: il sistema dovrà fornire proposte d’azioni oggettive al policy maker per sviluppare
le zone più critiche.
RF34. Definizioni privilegi per la visualizzazione delle statistiche
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità di definire livelli di accesso per i diversi attori o
utilizzatori del servizio offerto.
Motivazione: l’Ente o gestore del sistema definirà quali statistiche rendere pubblico o meno.
RF35. Selezione del Comune/i
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità di scegliere uno o più comuni (se è possibile
l’aggregazione) di cui l’utente vuole visualizzare le informazioni specifiche.
Motivazione: oltre alle mappe georeferenziate il funzionario deve poter selezionare la zona
territoriale di cui vuole ottenere dati specifici organizzati in grafici e tabelle.
RF36. Selezione indicatore/i
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità di scegliere gli indicatori di cui l’utente vuole
visualizzare le informazioni specifiche
Motivazione: l’utente potrà selezionare dalla lista completa uno o più indicatori per una
comprensione facilitata degli stessi
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 87 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
RF37. Cambiamento del metodo di visualizzazione
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità di cambiare il metodo di visualizzazione ed
organizzazione delle informazioni
Motivazione: l’utente potrà selezionare il metodo di visualizzazione che preferisce tra mappe
georeferenziate, istogrammi, diagrammi a barre e tabelle
RF38. Cambiamento dell’intervallo temporale
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità di cambiare l’intervallo temporale da cui
prelevare le informazioni
Motivazione: l’utente potrà modificare l’intervallo temporale in modo da poter verificare come
gli indicatori variano nel tempo.
RF39. Confronto con altri Comuni/Province/Regioni
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità di aggiungere un altro comune/provincia/regione
nel sistema di visualizzazione
Motivazione: l’utente potrà aggiungere un altro comune/provincia/regione in modo da poter
effettuare un confronto
RF40. Impostazione Comune ed Indicatore “sotto controllo”
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità di selezionare un indicatore di un determinato
comune ed una soglia critica, se l’indicatore supera tale soglia l’utente riceverà una notifica
Motivazione: l’utilizzatore rimarrà costantemente informato sulle variazioni critiche degli
indicatori che vuole tenere sotto controllo
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 88 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
RF41. Gestione degli indicatori “sotto controllo”
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità di gestire gli indicatori posti sotto controllo,
ovvero modificarli, rimuoverli o aggiungerne altri
Motivazione: l’utilizzatore deve poter gestire gli indicatori da lui stesso messi sotto controllo od
aggiungerne alla lista
RF42. Impostazione Comune ed Indicatore “preferito”
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità di selezionare un indicatore di un determinato
comune che verrà visualizzato in una lista per la fruizione rapida
Motivazione: l’utilizzatore in tal modo potrà raggiungere rapidamente le informazioni su
comuni ed indicatori di preferenza
RF43. Gestione degli Indicatori “preferiti”
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità di gestire gli indicatori posti nella lista dei
preferiti, ovvero modificarli, rimuoverli o aggiungerne altri
Motivazione: l’utilizzatore deve poter gestire gli indicatori da lui stesso messi nei preferiti od
aggiungerne alla lista
RF44. Visualizzazione del grado di affidabilità dei dati
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità all’utente di verificare l’affidabilità dei dati legati
ad un indicatore
Motivazione: l’utilizzatore deve poter verificare la bontà dei dati che riguardano un indicatore
per capire quanto sono affidabili gli stessi
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 89 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
RF45. Esportazione dei dati visualizzati
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità all’utente di esportare i dati visualizzati in file
excel o csv
Motivazione: l’utilizzatore deve poter esportare i valori degli indicatori che sta visualizzando in
file di formato tabellare per una successiva fruizione o elaborazione che non richieda l’accesso al
sistema
RF46. Visualizzazione avvisi
Attori: Utente
Dettagli: il sistema dovrà fornire la possibilità di fornire all’utente avvisi su eventuali modifiche
del sistema
Motivazione: l’utilizzatore deve poter essere avvisato nel caso di modifiche agli indicatori,
aggiunta di metodi di visualizzazione o altri cambiamenti
RF47. Aggiunta interfaccia
Attori: View manager
Dettagli: Il sistema è estensibile, sarà predisposto per l’aggiunta di nuove interfacce
Motivazione: Il View Administrator potrà aggiungere facilmente nuove interfacce per l’accesso
al sistema per un’utilizzo del sistema tramite più dispositivi possibili
RF48. Modifica interfaccia
Attori: View Administrator
Dettagli: Il sistema è predisposto per rendere facile e veloce la modifica delle interfacce
Motivazione: Il View Administrator potrà modificare le interfacce che accedono al sistema per
aggiornarle ai nuovi standard tecnologici
RF49. Visualizza elenco funzioni
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 90 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Attori: View Administrator
Dettagli: Il sistema è strutturato in modo che il View Administrator possa visualizzare un’elenco
delle funzioni attivabili sulle interfacce
Motivazione: Il View Administrator dovrà poter visualizzare una lista di funzioni per ogni
interfaccia che potranno essere abilitate o meno, tale lista verrà aggiornata man mano che
verranno aggiunte nuove funzionalità nel sistema
RF50. Abilita/Disabilita funzioni
Attori: View Administrator
Dettagli: Il sistema è strutturato in modo che il View Administrator possa abilitare o disabilitare
una determinata funzione di un ‘interfaccia
Motivazione: Il View Administrator dovrà avere la possibilità di abilitare o disabilitare una
funzione che corrisponde ad una determinata caratteristica di un’interfaccia
RF51. Visualizza elenco periferiche
Attori: View Administrator
Dettagli: Il sistema dovrà mostrare al View Administrator l’elenco completo delle periferiche
supportate dal sistema
Motivazione: Il View Administrator deve sapere quali periferiche sono supportate dal sistema e
quali funzionalità sono implementate e funzionanti sulle stesse
RF52. Visualizza avvisi
Attori: View Administrator
Dettagli: Il sistema dovrà mostrare al View Administrator l’elenco degli avvisi riguardanti le
interfacce
Motivazione: Il View Administrator deve poter visualizzare la lista degli avvisi riguardanti le
interfacce, quali nuove funzioni, nuovi aggiornamenti dispondibili.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 91 di 119
Unità complessa eGovernment
Dipartimento di Scienze Ambientali, Informatica e Statistica
4.5
Funzioni di Programmazione – Policy Manager
Politiche
Progetti
Azioni
Obiettivi
KPI indiretti
Soglie
Indicatori
KPI diretti
Rilevazione
iniziale
Rilevazioni
intermedie
Rilevazione
finale
RF53. Definizione delle politiche
Attori: Policy maker
Dettagli: il sistema darà la possibilità di definire gerarchicamente politiche, progetti, azioni e per
questi i relativi obiettivi ed assegnare le soglie ad una specifica selezione degli indicatori.
Motivazione: il sistema dovrà consentire un preciso monitoraggio dell’evoluzione degli
indicatori correlati alle politiche di intervento, nonché una rilevazione al termine delle
progettualità connesse.
RF54. Definizione delle proposte d’azione
Attori: Policy maker
Dettagli: il sistema darà la possibilità di individuare proposte d’azioni per recuperare le zone
individuate come critiche.
Motivazione: Il policy maker dopo aver esaminato le criticità e delle possibili proposte d’azione,
sceglierà che azioni compiere per migliorare la situazione
RF55. Definizione obiettivi
Attori: Policy maker
Dettagli: il sistema darà la possibilità di definire degli obiettivi da associare alle politiche
Motivazione: il sistema deve consentire al policy maker di associare dei determinati parametri
alle politiche che diventeranno gli obiettivi da perseguire
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 92 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
RF56. Associazione obiettivi indicatori (metriche)
Attori: Policy maker
Dettagli: il sistema fornirà la funzionalità di associazione obbiettivo ed indicatori
Motivazione: Il policy maker potrà definire le metriche che riguardano le politiche ovvero quali
indicatori le riguardano, quale base territoriale, e con che frequenza dovranno venire aggiornati
gli stessi
RF57. Visualizzazione politiche
Attori: Policy maker
Dettagli: il sistema darà la possibilità visualizzare l’insieme delle politiche
Motivazione: Il policy maker potrà visualizzare graficamente l’andamento generale delle
politiche da lui definite
RF58. Visualizzazione affidabilità indicatori
Attori: Policy maker
Dettagli: il sistema darà la possibilità al policy maker di visualizzare l’affidabilità degli
indicatori
Motivazione: Il policy maker potrà visualizzare tramite un parametro un valore approssimato
dell’affidabilità associata agli indicatori, perciò potrà decidere o meno di effettuare o meno una
determinata azione sulla base di tale parametro
RF59. Supervisione e Controllo conflitti nelle politiche
Attori: Policy Administrator
Dettagli: il sistema darà la possibilità al Policy Administrator di supervisionare i Policy Maker
Motivazione: Il policy administrator potrà controllare le politiche create dai policy maker ed i
loro obiettivi, verificare che non siano in conflitto tra loro e che il loro lavoro sia consistente.
RF60. Visualizzazione avvisi
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 93 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Attori: Policy administrator, policy maker
Dettagli: il sistema darà la possibilità di visualizzare avvisi del sistema
Motivazione: i policy maker ed i policy administrator saranno avvisati sulle nuove funzionalità
del sistema, sui nuovi indicatori a disposizione o sul raggiungimento di determinati obiettivi
RF61. Invio avvisi
Attori: Policy administrator, policy maker
Dettagli: il sistema darà la possibilità al policy administrator di inviare degli avvisi ai Policy
Maker
Motivazione: Il Policy administrator deve aver la possibilità di inviare delle notifiche ai Policy
maker nel caso riscontrasse incongruenze nella definizone delle politiche o per coordinare il
lavoro degli stessi
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 94 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
5 Requisiti Non Funzionali
I Requisiti Non funzionali non sono collegati direttamente con le funzioni implementate dal
sistema, ma piuttosto alle modalità operative e di gestione. Di seguito si evidenzieranno i vincoli
a cui il sistema si dovrà attenere.
5.1
RNF1.
Requisiti di Prodotto
Usabilità
Il sistema deve essere consultabile online dai cittadini/imprese senza nessuna particolare
conoscenza tecnica, al fine di non scoraggiare i meno abili nelle apparecchiature tecnologiche.
Gli amministratori e i funzionari dovranno invece sostenere un periodo di formazione al fine di
comprendere perfettamente l’uso della piattaforma, dei database e di tutto ciò che concerne la
buona riuscita del sistema.
RNF2.
Efficienza
Il sistema deve poter fornire un’ottima efficienza determinata dalla velocità di banda e
dell’apparecchiatura hardware a disposizione.
Il sistema deve rispondere ad ogni comando dell’utilizzatore entro pochi secondi.
RNF3.
Affidabilità
Il DBMS deve essere in grado di ricaricare l’ultima versione utile della base di dati in caso di
crash. Il sistema per tanto non deve consentire il verificarsi di errori critici, cioè di quelle
tipologie di errori che comportano la perdita di dati, o perlomeno limitarne considerevolmente la
probabilità.
Il sistema dovrà prevedere una quota di ore al mese per la manutenzione e gli aggiornamenti per
garantire un servizio ottimale.
L’acquisizione dei dati deve essere robusta e sicura, in particolare dovrà essere garantita la
corretta esecuzione delle campagne raccolta dati programmate, informando tempestivamente
l’amministratore di sistema in caso di anomalie o guasti.
RNF4.
Requisiti di Portabilità
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 95 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Tutti i dati memorizzati nel sistema avranno come codifica: UTF-8 (Unicode Transformation
Format, 8 bit) per permette di rappresentare tutti i caratteri, a differenza di codifiche più vecchie.
Il sistema dovrà consentire la fruizione online attraverso client con sistemi operativi diversi al
fine di garantire, al più ampio bacino di utenza, l’accesso al dato.
RNF5.
Authentication, Accounting & Auditing (AAA)
Il sistema SmeD dovrà consentire la tracciabilità degli utilizzi della piattaforma (auditing), la
misurazione del consumo di risorse per gli utenti delle viste (accounting), previa autenticazione.
I meccanismi di autenticazione dovranno poter essere governati anche su base territoriale (ad es.
un comune dovrà poter distribuire accessi gerarchicamente subordinati all’accesso di riferimento
per quel territorio).
5.2
RNF6.
Requisiti di Processo
Requisiti per la “bot maintenance”
I motori dovranno essere suscettibili di continua manutenzione per l’adattamento alle pagine web
di competenza (cfr. ruoli Engine Developer ed Engine Administrator).
Andranno definite delle APIs di riferimento per accelerare la scrittura dei motori da parte degli
Engine Developers e consentirne una corretta gestione all’interno di SmeD da parte dell’Engine
Manager.
RNF7.
Requisiti di implementazione
Per evitare la ridondanza dei dati e mantenere la base di dati in stato consistente si utilizzerà
un’unica base di dati comune.
Il DBMS (Database Management System) del sistema dovrà poter interoperare con i sistemi
operanti attualmente presso la Direzione Sistemi Informativi della Regione del Veneto
Il sistema dovrà dare continuità al servizio offerto con una tolleranza prevista per eventuali
aggiornamenti o anomalie hardware.
RNF8.
Requisiti sugli Standard
Per l’individuazione nel database dei Comuni interessati all’analisi verranno etichettati tramite la
codifica Istat e/o tramite i codici NUTS europei.
Le pagine web prodotte dovranno necessariamente superare la validazione dello standard W3C
per migliorare il supporto nei diversi browser.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 96 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Il formato standard per i report da consultare sarà il pdf per fornire la massima portabilità ed una
precisa conservazione del layout.
UTF-8 sarà la codifica adottata dal sistema in quanto predefinita dal formato XML.
Il sistema dovrà fornire in tutte le aree in cui transito informazioni sensibili la crittografia
HTTPS;
RNF9.
Business Continuity
SmeD dovrà poter operare con continuità, giorno per giorno, per diversi anni senza interruzioni
del flusso dei dati superiori a qualche frazione di una giornata.
5.3
Esterni
RNF10.
Requisiti di Interoperabilità
Il sistema dovrà garantire la capacità di interagire con sistemi, piattaforme, protocolli eterogenei.
RNF11.
Requisiti Etici
L’azienda si impegna a rispettare il Software Engineering Code of Ethics: documento che
specifica un codice etico per l’attività di ingegneria del software approvato da ACM e IEEE.
RNF12.
Requisiti Legislativi
Il sistema per favorire l’accesso a soggetti disabili agli strumenti informatici dovrà aderire ai
contenuti della Legge n.4 del 2004 (Legge Stanca)
Il sistema dovrà inoltre aderire alle raccomandazioni WAI (Web Accessibility Initiative)
promosse da W3C riguardanti il favorire l’accesso dei soggetti disabili.
5.3.1 Requisiti normativi (Agenda Digitale Italiana)
La piena coerenza del sistema tecnologico SmeD con gli obiettivi dell’Agenda Digitale come
recepita in termini della Cabina di Regia nazionale, si traduce nei seguenti:
RNF13.
Smart Cities
il sistema è da considerarsi quale elemento (sensoriale) fondativo per una infrastruttura
tecnologica in logica Smart Cities;
RNF14.
Cloud Computing
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 97 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
La tecnologia dovrà far leva sulla flessibilità e convenienza di logiche di gestione Cloud
Computing altamente flessibili, remote ed interagenti con altri servizi software as a service
(SaaS) e platform as a service (PaaS). Tali funzionalità potranno facilitare la condivisione dei
dati raccolti dalla Regione del Veneto con le Amministrazioni locali (Comuni, Province,
Prefetture). Ciò potrà comportare dei vincoli legati alla specifica tecnologia scelta:
Limite dei linguaggi: In una piattaforma, in genere, si possono utilizzare solo alcuni dei
linguaggi esistenti al mondo (es: su Google App Engine sono supportati solo il Java, Python, Go,
Ruby e, in maniera ridotta, php).
Limite delle librerie: Per un linguaggio utilizzato per lo sviluppo su una piattaforma cloud, in
genere, non si possono usare tutte le librerie e le funzioni native per quel linguaggio e infatti,
come esempio, nel Google App Engine vi sono dei limiti nell’uso della classe Socket per
richiedere pagine http dall’esterno.
RNF15.
Open Data
gli indicatori monitorati potranno incrementare in qualità, precisione, quantità, frequenza e
granularità di scala territoriale le informazioni disponibili in piena trasparenza ai cittadini Open
Data; l’infrastruttura potrà inoltre consentire una più efficace condivisione dei dati raccolti in
termini di disponibilità delle informazioni e delle funzionalità delle interfacce.
RNF16.
Estensibilità
Il sistema SmeD si muove su tre assi di specializzazione/estensibilità:
1
bot engines: modularità, strutturata su “motori” raccoglitori di dati (Engine Manager),
2
per territorio: declinazione territoriale in luoghi, fonti dati e siti web locali – blocchi
territoriali (vedasi ruolo analista e contesto indicatori); in alternativa, per analisi aziendali:
declinazione merceologica,
3
interfacce per ambito: adattabilità, sono previsti diversi layer di presentazione dei dati, con
viste anche su mobile/tablet (View Manager).
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 98 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
6 Cenni alla struttura dati
Figura 25 - Strutture dati: motori, indicatori e territorio.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 99 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Tabella: Istanza_bot_comune
Descrizione: Tabella che contiene la lista dei comuni su cui deve lavorare un bot, inoltre
contiene le informazioni sulla data in cui un determinato comune è stato assegnato ad un bot e
la data di fine elaborazione
Campi:
-
Id_istanza_bot_comune (Pk)
-
Id_esecuzione (Fk: Log_bot_esecuzione)
-
Fk_comune (Fk: Comune)
-
Valore
-
Assegnato
-
Completato
Tabella: Comune
Descrizione: Tabella che contiene la lista dei comuni con relative informazioni.
Campi:
-
Id_comune (Pk) (codice istat)
-
Nome
-
Descrizione
-
Gps_longitudine
-
Gps_latitudine
-
Cap
-
Codice_GoogleA
-
Fk_tipobot (Fk:Tipo Bot)
Tabella: Provincia
Descrizione: Tabella che contiene la lista delle province con relative informazioni.
Campi:
-
Id_provincia (codice istat)
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 100 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
-
Sigla_provincia
-
Codice ISO
-
Codice NUTS
-
Fk_regione (Fk: Regione)
Unità complessa eGovernment
Tabella: Regione
Descrizione: Tabella che contiene la lista delle regioni con relative informazioni
Campi:
-
Id_regione (codice istat)
-
Sigla_regione
-
Codice ISO
-
Codice NUTS
Tabella: Affidabilità comune
Descrizione: Tabella che contiene un valore dell’affidabilità dei dati raccolti su un determinato
comune con un determinata tipologia di bot, tale tabella serve perché in alcuni determinati
comuni, l’affidabilità di alcuni bot cambia drasticamente, percui bisogna tenerne conto nel
determinare il grado di affidabilità del risultato finale.
Campi:
-
Id_affidabilità_comune (Pk) (codice istat)
-
Fk_tecnica (Fk: Tecnica)
-
Fk_comune (Fk:Comune)
-
Valore
Tabella: Tipo Bot
Descrizione: Tabella che contiene la descrizione della tipologia dei bot usati (Es. BotTwitter,
BotYahoo, MitapBot…)
Campi:
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 101 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
-
Id_tipobot(Pk)
-
Nome
-
Descrizione
Unità complessa eGovernment
Tabella: Indicatore
Descrizione: Tabella che contiene le informazioni sul tipo degli indicatori, tra cui descrizione,
tecniche di raccolta, tipo di bot utilizzati, inoltre il campo booleano “Derivato” denota se tale
indicatore è derivato da un altro oppure se è un indicatore primario
Campi:
-
Id_indicatore(Pk)
-
Nome
-
Descrizione
-
Derivato (boolean)
-
Fk_tecnica (Fk: Tecnica)
-
Fk_tipobot (Fk: Tipo Bot)
Tabella: Derivazione Indicatori
Descrizione: Tabella derivata da Indicatore dove vengono tenute le informazioni sugli indicatori
derivati, il primo campo si riferisce all’indicatore derivato, il secondo all’indicatore da cui
deriva
Campi:
-
Id_derivazione_indicatore(Pk)
-
Fk_indicatore1 (Fk: Tipo Indicatore)
-
Fk_indicatore2 (Fk: Tipo Indicatore)
Tabella: Istanza_bot_indicatore
Descrizione: Tabella che contiene tutte le istanze dei bot in esecuzione con il parametro
impostato su un determinato indicatore
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 102 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Campi:
-
Id_istanza_bot_ind (Pk)
-
Id_esecuzione (Fk: Log_bot_esecuzione)
-
Fk_indicatore (Fk: Tipo Indicatore)
-
Valore
Tabella: Risultato
Descrizione: Tabella contenente il risultato finale dell’elaborazione dei bot, cioè il valore di un
indicatore con associato la localizzazione territoriale e la data di raccolta, inoltre viene indicato
se il risultato è derivato da una elaborazione di altri indicatori e se lo stesso è stato marcato
come valido da un ‘analista e quindi pronto per l’utilizzo e la visualizzazione dalla parte policy
Campi:
-
Id_risultato(Pk)
-
Nome
-
Valore
-
Derivato (boolean)
-
Data
-
Validato (boolean)
-
Fk_bot_comune (Fk:Istanza_bot_Indicatore)
-
Fk_bot_tipo_indicatore (Fk:Istanza_bot_Comune)
Tabella: Derivazione
Descrizione: Tabella derivata da risultati, tiene conto dei dati risultati nel caso siano derivati da
altri
Campi:
-
Id_derivazione(Pk)
-
Fk_risultato1 (Fk: Indicatore)
-
Fk_risultato2 (Fk: Indicatore)
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 103 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Tabella: Affidabilità
Descrizione: Tabella che contiene le informazioni sulla affidabilità di un dato indicatore, tale
dato sarà definito elaborando il valore dell’affidabilità del comune in relazione all’indicatore
scelto
Campi:
-
Id_affidabilità(Pk)
-
Fk_indicatore (Fk: Indicatore)
-
Bontà (valore da 0 a 1)
-
Sperimentale (boolean)
Tabella: Log_bot_esecuzione
Descrizione: Tabella che contiene informazioni su tutti i bot in esecuzione al momento
Campi:
-
Id_Log_bot_esec(Pk)
-
Status
-
Fk_tipobot (Fk:Tipo Bot)
Tabella: Log_bot
Descrizione: Tabella che contiene le informazioni su tutti i passaggi di status dei bot, con
annessa data e riferimento al tipo di evento avvenuto.
Campi:
-
Id_botlog(Pk)
-
Fk_idesecuzione (Fk: Log_bot_esecuzione)
-
Fk_evento
-
Timestamp
Tabella: Evento
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 104 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Descrizione: Contiene la descrizione degli eventi e degli status dei bot, che possono essere:
“Pronti”,”In Esecuzione”, “Pausa”, “Ripresa Esecuzione”, “Fine” (con successo), “Abort”
(interrotto da utente), “Errore”
Campi:
-
Id_evento (Pk)
-
Nome
-
Descrizione
-
Schema DB Policy
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 105 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Figura 26 - Tabelle relative a politiche/azioni/progetti e correlati obiettivi & indicatori.
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 106 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Tabella: Ente
Descrizione: Tabella che generalizza le entità territoriali contenute nelle tabelle “Regione”,
“Provincia”, “Comune” ed “Altro Ente”, nella quale sono contenute le informazioni comune
delle stesse come la descrizione ed il codice Istat.
Campi:
-
Id_ente(Pk)
-
Nome
-
Descrizione
-
Sito
-
Codiceistat
Tabella: Politica
Descrizione: Tabella che definisce le politiche territoriali distite ed univoche per ogni territorio,
i campi contengono le informazioni di base, come la descrizione ed il fondo totale a
disposizione.
Campi:
-
Id_politica(Pk)
-
Nome
-
Descrizione
-
Fondo_totale
-
Fk_ente (Fk:Ente)
Tabella: Obiettivo Politica
Descrizione: Tabella che definisce l’obiettivo specifico relativo ad una politica, questo obiettivo
ha un valore soglia di riferimento da raggiungere, viene specificato con un periodo stimato di
raggiungimento ed una periodicità di osservazione
Campi:
-
Id_obiettivo_politica(Pk)
-
Nome
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 107 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
-
Descrizione
-
Periodo_raggiungimento
-
Valore_obiettivo
-
Periodicità_osservazione
-
Fk_politica (Fk:Politica)
Unità complessa eGovernment
Tabella: Ambito
Descrizione: Tabella che definisce l’ambito di una politica ovvero il “dove” si andrà a valutare
e misurare l’andamento di una politica, ad ogni ambito sono associati più progetti d’azione
(vedi tab Progetti), ed indicatori.
Campi:
-
Id_ambito (Pk)
-
Nome
-
Descrizione
-
Investimento
-
Fk_politica (Fk: Politica)
Tabella: Progetto
Descrizione: Tabella che definisce un progetto che viene inteso come azione specifica da
misurare in un ambito di una determinata politica (Es. Ambito: “Imprese ICT nel territorio”,
Progetto: “Investimenti nelle imprese ICT”, “Profitto delle imprese ICT”…)
Campi:
-
Id_progetto (Pk)
-
Nome
-
Descrizione
-
Data_inizio
-
Data_fine
-
Fk_Ambito (Fk:Ambito)
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 108 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Tabella: Indicatore
Descrizione: Tabella che contiene la lista di tutti gli indicatori (derivati e non), con la
descrizione e la specifica del tipo di dato fornito ed una valutazione dell’affidabilità dello stesso
Campi:
-
Id_indicatore (Pk)
-
Nome
-
Descrizione
-
Formato_dato
-
Tipo_dato
-
Affidabilità
Tabella: Indicatore_Ambito
Descrizione: Tabella che evidenzia a quale Ambito ogni Indicatore appartiene.
Campi:
-
Id_indicatore_ambito (Pk)
-
Fk_indicatore (Fk:Indicatore)
-
Fk_ambito (Fk: Ambito)
Tabella: Indicatore_Progetto
Descrizione: Tabella che mette in relazione i Progetti con gli indicatori da valutare scelti dal
Policy Maker, sono anche descritti i campi “Periodicità” e “Fattore_moltiplicano” che
evidenziano rispettivamente il periodo di aggiornamento dell’indicatore, e quante estrazioni
vengono fatte mensilmente.
Campi:
-
Id_indicatore_progetto(Pk)
-
Fk_indicatore (Fk:Indicatore)
-
Fk_progetto (Fk: Progetto)
-
Periodicità
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 109 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
-
Unità complessa eGovernment
Fattore_moltiplica
Tabella: Soglia
Descrizione: Contiene la lista di tutte le soglie con annesso valore stimato e valore rilevato e
data di rilevazione.
Campi:
-
Id_soglia(Pk)
-
Data
-
Valore Stimato
-
Valore Rilevato
Tabella: Soglia_indicatore
Descrizione: Contiene la lista delle relazioni tra soglia ed indicatore per ogni progetto definito.
Campi:
-
Id_soglia_indicatore(Pk)
-
Fk_soglia (Fk: Soglia)
-
Fk_indicatore_progetto (Fk: Indicatore_progetto)
Tabella: Risultato Progetto
Descrizione: Tabella che conterrà tutte le statistiche sui risultati degli indicatori dopo la fase di
elaborazione dei bot, o il caricamento dei dati nell’indicatore presi da banche dati, sarà inoltre
presente un campo “pubblico” che indicherà attraverso un valore booleano se il risultato è
visibile a tutti o se è privato e quindi visibile solo a determinate classi di utenza.
Campi:
-
Id_risultato (Pk)
-
Valore
-
Data_inizio_raccolta
-
Data_fine_raccolta
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 110 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
-
Pubblico
-
Fk_ente
-
Fk_indicatore_progetto
Unità complessa eGovernment
7 Appendice
7.1
Quali indicatori?
Sono possibili numerose scelte per quanto riguarda gli indicatori. Non vi è infatti un unico
standard, sono diversi invece i framework proposti di misurazione/benchmark dei territori e della
società.
7.2
Indicatori Smart Cities
Di seguito riportiamo i 74 indicatori estratti da: “Smart cities Ranking of European mediumsized cities”, Ottobre 2007, www.smart-cities.eu. Si tratta di indicatori che sono in grado di
esprimere un aggiornato concetto di “città avanzata”, ovvero tecnologica, sostenibile e vivibile.
Gli indicatori sono raggruppati in sei categorie: economia, ambiente, qualità della vita, mobilità,
governance, persona. Per gli obiettivi di SmeD sarà necessario qualche adattamento in merito a:
-
granularità: per applicare gli indicatori ai comuni veneti (che non sono small-medium
cities)
-
frequenza: per rilevare gli indicatori a periodicità ravvicinate (mese / settimana, fino al
giorno).
7.2.1 Smart Economy – Competitiveness: ability to transform
1. Innovative Spirit
SC01 R&D expenditure in % of GDP
SC02 Employment rate in knowledge-intensive sectors
SC03 Patent applications per inhabitant
2. Entrepreneurship
SC04 Self-employment rate
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 111 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
SC05 New businesses registered
3. Economic image & trademarks
SC06 Importance as decision-making centre (HQ etc.)
4. Productivity
SC07 GDP per employed person
5. Flexibility of labour market
SC08 Unemployment rate
SC09 Proportion in part-time employment
6. International embeddedness
SC10 Companies with HQ in the city quoted on national stock market
SC11 Air transport of passengers
SC12 Air transport of freight
7.2.2 Smart People – Social & Human Capital
7. Level of qualification
SC13 importance as knowledge centre (top research centres, top universities etc.)
SC14 Population qualified at levels 5-6 ISCED
SC15 Foreign language skills
8. Affinity to life long learning
SC16 Book loans per resident
SC17 Participation in life-long-learning in %
SC18 Participation in language courses
9. Social and ethnic plurality
SC19 Share of foreigners
SC20 Share of nationals born abroad
10. Flexibility
SC21 Perception of getting a new job
11. Creativity
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 112 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
SC22 Share of people working in creative industries
12. Cosmopolitanism/Open-mindedness
SC23 Voters turnout at European elections
SC24 Immigration-friendly environment (attitude towards immigration)
SC25 Knowledge about the EU
13. Participation in public life
SC26 Voters turnout at city elections
SC27 Participation in voluntary work
7.2.3 Smart Governance – Participation: political strategies & perspectives
14. Participation in decision-making
SC28 City representatives per resident
SC29 Political activity of inhabitants
SC30 Importance of politics for inhabitants
SC31 Share of female city representatives
15. Public and social services
SC32 Expenditure of the municipal per resident in PPS
SC33 Share of children in day care
SC34 Satisfaction with quality of schools
16. Transparent governance
SC35 Satisfaction with transparency of bureaucracy
SC36 Satisfaction with fight against corruption
7.2.4 Smart Mobility – Transport and ICT
17. Local accessibility
SC37 Public transport network per inhabitant
SC38 Satisfaction with access to public transport
SC39 Satisfaction with quality of public transport
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 113 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
18. (Inter-)national accessibility
SC40 International accessibility
19. Availability of ICT-infrastructure
SC41 Computers in households
SC42 Broadband internet access in households
20. Sustainable, innovative and safe transport systems
SC43 Green mobility share (non-motorized individual traffic)
SC44 Traffic safety
SC45 Use of economical cars
7.2.5 Smart Environment – Natural Resources
21. Attractivity of natural conditions
SC46 Sunshine hours
SC47 Green space share
22. Pollution
SC48 Summer smog (Ozon)
SC49 Particulate matter
SC50 Fatal chronic lower respiratory diseases per inhabitant
23. Environmental protection
SC51 Individual efforts on protecting nature
SC52 Opinion on nature protection
24. Sustainable resource management
SC53 Efficient use of water (use per GDP)
SC54 Efficient use of electricity (use per GDP)
7.2.6 Smart Living – Quality of Life
25. Cultural facilities
SC55 Cinema attendance per inhabitant
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 114 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
SC56 Museums visits per inhabitant
SC57 Theatre attendance per inhabitant
26. Health conditions
SC58 Life expectancy
SC59 Hospital beds per inhabitant
SC60 Doctors per inhabitant (LF/HF)
SC61 Satisfaction with quality of health system
27. Individual safety
SC62 Crime rate
SC63 Death rate by assault
SC64 Satisfaction with personal safety
28. Housing quality
SC65 Share of housing fulfilling minimal standards
SC66 Average living area per inhabitant
SC67 Satisfaction with personal housing situation
29. Education facilities
SC68 Students per inhabitant
SC69 Satisfaction with access to educational system
SC70 Satisfaction with quality of educational system
30. Touristic attractivity
SC71 Importance as tourist location (overnights, sights)
SC72 Overnights per year per resident (HF!)
31. Social cohesion
SC73 Perception on personal risk of poverty
SC74 Poverty rate
7.3
Benchmarking Digital Europe
Riportiamo in questa sezione gli indicatori ICT-specifici proposti in sede europea. Questi
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 115 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
sono estratti da: “Benchmarking Digital Europe 2011-2015 – a conceptual framework”, i2010
High Level Group. Gli ambiti individuati sono: the ICT Sector, Broadband and Connectivity,
ICT usage by Households and Individuals, ICT usage by Enterprises, e-Public Services.
7.3.1 ICT Sector
A1
Share of the ICT sector in the economy measured as a proportion of GDP and of total
employment
A2
Growth of the ICT sector measured as a % change of value added at current and constant
prices.
A3
Ratio of the productivity level in the ICT sector with respect to the entire economy
A4
Productivity growth in the ICT sector.
A5
Size and nominal growth of ICT markets (IT and telecom)
A6
R&D expenditure by the ICT sector as a % of GDP
A7
R&D expenditure in the ICT sector as a % of total R&D expenditure in the business
sector (BERD)
A8
R&D expenditure in the ICT sector as a % of value added (in the ICT sector)
A9
Imports and exports of ICT goods and services as a % of total imports and exports
7.3.2 Broadband and Connectivity
B1
Broadband coverage: % of population reached by wired (e.g. DSL, cable, fiber), wireless
(e.g. Wifi, Wimax, Satellite) and mobile (e.g. EDGE, UMTS, HSPA) broadband access (by
region)
B2
Subscription numbers broken down by nominal speed (256, 512, 1024 (Kbps), 2, 4, 8, 16
(Mbps))
B3
Broadband price
B4
Number of broadband subscriptions per 100 inhabitants (broken down by platform)
B5
% of households with internet access at home
B6
% of households with internet access via broadband
B7
Places for accessing the internet in the last three months
B8
% of individuals accessing the internet through mobile connections
B9
Reasons for not having internet access at home.
B10 % of persons employed using computers connected to the internet in their normal work
routine
B11 % of enterprises with broadband access (fixed or mobile)
B12 % of enterprises giving devices for a mobile connection to the internet to their employees
B13 % of persons employed provided by the enterprises with devices for a mobile connection to
the internet
7.3.3 ICT usage by Households and Individuals
C1
C2
% of individuals using the internet at least once a week
% of individuals using the internet every day or almost every day
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 116 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
Personal communication:
C3
Sending/receiving e-mails
C4
Telephoning, videocalls over the internet
C5
Other communication uses (chat sites, messenger, etc.)
C6
Participating in social networking (facebook, twitter, etc.)
Use of entertainment (web TV and radio, online games, music and videos):
C7
Listening to web radios or watching web TV
C8
Uploading games, images, films or music files to be shared
C9
Downloading games, images, films or music
C10 Playing networked games
Access to information:
C11 Reading / downloading online newspapers / news magazines
C12 Subscribing to news services or products to receive them regularly (including RSS, … )
/biannual/
C13 Seeking health information (on injuries, diseases, nutrition)
C14 Looking for information about education, training, courses
C15 Looking for information about goods or services
C16 Downloading software (Other than games)
Civic and political participation:
C17 Accessing or posting opinions on websites (e.g. blogs, social networks, etc) for
discussing civic and political issues
C18 Taking part in consultations, voting and opinion polls on-line on political issues
Creativity (user generated content: photos, music, blogs, wikipedia):
C19 Creating websites or blogs
C20 Uploading self created content (including software) to any website to be shared
Learning:
C21 Doing an online course
C22 Using wikis
e-Health:
C23 Making an appointment with a practitioner
C24 Consulting a practitioner online
Managing of personal finance/personal administration:
C25 e-banking
e-Commerce:
C26 Selling of goods or services
C27 Purchasing goods or services
C28 Cross-border purchases
C29 Purchasing services related to travel and accommodation
Professional life:
C30 Looking for a job or sending a job application proxies
C31 Using professional networking sites Linkedin
e-Skills
C32 % of individuals with computer skills (none, low, medium, high)
C33 % of individuals with internet skills (none, low, medium, high)
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 117 di 119
Dipartimento di Scienze Ambientali, Informatica e Statistica
Unità complessa eGovernment
e-Inclusion
Analysis will be based on indicators of the level of disparity in internet usage and skills, based
on break down by gender, age, employment situation, education level, household income, area of
residence, migrant status
7.3.4 ICT usage by Enterprises
Internal processes
D1
Integration of internal business processes: % of enterprises whose internal business
processes are automatically linked
D2
% of enterprises using dedicated application for employees to access human resources
services
Integration with customers/suppliers and SCM
D3
% of enterprises electronically exchanging business documents with suppliers and/or
customers broken down by type of document
D4
% of enterprises sharing electronically information on supply chain management broken
down by business function
D5
% of enterprises sending and/or receiving e-invoices
Key technologies for the internet of things
D6
% of enterprises using key technologies for the internet of things, by purpose
e-Commerce, Customer Relation management (CRM) and secure transactions
D7
% of enterprises having a website with e-commerce functions
D8
% of enterprises using software applications for managing information about clients, like
CRM
D9
enterprises' turnover from e-commerce as % of total turnover
D10 % of enterprises selling by e-Commerce
D11 % of enterprises purchasing by e-Commerce
D12 % of enterprises doing e-commerce transactions broken down by destination (National, EU,
World)
7.3.5 e-Public Services
E1
online availability and interactivity of the 20 basic public services for citizens and
enterprises
E2
% of individuals using the internet for interacting with public authorities by level of
sophistication
E3
% of enterprises using the internet for interacting with public authorities broken down by
level of sophistication
Analisi dei requisiti e specifiche tecniche
Smart eGovernment Dashboard (SmeD), D1 Rev.1.0 del 30/06/2013
Pag. 118 di 119