Direzione Generale
Direzione Generale
07-01-01 Servizio Sistemi Informativi
Realizzazione di un sistema informativo per la promozione della rete escursionistica e ciclabile regionale
Capitolato Speciale d'Appalto
Procedura telematica di acquisto ai sensi dell’art. 36 del D.Lgs. n. 50/2016
[CIG 7580083260]
Oggetti Significativi Territoriali (OST) 30
Linee guida per l’architettura dell’informazione del sistema SIN2 33
Articolo 6 bis. Voci della fornitura 35
O-ADPST (Architecture-Deploy-Performance-Security-Testing) 50
O-FSUP (Formazione e Supporto) 53
O-CON (Passaggio di consegne) 55
O-MAN (Servizi di Manutenzione correttiva) 55
Articolo 7. Modalità operative di realizzazione della fornitura 57
Articolo 8. Gestione del progetto e fasi 57
Articolo 9. Articolazione temporale del progetto e SAL 61
Articolo 10. Corrispettivi e condizioni di fatturazione 61
Articolo 11. Competenze, esperienze e qualificazione del team di progetto 62
Articolo 12. Criteri di valutazione delle offerte 64
Articolo 13. Documentazione 67
Articolo 14. Livelli di servizio (SLA) 67
Articolo 14bis. Penalità e recesso dal contratto 71
Articolo 15. Aggiudicazione dell’R.D.O. e stipula del contratto 72
Articolo 16. Garanzia definitiva 73
Articolo 17. Conoscenza delle condizioni e revisione prezzi 74
Articolo 18. Regolamento Generale sulla Protezione dei Dati (UE/2016/679) 74
Articolo 20. Divieto di subappalto 75
Articolo 21. Divieto di sospensione dei servizi 76
Articolo 22. Patto di integrità 76
Articolo 23. Esonero responsabilità 76
Articolo 24. Contatti con l'unità ordinante 77
Articolo 25. Foro competente 77
Acronimi e sigle
RAS | Regione Autonoma della Sardegna |
SITAC | Sistema Informativo del Turismo, Artigianato e Commercio |
SIRED | Sistema Informativo di Raccolta ed Elaborazione Dati turistici |
SIRA | Sistema Informativo Regionale dell’Ambiente |
IDM | Identity Management |
AO | Area Operatori |
CSR | Centro Servizi Regionale |
SOA | Service Oriented Architecture |
SSO | Single sign on |
CNS | Carta Nazionale dei Servizi |
CIE | Carta di Identità Elettronica |
CRS | Carta Regionale dei Servizi |
API | Application Programming Interface |
SEO | Search Engine Optimization |
POI | Point of Interest |
REST | Representational State Transfer |
RDF | Resource Description Framework |
RDFS | Resource Description Framework Schema |
OWL | Ontology Web Language |
GPL | General Public License |
SNS | Social Network Site |
UX | User Experience |
UXA | User Experience Analysis |
MTB | Mountain Bike |
RES | Rete Escursionistica e ciclo-escursionistica della Sardegna (sentieri tipicamente per |
il trekking e il biking (MTB) | |
RIS | Rete delle Ippovie della Sardegna |
RICSS oppure RICS | Rete degli itinerari Ciclabili su Strada (della Sardegna) |
ARST | Azienda Regionale Sarda Trasporti |
WFS | Web Feature Service, Servizio per l’erogazione di dati Gis secondo le spoecifiche standard dell’Open Geospatial Consortium |
OGC | Open Geospatial Consortium |
Articolo 1. Premessa
L’affidamento di cui al presente Capitolato avverrà tramite richiesta di offerta (RDO) sul MEPA, Mercato Elettronico della Pubblica Amministrazione.
L’aggiudicazione avverrà in base al criterio dell’offerta economicamente più vantaggiosa ai sensi dell’art. 95 del D.Lgs n. 50/2016.
Le Condizioni Generali del bando MEPA SERVIZI sono integrate e modificate dalle clausole del presente Capitolato, le quali prevarranno in caso di contrasto.
Nello stesso modo, l'indicazione puntuale dei servizi indicati in questo documento ha prevalenza rispetto alle relative righe di catalogo eventualmente utilizzate per comporre la Richiesta di Offerta (RdO), le quali hanno lo scopo di indicare il prodotto di massima.
Per quanto premesso, si richiede espressa accettazione di tutte le condizioni indicate nel presente Capitolato mediante la sottoscrizione dello stesso con firma digitale da parte del Rappresentante Legale della società partecipante.
Il presente Capitolato controfirmato digitalmente dovrà essere obbligatoriamente allegato all'offerta, a pena di esclusione. Saranno esclusi dalla procedura gli operatori economici concorrenti che presentino offerte nelle quali siano sollevate eccezioni e/o riserve e/o condizioni di qualsiasi natura ai termini di fornitura specificati nel Capitolato, ovvero offerte che sostituiscano, modifichino e/o integrino le predette condizioni, nonché offerte incomplete e/o parziali.
Articolo 2. Oggetto e ammontare dell’appalto
Il presente Capitolato regolamenta la realizzazione di un sistema informativo con la finalità di rendere disponibili al turista attivo le basi informative degli enti regionali per la promozione della rete escursionistica e ciclabile regionale.
Il presente appalto rientra nel progetto INTENSE "Itinerari Turistici Sostenibili" finanziato dal Programma INTERREG Italia-Francia Marittimo, programmazione 2014-2020, Asse Prioritario II (Protezione e valorizzazione delle risorse naturali e culturali e gestione dei rischi), Lotto 3, con Priorità 6c e Obiettivo Specifico 1 (Migliorare l’efficacia delle azioni pubbliche nel conservare, proteggere, favorire e sviluppare il patrimonio naturale e culturale dello spazio di cooperazione). Tipo di Progetto: strategico integrato tematico.
Per la realizzazione dei servizi sopra indicati, l’importo previsto per la base d’asta è di €
€135’725,41 (euro centotrentacinquemilasettecentoventicinque/41) oltre l’IVA dovuta ai sensi di legge.
Considerata la natura del servizio in oggetto e le modalità di svolgimento del contratto, non sono previsti particolari rischi ai fini della sicurezza, rispetto a quelli specifici dell’attività propria dell’operatore economico. Pertanto, non è necessaria l’elaborazione del documento unico di valutazione dei rischi da interferenze (D.U.V.R.I.) e non sono previsti oneri per la sicurezza non soggetti a ribasso.
Infine, i servizi oggetto del presente appalto non sono oggetto dei criteri ambientali minimi adottati nell’ambito del Piano d’azione per la sostenibilità ambientale dei consumi nel settore della pubblica amministrazione, di cui all’art. 34 del D.Lgs 50/2016.
Articolo 3. Requisiti per la partecipazione
I concorrenti dovranno dimostrare di essere in possesso, a pena di esclusione, dei seguenti requisiti di partecipazione:
- assenza della cause di esclusione di cui all’art. 80 del D.Lgs. n. 50/2016;
- attestazione, ai sensi dell’art.83, comma 1, lett. c) del D.Lgs. n. 50/2016:
o dell’elenco dei principali servizi analoghi a quello oggetto del presente affidamento, di cui almeno uno prestato ad una pubblica amministrazione, resi negli ultimi tre anni con l’indicazione degli oggetti delle prestazioni, dei destinatari
pubblici e privati, delle date e degli importi, questi ultimi complessivamente pari ad almeno 130’000,00 € IVA esclusa;
o dei titoli di studio e professionali - dei prestatori di servizi o dei dirigenti dell’impresa concorrente e, in particolare, dei soggetti concretamente responsabili della prestazione di servizi - che soddisfino i requisiti minimi prescritti dall’art.11 del presente Capitolato.
Ai sensi dell’art. 83, comma 8 del D.Lgs. n. 50/2016, i requisiti per la partecipazione indicati nel presente Capitolato sono espressi come livelli minimi di capacità, e devono essere adeguatamente comprovati e documentati dall’offerente in sede di offerta. L’amministrazione procedente effettuerà la verifica formale e sostanziale delle capacità realizzative, delle competenze tecniche e professionali, ivi comprese le risorse umane, organiche all'impresa, nonchè delle attività effettivamente eseguite.
In caso di operatori raggruppati, il requisito generale ai sensi dell’art. 80 del D.Lgs 50/2016 deve essere posseduto da ciascuna impresa componente il raggruppamento e, in caso di consorzi di cui all’articolo 45 comma 2 lett. b) e c), sia dal consorzio che dalle imprese indicate quali esecutrici.
E’ ammesso l’avvalimento nei limiti e con le modalità di cui all’art. 89 del D.lgs 50/2016.
È vietato il ricorso all’istituto dell’avvalimento per la soddisfazione dei requisiti generali.
E' fatto divieto di chiedere l’invito contemporaneamente sia in forma individuale che in forma di componente di un raggruppamento o consorzio, ovvero come componente di più di un raggruppamento temporaneo o più di un consorzio, ovvero come componente sia di un raggruppamento temporaneo che di un consorzio. Ai sensi dell’art. 48, comma 7, del D.Lgs. 50/2016, i consorzi di cui all'art. 45, comma 2, lettere b) e c) del citato decreto sono tenuti ad indicare per quali consorziati presentano domanda.
Le carenze di qualsiasi elemento formale della domanda di partecipazione potranno essere sanate attraverso la procedura di soccorso istruttorio di cui al comma 9 dell’art. 83 del D.Lgs. n. 50/2016. Resta inteso sin d’ora che la stazione appaltante assegnerà al concorrente
un termine di 5 (cinque) giorni lavorativi, a pena di esclusione, affinché dal medesimo siano rese, integrate o regolarizzate le dichiarazioni necessarie, indicandone il contenuto e i soggetti che le devono rendere.
Articolo 4. Modalità di presentazione dell’offerta
Per la partecipazione alla RDO in oggetto, le imprese concorrenti dovranno caricare, nelle apposite sezioni del MEPA, esclusivamente per via telematica ed in formato elettronico, i seguenti documenti:
1) “documentazione amministrativa”, consistente in:
a) copia del presente Capitolato controfirmato digitalmente dal fornitore per sua totale espressa accettazione, a pena di esclusione;
b) dimostrazione del possesso dei requisiti generali di cui all’art. 80 del D.Lgs. n. 50/2016. Si precisa che, qualora la dichiarazione non sia anche espressamente e nominativamente resa nei confronti di ciascuno dei soggetti di cui all’art. 80, comma 3 del D.Lgs. n. 50/2016, andrà prodotta, da tali soggetti, apposita dichiarazione resa ai sensi del DPR n. 445/2000 attestante l’assenza delle cause di esclusione ivi indicate, nonché la presa visione dell’informativa di cui all’art. 13 del D.Lgs. n. 196/2013 e smi;
c) attestazione, ai sensi dell’art.83, comma 1, lett. c) del D.Lgs. n. 50/2016, redatta in conformità al modello allegato (All. 1), dell’elenco dei principali servizi analoghi a quello oggetto del presente affidamento, di cui almeno uno prestato ad una pubblica amministrazione, resi negli ultimi tre anni con l’indicazione degli oggetti delle prestazioni, dei destinatari pubblici e privati, delle date e degli importi, questi ultimi complessivamente pari ad almeno 130’000,00 € IVA esclusa;
d) adeguata documentazione a comprova della realizzazione dei servizi analoghi di cui al punto precedente; per le finalità di cui all’art.29 del D.Lgs. n. 50/2016, è richiesta già in sede di offerta adeguata documentazione a comprova delle
attestazioni rese, consistente nei certificati di regolare esecuzione rilasciati dai committenti per i servizi svolti; nel caso di committenti privati la comprova potrà avvenire con la trasmissione delle fatture e delle relative evidenze bancarie che ne documentino il pagamento;
e) attestazione, ai sensi dell’art.83, comma 1, lett. c) del D.Lgs. n. 50/2016, redatta singolarmente da ciascuno dei soggetti in conformità al modello allegato (All. 2), dei titoli di studio e professionali dei soggetti concretamente responsabili della prestazione dei servizi; i requisiti devono soddisfare i requisiti minimi prescritti dall’art.11 del presente Capitolato;
f) attestazione, a pena di esclusione, dell’avvenuto versamento del contributo ANAC; la mancata dimostrazione dell’avvenuto versamento è causa di esclusione dalla procedura di scelta del contraente ai sensi dell’art. 1, comma 67 della L. 266/2005;
g) garanzia provvisoria, rilasciata in conformità a quanto disposto dall’art. 93 del D.Lgs. n. 50/2016, per un importo pari al 2 per cento del valore complessivo stimato dell’appalto. Detto importo potrà essere ridotto del 50 per cento qualora l’impresa sia in possesso della certificazione del sistema di qualità conforme alle norme europee della serie UNI CEI ISO 9000 da comprovare mediante inserimento nella documentazione di gara di copia della certificazione in corso di validità;
h) impegno di un fideiussore, a pena di esclusione ai sensi del comma 8 dell’art. 93 del D.Lgs. n. 50/2016, a rilasciare la garanzia definitiva in caso di aggiudicazione;
i) Patto di integrità della Regione Sardegna sottoscritto con firma digitale dal Legale Rappresentante dell’impresa concorrente
j) Eventuale documentazione relativa all'avvalimento;
k) Eventuali atti relativi a R.T.I. o Consorzi.
NOTA BENE: i documenti dovranno essere sottoscritti dai dichiaranti e/o dal concorrente, a pena di esclusione, con firma digitale e ad essi dovrà essere allegato documento di identità in corso di validità.
2) “offerta tecnica”, firmata digitalmente ed allegata nell’apposita sezione del MEPA, a pena di esclusione;
3) “offerta economica”, firmata digitalmente ed allegata nell’apposita sezione del MEPA, a pena di esclusione.
Articolo 5. Descrizione del contesto
La sfida affrontata dal progetto INTENSE, in maniera congiunta nei territori della Toscana, Liguria, PACA, Corsica e Sardegna, consiste nell'individuazione e nella gestione integrata di un sistema di itinerari turistici sostenibili, che interessa tutti i territori senza soluzione di continuità, per la promozione del turismo ciclabile ed escursionistico.
Un risultato preliminare del progetto è stata la definizione di un modello del dato e delle tassonomie per la rappresentazione di una proposta di fruizione dell’itinerario transfrontaliero, individuato dal progetto INTENSE, che tiene conto di quanto è in uso nei differenti territori per la descrizione e presentazione delle proposte turistiche di itinerari ciclabili, escursionistici e cicloescursionistici al turista attivo. Allo stesso tempo, allo scopo di indentificare le buone pratiche nella gestione e presentazione delle proposte turistiche al turista attivo, sono state censite le basi di dati e i servizi che erogano il dato utile alla costruzione della proposta turistica nell’area transfrontaliera.
Per quanto riguarda la Sardegna, i partner di progetto coinvolti nella realizzazione del presente appalto sono RAS, CRS4 e Agenzia Forestas, firmatari allo scopo di uno specifico accordo ai sensi dell’art. 15 della L. 241/90.
Il progetto INTENSE è inoltre collegato ad ulteriori attività progettuali portate avanti dalla Regione Sardegna, CRS4 e Forestas nell’ambito della programmazione 2014/2020.
In particolare i dati raccolti su INTENSE verranno resi disponibili nel progetto SMART DESTINATION (Interreg Marittimo Italia-Francia) e il progetto si integra nelle iniziative intraprese nell’ambito del POR FESR 2014/2020 - Azione 2.2.2 - Evoluzione della piattaforma SardegnaTurismo e dell’Osservatorio del Turismo, Artigianato e Commercio sfruttando gli ambienti cloud costruiti in tale contesto e fornendo nuovi dati per l’offerta di servizi turistici e per l’analisi dell’Osservatorio.
Di seguito si opera una descrizione del contesto di riferimento dal punto di vista territoriale e tecnologico.
Panoramica generale sulle ciclovie e i sentieri Forestas
Rientra fra le competenze dell’Agenzia Forestas la gestione del patrimonio naturalistico della Regione Sardegna, rappresentano dalle oltre 40 Foreste Demaniali. Attualmente inoltre Forestas gestisce circa 220.000 ha - pari a circa il 10% di tutta la superficie Regionale - in cui
sono incluse aree di elevato pregio ambientale, naturalistico e paesaggistico fra cui Parchi Nazionali e Regionali, aree SIC e ZPS.
In ambito forestale, gli obiettivi che l'Ente persegue, sono incentrati verso attività tese alla gestione sostenibile delle foreste, anche attraverso la realizzazione di percorsi escursionistici per la valorizzazione turistico-ricreativa. In quest’ottica l’Ente collabora con l’Assessorato Regionale al Turismo, artigianato e Commercio, con gli altri enti-parco localmente presenti nel territorio isolano, con Università e Istituti di ricerca, con il Club Alpino Italiano e varie altre associazioni del settore “Turismo Attivo”, anche connessi con lo sviluppo della RES (Rete Escursionistica della Sardegna) e della rete ciclo/escursionistica istituite con Legge Regionale n.16/2017.
L’attività svolta nell’ambito del progetto INTENSE comprenderà gli interventi di valorizzazione di alcune aree protette co-gestite dall’ente foreste (Oasi Tepilora, area protetta forestale-marina di Porto Conte – Le Prigionette – Alghero). Inoltre sarà fondamentale il know- how maturato dall’Ente Foreste nella realizzazione e gestione, sin dal 2000, di una diffusa Rete Escursionistica nelle foreste demaniali di tutta l’isola (circa 1000 km di percorsi, ad oggi) nonché il know how maturato con la partecipazione al progetto semplice CoREM (sottoprogetto b, in parternariato con le due regioni della Corsica, le precedente bando P.O.Marittimo IT/FR) dove è stata curata la realizzazione di un Sistema Informativo per la gestione del Catasto Sentieri ed un sito web (xxx.xxxxxxxxxxxxxxxx.xx ancora in attività e continuamente evoluto con investimenti propri). Tutto ciò anche attraverso l’utilizzo di strumenti e tecnologie Open-Source.
Attività di Forestas connesse al progetto INTENSE:
- Presenza ed operatività su scala regionale in gran parte delle aree naturalistiche protette
- Pregressa gestione della RES (circa 1000km di percorsi di trekking)
- Partecipazione a vari tavoli tecnici regionali, tra i quali quello con l’assessorato regionale al Turismo, Artigianato e Commercio per lo sviluppo della filiera
ciclo/escursionistica, con l’assessorato regionale alla Difesa Ambiente per lo sviluppo del CATASTO REGIONALE SENTIERI (fra gli altri, nell’ambito del progetto SIRAnet, Sistema Informativo Regionale dell’Ambiente, recentemente ceduto in riuso anche alla Regione Friuli V.G.)
- Collaborazione con l’xxx.xx regionale ai LL.PP. per la redazione preliminare del c.d. “piano Straordinario per la ciclabilità” recentemente approvato con DELIBERAZIONE N. 22/1 DEL 7.5.2015 - Protocollo triennale di intesa per la gestione della RES stipulato con il raggruppamento CAI Sardegna nel 2015.
Quadro di contesto tecnologico
Il contesto nel quale deve inserirsi il sistema oggetto del presente capitolato è rappresentato dal seguente flusso informativo:
Le componenti indicate nel diagramma sono di seguito dettagliate per fornire un quadro di contesto complessivo.
Catasto Sentieri escursionismo e cicloescursionismo
Sarà ospitato dall’ass. regionale all’ambiente presso il SIRA (Sistema Informativo Regionale dell’Ambiente) e gestito dall’Agenzia Forestas insieme al medesimo assessorato. All’attualità non è stata rilasciata una versione operativa dell’applicazione. All’attualità non è disponibile un’istanza completamente popolata con i dati della rete escursionistica.
Di seguito si forniscono alcuni elementi conoscitivi sul progetto per la realizzazione del Catasto Sentieri nel sistema regionale SIRA, che a regime ospiterà tutte le procedure, i dati alfanumerici e geografici (tracce e nuvole di punti di interesse associati al SEntiero).
Descrizione SIRA
Il SIRA Sardegna rappresenta un sistema informativo di notevole complessità, la cui efficiente ed efficace operatività potranno essere garantite solo da una corretta ed equilibrata integrazione e cooperazione di elementi tecnici, organizzativi e tecnologici.
Il SIRA Sardegna è stato realizzato per consentire la condivisione e la fruizione, da parte della Comunità di utenti dello “spazio SIRAnet della Sardegna”, dell’informazione di rilevanza ambientale disponibile per il territorio regionale, elaborata e rappresentata nelle forme, secondo i punti di vista e le esigenze conoscitive di utenti pubblici e privati, diversi sia per formazione che per le finalità di impiego. Le principali finalità alla base della realizzazione del progetto SIRA, possono essere così riassunte:
● la costituzione di un’infrastruttura per la gestione, l’accesso e la diffusione dei dati ambientali, integrata con l’esistente infrastruttura dedicata ai dati territoriali (IDT del SITR);
● l’integrazione dei dati di rilevanza ambientale già disponibili, ai fini della loro
condivisione in rete;
● la realizzazione dei principali Moduli applicativi per le Aree tematiche prioritarie e l’automazione dei processi di popolamento della comune base di conoscenza del SIRA;
● la fornitura in rete dei servizi a tutti gli utenti dello spazio SIRANet, siano essi Enti pubblici e privati, imprese, cittadini, associazioni ambientali.
Il progetto del SIRA Sardegna è stato quindi articolato in tre ambiti d’azione principali, tra di loro strettamente integrati:
1. il Modulo Comune dello spazio SIRAnet, comprendente servizi comuni (web services) di gestione della base regionale di conoscenza ambientale, condivisi in rete, la Porta di Dominio (PdD) del SIRA, la comune base regionale di conoscenza ambientale e la base dati “riconciliata” da esporre nel dominio SINAnet, conforme al modello logico condiviso determinato dagli standard SINAnet proposti per le diverse aree tematiche;
2. l’infrastruttura tecnologica e di rete, che abilita i servizi del Modulo comune, i diversi Moduli applicativi e la fruizione della base di conoscenza ambientale sulla rete telematica regionale;
3. i Moduli applicativi “specializzati”, dedicati alle diverse Aree tematiche, all’automazione di processi intertematici, al controllo ed alla bonifica dei dati provenienti da “datasource esterni” o non conformi ed al supporto decisionale.
Il SIRA è stato realizzato nel pieno rispetto degli standard del Sistema Pubblico di Connettività e Cooperazione ed in esso integrato, rendendo disponibili alla Comunità di utenti dello spazio SIRAnet specifici servizi informatici utilizzabili anche tramite cooperazione applicativa, creando così le condizioni per rendere interoperabili i sistemi informativi degli enti che partecipano al dominio SIRAnet.
I servizi erogati dal SIRA sono stati realizzati in modo che essi siano disponibili nella Intranet della RAS, per gli utenti del dominio SIRAnet, che attraverso Internet, cioè per utenti pubblici e privati non appartenenti al dominio.
Oltre a quanto sopra descritto, il SIRA comprende servizi software che migliorano la gestione dell’intero sistema, ad esempio servizi comuni per il controllo accessi all’infrastruttura, etc… L’accesso ai servizi del SIRA avviene mediante delle interfacce conformi ai vincoli tecnici indicati dalle linee guida e dagli standard per il SPCoop previsti dal piano di e-government, nonché nelle specifiche OGC (Open GIS Consortium); è quindi richiesto un diffuso impiego del protocollo SOAP, del formalismo WSDL e dello standard XML, al fine di consentire la cooperazione applicativa e l’interscambio dei dati tra architetture eterogenee. Servizi e dati del SIRA si appoggiano sull’infrastruttura regionale di supporto alla connettività ed alla cooperazione applicativa e sull’infrastruttura regionale di rete a banda larga
All’interno del sistema SIRA, la subarea funzionale n.3 include i moduli per la c.d. “gestione Forestale” Questo modulo ha lo scopo di soddisfare le esigenze dell’Agenzia Forestas, i cui compiti istituzionali sono definiti nella Legge Regionale del 2016 n.8.
Vista la peculiarità della tematica si è reso necessario concordare con lo stessa Agenzia Forestas la migliore soluzione tecnica operativa a valle di un tavolo tecnico necessario per la definizione dei campi e delle relazioni tra gli OST. L’istruttoria è in corso, ma
sono stati definiti nelle parti fondamentali il modello del dato e l’architettura del c.d. catasto sentieri e dei POI (point of interest) ad essi collegati.
I catasti e moduli per questa area tematica consentono di raccogliere in modo storicizzato e georiferito tutte le informazioni relative a: strutture forestali, fabbricati, terreni, sentieri pedonali e attività della sentieristica, strade forestali, laghetti collinari, vivai, centri fauna, autoparchi e opifici dell’agenzia Forestas. Essi sono strutturati e implementati per poter essere una fonte sempre aggiornata di alimentazione del quadro conoscitivo per i diversi fini istituzionali (informazione, pianificazione e controllo) e per soddisfare le esigenze informative sulla gestione forestale, inclusa la sentieristica.
Il SIRA prevede la perfetta integrazione di funzioni e dati del sistema suddetto attraverso un interfacciamento o una totale e completa trasposizione di funzioni e dati. Le modalità di integrazione e le varie specifiche per la caratterizzazione degli oggetti all’interno del SIRA verranno decise tramite tavoli.
Il sistema permette quindi una caratterizzazione dell’oggetto completa della sua impronta geometrica secondo la metodologia di “segmentazione dinamica”. L’efficienza e la funzionalità del catasto in oggetto dipende dalla tipologia di OST gestiti e non gestiti che caratterizzano il dominio applicativo e dalle relazioni funzionali che sono impostate tra essi. L’insieme degli OST e le relazioni tra essi permettono all’utente finale di mappare esaustivamente sia le situazioni fisiche realmente esistenti sia le informazioni relative agli aspetti tecnico-amministrativi dei procedimenti.
Il progetto per la realizzazione del catasto SENTIERI nel SIRA lo configura come un catasto trasversale, in quanto la sentieristica può essere realizzata e gestita da differenti enti. Il catasto è stato strutturato sulla base della pluriennale esperienza dell’Ente Foreste della Sardegna, nella progettazione e realizzazione delle sentieristica in Sardegna.
Nel catasto della sentieristica gli elementi di rilevanza ambientale sono del tipo OST “gestito”. Le interfacce grafiche, sono modulate a seconda del profilo utente, ovvero client
utente semplice, o client gestore del dato. I principali obiettivi del SIRA – “Catasto Sentieristica EF” sono:
● consentire l’inserimento e il continuo aggiornamento dei dati afferenti alla rete, comprese le informazioni relative alla segmentazione dinamica dei sentieri, la manutenzione dei tracciati, la messa in sicurezza, ecc.;
● consentire la gestione e la storicizzazione dei dati e degli elaborati progettuali della rete escursionistica ( d’ora innanzi, RES);
● consentire attività di reportistica e di integrazione dei dati relativi alla RES, anche attraverso l’editing su mappa base dei percorsi esistenti (sentieri, tracce/tracciati dei sentieri, elementi puntiformi associati ai sentieri, dati alfanumerici dei sentieri);
● esporre apposite API per consentire la pubblicazione su altri sistemi web (esempio: xxxxxxxxxxxxxxxx.xx) delle singole tracce dei sentieri rella RES (in formato gpx e kmz) e dell’insieme dei sentieri della RES (in kmz/kml o shape) o di una selezione di sentieri e punti notevoli della RES (in kmz/kml o shape);
● consentire la generazione di mappe tematiche anche ricorrendo alla fusione degli strati informativi propri della RES.
Per il catasto sentieri verranno sviluppate due funzionalità di export:
- export dello strato dei sentieri (full) o di alcuni sentieri selezionati in mappa in formato shp sia nel sistema Gauss Boaga che nel sistema di riferimento WGS84 e sia in formato shp che in altri formati di interscambio 8es: gpx/kmz/kml)
- export dello strato dei POI (full) o di alcuni POINT OF INTEREST selezionati in mappa e dei POI in formato GPX o shp o km/kml sia nel sistema Gauss Boaga che nel sistema di riferimento WGS84.
Infine tutti i dati della RES, verranno esposti in formato WFS/WMS. In conclusione, attraverso l’area Catasto si possono consultare e gestire i dati tecnici, amministrativi e geometrici del sentiero in modo del tutto analogo agli altri OST nel SIRA.
Portale Sardegna Sentieri (xxxx://xxx.xxxxxxxxxxxxxxxx.xx/)
Il portale è dedicato alla promozione dei sentieri escursionistici e ciclo escursionistici. I dati sui sentieri e i contenuti multimediali di promozione sono archiviati e gestiti tramite un CMS Drupal, non sono fruibili API per l’accesso ai dati.
L’utilizzo dei dati del portale comporterebbe l’implementazione di procedure batch per l’estrazione degli stessi dal database del CMS comprese le tracce in formato gpx.
Portale Sardegna Ciclabile (xxxx://xxx.xxxxxxxxxxxxxxxxx.xx)
Il portale è dedicato alla comunicazione, alla conoscenza, alla pubblicizzazione e alla consultazione dei documenti, delle elaborazioni e dei contenuti relativi al processo di Pianificazione della Mobilità Ciclistica della Sardegna. Il portale è gestito dall’ARST, Regione Sardegna e CIREM. L’utilizzo dei dati del portale potrebbe comportare l’implementazione di procedure batch per l’estrazione dei dati da shapefile.
Portale SardegnaTurismo (xxx.xxxxxxxxxxxxxxx.xx)
Portale turistico ufficiale della Regione Sardegna, accoglie tutte le informazioni su punti di interesse, eventi, articoli di approfondimento e strutture ricettive presenti in Sardegna. Il portale espone i contenuti tramite API REST. Il sistema è ospitato su piattaforma Acquia Drupal la cui infrastruttura è costituita dai seguenti macrocomponenti:
- Varnish cache (sistema di caching lato frontend xxx.xxxxxxx-xxxxxxxx.xxx)
- Apache Solr (motore di indicizzazione dei contenuti xxx.xxxxxx.xxxxxx.xxx/xxxx);
- Database (MySQL)
- CMS Drupal (Content Management System xxxxx://xxx.xxxxxx.xxx/)
Il portale SardegnaTurismo contiene Attrattori ed Eventi, cioè “potenziali OST” (dati utili a creare nel SIN2 nuovi OST) puntuali corredati di informazioni multimediali: descrizioni testuali multilingue, immagini, categorie di classificazione mediante tassonomie strutturate e curate redazionalmente.
Questi OST vengono esposti tramite API REST che potranno essere interrogate da SIN2 per l’estrazione dei dati e metadati associati sia puntualmente che tramite liste di estrazione filtrabili.
Gli OST e i relativi contenuti multimediali sono il prodotto dell’attività redazionale della
RAS.
Area Operatori (AO) (xxxx://xxxxxxxxx.xxxxxxxxxxxxxxx.xx/)
Applicazione web Drupal 7 che costituisce un canale di comunicazione tra le diverse categorie di operatori turistici sul territorio regionale e la RAS. L’AO è l’hub di accesso ai vari servizi disponibili per gli operatori; consente a questi ultimi di gestire il proprio profilo anagrafico e commerciale e costituisce lo strumento attraverso il quale conferire contenuti certificati e qualificati, anche in chiave di dematerializzazione delle procedure e di redazione diffusa (foto, eventi, punti di interesse).
Il sistema in produzione è ospitato su piattaforma CSR mentre l’ambiente di sviluppo è ospitato su Cloud AWS. Sono in fase di chiusura le operazioni di migrazione di Area Operatori su Cloud XXX.Xx sistema AO ha inoltre lo scopo di gestire le autorizzazioni dei diversi soggetti e operatori in ambito turistico ed espone tali autorizzazioni mediante API REST agli altri sistemi della piattaforma.
L’Area Operatori è connessa al sistema IDM della Regione Sardegna (xxxx://xxx.xxxxxxx.xxxxxxxx.xx/xxxxxxx-xxx/) tramite protocollo SAML 2 ed è in via di connessione, via OAuth, al nuovo sistema Access Manager che intermedierà gli accessi tramite Spid (Sistema Pubblico di Identità Digitale).
L’Area Operatori ha una infrastruttura costituita dai seguenti macrocomponenti:
- Varnish cache (sistema di caching lato frontend xxx.xxxxxxx-xxxxxxxx.xxx)
- Apache Solr (motore di indicizzazione dei contenuti (xxx.xxxxxx.xxxxxx.xxx/xxxx);
- Database (MySQL)
- CMS Drupal (Content Management System xxxxx://xxx.xxxxxx.xxx/)
L’applicazione Area Operatori contiene le schede degli operatori turistici, cioè OST puntuali corredati di informazioni strutturate: nome, tipologia attività, indirizzi, contatti, partita iva, eccetera. Le informazioni sono acquisite dalle anagrafi e albi regionali o create in self provisioning e autocertificazione dagli stessi operatori direttamente sul sistema.
Area Operatori espone inoltre informazioni che collegano gli utenti IDM (le persone fisiche riconosciute tramite codice fiscale) a specifici gruppi o operatori turistici. Questo consente ad esempio di capire:
● che ruolo aziendale una persona ricopre all’interno di un'azienda che opera nel
settore turistico (es. legale rappresentante di una struttura ricettiva)
● se un certo utente fa parte di specifiche categorie di utenti (es. redattori Hyperlocal) in base all’appartenenza ad un gruppo.
Area Operatori può essere interrogata da SIN2, tramite API REST sia per estrarre le informazioni legate agli OST che per recuperare informazioni sul ruolo dei singoli utenti che intendono accedere al sistema (funzioni di autorizzazione). L’estrazione dei dati e metadati associati sia puntualmente che tramite liste di estrazione filtrabili.
Destination Management System (DMS)
Piattaforma tecnologica per la promo-commercializzazione della destinazione turistica; consente agli operatori il caricamento della propria anagrafica commerciale e delle proprie offerte, esposte tramite API, per la vendita attraverso diversi canali, istituzionali e non. Il sistema supporta il caricamento delle offerte per dieci differenti tipologie di prodotto ed integra funzionalità finalizzate all’attivazione di partnership commerciali tra gli operatori. Il sistema, ospitato su Cloud AWS, è una applicazione web sviluppata in PHP con database MySQL, basata su Apache Http Server e Solr. Nella figura seguente si riporta lo schema architetturale del sistema.
L’applicazione DMS contiene le schede degli operatori turistici, cioè OST puntuali corredati di:
● informazioni strutturate: un sottoinsieme di quelle presenti in Area Operatori a cui si aggiungono ulteriori informazioni (es. account Twitter e Facebook, email commerciale, etc);
● contenuti multimediali: descrizioni testuali estese, galleria di immagini, galleria video;
● schede prodotti, loro descrizioni e disponibilità (es. camera doppia con servizi connessi, prezzi, disponibilità, descrizioni testuali, foto, video).
Le informazioni di base sono acquisite dalle anagrafi e albi regionali o create in self provisioning e autocertificazione dagli stessi operatori direttamente sul sistema.
Il DMS può essere interrogato da SIN2, tramite API REST sia per estrarre le informazioni legate agli OST che per recuperare informazioni sul ruolo dei singoli utenti che intendono accedere al sistema (funzioni di autorizzazione). L’estrazione dei dati e metadati associati sia puntualmente che tramite liste di estrazione filtrabili.
Hyperlocal Infopoint Sardegna (HIS)
Sistema per la raccolta e distribuzione di informazioni iperlocali, che mette a disposizione di territori e comunità geograficamente definite un insieme di strumenti di redazione diffusa. I contenuti raccolti alimentano un sistema di accoglienza costituito da elementi sia fisici (infotouch, desk e cartellonistica) che virtuali (APP mobile); il sistema attinge ai contenuti prodotti centralmente (x.xx. da SardegnaTurismo) secondo una logica top-down, e produce contenuti che nascendo dal basso possono essere riusati centralmente secondo una logica bottom-up. Il sistema, basato su tecnologie Drupal, Elasticsearch, Kibana, Logstash, CiviCRM e Ionic, è ospitato su Acquia Drupal e su Cloud AWS ed è costituito dai seguenti componenti: HCMS, HIS-INFONET, HIS-API, CRM e MONIT.
HCMS
Il componente HCMS sviluppato su Drupal, implementa le funzioni di content management del sistema HIS e fornisce gli ambienti di back office dedicati alla redazione e all'infopoint delle comunità hyperlocal. L'accesso è consentito ai soli utenti autenticati (IdM) e autorizzati (Area Operatori). Il sistema è ospitato su Acquia Drupal.
HIS-INFONET
La componente HIS-INFONET comprende le applicazioni mobile (Here Is Sardinia) disponibili sugli store pubblici e realizzate con tecnologia Ionic su piattaforme iOS e
Android, oltre all’applicazione SPA (Single Page Application) visualizzata dai dispositivi infopoint e sviluppata su tecnologia AngularJS.
HIS-API
La componente HIS-API, sviluppata su Drupal ed Elasticsearch, consente l'invocazione di servizi e lo scambio di informazioni tra i diversi attori del sistema HIS. Ogni chiamata API è oggetto di autenticazione mediante sistema OAUTH e, in particolare quelle realizzate per la mobile app, contengono le coordinate del dispositivo anonimizzate in fase di memorizzazione.
CRM
Il componente CRM rappresenta il CRM del sistema HIS la cui principale funzione è la raccolta di contatti-utente e l'invio di newsletter. Il CRM utilizzato è CiviCRM, basato su Drupal e consente di utilizzare le metodologie e gli strumenti definiti per il componente HCMS.
MONIT
Il componente MONIT, sviluppato su stack ELK (Elasticsearch+Logstash+Kibana), ha il compito di raccogliere, analizzare, presentare e conservare le informazioni sulle attività svolte dagli altri componenti del sistema Hyperlocal.
La figura seguente illustra l’architettura del sistema.
Il sistema Hyperlocal contiene:
● Attrattori ed Eventi, cioè OST puntuali corredati di informazioni multimediali: descrizioni testuali multilingue, immagini, categorie di classificazione mediante tassonomie strutturate e curate redazionalmente;
● Itinerari, cioè OST caratterizzati come collezione di OST puntuali (Attrattori ed Eventi) corredati di informazioni multimediali: descrizioni testuali multilingue, immagini, categorie di classificazione mediante tassonomie strutturate e curate redazionalmente.
Questi OST vengono esposti tramite API REST che potranno essere interrogate da SIN2 per l’estrazione dei dati e metadati associati sia puntualmente che tramite liste di estrazione filtrabili.
Gli OST e i relativi contenuti multimediali sono il prodotto dell’attività redazionale dalla comunità Hyperlocal.
SardegnaMobilità (xxxx://xxx.xxxxxxxxxxxxxxxx.xx/)
Particolarmente importanti per il carattere transfrontaliero del progetto sono i collegamenti con gli altri territori transfrontalieri tramite i nodi del trasporto le cui informazioni sono trattate dal Servizio Informativo dei Trasporti della Sardegna (SITRA) erogate dai suoi servizi e dal portale SardegnaMobilità.
Il portale SardegnaMobilità offre diversi strumenti per la consultazione delle informazioni sui trasporti pubblici e privati utili al turista attivo relativamente a:
● Bus e Treni per la mobilità interna. Le informazioni riguardano: ARST S.p.A (compreso urbano di Carbonia, Xxxxxxxx, Alghero, Macomer, Oristano ), FS Trenitalia, Aziende Private (ANAV) - urbano e extraurbano, CTM Cagliari, ATP Sassari, ATP Nuoro, ASPO Olbia S.p.A.;
● Aereo o Nave per la mobilità da e per la Sardegna e per i collegamenti con le isole minori.
L’accesso al dato è possibile tramite:
● i riferimenti ai dati nella pagina Open Data: xxxx://xxx.xxxxxxxxxxxxxxxx.xx/xxxxxxxxxxxxxx/xxxxxxxx/
● il Travel Planner (xxxx://xxx.xxxxxxxxxxxxxxxx.xx/xxxxxxxxxxxxx/), basato su Open Trip Planner (xxxx://xxx.xxxxxxxxxxxxxxx.xxx/) e dotato di API (adattamento delle Open Trip Planner API) che sono al momento in fase di test e che restituiscono la componente spaziale del dato.
Un esempio di richiesta al servizio è:
xxxx://xxx.xxxxxxxxxxxxxxxx.xx/xxx/xxxx/xxxx/?&xxxxXxxxxx00.000000,0.0000000&xxXxxxxx00
.8002778,12.2388889&time=12:50&date=06-22-2018.
Articolo 6. Articolo 6. Descrizione della fornitura
Il progetto INTENSE ha come scopo principale l’identificazione di un itinerario turistico transfrontaliero per il turista attivo. La realizzazione di tale itinerario non è però sufficiente a garantire il successo e la continuità nel tempo dell’offerta turistica: a corredo di tale realizzazione, per conseguire la condivisione di informazioni adeguate allo sviluppo dell’offerta
turistica, si intende mettere a sistema i catasti e i servizi che forniscono i dati utili alla promozione degli itinerari, delle attività e delle attrazioni correlate.
La Regione Sardegna - Assessorato del Turismo, il CRS4 e Forestas, attraverso il presente Capitolato intendono realizzare un sistema informativo che dovrà gestire delle schede informative denominate “schede INTENSE” mediante l’acquisizione, da un operatore esterno qualificato, dei servizi di seguito descritti.
Il sistema verrà denominato SIN2 (Sistema INformativo INtense) e sarà ospitato presso la RAS all’interno della piattaforma SardegnaTurismo Evoluzione sul cloud dell'Assessorato del Turismo, Artigianato e Commercio.
Sebbene il sistema SIN2 gestirà l’offerta turistica per il turismo attivo solo per il territorio Sardo ha comunque valenza transfrontaliera in quanto:
● permette di inserire come punti tappa i nodi trasportistici intermodali di interconnessione tra i territori transfrontalieri cioè da e per la Sardegna. Questo permette potenzialmente di collegare l’offerta turistica sul territorio Sardo a offerte turistica calate negli altri territori transfrontalieri;
● utilizza il modello del dato e le tassonomie definite nel progetto INTENSE realizzate per la creazione di un’offerta turistica “transfrontaliera” per il turismo attivo frutto dell’armonizzazione di quanto è in uso nei diversi territori dell’area transfrontaliera nella proposta turistica al turista attivo.
Nella realizzazione del sistema saranno coinvolti:
● il catasto della rete escursionistica, cicloescursionistica (RES) ed Ippoviaria (RIS) gestito dall'Ente regionale Forestas che verrà ospitato dall’Xxx.xx della difesa dell’Ambiente presso il Sistema Informativo Regionale Ambientale (SIRA) o presso un Sistema dell’Xxx.xx del Turismo, Artigianato e Commercio;
● la Rete degli Itinerari Ciclabili della Sardegna (RICS) che verrà ospitata nel Sistema Sardegna Ciclabile;
● I Sistemi Informativi dell'Assessorato del Turismo, Artigianato e Commercio quali il portale SardegnaTurismo, il Destination Management System, il sistema Hyperlocal e l’Area Operatori;
● il Sistema Informativo dei trasporti (SiTra) e i relativi open data;
● i dati dell’itinerario transfrontaliero INTENSE raccolti e prodotti dallo stesso progetto.
La scheda INTENSE che il sistema dovrà gestire è una composizione di dati multimediali e metadati funzionali alla promozione, descrizione e presentazione di un itinerario escursionistico e\o ciclabile come proposta al turista attivo.
Il sistema realizzato dovrà permettere di:
● interrogare i sistemi informativi regionali, elencati nel presente documento, che detengono il dato utile;
● gestire le tassonomie che definiscono le caratteristiche dell’itinerario INTENSE e permettono la conciliazione del dato proveniente da altri sistemi;
● riconciliare le informazioni estratte dai sistemi informativi regionali rispetto alle entità semantiche a cui le schede INTENSE fanno riferimento (luoghi, percorsi, attrattori naturali, monumenti, categorie turistiche, attività, eccetera) in modo da fornire una visione unitaria sempre aggiornata di tali entità;
● gestire la possibile equivalenza semantica tra entità ricavate da sistemi regionali diversi derivandone una univoca.
● permettere ai tecnici della Regione la creazione di itinerari INTENSE, da codificare successivamente nella scheda INTENSE;
● indicizzare le schede INTENSE su motori di ricerca interni dotati di funzioni di query estese (full text, geografiche, temporali, tassonomiche, faceted, eccetera);
● gestire le schede INTENSE e le loro componenti mediante opportuni strumenti di workflow redazionale e un back office per il personale RAS e gli operatori turistici accreditati;
● rendere disponibili le schede INTENSE ai servizi di promozione dell’itinerario ciclabile e/o escursionistico mediante API REST;
● rendere disponibili le schede INTENSE e tutti i dati geografici raccolti e riconciliati sotto forma di web gis service;
● fornire dati e servizi di fruizione delle schede INTENSE tramite API REST a una app mobile e ad un portale gis collaborativo che saranno realizzati per fornire al turista un prodotto completo per supportare il turismo attivo e che saranno oggetto di un bando separato
● garantire l’accesso sicuro alle API mediante sistemi di autenticazione configurabili (es. oauth).
La scheda INTENSE è composta di uno o più OST (Oggetto Significativo Territoriale) con le seguenti specifiche minime:
Oggetti Significativi Territoriali (OST)
Un itinerario INTENSE è costituito da Oggetti Significativi Territoriali denominati OST estratti dal dato erogato da una o più fonti.
Le tipologie di OST definite in INTENSE sono:
● Segmento di percorso: elemento lineare che costituisce la RES, la RICS e la RIS;
● Punto tappa: elemento puntuale a corredo della RES, la RICS e la RIS; a questa tipologia appartengono anche i nodi di intermodalità trasportistica e le pertinenze della RES;
● Attrattore turistico: elemento puntuale o areale che rappresenta un polo attrattore turistico;
● Servizio al turista attivo: elemento puntuale o areale che rappresenta un servizio per il turista attivo (es: area di sosta).
In SIN2 un OST :
1) dovrà essere descritto da caratteristiche intrinseche, cioè presenti nel dato da cui è ricavato, o calcolate da indicatori previsti nel modello del dato INTENSE;
2) dovrà avere almeno una componente spaziale che potrà essere di tipo lineare, puntuale o areale, di cardinalità singola o multipla (ad esempio una multilinea);.
3) potrà essere estratta da più fonti: cioè ciascuna entità estratta da una fonte sarà confrontata con le entità ricavate da altri sistemi tramite una procedura semi- automatica per verificare e risolvere una eventuale equivalenza che dovrà essere validata da un operatore e che per ciascuna caratteristica equivalente nelle entità dovrà conoscere la fonte prioritaria;
4) dovrà essere aggiornato con scadenza temporale opportuna.
Quale esempio del punto 3 l’estrazione dei dati di un ‘Albero monumentale’ in qualità di ‘Attrattore turistico’ da Sardegna Turismo sarà una entità con caratteristiche ricavabili dai dati forniti da Sardegna Turismo. Allo stesso modo è possibile che una entità per lo stesso albero monumentale sia stata estratta dai dati forniti da Forestas. Il sistema rilevata l’equivalenza tra le due entità, la notificherà ad un validatore che se la accetterà darà seguito alla trasformazione delle entità tramite l’aggregazione delle caratteristiche individuata, ad esempio la dimensione come l’altezza, scegliendo una fonte prioritaria in caso di equivalenza, ad esempio selezionando il dato sull’altezza indicato da Forestas. Infine l’OST risultante sarà caricato nel sistema e potrà essere parte di una scheda INTENSE.
La procedura semi automatica dovrà gestire in modo opportuno anche i casi in cui non sia rilevata una equivalenza semantica e spaziale.
La classificazione degli OST di tipo “Attrattore Turistico” e “Servizio al turista” farà riferimento alle tassonomie INTENSE che specificano anche il mapping delle categorie e
macro categorie utilizzate dal sistema informativo SITR-IDT e avranno una struttura conforme con le specifiche W3C ( xxxxx://xxx.x0.xxx/0000/XXX/xxxx/Xxxx_Xxxxx).
Inoltre, la modellazione ed esposizione dei dati relativi agli OST dovrà fare riferimento ai seguenti standard:
● Fiwire: xxxxx://xxx.xxxxxx.xxx/ con particolare riguardo ai modelli xxxxx://xxx.xxxxxx.xxx/xxxxxxxxxx/xxxx-xxxxxx/
● Xxxxxx.xxx - xxxxx://xxxxxx.xxx/
Particolare importanza avranno le scelte del fornitore, in accordo con la RAS, nell’individuare ulteriori caratteristiche utili a descrivere un OST, ad esempio la disponibilità in termini di capienza e orari di apertura di un servizio, qualora questi siano disponibili nel sistema che espone il dato. L’aggiunta di caratteristiche agli OST dovrà essere corredata di tassonomie e riferimenti approvate dalla RAS. Un OST potrà essere componente di uno o più itinerari e riferito in una o più schede.
La scheda INTENSE descrive un itinerario escursionistico e\o ciclabile proposto ad un turista attivo all’interno del territorio transfrontaliero. L’itinerario è costituito da una selezione di OST disponibili in uno specifico periodo dell’anno. L’itinerario dovrà rispettare alcuni vincoli di tipo spaziale che garantiscano la continuità del percorso descritto. La scheda avrà come elementi minimi fondamentali almeno:
● un nome
● una descrizione disponibile in diverse lingue (di base almeno inglese, italiano e francese);
● un periodo dell'anno a carattere indicativo o specifico che ne indichi attualità e disponibilità;
● un percorso rappresentato da un elemento spaziale lineare singolo o multilinea, calato sulla RES, RIS, RICS, costituito dall’aggregazione degli OST lineari “Segmento di percorso” che lo compongono e dai tratti, opportunamente evidenziati, eseguiti su mezzi di trasporto (Bus/Treno/Nave/Aereo), a piedi o su bicicletta;
● un insieme di caratteristiche ottenute aggregando quelle degli OST lineari “Segmento di percorso” che compongono l’itinerario;
● un insieme ordinato di riferimenti a OST “Punti-tappa” che compongono il
percorso, comprensivo delle caratteristiche rilevanti e multimedia descrittivi
● un insieme ordinato di riferimenti a OST “Attrattori” comprensivo delle caratteristiche rilevanti e multimedia descrittivi;
● un insieme ordinato di riferimenti a OST “Servizi” comprensivo delle caratteristiche rilevanti e multimedia descrittivi;
● un insieme di contenuti multimediali descrittivi dell’itinerario nel suo insieme.
Linee guida per l’architettura dell’informazione del sistema SIN2
Di seguito vengono delineate le linee guida per l’architettura dell’informazione che sottende tutto lo sviluppo del sistema SIN2. I soggetti a cui è destinato il sistema sono di seguito riportati:
● personale dell’Assessorato del Turismo, Artigianato e Commercio relativamente alle attività di creazione e promozione di itinerari escursionistici e ciclabili per il turismo attivo;
● operatori turistici accreditati nell’area operatori relativamente alle attività di creazione e promozione di itinerari escursionistici e ciclabili per il turismo attivo;
● personale dell’Agenzia Forestas relativamente alle attività di creazione e monitoraggio di itinerari escursionistici ciclo escursionistici e ciclabili per il turismo attivo.
Il sistema avrà le seguenti finalità:
● utilizzare la base informativa sulla RES, RIS gestita da Forestas nel catasto ospitato presso il SIRA o suo servizio sostitutivo presso Assessorato del Turismo per la promozione del turismo attivo;
● utilizzare la base informativa sulla RICS gestita da Sardegna Ciclabile;
● utilizzare le informazioni su attrattori turistici e servizi al turista attivo presenti nei sistemi informativi dell’Assessorato del Turismo, Artigianato e Commercio;
● utilizzare le informazioni su servizi di tipo trasportistico utili al turista attivo;
● fornire strumenti editoriali che consentano di gestire il ciclo di vita delle schede INTENSE e la validazione degli OST, ricavati dalle fonti, utilizzati nella costruzione delle schede;
● permettere la ricerca intelligente di schede INTENSE e di OST caricati nel sistema mediante motori di ricerca interni;
● permettere flessibilità rispetto alla base informativa nella gestione:
○ degli aspetti semantici legati alla rappresentazione del dato;
○ degli aspetti semantici legati al caricamento del dato da diverse fonti nel contesto territoriale transfrontaliero;
○ dell’aggiornamento delle informazioni veicolate dalle schede INTENSE;
○ della qualità dell’informazione in base alla gestione delle equivalenze tra gli OST ricavati da fonti diverse;
● gestire gli aspetti multilingua legati all’informazione almeno per le lingue italiano,
francese ed inglese;
● erogare l’informazione su base applicativa tramite la pubblicazione di API (Application Programming Interface) e OGC WFS (Web Feaure Server) per l’accesso e la ricerca di schede INTENSE e di OST in termini di dati e metadati da parte dei servizi di promozione e informazione al turista attivo.
Nel caso in cui i sistemi che forniscono i dati sulla rete escursionistica e ciclo escursionistica non risultino operativi sia nella fase prototipale di test (tuttora il catasto sentieri regionale non è operativo) sia nella fase di implementazione della versione finale del sistema si richiede al fornitore l’implementazione di procedure batch e di un servizio WMS/WFS (e.g Geoserver) che permetta di esporre e caricare in primis i dati dell’itinerario ciclabile indicato dal progetto INTENSE e, qualora i sistemi che si ipotizza di utilizzare per ospitare il catasto sentieri (es: SIRA) non fossero operativi, anche i dati della rete ciclo-escursionistica, escursionistca ed ippoviaria (Sentieri, Attrattori, Servizi e pertinenze della RES e della RIS) e delle ciclovie della Sardegna disponibili presso l’agenzia Forestas.
La consegna dei dati al fornitore, comprensiva della documentazione sui tracciati escursionistici (ed eventuali metadati) sarà a cura di Xxxxxxxx anche nel caso di indisponibilità del sistema informativo sorgente. In tal ultimo caso, la modalità di fornitura da parte dell’Agenzia Forestas, soggetto deputato per legge regionale (LR 16/2017) alla gestione delle infrastrutture viarie della sentieristica in Sardegna, sarà basato su un set minimale di shapefile corredato da un set minimale di dati e metadati attraverso file .dbf collegati ai file .shp.
Per la componente di autenticazione e autorizzazione il sistema dovrà consentire agli operatori e agli amministratori l’accesso tramite IDM (Identity management system) della RAS, o mediante la sua evoluzione (Access Manager), e l’attribuzione di un ruolo e dei relativi permessi di autorizzazione mediante l’utilizzo delle API di Area Operatori (analogamente a quanto già fatto per altri sistemi quali Hyperlocal e DMS). Questo consentirà un accesso certificato che potrà essere esteso in futuro anche a utenti che intendano contribuire alla creazione/manutenzione delle schede INTENSE e che provengano da enti pubblici e/o da associazioni/società di servizi.
Articolo 6 bis. Voci della fornitura
Xxx non espressamente previsto dal capitolato, tutte le componenti software richieste dovranno essere obbligatoriamente rilasciate con licenze Open Source e/o utilizzare software open source.
Tutte le forniture software dovranno rispettare le policy di rilascio, le best practice e i livelli di qualità definiti dalla Stazione Appaltante.
Tutto il codice sorgente, anche durante il suo sviluppo iniziale, dovrà essere conservato sui repository git forniti dalla RAS. Tali repository dovranno essere usati dal fornitore come strumento di versioning e potranno essere usati dalla Stazione Appaltante per un costante monitoraggio dello stato di avanzamento dei lavori. Per tale ragione la gestione del codice da parte degli sviluppatori dovrà essere adeguata alle best practice di gestione del codice su git.
Qualora alcune componenti della fornitura del software siano fatte mediante cessione di licenza d’uso, tale licenza dovrà essere a tempo indeterminato, utilizzabile su qualsiasi architettura hardware o virtuale, senza vincoli sulla scalabilità orizzontale e verticale, senza limiti sul numero di utenti di back office o di front-end, senza limiti sul numero di client che utilizzano le API o altre limitazioni che restringano la possibilità da parte della Stazione Appaltante nell’utilizzo del software acquisito.
Tutti gli sviluppi dovranno avvenire, oltre che su ambienti locali del fornitore, su servizi Cloud identificati e forniti da RAS (Amazon AWS, Acquia Drupal, etc) e/o su cloud Ibrido fornito da RAS.
Nella realizzazione dei servizi, RAS fornirà le risorse cloud necessarie per tutti gli ambienti (sviluppo, stage e produzione).
Conseguentemente, sono richiesti al fornitore aggiudicatario elevati livelli di professionalità, competenza ed esperienza sia nelle tecnologie che saranno proposte per realizzare quanto richiesto dal presente capitolato che nello sviluppo di applicazioni su cloud, in particolare mediante l’utilizzo di container docker e servizi nativi (es. S3, EC2, ECS).
Resta inteso che, ai fini della collaudabilità, il fornitore dovrà garantire non solo il pieno funzionamento delle componenti sviluppate ma anche la loro corretta integrazione rispetto all’intero ecosistema SardegnaTurismo, a fronte dei diversi momenti in cui avverrà il rilascio delle componenti medesime e dei reciproci ambiti di interazione tra queste e l’ecosistema.
A tal fine, RAS renderà disponibili opportuni ambienti di integrazione su cloud in modo che il fornitore possa utilizzarli per testare i nuovi sviluppi.
Si precisa che per tutti gli interventi realizzati nell’ambito della presente fornitura è compresa la garanzia su quanto realizzato, per un periodo di 12 mesi a partire dal collaudo finale e senza costi aggiuntivi per la Stazione Appaltante. La garanzia dovrà coprire la correzione dei bug e malfunzionamenti interni alle componenti sviluppate e/o connessi alla non corretta integrazione delle componenti medesime rispetto all’intero ecosistema SardegnaTurismo.
Le richieste di correzione verranno segnalate dalla stazione appaltante all’impresa, attraverso un sistema task management e bug tracking fornito dall’impresa o indicato da RAS. L’accertamento e la rimozione delle cause e degli effetti dei bug e dei malfunzionamenti come sopra individuati, dovrà avvenire con assoggettamento agli SLA individuati nell’art. 14 e secondo le tipologie di errore da questo definite.
Il fornitore dovrà includere uno studio che identifichi l’approccio da seguire per il trattamento dei dati gestiti da SIN2, rispetto alle best practice e alle attuali norme vigenti in Italia e in Europa in tema di data privacy (GDPR).
Il sistema è illustrato nella seguente figura:
Componenti del sistema SIN2
Il sistema sarà costituito da 3 componenti:
● SIN2-DSAM (INTENSE Data Source Access Management) dedicato alla gestione della connessione alle sorgenti dei dati cioè i sistemi informativi regionali detentori e gestori dei dati costitutivi degli OST, e ai contenuti a loro collegati. La componente gestisce anche l’archiviazione, indicizzazione e recupero delle schede INTENSE, degli OST e delle tassonomie;
● SIN2-CMS (INTENSE Content Management System) un sistema web CMS che
consenta la gestione delle schede INTENSE, degli OST e delle tassonomie. Il front- end del sistema avrà come utilizzatori gli editori delle schede INTENSE cioè il personale dell’Assessorato del Turismo, Artigianato e Commercio, il personale Forestas e gli operatori turistici accreditati. La componente dovrà essere costituita da:
○ modulo per la gestione delle schede INTENSE e degli OST comprensivo di interfacce per l’editing delle schede anche su mappe;
○ modulo per la gestione delle tassonomie e del mapping concettuale utilizzati nella trasformazione e caricamento delle informazioni negli OST e costruzione delle schede INTENSE;
○ modulo per la gestione degli accessi.
● SIN2-API (INTENSE Application Programming Interface) fornisce un accesso unificato CRUD (Create, Read, Update, Delete) alle schede INTENSE, agli OST e alle tassonomie garantendo meccanismi di autorizzazione, sicurezza, performance e scalabilità adeguati. Le API sono a supporto dei sistemi preposti alla pubblicazione e fruizione delle schede INTENSE e degli OST, in special modo alle app web/mobile INTENSE oggetto di altra apposita gara. In aggiunta la componente dovrà fornire un accesso agli OST e schede INTENSE secondo le specifiche OGC WFS. Le API dovranno essere dotate di opportuni sistemi di autenticazione/autorizzazione applicativa (es. oauth).
I servizi di analisi, progettazione e sviluppo richiesti nel presente bando saranno destinati al conseguimento delle funzionalità strategiche indicate attraverso la realizzazione di forniture di due tipi:
● forniture verticali: si tratta di attività mirate alla realizzazione di una specifica componente del sistema SIN2;
● forniture orizzontali: si tratta di attività e servizi che hanno un valore trasversale rispetto alla costruzione delle componenti del sistema SIN2 e sono a supporto di ciascuna componente.
Di seguito elenchiamo le forniture verticali :
● V-DSAM: progettazione, costruzione, test e deploy della componente SIN2-DSAM;
● V-CMS: progettazione, costruzione, test e deploy della componente SIN2-CMS;
● V-API: progettazione, costruzione, test e deploy della componente SIN2-API. Di seguito elenchiamo le forniture orizzontali:
● O-ADPST (Architecture Deploy Performance Security Testing): progettazione e dimensionamento dell’architettura generale del sistema e delle singole componenti,
che includa gli aspetti non funzionali, le politiche di change management e la definizione di uno schema di deploy per l’ambiente di produzione con relativo dimensionamento. La fornitura include la predisposizione da parte del fornitore degli ambienti di sviluppo su infrastrutture cloud fornite da RAS;
● O-TEST (Test): Impostazione metodologica e definizione degli strumenti per l’erogazione dei servizi di test funzionali e di non regressione delle componenti software del sistema;
● O-FORM (Formazione): formazione per gli operatori di back-office all’uso delle funzionalità di creazione, modifica e gestione complessiva delle schede INTENSE, degli OST e di tutti gli strumenti di integrazione dati dalle fonti esterne. La formazione deve prevedere anche attività di trasferimento di competenze verso figure tecniche specialistiche per consentire la manutenzione e l’estensione della piattaforma verso nuove fonti dati;
● O-MAN (Manutenzione): Servizi di manutenzione correttiva e adeguativa;
● O-CON (Passaggio di Consegne): Servizi per il passaggio di consegne dell'infrastruttura tecnologica verso la Regione Sardegna o un soggetto da essa individuato.
Di seguito sono descritte nel dettaglio le singole forniture:
Oggetto della fornitura è lo sviluppo della componente SIN2-DSAM costituita da:
● un connettore per ciascuna fonte dei dati indicata e per quelle proposte dal fornitore che dovrà estrarre, trasformare e caricare nel sistema gli OST secondo il modello del dato e le tassonomie INTENSE;
● un modulo per la gestione degli aspetti semantici legati al processo di trasformazione del dato, cioè delle relazioni tra caratteristiche del dato, della fonte e il modello del dato INTENSE, e per la risoluzione semi-automatica delle equivalenze tra OST ricavati da fonti diverse;
● un modulo per l’archiviazione e il recupero delle schede INTENSE, OST e le tassonomie INTENSE;
● le interfacce di accesso alle funzionalità della componente per le altre componenti del sistema.
La componente dovrà permettere:
1. l'estrazione, conciliazione e caricamento da file degli OST relativi alla rete escursionistica e ciclo escursionistica RES e RIS, qualora il catasto sul SIRA non risulti operativo entro la scadenza temporale della fase di progettazione del sistema. In questo caso sarà cura di Forestas fornire i dati in formato file unitamente alla loro documentazione e metadati;
2. l'estrazione, conciliazione e caricamento degli OST utilizzando le sorgenti di dati indicate nell’articolo 5 del presente bando;
3. la verifica dell'equivalenza tra OST di fonti diverse e la risoluzione dell’equivalenza tramite l’aggregazione delle caratteristiche;
4. l'archiviazione, l'indicizzazione e il recupero degli OST ricavati;
5. l'archiviazione, l'indicizzazione e il recupero delle schede INTENSE;
6. l’esposizione delle interfacce di accesso alle funzionalità della componente per le altre componenti del sistema.
Perchè il sistema sia flessibile si richiede che per ciascuna fonte individuata venga realizzato un modulo con le funzionalità di estrazione del dato con un’architettura a plug-in. Per l’integrazione futura di nuove fonti di dati e la riusabilità nel contesto transfrontaliero si richiede la realizzazione di un framework per lo sviluppo di ulteriori estrattori (plug-in) comprensivo di una adeguata documentazione.
Nel dettaglio:
A. La progettazione e implementazione di un estrattore dei dati della RICS, che avrà come fonte Sardegna Mobilità che chiameremo V_DSAM_CICLOVIE;
B. La progettazione e implementazione di un modulo che chiameremo V_DSAM_SENTIERI che dovrà contenere:
○ un estrattore dei dati della RES e RIS dal catasto dei sentieri di Forestas sul SIRA (o alternativamente un estrattore dei dati che, se non disponibile il SIRA, verranno messi a disposizione in formato shapefle);
○ un estrattore dei contenuti descrittivi dei sentieri escursionistici su Sardegna Sentieri (o ALTERNATIVAMENTE un aggregatore che estrae ed integra i dati provenienti dal database del CMS Drupal di SardegnaSentieri);
C. La progettazione e implementazione di un modulo contenente gli estrattori dei dati dalle fonti dell’ass. al Turismo (HIS, DMS, Portale sardegna Turismo) che chiameremo V_DSAM_TURISMO;
D. La progettazione e implementazione di un modulo che chiameremo V_DSAM_TRASPORTI che conterrà un estrattore dei dati del SITRA (o ALTERNATIVAMENTE dai file open data pubblicati dal SITRA);
E. La progettazione e l'implementazione di un modulo, che chiameremo V_DSAM_SEMANTIC per:
○ la verifica di equivalenza tra OST caricati nel sistema da fonti diverse;
○ la risoluzione dell'equivalenza tra due OST e determinazione dell’OST unico ricavato dal merging delle caratteristiche degli OST equivalenti;
○ Il calcolo degli indicatori per l’assegnazione all’OST di caratteristiche non
presenti nel dato della fonte ma calcolabili e previste in INTENSE;
○ L’archiviazione e recupero delle informazioni semantiche relative al modello del dato, alle tassonomie INTENSE e al mapping semantico tra caratteristiche del dato di una fonte e il modello del dato e tassonomie INTENSE;
F. La progettazione e l'implementazione del modulo principale della componente, che chiameremo V_DSAM_CORE per:
○ l’archiviazione degli OST ricavati dalla varie fonti e indicizzazione tramite le tassonomie INTENSE;
○ l’archiviazione delle schede INTENSE e loro indicizzazione tramite le tassonomie INTENSE;
○ l’archiviazione e indicizzazione delle tassonomie INTENSE;
○ l’archiviazione e indicizzazione delle informazioni per il mapping semantico delle caratteristiche dei dati estratti dalle fonti e il modello del dato INTENSE e la definizione della fonte più autorevole per le caratteristiche degli OST;
○ le interfacce di accesso alle funzionalità della componente per gli altri moduli della componente V_DSAM e per le altre componenti del sistema.
Tabella dei deliverable per la componente SIN2-DSAM e loro suddivisione per argomenti
Sono previsti i seguenti deliverable anche in forma accorpata e composti di più sezioni, ciascuna delle quali è legata ad una fase specifica di avanzamento dei lavori
Codice deliverable/ nome sezione | Descrizione | Termine, a partire dalla data di approvazione della stipula del contratto, entro e non oltre il quale deve avvenire il rilascio |
SIN2_DSAM_D 1 | Analisi dei dati e delle fonti dei dati per la creazione degli OST, definendo schemi concettuali e usando tecnologie per il web semantico (e.g SKOS); modellazione dei dati e | Mese 2 |
metadati per OST, tassonomie e Scheda INTENSE usando tecnologie per il web semantico (e.g SKOS); Definizione delle procedure di estrazione e trasformazione per ciascuna fonte; definizione della procedura per la verifica di equivalenza tra OST | ||
SIN2_DSAM_D 2 | Progettazione dei moduli della componente: V_DSAM_CICLOVIE, V_DSAM_SENTIERI, V_DSAM_TURISMO, V_DSAM_TRASPORTI, V_DSAM_SEMANTIC, V_DSAM_CORE e dei moduli per l’aggregazione dei dati indicati dal fornitore per l’ampliamento della base informativa. | Mese 5 |
SIN2_DSAM_D 3 | Componente SIN2_DSAM versione prototipale end-to-end | Mese 4 |
SIN2_DSAM_D 4 | Componente SIN2_DSAM versione intermedia | Mese 7 |
SIN2_DSAM_D 5 | Componente SIN2_DSAM versione finale | Mese 9 |
SIN2_DSAM_D 6 | Progettazione software di dettaglio e documentazione del codice | Mese 9 |
SIN2_DSAM_D 7 | Linee guida, strumenti e risorse software per l’estensione della base informativa tramite l’implementazione di un nuovo connettore ad una nuova fonte dati | Mese 9 |
SIN2_DSAM_D 8 | Documentazione su architettura, deploy, performance, security, testing (come da elenco descritto in O-ADPST ) relativi a questa componente | Mese 9 |
SIN2_DSAM_D 9 | Documentazione sui test del sistema (come da elenco descritto in O-TEST) relativi a questa componente | Mese 9 |
Oggetto della fornitura è lo sviluppo della componente SIN2-CMS che deve permettere la gestione delle schede INTENSE. La componente SIN2-CMS sarà utilizzata prevalentemente da redattori RAS del settore di promozione al turismo attivo, dovrà essere quindi curata e valutata la User Experience per tale tipologia di fruitori in fase di progettazione e di realizzazione delle interfacce utente.
Per garantire il carattere di riusabilità e di transfrontalierità del sistema, si dovrà permettere che nella fase di editing possano essere utilizzati OST forniti da altri sistemi SIN2 tramite le API sviluppate nella componente SIN2-API.
Più in generale le interfacce utente realizzate dovranno appoggiarsi completamente alle API sviluppate nella componente SIN2-API per tutte le operazioni CRUD (Create, Read, Update, Delete) sulle entità gestite da INTENSE, inclusa la gestione degli utenti e dei ruoli. Questo al fine di garantire il disaccoppiamento tra le interfacce utente e la componente SIN2- DSAM.
Di seguito le funzionalità che si richiede per la componente:
1. La creazione, modifica e gestione del ciclo di vita delle schede INTENSE, la loro catalogazione tramite le tassonomie INTENSE e la disponibilità delle risorse nel tempo;
2. L’applicazione del calcolo di indicatori definiti nel modello del dato INTENSE per l’assegnazione delle caratteristiche da attribuire all’itinerario descritto dalla scheda INTENSE e calcolate sulla base delle caratteristiche dei singoli OST che lo
compongono;
3. La gestione e validazione degli OST caricati dalle fonti;
4. La gestione multilingua dei contenuti e di tutte le risorse multimediali correlate ai singoli OST o all’itinerario descritto dalla scheda INTENSE (foto, video, audio, testi);
V-CMS dovrà implementare un workflow redazionale multiruolo, composto da: Redattori (RR) di schede INTENSE e delle tassonomie in uso nel sistema; Validatori (VR) dei contenuti editati nonchè degli OST ricavati dalle fonti qualora il sistema abbia rilevato una possibile equivalenza. La content strategy nel contesto organizzativo definita nel presente capitolato sarà suscettibile di eventuali variazioni comunicate dalla Stazione Appaltante in fase di analisi di dettaglio.
V-CMS dovrà essere integrato con un sistema di indicizzazione e ricerca in grado di garantire elevati livelli di performance, granularità nella ricerca, funzioni evolute full text search, gestione faceted search, ricerca per prossimità geografica e per finestra temporale riferite alla disponibilità delle risorse turistiche che identificano gli OST. La ricerca sarà eseguita sia sulle schede INTENSE che sugli OST per facilitare la creazione o la modifica di Schede INTENSE. Il sistema dovrà restituire i risultati sulla base di un meccanismo di ranking basato su parametri configurabili e dovrà avere interfacce utente integrate nel back-office per consentire una rapida ricerca nel patrimonio informativo del sistema legato agli OST e alle schede INTENSE nonché alle tassonomie (definizione e descrizione classificazioni).
V-CMS dovrà permettere la gestione delle API realizzate in V-API per la componente SIN2-API tramite interfacce nel back-office (es. creazione chiavi applicative, configurazione livelli di accesso e throttling) .
Tabella dei deliverable minimi
Sono previsti i seguenti deliverable anche in forma accorpata e composti di più sezioni, ciascuna delle quali è legata ad una fase specifica di avanzamento dei lavori
Codice deliverable/ nome sezione | Descrizione | Termine, a partire dalla data di approvazione della stipula del contratto, entro e non oltre il quale deve avvenire il rilascio |
SIN2_CMS_D1 | Analisi dei requisiti funzionali della componente e della content strategy | Mese 2 |
SIN2_CMS_D2 | Componente SIN2_CMS versione prototipale end-to-end | Mese 4 |
SIN2_CMS_D3 | Progettazione della componente | Mese 5 |
SIN2_CMS_D4 | analisi dei requisiti delle interfacce utente e valutazione della user Experience per le versioni intermedie | Mese 7 |
SIN2_CMS_D5 | Componente SIN2_CMS versione finale | Mese 9 |
SIN2_CMS_D6 | Progettazione software di dettaglio | Mese 6 |
SIN2_CMS_D7 | Documentazione del codice sorgente realizzato | Mese 9 |
SIN2_CMS_D8 | Linee guida, strumenti e risorse software per l’utilizzo di dati erogati da altri sistemi INTENSE tramite le API realizzate in V_API nella costruzione delle schede INTENSE. | Mese 9 |
SIN2_CMS_D9 | Documentazione di: architettura, deploy, performance, security, testing (come da elenco descritto in O-ADPST ) relativi a questa componente | Mese 9 |
SIN2_CMS_D10 | Documentazione sui test del sistema (come da elenco descritto in O-TEST) relativi a questa componente | Mese 9 |
La fornitura ha come obiettivo la costruzione della componente SIN2-API.
La componente SIN2-API fornisce al sistema SIN2 un livello (layer) di API (Application Programming Interface) che:
● consente di esporre funzioni CRUD (Create, Read, Update,Delete), verso sistemi e applicazioni esterne, per gestire i dati relativi agli OST, alle Schede INTENSE e alle Tassonomie INTENSE;
● consente di esporre verso il front-end della componente SIN2_CMS, tutte le funzioni necessarie alla realizzazione delle funzionalità richieste;
● consente di esporre in lettura verso sistemi e applicazioni esterne, tramite una interfaccia OGC WFS, i dati relativi agli OST e alle Schede INTENSE;
● consente di configurare per specifiche politiche di autenticazione/autorizzazione;
● garantisce la scalabilità sotto il profilo delle prestazioni al crescere del carico e della quantità delle informazioni gestite.
Oltre alle API è richiesto al fornitore di dotare il sistema SIN2 anche di una interfaccia OGC WFS (e.g Geoserver: xxxx://xxxxxxxxx.xxx/) che esponga gli OST e l’itinerario che identifica la scheda INTENSE.
Per quanto riguarda le API, dovranno essere previste due tipologie di accesso dei sistemi esterni tramite API:
● una API adatta a interrogare sistema SIN2 in tempo reale, attraverso sistemi web asincroni (p. es. basati su AJAX) e applicazioni mobile, senza richiedere la ricostruzione e l’allineamento di una versione cache dei dati all’interno dell’applicazione; questa API deve fornire almeno le seguenti funzionalità:
○ query real time;
○ query spaziale;
○ query full text;
○ query complesse e filtri avanzati;
○ funzioni CRUD RESTful;
○ supporto XML/JSON;
● una API adatta a tenere sincronizzata una copia di una Scheda INTENSE o di un OST presente nel sistema SIN2 sulle app o su sistemi esterni.
Per quanto riguarda l’integrazione del servizio con interfaccia OGC WFS. I dati esposti avranno come caratteristiche minime:
● OST
○ l’elemento spaziale lineare, areale o puntuale associato;
○ le caratteristiche essenziali dell’OST così come da modello del dato INTENSE compresi gli indicatori;
○ la classificazione OpenPOI su due livelli utilizzata dai sistemi informativi della Regione Sardegna equivalente a quella definita nelle tassonomie INTENSE;
○ formato dati compatibile con le specifiche Fiwire e Xxxxxx.xxx;
● Schede INTENSE:
○ l’elemento lineare che descrive l’itinerario;
○ le caratteristiche essenziali dell’OST così come da modello del dato INTENSE compresi gli indicatori;
○ formato dati compatibile con le specifiche Fiwire e Xxxxxx.xxx.
Tramite il WFS dovrà essere possibile interrogare la base di dati con filtri spaziali. A titolo di esempio ne vengono elencati alcuni:
● Richiesta degli OST interni ad un buffer ricavato da un elemento lineare o puntuale
unitamente ad una distanza;
● Richiesta degli OST ricadenti all’interno di un OST areale.
Si riportano alcuni esempi (indicativi e non esaustivi) di sistemi esterni che dovranno potersi agganciare alle API o al WFS di SIN2:
● siti internet pubblici e privati di promozione territoriale;
● widget html+javascript da integrare su siti web;
● applicazioni mobile;
● il portale partecipativo previsto per il progetto INTENSE su bando separato;
● l’applicazione per dispositivi mobili prevista per il progetto INTENSE su bando separato.
Le API e il WFS dovranno essere progettate in modo da tenere conto di queste possibilità e dei relativi casi d’uso, in modo da esporre tutte le funzioni necessarie. In riferimento al loro uso nel portale partecipativo e nell’applicazione mobile previsti per il progetto INTENSE e dedicati alla fruizione delle schede INTENSE da parte del turista attivo, oggetto di un’altro bando, sarà cura della RAS fornire la necessaria documentazione delle specifiche dei due applicativi, e del fornitore le eventuali modifiche correttive necessarie dopo le fasi di test sulle versioni prototipali delle API.
Le API e il WFS dovranno essere corredate di script (in un linguaggio tra javascript e python) che testino le funzionalità lato client.
Dovrà essere possibile agli amministratori del sistema SIN2 la gestione delle API tramite interfacce di back-office, realizzate in V-CMS per la componente SIN2-CMS. La creazione e gestione delle chiavi applicative per le diverse applicazioni dovrà essere realizzata mediante apposite interfacce utente accessibili dagli sviluppatori opportunamente accreditati sul sistema mediante Area Operatori e IDM.
Tabella dei deliverable minimi
Sono previsti i seguenti deliverable anche in forma accorpata e composti di più sezioni ciascuna delle quali è legata ad una fase specifica di avanzamento dei lavori
Cod. Deliverable | Descrizione | Termine, a partire dalla data di approvazione della stipula del contratto, entro e non oltre il quale deve avvenire il rilascio |
SIN2_API_D1 | Documento analisi dei requisiti funzionali della componente | Mese 2 |
SIN2_API_D2 | Componente SIN2_API versione prototipale end-to-end | Mese 4 |
SIN2_API_D3 | Documento progettazione delle API e del WFS nel dettaglio | Mese 5 |
SIN2_CMS_D4 | Documentazione di dettaglio delle API e del WFS per lo svliuppatore | Mese 6 |
SIN2_API_D5 | Componente SIN2_API versione finale | Mese 9 |
SIN2_API_D6 | Linee guida, strumenti e risorse software per l’utilizzo delle API nella costruzione delle schede INTENSE da parte della componente SIN2- CMS. | Mese 9 |
SIN2_API_D7 | Documentazione prevista per l’architettura, deploy, performance, security, testing (vedi elenco O- ADSP) relativi a questa componente | Mese 9 |
SIN2_API_D8 | Documentazione prevista per i Test (vedi elenco O-TEST) relativi a questa componente | Mese 9 |
O-ADPST (Architecture-Deploy-Performance-Security-Testing)
L’obiettivo della fornitura è quello di realizzare la progettazione e il dimensionamento dell’architettura generale del sistema e di ciascuna componente, inclusa la definizione di uno schema di deploy per l’ambiente di produzione che ospiterà SIN2.
ll sistema SIN2 dovrà essere sviluppato su cloud Amazon AWS in modo da poter essere inserito all’interno dell’infrastruttura che attualmente ospita gli altri sistemi informatici dell’Assessorato del Turismo, Artigianato e Commercio.
Il fornitore dovrà definire il dimensionamento in termini di server, container, servizi serverless, risorse di calcolo, memoria e spazio disco e specificare come l’architettura applicativa proposta soddisfi i requisiti non funzionali legati a performance, scalabilità, affidabilità e sicurezza.
I sistemi dovranno essere progettati in modo da utilizzare servizi gestiti da AWS o tecnologie container (Docker) e sistemi di orchestrazione (ECS, Kubernetes) su cloud AWS.
Il fornitore dovrà definire quali accorgimenti verranno adottati per garantire la sicurezza informatica del sistema sfruttando i sistemi nativi Amazon AWS e quelli specifici delle piattaforme software scelte per il progetto.
Il fornitore dovrà predisporre strumenti di test delle performance e della scalabilità del sistema.
Le attività di configurazione sugli ambienti cloud di stage e produzione saranno a carico di RAS, anche per il tramite di fornitori terzi. Saranno invece a carico del fornitore le attività di configurazione degli ambienti cloud di sviluppo. L’aggiudicatario dovrà quindi disporre delle necessarie competenze per l’utilizzo e la personalizzazione delle risorse cloud allocate da RAS a suo uso e consumo nell’ambito del progetto, nel rispetto delle linee guida
indicate da RAS. Le attività di sviluppo potranno anche includere attività che implichino l’utilizzo dell’infrastruttura di cloud ibrido in fase di realizzazione.
Le operazioni sistemistiche realizzate dal fornitore in ambiente di sviluppo, sia locale che cloud, dovranno essere adeguatamente documentate per poter essere eseguite negli ambienti di stage/test e produzione da parte di RAS. RAS potrà richiedere al fornitore la creazione di appositi template AWS CloudFormation o altro strumento analogo, che realizzino l’infrastruttura sotto forma di codice.
La progettazione dovrà accogliere le indicazioni e best practice, prodotte da RAS in corso d’opera, per quanto attiene le metodologie e processi di change management e di gestione degli ambienti di sviluppo, stage e produzione da adottare su cloud, inclusa la gestione del deploy su tali ambienti delle diverse versioni del software (DevOps).
Costituiscono deliverable della fornitura:
● Documento di analisi e progettazione di dettaglio dell’architettura, che comprenda i requisiti non funzionali:
○ security;
○ data privacy;
○ performance;
○ scalability;
● Documento di progettazione della scalabilità automatica del sistema al crescere del carico;
● Test di performance e scalabilità:
○ tool;
○ piano test;
○ report di esecuzione;
● Ambienti di sviluppo;
● Documenti definizione processi e metodologie di deploy, change management e gestione ambienti di stage e produzione (coerenti con le linee guida RAS)
La fornitura si focalizza sulla definizione delle metodologie di test della fornitura, sia in fase di sviluppo che di rilascio incrementale di nuove funzionalità, sia nella effettiva pianificazione ed esecuzione dei test, sia nella predisposizione degli strumenti di test.
In particolare il fornitore dovrà produrre un deliverable apposito nel quale indicherà:
● come le discipline di testing intervengono nelle fasi di sviluppo del software (es. test driven development);
● quali metodologie di test verranno applicate per evitare regressioni del sistema a fronte di nuovi rilasci;
● quali strumenti di test saranno utilizzati e come saranno configurati gli ambienti di continuous integration e/o test automation forniti da RAS;
● quali tecniche e strumenti di versioning del software saranno utilizzati;
● la pianificazione dei test.
Il documento prodotto dovrà avere esplicita approvazione da parte della Stazione Appaltante. Sulla base di tale documento il fornitore provvederà ad erogare tutte le forniture previste dal capitolato dando evidenza alla Stazione Appaltante dell’aderenza ai principi e metodologie preventivamente indicati.
Per tutti i nuovi rilasci delle componenti software nel corso del progetto il fornitore dovrà garantire la definizione, lo sviluppo e l’esecuzione di:
1. test funzionali, a garanzia del funzionamento di nuove implementazioni;
2. test di non regressione, a garanzia del fatto che i nuovi rilasci non comportino problemi su funzionalità già rilasciate in passato;
3. test di integrazione per garantire il corretto funzionamento del sistema nella sua articolazione interna e anche in relazione ai sistemi esterni.
Costituiscono deliverable della fornitura:
● Documenti di definizione delle metodologie e strumenti di test adottati;
● Documenti di definizione delle metodologie e strumenti di versioning del software (se applicabile);
● Predisposizione tool ed ambienti di test;
● Esecuzione test;
● Documenti con i piani di test;
● Sviluppo e codice sorgente dei test;
● Rapporti sui test.
O-FSUP (Formazione e Supporto)
Trasversalmente a tutte le forniture sopra indicate, dovrà essere erogata una attività di formazione e una di supporto.
Le attività di formazione e supporto sono rivolte agli utenti del back-office, che utilizzeranno il sistema nei diversi ruoli previsti, e agli sviluppatori che dovranno usare le API Intense.
L’attività di supporto dovrà essere erogata a partire dalla data di completamento delle fasi di Costruzione e per i 12 mesi successivi alla data di positivo collaudo finale delle forniture. Le attività di supporto dovranno essere erogate anche mediante il sistema di trouble ticketing previsto nella fornitura HIS-MAN e mediante canale telefonico.
La calendarizzazione delle attività di supporto dovrà essere dettagliata nel piano delle attività che sarà concordato con la committenza, e le attività dovranno essere temporalmente contigue rispetto ai rilasci delle previste voci di fornitura.
Saranno oggetto della fornitura le attività di supporto alle redazioni INTENSE e ai loro responsabili, per le problematiche legate all’utilizzo dello strumento sotto forma di linea ticket per la segnalazione e gestione di problemi e anomalie gestita tramite help desk
● telefonico in orari di ufficio;
● email;
● supporto tramite il forum web;
● aggiornamento costante delle FAQ.
Le richieste di supporto dovranno essere inserite in modo da specificare il tipo di problematica attraverso l’indicazione di specifici tag da parte dell’utente. Le richieste e le risposte di assistenza, una volta risolte e opportunamente anonimizzate, confluiranno in una sezione comune di FAQ.
Il fornitore dovrà inoltre garantire un attività di formazione in merito all’utilizzo del sistema e delle API basata su:
● lezioni frontali (anche mediante sistemi di comunicazione remoti);
● produzione di un congruo numero di learning object (LO) digitali di auto formazione;
● una sezione costantemente aggiornata di FAQ;
● help in linea su tutte le interfacce di backoffice;
● sistemi di navigazione guidata integrati nelle interfacce;
L’attività di formazione dovrà essere erogata presso la sede della committenza o presso altra sede da questa indicata, potrà coinvolgere gli stakeholder del progetto secondo le indicazioni della Stazione Appaltante, e dovrà avere una durata minima di 5 giornate per l’insieme delle voci di fornitura. La calendarizzazione delle attività di formazione dovrà essere dettagliata nel piano delle attività che sarà concordato con la committenza, e le attività dovranno essere temporalmente contigue rispetto ai rilasci delle previste voci di fornitura.
Ciascun LO avrà un singolo e specifico obiettivo di formazione che sarà sviluppato in un massimo di 20 schermate, pari ad una tempo di fruizione massimo stimato in 30 minuti. Esempi non vincolanti di obiettivi di formazione degli LO sono: “imparare a pubblicare una scheda INTENSE”, “imparare a pubblicare un OST”, etc. I LO potranno inoltre essere usati per introdurre gli argomenti delle lezioni frontali e/o rivedere i contenuti trattati in gruppo.
Deliverable della fornitura (per utenti e sviluppatori):
● Servizi di assistenza e supporto;
● Manualistica;
● Rapporti periodici;
● Servizi di formazione e supporto indicati;
● Raccolta feedback discenti;
● Forum operativo;
● Attività di animazione sul forum;
● Sezione FAQ aggiornata;
● Learning object;
● Help in linea;
● Sistema gestione linea ticket;
● Sistema di navigazione guidata;
L’attività si rende necessaria per permettere la presa in carico e gestione del sistema realizzato da parte di soggetti individuati dalla Stazione Appaltante, dal punto di vista:
● delle funzionalità sviluppate, permettendo la necessaria presentazione ed illustrazione di queste ultime al personale che dovrà gestire e/o utilizzerà operativamente le applicazioni sviluppate;
● sistemistico, con riferimento agli ambienti di erogazione dispiegati per il progetto nell’ambito del Cloud AWS di RAS;
● applicativo, per quanto riguarda gli aspetti necessari alla manutenzione del software, con riguardo al livello di accesso e/o di modifica e/o di redistribuzione del codice sorgente proposto dal fornitore.
Le attività di passaggio di consegne dovranno essere garantite con uno effort di 12gg uomo di livello senior, da erogare a consumo e potranno essere espletate mediante strumenti on-line e, ove ritenuto necessario dalla Stazione Appaltante e comunque non oltre la misura della metà delle giornate, presso la sede di RAS o di un soggetto terzo individuato da RAS con sede sul territorio nazionale.
Deliverable della fornitura:
● Piano del passaggio di consegne e trasferimento competenze (tempi, competenze tecniche richieste, figure professionali coinvolte, materiale tecnico a supporto);
● Servizi passaggio di consegne e di trasferimento competenze verso la Stazione Appaltante e/o soggetti identificati da quest’ultima;
● Report di dettaglio sulle attività erogate con granularità oraria.
O-MAN (Servizi di Manutenzione correttiva)
Su tutte le componenti del sistema SIN2 realizzato e avviato in esercizio nel corso della fornitura, a partire dal loro rilascio e per i 12 mesi successivi al collaudo (a meno di offerta migliorativa in sede di gara), l’impresa aggiudicataria dovrà garantire i servizi di manutenzione correttiva e adeguativa.
Resta inteso che nella fornitura è esplicitamente compresa l’esecuzione da parte dell’aggiudicatario degli interventi necessari per garantire il pieno funzionamento e la corretta
integrazione delle componenti sviluppate nell’ambito dell’intera fornitura e con i sistemi esterni ad esse connessi.
Riguardo alla manutenzione correttiva, i malfunzionamenti verranno segnalati dalla stazione appaltante all’impresa, anche per il tramite di soggetti terzi individuati da RAS; l’accertamento e la rimozione delle cause e degli effetti dei malfunzionamenti delle procedure e dei moduli applicativi realizzati dovrà avvenire con assoggettamento agli SLA individuati nell’articolo 14, e secondo le tipologie di errore da questo definite. È ricompresa in questa fornitura la messa a disposizione da parte dell’aggiudicatario di un sistema di trouble ticketing per la gestione ed il tracciamento delle segnalazioni di malfunzionamento e il conseguente dialogo con i referenti della Stazione Appaltante. Il sistema di trouble ticketing deve prevedere:
● Accesso via web;
● Apertura delle problematiche via mail;
● Gestione gerarchica delle code di richiesta;
● Gestione livelli di priorità delle segnalazioni;
● Gestione priorità e allarmi;
● Workflow di gestione degli stati delle richieste condivisa con la Stazione Appaltante;
● Esportazione massiva delle attività registrate sotto forma di report dettagliati.
A discrezione della Stazione Appaltante, potrà essere alternativamente fornito da questa un sistema di trouble ticketing, che il fornitore dovrà utilizzare per la gestione della fornitura di manutenzione.
È previsto un deliverable bimestrale di attività che riporti: sintesi e report delle attività eseguite, con indicazione sui ticket lavorati, tempi di risposta (con evidenza della loro condizione entro i limiti degli SLA indicati).
Deliverable minimi della fornitura:
● Servizi di manutenzione;
● Sistema di trouble ticketing;
● Rapporti periodici.
Articolo 7. Modalità operative di realizzazione della fornitura
L’esecuzione delle forniture descritte dovrà essere resa entro e non oltre il termine previsto dal presente capitolato per ciascuna delle componenti descritte.
Le attività dovranno essere pianificate di concerto con la Stazione Appaltante attraverso l’emissione da parte del fornitore di un Piano operativo di progetto (PO) entro il termine dei
15 gg solari successivi all’approvazione della stipula. Il piano dovrà essere formalmente approvato dalla Stazione Appaltante.
All’interno del piano operativo dovranno essere indicati:
● l’elenco e la descrizione delle attività previste per ogni fornitura;
● le milestone e le propedeuticità per le diverse attività;
● l’elenco dei deliverable previsti per ogni fornitura, dove è specificata una loro descrizione e le tempistiche di rilascio previste, anche articolate in più versioni dei deliverable, nel rispetto dei deliverable minimi e dei rispettivi tempi prescritti dal presente capitolato.
Il piano operativo dovrà rispettare le tempistiche indicate dal capitolato e potrà essere aggiornato e modificato solo in modo concordato con la Stazione Appaltante. Qualsiasi modifica al Piano Operativo proposta dall’Aggiudicatario dovrà essere formalmente approvata dalla Stazione Appaltante.
I risultati intermedi e finali di quanto prodotto dal fornitore inclusi documenti, schemi, progetti, codice sorgente, saranno di esclusiva proprietà della Stazione Appaltante che potrà usarli per qualsiasi finalità e renderli pubblici.
Articolo 8. Gestione del progetto e fasi
Il progetto dovrà essere articolato in fasi di realizzazione secondo quanto previsto dall’Agile Unified Process (AUP), dove la fase di Inception si considera già conclusa.
Al termine di ciascuna fase devono essere raggiunti degli specifici obiettivi: si parla di milestone di passaggio da una fase alla successiva. Il progetto è gestito in modo seriale al livello macro (serial in the large) e iterativo a livello micro.
All’interno di ciascuna fase il lavoro dovrà essere fatto utilizzando metodologie Agili e dunque si procederà per raffinamenti incrementali, fino al raggiungimento delle condizioni per il passaggio alle fasi successive.
Il fornitore dovrà specificare nel PO quale metodologia agile verrà utilizzata per tale sviluppo iterativo.
In ciascuna fase dovranno essere eseguite le diverse discipline di analisi, disegno e gestione previste nell’AUP, che andranno incluse nelle forniture del presente capitolato:
● modellazione;
● implementazione;
● test;
● deployment;
● configuration management;
● project management;
● environment.
Le esatte attività delle varie fasi saranno dettagliate dal fornitore nel Piano Operativo (PO) nel rispetto dei vincoli del capitolato. Le fasi sono descritte di seguito.
Fase di Elaborazione
Lo scopo di questa fase è definire l’architettura del sistema end-to-end (si parla di un “prototipo architetturale”).
Il software sviluppato sarà effettivamente funzionante e garantirà il soddisfacimento di diversi casi d’uso “difficili”, individuati appositamente, dimostrando la reale fattibilità del sistema.
Per passare alla fase successiva bisogna superare la milestone chiamata Lifecycle Architecture o Architettura Globale. La questione importante a questo punto è mostrare che il fornitore ha completato un prototipo funzionante che confermi la bontà della strategia individuata per arrivare alla costruzione del prodotto finito.
Riportiamo di seguito alcuni macro obiettivi su cui si concentra questa fase:
1. definire la progettazione tecnica in termini di scelta delle tecnologie e definizione delle architetture software per tutte le componenti della linea;
2. definire l’information architecture della componente verticale V-CMS;
3. produrre una prima versione prototipale end-to-end del sistema;
4. eseguire i test di usabilità sul sistema prototipale della componente verticale V- CMS di UX (User eXperience);
5. raccogliere i risultati dei test di usabilità e consolidare la progettazione della user experience della componente verticale V-CMS.
I macro obiettivi sono caratterizzanti delle priorità della fase e andranno estesi e dettagliati coerentemente nel PO.
Fase di Costruzione
Lo scopo di questa fase è costruire un sistema funzionante in modo regolare e incrementale così da raggiungere gli obiettivi prefissati.
La fase è focalizzata sullo sviluppo del sistema fino al punto in cui sia disponibile per il test e la pre-produzione (un passo prima della presentazione al pubblico).
In questa fase il fornitore si concentra sulla effettiva individuazione e realizzazione delle soluzioni di dettaglio, della loro codifica software e dei test.
In questa fase verranno rilasciate delle versioni preliminari del software in modo che gli utenti e gli sviluppatori che useranno le API, possano iniziare usare il prodotto e dare dei feedback.
Per uscire dalla fase di Costruzione il team di sviluppo deve superare la milestone chiamata Initial Operational Capability detta anche di Operatività Iniziale. Il punto fondamentale è stabilire se le versioni del software già rilasciate siano pronte ad andare in produzione.
Riportiamo di seguito alcuni macro obiettivi su cui si concentra questa fase:
1. concludere la progettazione tecnica;
2. produrre la versione finale stabile per tutte le componenti della linea;
3. eseguire i test di usabilità come previsto nella fornitura V-CMS;
4. realizzare la versione finale della progettazione tecnica e, per la componente V- CMS, della progettazione UX (User eXperience);
5. sviluppare ed eseguire tutti i test funzionali e di integrazione secondo la metodologia della fornitura O-TEST;
6. iniziare la formazione per i tecnici RAS sull’uso delle funzionalità del sistema SIN2 Visto che dalle API INTENSE, dipendono progetti (applicazioni mobile e portale
collaborativo), sarà necessario che il fornitore concordi con RAS dei rilasci intermedi di tali
funzioni entro il sesto mese dall’inizio dei lavori.
I macro obiettivi sono caratterizzanti delle priorità della fase e andranno estesi e dettagliati coerentemente nel PO (Piano Operativo).
Fase di Transizione
Lo scopo di questa fase è validare e dispiegare il sistema in un ambiente di produzione.
Ci possono essere delle attività di test importanti durante le quali avviene una “sintonia fine” del prodotto software o la ricostruzione di parti difettose in base ai riscontri avuti nei test.
Per uscire dalla fase di Transizione il Team di sviluppo deve passare la milestone detta Product Release (PR) o di Rilascio del Prodotto. Punto nodale è qui stabilire se il sistema possa essere messo in produzione.
A questo punto il sistema è in produzione e inizia l’esercizio e la sua gestione e manutenzione correttiva.
Riportiamo di seguito i macro obiettivi su cui si concentra questa fase:
● bug fixing;
● proseguire con la formazione;
● realizzare la versione finale di tutte le componenti;
● completare lo sviluppo di tutti i test funzionali secondo la metodologia della fornitura O-TEST;
● completare il deploy dell’infrastruttura SIN2 sulla piattaforma SardegnaTurismo Evoluzione sul cloud dell'Assesorato al Turismo.
I macro obiettivi sono caratterizzanti delle priorità della fase e andranno estesi e dettagliati coerentemente nel PO.
Articolo 9. Articolazione temporale del progetto e SAL
Sono dettagliate di seguito le fasi, le milestone salienti e i tempi di realizzazione, si rimanda al dettaglio delle singole forniture per le tempistiche di rilascio dei singoli deliverable.
Fase | M1 | M2 | M3 | M4 | M5 | M6 | M7 | M8 | M9 | M10 | M11 |
Elaborazione | |||||||||||
Costruzione | |||||||||||
Transizione |
I mesi progetto sono da intendersi a decorrere dalla data di approvazione della stipula del contratto.
Sono previste le seguenti milestone:
● Inizio 1° mese: (Anticipo) inizio lavori;
● fine 4° mese: (SAL I) chiusura Elaborazione e rilascio versione prototipale del sistema;
● fine 6° mese: rilascio prima versione stabile API;
● fine 9° mese: (SAL II) chiusura Costruzione e rilascio versione stabile;
● fine 11° mese: (Saldo) chiusura transizione e rilascio versione in produzione.
Articolo 10. Corrispettivi e condizioni di fatturazione
I servizi resi saranno rendicontati dal fornitore secondo stati di avanzamento riportati in forma di relazioni (SAL) intermedie e finali. Il presente articolo definisce gli stati di avanzamento nell’esecuzione delle forniture in corrispondenza dei quali si maturano i valori fatturabili misurati in percentuale sull’importo dell’appalto.
Il fornitore potrà pertanto emettere gli stati di avanzamento nel momento in cui risultino completate le parti di fornitura di seguito elencate
Avanzamento | Valore % del SAL | Note |
Partenza lavori - Anticipo | 35% | Anticipo |
SAL I | 33% | Rilascio versione prototipale per tutte le forniture |
SAL II | 22% | Rilascio versione di costruzione per tutte le forniture |
Collaudo finale - completamento fase di Transizione per tutte le forniture verticali | 10% | Dalla positiva verifica del presente SAL decorrono i 12 mesi di manutenzione e supporto collaudo |
Articolo 11. Competenze, esperienze e qualificazione del team di progetto
La ditta aggiudicataria dovrà dispiegare un team di progetto composto da esperti con competenze, esperienze e qualificazione almeno pari a quelle di seguito indicate.
Gli esperti indicati per ciascun profilo professionale dovranno compilare la dichiarazione di cui all’Allegato 2. Un medesimo esperto può essere indicato per ricoprire un solo profilo professionale tra quelli indicati sotto.
Per i singoli profili professionali – con la sola eccezione del Project manager - sono indicate le aree tematiche che ne costituiscono declinazione. Si precisa che, affinchè l’esperto possa essere considerato adeguato rispetto ai requisiti minimi previsti dal presente capitolato, deve aver affrontato complessivamente, nell’ambito della sua carriera, almeno due delle aree tematiche elencate nel profilo professionale per il quale viene proposto.
Altresì, la singola esperienza attestata dall’esperto potrà essere ritenuta valida rispetto ai requisiti minimi richiesti, solo se attinente ad almeno una delle aree che costituiscono declinazione del profilo per il quale viene proposto.
Saranno computati un’unica volta i periodi nei quali due o più esperienze attestate si sovrappongono temporalmente.
Si riportano di seguito i profili professionali minimi richiesti:
● Programmatore senior web con almeno 5 anni di esperienza professionale documentata nelle seguenti aree:
o sviluppo applicazioni web, webgis su tecnologie
HTML5/CSS3/JavaScript o framework JavaScript (React.js, Angular.js o similari), sviluppo di applicazioni web Nodejs o PHP o Java based;
o integrazione applicativa nell’ambito di un ecosistema complesso;
o sviluppo in ambienti cloud;
● Cloud Architect/Web Architect con almeno 5 anni di esperienza documentata nelle seguenti aree:
o raccolta requisiti, analisi e disegno di architetture web;
o raccolta requisiti, analisi e disegno di architetture cloud;
o raccolta requisiti, analisi e disegno di architetture GIS o webgis;
● Data Architect con almeno 5 anni di esperienza documentata nelle seguenti aree:
o raccolta requisiti, analisi e modellazione di dati nell’ambito di un ecosistema complesso;
o Semantic web e modellazione semantica;
o competenze su sistemi GIS e dati geografici;
● UX Designer con almeno 2 anni di esperienza professionale documentata nelle seguenti aree:
o design applicazioni web front end e back-office;
o interfacce geografiche su web;
● Project manager con almeno 5 anni di esperienza professionale documentata nello specifico ruolo.
Si precisa che l’assenza anche solo di uno dei profili professionali indicati comporterà la non ammissibilità dell’offerta.
I requisiti richiesti devono essere documentati dal fornitore, mediante attestazioni redatte singolarmente da ciascuno dei soggetti in conformità al modello allegato (All. 2). La Stazione Appaltante potrà rifiutare, con adeguata motivazione, una o più delle candidature proposte dal fornitore nel caso in cui rilevi la mancanza dei requisiti sopra indicati. Inoltre la
RAS potrà richiedere l’esclusione di uno o più prestatori d’opera del fornitore, con adeguata motivazione, qualora se ne rilevi l’inadeguatezza nel corso di realizzazione della fornitura.
Articolo 12. Criteri di valutazione delle offerte
L’amministrazione procederà all’aggiudicazione dell’appalto mediante il criterio dell’offerta economicamente più vantaggiosa ai sensi dell’art. 95 del D.Lgs 50/2016.
Potrà essere attribuito all’offerta un punteggio massimo di 100 punti, calcolato prendendo in considerazione i criteri di valutazione di seguito definiti:
Componente | Punteggio max attribuibile |
a) Offerta tecnica | 70 |
b) Offerta economica | 30 |
Totale | 100 |
a) Offerta tecnica. Punteggio max attribuibile = 70 punti.
L’offerta redatta dall’impresa proponente dovrà essere corredata da un documento tecnico nel quale l’offerente dovrà descrivere il team di progetto e articolare la propria proposta specificando, coerentemente con quanto prescritto dal capitolato:
● metodologie di gestione del flusso di sviluppo e delivery che l’offerente propone di applicare nel corso dell’appalto;
● metodologie di testing che l’offerente propone di applicare nel corso dell’appalto;
● proposta di progetto che specifichi l’architettura generale del sistema e in particolare:
○ i sistemi di importazione degli OST, conciliazione dei dati degli OST e gestione semi automatica l’equivalenza semantica degli OST;
○ le modalità di integrazione delle informazioni trasportistiche nella costruzione delle schede INTENSE;
○ la struttura applicativa del SIN2-CMS e la sua integrazione mediante API al SIN2-DSAM;
○ le modalità di realizzazione delle API;
○ l’integrazione del servizio WFS in SIN2;
○ le metodologie di trattamento e gestione del dato spaziale e delle relazioni semantiche;
○ lo schema di deploy basato su su cloud AWS e container.
II sistema proposto dovrà prevedere la descrizione dell’architettura applicativa e il suo dispiegamento ambiente cloud AWS coerentemente con quanto indicato nel presente capitolato (es. uso container), prevedendo adeguati meccanismi di scalabilità orizzontale, alta affidabilità e sicurezza mediante l’utilizzo di strumenti tipici del cloud AWS (IAM, Elastic Load Balancing, Virtual Private Cloud).
Il fornitore dovrà inoltre corredare la descrizione del sistema con tutti gli aspetti relativi alle procedure di deploy e testing di nuove versioni in ottica di realizzare meccanismi di continuous integration.
L’offerta tecnica sarà valutata secondo i seguenti criteri:
● Esperienze professionali documentate migliorative rispetto a quelle minime richieste per le figure professionali previste dall’art.11 del presente Capitolato (fino a un massimo di 10 punti totali):
● 1 punto per ogni anno di esperienza documentata in più per Programmatore senior web, Cloud Architect/Web Architect, Data Architect, UX Designer, Project manager
● Estensione della garanzia oltre i 12 mesi previsti sugli interventi effettuati (fino a 10 punti per l’estensione della garanzia a 36 mesi)
● Qualità del documento tecnico di offerta (fino a 50 punti), con riferimento ai seguenti sub-criteri:
○ metodologie di gestione del flusso di sviluppo e delivery (fino a 8 punti);
○ metodologie di testing (fino a 7 punti);
○ proposta di progetto (fino a 35 punti) di cui:
■ qualità proposta per i sistemi di importazione degli OST, conciliazione dei dati degli OST e gestione semi automatica l’equivalenza semantica degli OST (fino a 5 punti);
■ qualità proposta per le modalità di integrazione delle informazioni trasportistiche nella costruzione delle schede INTENSE (fino a 5 punti);
■ qualità proposta per la struttura applicativa del SIN2-CMS e la sua integrazione mediante API al SIN2-DSAM (fino a 5 punti);
■ qualità proposta per le modalità di realizzazione delle API (fino a 5 punti);
■ qualità proposta per l’integrazione del servizio WFS in SIN2 (fino a 5 punti);
■ qualità proposta per le metodologie di trattamento e gestione del dato spaziale e delle relazioni semantiche (fino a 5 punti);
■ qualità proposta per lo schema di deploy basato su su cloud AWS e container (fino a 5 punti);
b) Offerta economica. Punteggio max attribuibile = 30 punti.
Le offerte economiche saranno valutate in base al ribasso percentuale offerto sulla base d’asta dell’appalto.
Il prezzo offerto per l’esecuzione di quanto sopra si intende comprensivo di tutte le prestazioni connesse ed accessorie che si dovessero rendere necessarie per l’esecuzione a regola d’arte dei servizi in oggetto, nonché di tutti gli oneri diretti ed indiretti derivanti dalla realizzazione di quanto previsto nel presente Capitolato, nel pieno rispetto della normativa vigente nazionale e comunitaria applicabile.
Il punteggio verrà determinato mediante applicazione della seguente formula:
Pi= Omin/Oi *30
In cui si ha:
Pi = punteggio dell’offerta in esame;
Omin = prezzo più basso delle offerte presentate;
Oi = prezzo dell’offerta in esame.
Articolo 13. Documentazione
La documentazione riferita all’esecuzione delle forniture descritte è rappresentata da tutti gli elaborati ed i contenuti intermedi e finali prodotti durante l’esecuzione dell’appalto.
La documentazione prodotta resterà di piena ed esclusiva proprietà della Regione Autonoma della Sardegna e dei soggetti partner che ne hanno richiesto la produzione tramite il presente Capitolato, e potrà essere pubblicata, rilasciata e diffusa in piena discrezionalità da RAS, CRS4 e Forestas. Potrà altresì essere utilizzata anche da altre istituzioni facenti parte del sistema regionale per gli scopi istituzionali perseguiti dalla Regione.
Articolo 14. Livelli di servizio (SLA)
I livelli di servizio attesi dalla stazione appaltante sono definiti con riferimento alle voci di fornitura sopra descritte, secondo gli indicatori ed i livelli di soglia di seguito riportati.
SLA di riferimento per le fasi di fornitura
Indicatore | Definizione | Servizio atteso - Valori di soglia |
PRD | Puntualità nei rilasci dei singoli deliverable documentali o dei rilasci sw rispetto ai tempi indicati per ciascuno di essi nel presente capitolato | Almeno il 90% dei rilasci entro la data pianificata nel presente capitolato per ciascun deliverable documentale o rilascio sw. Valore di check rilevato su base bimestrale |
PRR | Puntualità nei rilasci delle revisioni dei deliverable documentali o dei rilasci sw a seguito delle eventuali osservazioni fatte dalla Stazione Appaltante | Almeno il 90% dei rilasci delle revisioni entro 5 giorni lavorativi dalla data di comunicazione delle osservazioni da parte della Stazione Appaltante sul precedente rilascio del deliverable o del sw. Il termine è calcolato dalla data di invio della PEC o di ricezione della raccomandata cartacea. Valore di check rilevato su base bimestrale |
PCF | Puntualità nella chiusura delle fasi rispetto ai tempi previsti nel presente capitolato | Chiusura di ciascuna fase entro i termini previsti con una tolleranza massima di 5 giorni lavorativi per Linea di attività e comunque a condizione che i ritardi delle singole Linee tra loro sommati non siano superiori a 15 giorni lavorativi complessivi. |
SLA di riferimento per la manutenzione correttiva e adeguativa (MAN)
Indicatore | Definizione | Severità | Servizio atteso - Valori di soglia |
MAN-FPS | Finestra temporale di presidio del servizio | - | ore 09.00 - 17.30 da lun a ven |
MAN-FOS | Finestra di osservazione dello SLA | - | ore 09.00 - 17.30 da lun a ven |
MA N-TER | Tempo di evasione richieste di manutenzione correttiva e adeguativa in orario di presidio (FPS) | Bloccante Errore che determina il blocco dell’applicativo, o comporta l’interruzione del funzionamento totale o parziale di una specifica funzionalità da cui consegue un blocco del flusso di lavoro. | Almeno il 90% entro 1g (8H) su media rilevata nel bimestre |
MAN-TER | Tempo di evasione richieste di manutenzione correttiva e adeguativa in orario di presidio (FPS) | Grave Errore su una funzionalità che può essere bypassato tramite una soluzione temporanea o alternativa. | Almeno il 90% entro 2gg su media rilevata nel bimestre |
MAN-TER | Tempo di evasione richieste di manutenzione correttiva e adeguativa in orario di presidio (FPS) | Lieve Errore minore che non impedisce il “normale” funzionamento delle funzionalità su cui è rilevato. | Almeno il 90% entro 4gg su media rilevata nel bimestre |
SLA di riferimento per le attività di supporto e formazione (FSUP)
Indicatore | Definizione | Severità | Servizio atteso - Valori di soglia |
SUP-FPS | Finestra temporale di presidio del servizio | - | ore 09.00 - 17.30 da lun a ven |
SUP-FOS | Finestra di osservazione dello SLA | - | ore 09.00 - 17.30 da lun a ven |
SUP-TER | Tempo di evasione richieste di supporto in orario di presidio (FPS) | Bloccante Il mancato supporto all’utente comporta un blocco delle attività redazionali, o comporta | Almeno il 90% entro 1g (8H) su media rilevata nel bimestre |
un blocco | |||
nell’erogazione dei dati. | |||
Grave Il mancato supporto | Almeno il 90% entro 2gg su media rilevata nel bimestre | ||
all’utente può essere | |||
superato tramite una | |||
soluzione | |||
temporanea o | |||
alternativa. |
Lieve Il mancato supporto non impedisce il “normale” funzionamento del sistema. | Almeno il 90% entro 4gg su media rilevata nel bimestre |
Articolo 14bis. Penalità e recesso dal contratto
Qualora l’Impresa non rispetti i livelli di servizio sopra definiti, l’Amministrazione potrà applicare delle penali, fatto comunque salvo il risarcimento dell’eventuale maggior danno subito.
Il superamento di uno o più SLA dovrà essere comunicato dall’Amministrazione, ai fini dell’applicazione delle penali, in forma scritta. All’impresa è concesso un termine di 10 giorni solari per controdedurre in forma scritta; trascorso tale termine, ove non venga addotta alcuna giustificazione oppure questa, a insindacabile giudizio dell’Amministrazione, non venga riconosciuta sufficiente, potrà essere applicata la penale.
La penale potrà essere applicata al verificarsi del mancato raggiungimento dei valori di soglia degli SLA indicati nel precedente articolo. All’interno del valore di soglia non saranno applicate penalità: queste varranno per i soli contenuti eccedenti tale limite. In particolare:
o Mancato raggiungimento SLA PRD, PRR, PCF: l’importo delle penali è pari, per ciascun giorno di ritardo nel completamento delle attività pianificate, all’uno per mille dell’importo contrattuale; il ritardo è computato a partire dal momento in cui si verifica il mancato raggiungimento dello SLA.
o Mancato raggiungimento SLA MAN_TER: l’importo delle penali è pari, per ciascun giorno di ritardo nell’evasione delle richieste di manutenzione, all’uno per mille dell’importo contrattuale; il ritardo è computato a partire dal momento in cui si verifica il mancato raggiungimento dello SLA;
o Mancato raggiungimento SLA SUP_TER: l’importo delle penali è pari, per ciascun giorno di ritardo nell’evasione delle richieste di supporto, all’uno per mille dell’importo contrattuale; il ritardo è computato a partire dal momento in cui si verifica il mancato raggiungimento dello SLA.
Gli importi delle penalità, calcolate come sopra specificato, non potranno superare complessivamente il 10% dell’importo contrattuale e saranno trattenuti, di preferenza, sul primo mandato di pagamento utile.
L’Assessorato si riserva inoltre la facoltà di recedere dal contratto, indipendentemente dalle penalità da applicare e fatta salva ogni tutela e facoltà prevista per legge, qualora:
● si determini il superamento degli SLA sopraindicati per più di 5 volte;
● uno o più valori di soglia rilevati in corso di realizzazione con riferimento agli SLA sopraindicati, scendano al di sotto del 75%.
Articolo 15. Aggiudicazione dell’R.D.O. e stipula del contratto
L’aggiudicazione dell'offerta avverrà tramite il sistema messo a disposizione dal MEPA (Mercato Elettronico della Pubblica Amministrazione), secondo il criterio dell’offerta economicamente più vantaggiosa tra tutte le offerte pervenute dai fornitori.
Con la presentazione dell’offerta, la Ditta si obbliga nei confronti della Stazione Appaltante alla realizzazione della fornitura, nelle modalità e nei termini previsti nel presente Capitolato.
L’Amministrazione potrà, stante quanto riportato nei precedenti articoli, procedere all’aggiudicazione dell’appalto anche in presenza di una sola offerta valida e potrà altresì, a suo insindacabile giudizio, non affidare l’appalto ad alcuna delle Imprese concorrenti, senza che le Imprese partecipanti possano rivendicare alcun diritto.
La Stazione Appaltante, una volta disposta la proposta di aggiudicazione tramite il sistema MEPA, procede alla verifica del possesso dei requisiti richiesti dal presente Capitolato.
Qualora dai controlli risultasse, in capo all’aggiudicatario provvisorio, la mancanza di uno dei requisiti di ammissione alla gara, si procederà alla verifica sul concorrente secondo classificato; qualora anche quest’ultimo risultasse non in possesso dei requisiti prescritti, si procederà alla verifica sul concorrente terzo classificato e poi, a seguire, a quello di volta in volta successivo.
Una volta effettuati positivamente tutti i controlli di cui sopra, la Stazione Appaltante provvederà all’aggiudicazione definitiva sul MEPA. L’aggiudicazione definitiva diverrà efficace solo a seguito della sua formale approvazione con determina del Direttore del Servizio Sistemi Informativi.
Altresì, si precisa espressamente che il contratto con il fornitore sarà sottoposto alla condizione sospensiva dell’esito positivo della sua formale approvazione. Pertanto il contratto sarà efficace solo a seguito dell’emissione di apposita determina del Direttore del Servizio Sistemi Informativi.
Articolo 16. Garanzia definitiva
Nel termine di 7 giorni solari decorrenti dall’aggiudicazione definitiva, il fornitore dovrà far pervenire al Punto Ordinante idoneo documento comprovante la prestazione di una garanzia definitiva, in favore del Punto Ordinante, a garanzia degli impegni contrattuali, il cui importo sia conforme alla disciplina prevista dall’art. 103 del D.Lgs. 50/2016, che a tal fine integralmente si richiama.
La mancata costituzione della garanzia definitiva nei termini sopra indicati determinerà la decadenza dell’affidamento e l’escussione della garanzia provvisoria.
La garanzia dovrà avere efficacia per tutta la durata del contratto e, successivamente alla scadenza di tale termine, sino alla completa ed esatta esecuzione da parte del fornitore di tutte le obbligazioni nascenti dal contratto medesimo.
La garanzia sarà progressivamente svincolata a misura dell’avanzamento dell’esecuzione contrattuale. Si precisa che:
● la fidejussione bancaria o polizza assicurativa dovrà avere sottoscrizione dalla quale si evincano con chiarezza i poteri di firma del fideiussore o dell’assicuratore;
● dovrà, inoltre, prevedere espressamente:
- la rinuncia espressa al beneficio della preventiva escussione del debitore principale;
- la rinuncia all’eccezione di cui all’art. 1957, comma 2, del codice civile;
- l’operatività della garanzia medesima entro quindici giorni, a semplice richiesta scritta della stazione appaltante.
La documentazione richiesta dovrà essere inviata presso la casella di posta elettronica xxx.xxxxx@xxx.xxxxxxx.xxxxxxxx.xx.
Articolo 17. Conoscenza delle condizioni e revisione prezzi
L’assunzione dell’appalto di cui al presente capitolato implica da parte dell’Impresa aggiudicataria la conoscenza perfetta non solo di tutte le norme generali e particolari che lo regolano, ma altresì di tutte le condizioni locali, di tutti i fatti e le circostanze che possono influire in generale sulla convenienza di assumere l’appalto.
Resta pertanto convenuto che l’appalto si intenderà assunto dall’Impresa aggiudicataria ad esclusivo suo rischio in base a calcoli di sua convenienza e con implicita rinuncia ad ogni rivalsa per caso fortuito, nonché di qualsiasi altra circostanza che possa verificarsi dopo l’aggiudicazione.
Non è pertanto ammessa alcuna revisione dei prezzi indicati dal presente Capitolato che resteranno fissi ed invariabili.
Articolo 18. Regolamento Generale sulla Protezione dei Dati (UE/2016/679)
Il fornitore aggiudicatario dovrà garantire il rispetto del Regolamento Generale sulla Protezione dei Dati (UE/2016/679).
In particolare, l’aggiudicatario potrà assumere il ruolo di Responsabile del trattamento ai sensi dell’art. 28 del Regolamento, per quanto applicabile. L’aggiudicatario dovrà pertanto mettere in atto misure tecniche e organizzative adeguate in modo tale che il trattamento soddisfi i requisiti del citato Regolamento e garantisca la tutela dei diritti dell’interessato.
A norma dell’art. 25 del Regolamento, le misure di protezione dei dati dovranno essere previste sin dalla fase di progettazione (privacy by design) e garantire la protezione per impostazione predefinita (privacy by default).
Resta inteso che, richiamato l’art. 3 del Regolamento, è espressamente richiesto che il responsabile del trattamento sia stabilito nell’Unione e che non si concretizzino situazioni di trattamento transfrontaliero dei dati.
Articolo 19. Collaudo
Il collaudo potrà riguardare la totalità della fornitura e/o, a discrezione dell’Amministrazione, essere eseguito in corso d’opera su parti della fornitura stessa. Il collaudo sarà effettuato in contradditorio con il fornitore secondo le modalità che l’Amministrazione riterrà più utili.
Nel caso in cui le operazioni di collaudo ponessero in evidenza errori, difetti o mancanze, l’Impresa assume l’obbligo di eliminarli entro 5 giorni lavorativi. La puntualità nei rilasci correttivi è misurata dallo SLA PRR definito dall’art.14 del presente Capitolato.
Il collaudo si intenderà effettuato positivamente dopo che l’Amministrazione avrà riscontrato la rimozione degli errori, difetti o mancanze segnalati. L’esito positivo del collaudo comporta l’accettazione della fornitura da parte della stazione appaltante.
Articolo 20. Divieto di subappalto
In considerazione della specificità delle prestazioni richieste nell’ambito del presente affidamento, è vietato il subappalto.
Articolo 21. Divieto di sospensione dei servizi
L’Appaltatore non può sospendere i servizi forniti in seguito a decisione unilaterale, nemmeno nel caso in cui siano in atto controversie con la Stazione Appaltante.
L'eventuale sospensione dei servizi per decisione unilaterale dell’Appaltatore costituisce inadempienza contrattuale e conseguente causa di risoluzione del contratto per colpa.
In tal caso la Stazione Appaltante procederà all’incameramento della garanzia definitiva, fatta comunque salva la facoltà di procedere nei confronti dell’Appaltatore per tutti gli oneri conseguenti e derivanti dalla risoluzione contrattuale, compresi i maggiori oneri contrattuali eventualmente sostenuti dalla Stazione Appaltante e conseguenti a quelli derivanti dal nuovo rapporto contrattuale.
Articolo 22. Patto di integrità
Il fornitore garantisce il rispetto della delibera di Giunta Regionale n°30/16 del 16/06/2015 avente ad oggetto “Adozione misure di contrasto alla corruzione: applicazione dell’art. 4 del Regolamento ANAC 2014 in materia di attività di vigilanza e di accertamenti ispettivi e dell’art. 1, comma 17, della legge n. 190/2012 sui Patti di integrità” e del suo allegato.
Articolo 23. Esonero responsabilità
La Stazione Appaltante è esonerato da qualsiasi responsabilità derivante da rapporti instaurati a qualsiasi titolo dal fornitore con terzi in dipendenza delle attività connesse con l’espletamento del presente appalto.
Il fornitore garantisce inoltre la committenza che nell’ambito della fornitura non sarà violato alcun diritto di terzi (essendo compresi, a titolo esemplificativo e non esaustivo dati personali, diritti d’autore, diritti su segni distintivi, diritti di proprietà, etc) e si impegna a
manlevare e tenere indenne la Stazione Appaltante da qualsivoglia eventuale pretesa di terzi al riguardo.
Articolo 24. Contatti con l'unità ordinante
Per eventuali informazioni di natura tecnica o amministrativa nella fase precedente alla presentazione dell’offerta è possibile contattare il Servizio Sistemi Informativi attraverso i canali di comunicazione messi a disposizione all’interno del MEPA.
Articolo 25. Foro competente
Per eventuali controversie giudiziarie di qualsiasi natura, il Foro competente è quello di Cagliari.
(firma digitale)1
Il Direttore del Servizio Xxx. Xxxxxxxxxx Xxxxxx
1 Documento firmato digitalmente secondo le indicazioni sulla dematerializzazione contenute nella Deliberazione della Giunta Regionale n.71/40 del 16/12/2008 ai sensi e per gli effetti dell’art.20 comma 2 del D. Lgs 7 marzo 2005 n. 82 “Codice dell’amministrazione digitale”.