TDH)
CAPITOLATO TECNICO
Acquisizione dei servizi di evoluzione delle piattaforme Sardegna Turismo e Osservatorio del Turismo finalizzata all’interoperabilità con l’ecosistema Tourism Digital Hub
(TDH)
Procedura negoziata ai sensi dell’art. 50 comma 1 lett. e del d. lgs. 36/2023, mediante lo strumento della Richiesta di Offerta sul Mercato elettronico della P.A. con criterio di aggiudicazione al minor prezzo.
CUI S80002870923202000124 CUP E77H23002220008
CIG A02079027F
Acronimi e sigle 2
Articolo 1. Premessa 4
Articolo 2. Oggetto dell'appalto 5
Articolo 3. Descrizione del contesto 6
Portali SardegnaTurismo e Osservatorio del Turismo, Artigianato e Commercio 6
Tourism Digital Hub (TDH) 8
Articolo 4. Descrizione dei servizi richiesti 9
4.1. Migrazione del portale Sardegna Turismo e dell’Osservatorio del Turismo A. e C. a Drupal 10 11
4.2. Implementazione del sistema di integrazione con il Tourism Digital Hub 16
Articolo 5. Modalità operative di realizzazione della fornitura 19
Articolo 6. Livelli di servizio (SLA) 21
Articolo 7. Competenze, esperienze e qualificazione del team di progetto 22
Articolo 9. Verifica di conformità 24
Appendice. Elenco allegati. 25
Acronimi e sigle
Acronimo/sigla | Significato |
RAS | Regione Autonoma della Sardegna |
OTAC | portale Osservatorio del Turismo, Artigianato e Commercio |
ST | portale Sardegna Tursimo |
MEPA | Mercato Elettronico della Pubblica Amministrazione |
ICT | Information and Communication Technology |
RdO | Richiesta di Offerta |
CMS | Content Management System |
QA | Quality Assurance |
SLA | Service Level Agreement |
PAAS | Platform As A Service |
API | Application programming interface |
HW | Hardware |
UX | User eXperience |
UXA | User eXperience Analysis |
VM | Virtual Machine |
CSR | Centro Servizi Regionale (infrastruttura RAS) |
AWS | Amazon Web Services |
SIRA | Sistema Informativo Regionale dell'Ambiente |
POA | Piano Operativo delle Attività |
TDH | Tourism Digital Hub |
GIT | Software per il controllo di versione distribuito |
CI | Continuous Integration |
CD | Continuous delivery |
Articolo 1. Premessa
Il presente Capitolato ha lo scopo di descrivere i servizi personalizzati di sviluppo evolutivo dei portali SardegnaTurismo (xxxxx://xxx.xxxxxxxxxxxxxxx.xx/) e Osservatorio del Turismo, Artigianato e Commercio (xxxx://xxxxxxxxxxxx.xxxxxxxxxxxxxxx.xx/ ) richiesti agli operatori economici partecipanti alla gara.
L'affidamento di cui al presente Capitolato avverrà tramite richiesta di offerta (RDO) sul MEPA, Mercato Elettronico della Pubblica Amministrazione, ed è preceduto dall’Avviso di preinformazione pubblicato in data 26/10/2023 all’indirizzo xxxxx://xxx.xxxxxxx.xxxxxxxx.xx/xxxx-xxxxx-xxxxxxx/xxxx-xxxxxxxxxxxxxx/xxxxx/000000000000000 .
Sono ammessi a partecipare alla presente procedura di gara, tutti gli operatori economici che siano regolarmente iscritti sul Mercato elettronico della P.A. (MePA), ove siano espressamente abilitati a presentare offerte nel Bando “Servizi”, Area Merceologica “Informatica, Elettronica e Telecomunicazioni”, classe merceologica “Servizi ICT”, categoria “Supporto e consulenza in ambito ICT”, CPV 72230000-6 - Servizi di sviluppo di software personalizzati, che inoltre siano in possesso dei requisiti di ordine generale, tecnico e professionale indicate nel disciplinare di gara, ed in assenza delle cause di esclusione previste dal Codice degli Appalti (D.Lgs. 36/2023).
L’Avviso di preinformazione, reso pubblico 15 (quindici) giorni prima della pubblicazione della RDO MePA, ha avuto lo scopo di consentire alle imprese interessate di verificare, ovvero richiedere ed ottenere con anticipo, la regolare iscrizione nella piattaforma telematica MePA nel bando e categoria merceologica sopra indicate.
L’appalto verrà aggiudicato in base al criterio del prezzo più basso, ai sensi dell’art. 108, comma 3, del codice degli appalti.
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.
Il presente Capitolato tecnico integra quanto disposto dal disciplinare di gara.
Articolo 2. Oggetto dell'appalto
Il presente Capitolato regolamenta la fornitura di servizi professionali di sviluppo evolutivo dei portali Sardegna Turismo e Osservatorio del Turismo, Artigianato e Commercio per l'interfacciamento con il Tourism Digital Hub (TDH) del Ministero del Turismo, come descritti nel presente Capitolato.
I servizi di evoluzione sono acquisiti nell'ambito della realizzazione del Tourism Digital Hub, con un finanziamento previsto dal Ministero del Turismo con fondi europei mediante il Piano Nazionale di Ripresa e Resilienza (PNRR), Missione 1 (Digitalizzazione, innovazione, competitività, cultura e turismo), Componente 3 (Turismo e cultura), Investimento 4.1 – “Digital Tourism HUB”.
Articolo 3. Descrizione del contesto
Di seguito vengono introdotte le informazioni di contesto necessarie ad inquadrare sotto il profilo tecnologico i portali SardegnaTurismo e Osservatorio del Turismo, Artigianato e Commercio e il Tourism Digital Hub (TDH).
Portali SardegnaTurismo e Osservatorio del Turismo, Artigianato e Commercio
Con l’attuazione del progetto SardegnaTurismo Evoluzione, finanziato con il POR XXXX 0000-0000 – Linea di Attività 4.2.4.b, l’Assessorato del Turismo, Artigianato e Commercio ha realizzato e messo in uso la piattaforma tecnologica SardegnaTurismo. Nell’ambito del POR FESR Sardegna 2014-2020, ed in particolare dell’Asse II Agenda Digitale – Azione 2.2.2, sono stati realizzati gli interventi di “Evoluzione della piattaforma SardegnaTurismo e dell’Osservatorio del Turismo, Artigianato e Commercio”, come previsto dagli atti di programmazione della Giunta regionale (Deliberazione n. 49/3 del 6 ottobre 2015).
Nell’ambito di tale piattaforma tecnologica, il portale Sardegna Turismo (ST) e quello dell'Osservatorio del Turismo, Artigianato e Commercio (OTAC) costituiscono un’offerta informativa integrata e fanno riferimento dal punto di vista tecnologico ad una comune infrastruttura di erogazione.
I portali ST e OTAC costituiscono una piattaforma web integrata e fanno parte di un "ecosistema" informativo complesso, che è ospitato su infrastrutture Cloud AWS e CSR gestito da RAS.
Le componenti di tale ecosistema pertinenti rispetto al presente capitolato sono rappresentate di seguito:
● Access Manager: è il sistema di autenticazione regionale che implementa diversi meccanismi di autenticazione basati, ad esempio, sull'utilizzo della CNS (Carta Nazionale dei Servizi) o tramite SPID. Molti dei sistemi della piattaforma SardegnaTurismo e
dell'Osservatorio del turismo sono integrati con tali sistemi allo scopo di consentire agli utenti l’accesso ai diversi sistemi con le stesse credenziali condivise.
● Destination Management System (DMS): 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. Esso importa le strutture ricettive dall'Anagrafe delle Strutture Ricettive, e le esporta verso il portale xxx.xxxxxxxxxxxxxxx.xx tramite l'uso di API.
● Portale Sardegna Turismo - ST (xxx.xxxxxxxxxxxxxxx.xx): Sardegna Turismo è il 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 sistema è ospitato su piattaforma Acquia Drupal e la sua 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/).
● Filiera propagazione dati: si tratta di un sistema trasversale che integra tra loro alcune componenti della piattaforma Sardegna Turismo e dell'Osservatorio del turismo. In particolare l'Anagrafe delle Strutture Ricettive (ASR) è la fonte primaria delle informazioni relative alle strutture ricettive, che vengono propagate in altri sistemi a valle, tra i quali il DMS, all’interno del quale essi possono a loro volta essere integrati con dati commerciali prima di essere propagati verso il portale SardegnaTurismo e da questo verso l’app
SARDINIA.
La propagazione dei dati avviene in diverse modalità:
○ da ASR a DMS: mediante un processo a code basato su eventi: un messaggio si propaga ogni volta che interviene una variazione sui dati da propagare
○ da DMS a Sardegna Turismo ,e poi all’APP SARDINIA: attraverso processi batch basati sulle API esposte dai sistemi a monte e interrogate periodicamente da quelli a valle.
● Portale dell'Osservatorio del Turismo, Artigianato e Commercio (OTAC): sito che raccoglie ed espone in modo organico i dati sul fenomeno turistico in Sardegna (xxxx://xxxxxxxxxxxx.xxxxxxxxxxxxxxx.xx) ed i sistemi di data visualization in esso ospitati (xxxx://xxxxxxxxxxxx.xxxxxxxxxxxxxxx.xx/xx/xxxxxxx-xxxx); questi ultimi sono sistemi interattivi di analisi e visualizzazione dei flussi turistici in Sardegna, basati su dati provenienti dal Sired o da altre fonti.
Tourism Digital Hub (TDH)
Il "Tourism Digital Hub" (TDH) del Ministero del Turismo italiano è una piattaforma digitale innovativa progettata come un hub multi-canale, che include web, app e chat. Funziona come un ponte virtuale, collegando direttamente i bisogni dei turisti all'offerta turistica dell'Italia. Attraverso la diffusione dei contenuti raccolti, la piattaforma offre ai turisti, sia italiani che stranieri, esperienze digitali altamente personalizzate, rispondendo in modo efficace alle loro esigenze e preferenze. Questo progetto rappresenta un passo avanti significativo nella digitalizzazione e promozione del turismo italiano a livello globale.
ll TDH si avvale della collaborazione dei Partner e delle Regioni per l'acquisizione di contenuti. Ecco una sintesi di come il TDH viene alimentato:
● I Partner di progetto e le Regioni, grazie alla loro profonda conoscenza del territorio e dell'offerta turistica, svolgono un ruolo fondamentale nell'alimentazione del TDH.
● le Regioni e i Partner adattano contenuti esistenti nei propri siti o creano nuovi contenuti che vengono conferiti mediante API al TDH, creando un ecosistema in continuo aggiornamento.
● Il contributo dei Partner e delle Regioni è essenziale per produrre articoli che, tramite il TDH, vengono pubblicati sul portale Xxxxxx.xx, mettendo in luce le caratteristiche uniche del territorio italiano.
I contenuti forniti dalle Regioni al TDH devono rispettare delle Linee Guida Editoriali:
● La condivisione dei contenuti deve avvenire tramite API (protocollo di interoperabilità TDH).
● I contenuti devono essere inviati solo ed esclusivamente in lingua italiana.
● La selezione dei contenuti da pubblicare avviene sulla base delle tematiche presenti nei piani editoriali mensili.
● I link esterni devono essere utilizzati con moderazione e devono rimandare a pagine specifiche, come registrazioni ad eventi.
● È importante evitare link che rimandino ad approfondimenti editoriali su siti esterni.
Sono previste due modalità di condivisione dei contenuti attraverso TDH: condivisione di contenuti editoriali già pubblicati sul sito delle Regioni e condivisione di contenuti editoriali redatti ad hoc in linea con il piano editoriale di Xxxxxx.xx.
Nell’ambito dei servizi richiesti nel presente capitolato è inclusa la realizzazione di specifiche interfacce di back-office per la creazione di contenuti adatti all'alimentazione del TDH e i sistemi di invio di tali contenuti mediante le opportune API TDH.
Articolo 4. Descrizione dei servizi richiesti
L'Assessorato del Turismo, Artigianato e Commercio della Regione Autonoma della Sardegna, nell'ambito del contesto precedentemente illustrato, ha necessità di acquisire i servizi di sviluppo evolutivo dei portali ST e OTAC al fine di implementare le modifiche necessarie a poter
ospitare i contenuti adatti al portale xxxxxx.xx, e a poterli esportare verso il TDH con processi automatici. Visto il carattere istituzionale della piattaforma, nella realizzazione delle forniture di servizi web, si dovranno osservare i principi generali e le indicazioni operative contenute nelle Linee guida per i siti web delle PA previste dagli artt. 53 "Siti Internet delle pubbliche amministrazioni" e 71 "Regole Tecniche" del CAD, istituito con il decreto legislativo 7 marzo 2005,
n. 82 e ss.mm.ii.
Tutti gli sviluppi potranno avvenire, oltre che su ambienti locali del fornitore, su servizi Cloud identificati e forniti da RAS (Amazon AWS, Acquia Drupal o simili, etc.) e/o su cloud Ibrido fornito da RAS. Gli interventi richiesti al fornitore saranno comunque limitati alla sola piattaforma CMS Drupal utilizzata per i portali e non saranno richiesti interventi sulle altre componenti tecnologiche.
Il codice e la documentazione e tutti i deliverable prodotti nell'ambito dell'appalto, inclusi codice sorgente, i mockup grafici, i template, i prototipi, saranno di proprietà RAS. Sono incluse eventuali componenti applicative realizzate da terze parti, che devono essere fornite sotto licenza open salvo esplicito accordo scritto con RAS. Il codice sorgente prodotto e comunque necessario al dispiegamento dei portali e del sistema di integrazione con TDH dovrà essere gestito mediante sistemi di versioning (Git) forniti da RAS.
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 del singolo intervento e senza costi aggiuntivi per RAS. 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.
Durante tutte le fasi di sviluppo e test, come pure nella successiva fase di manutenzione della soluzione realizzata, le segnalazioni di malfunzionamenti saranno effettuate da RAS attraverso un sistema di task management e bug tracking JIRA fornito da RAS.
4.1. Migrazione del portale Sardegna Turismo e dell’Osservatorio del Turismo A. e C. a Drupal 10
Il Portale Sardegna Turismo è attualmente realizzato con Drupal versione 7.x, versione ormai obsoleta e prossima ad uscire fuori garanzia in quanto sostituita dalla versione 10.x. Pertanto, al fine di evitare un inutile dispendio di risorse si rende necessario realizzare gli interventi evolutivi direttamente su Drupal 10.x. Questo implica che l’intero Portale dev’essere migrato su tale versione. Il Portale Osservatorio del Turismo, Artigianato e Commercio è attualmente realizzato con Drupal versione 8.5. Pertanto, al fine di mantenere omogeneità con il sito Sardegna Turismo si rende necessario migrare anche tale portale su Drupal 10.x.
L’attività di migrazione potrà avvenire, laddove possibile, con l’ausilio di appositi tool; dove necessario, invece, i moduli Drupal e le specifiche configurazioni del CMS dovranno essere riscritti o sostituiti con versioni adeguate a Drupal 10, fino ad ottenere la piena compatibilità con il nuovo framework e con gli altri moduli installati. Salvo comprovati casi eccezionali esplicitamente approvati in forma scritta da RAS non potranno essere usati moduli o librerie che prevedono un canone o qualsiasi altra forma di pagamento.
La soluzione realizzata su Drupal 10.x dovrà garantire il pieno e corretto funzionamento di tutte le funzionalità e con tutti i dati e le configurazioni degli attuali portali, comprese quelle del front end, del backend. del back-office, sistemistiche e di integrazione con gli altri sistemi interconnessi.
In particolare l'attività di migrazione dovrà garantire che ciascuno dei nuovi portali:
● fornisca all’utente esterno le stesse funzionalità e la stessa esperienza utente disponibile sull’attuale versione del portale;
● fornisca agli utenti di back-office le stesse funzionalità e la stessa esperienza utente disponibile sull’attuale versione del portale;
● contenga tutti i contenuti attuali opportunamente migrati nella nuova versione;
● ricrei la medesima architettura informativa dei portali attuali;
● conservi l’integrazione con gli altri sistemi regionali attualmente supportati ed esponga le medesime API attualmente implementate;
● venga testato in modo automatico rispetto alla presenza di tutte le funzionalità oggetto di migrazione;
● venga testato in modo manuale e/o automatico per garantire il rispetto di tutti i requisiti di accessibilità a prescindere da quanto avviene nel portale attuale;
● venga testato in modo automatico rispetto alla presenza di tutti i contenuti e dati oggetto di migrazione;
● venga testato in modo automatico mediante lo sviluppo di una suite di test delle interfacce utente di front-end basate su tecniche e tecnologie di UI Testing cross browser (es. Chrome, Firefox) e cross device su PC, tablet e mobile (iOS, Android);
● venga testato in modo automatico rispetto all’integrazione con gli altri sistemi regionali attualmente supportati e all’esposizione delle API;
● venga testato in modo automatico rispetto alle performance nella risposta agli utenti sotto carico. Dovranno essere garantite almeno le performances attuali a parità di piattaforma di hosting su cui i sistemi sono ospitati.
Il fornitore dovrà altresì implementare su AWS una soluzione di Continuous Integration (CI) e Continuous Deployment (CD), Sistema CI/CD, per i portali Drupal oggetto di migrazione. Tale soluzione dovrà consentire l’esecuzione automatica dei test in ambiente di stage per ogni nuovo rilascio in lavorazione. Queste soluzioni dovranno adottare gli standard e le tecnologie di riferimento meglio specificate nell’apposito allegato al presente capitolato.
Eventuali interventi migliorativi rispetto ai portali attuali o al sistema di CI/CD potranno essere proposti dal fornitore ma dovranno essere esplicitamente approvati da RAS a suo insindacabile giudizio.
Come già specificato, al momento non si prevede la necessità di interventi adeguativi sugli altri sistemi informativi interconnessi ai portali oggetto di migrazione, che pertanto non sono oggetto del presente affidamento. Il fornitore potrà tuttavia proporre delle modifiche in tali sistemi, che RAS dovrà esplicitamente approvare in forma scritta, nel caso in cui esse possano portare a una semplificazione e al miglioramento della qualità dei relativi meccanismi di interconnessione.
Tutte le attività necessarie alla migrazione, quali ad esempio il porting dei dati sulla nuova piattaforma, compresi i testi, i contenuti multimediali, le traduzioni dei contenuti e dell’interfaccia, tutte le altre configurazioni, etc. sono da considerarsi comprese nel presente affidamento e includono qualunque eventuale attività di adattamento che dovesse rendersi necessaria. Sono inclusi i dati da migrare sulla nuova piattaforma. Si noti che le procedure di import dei dati devono essere automatizzate ed incrementali, in modo da consentire la loro esecuzione tutte le volte che risulti necessario (ad esempio a causa di errori di importazione, o per consentire l’allineamento della nuova piattaforma ai contenuti della vecchia prima dello switch finale dei due ambienti). RAS, anche per tramite di fornitori esterni, fornirà tutto il supporto necessario fornendo le specifiche delle attuali procedure di import.
Rispetto alle ottimizzazioni per i motori di ricerca la migrazione dovrà garantire l’opportuna impostazioni dei metadati della pagina in linea con quanto implementato nel portale attuale.
Quando la nuova versione dei portali sarà in linea le url parlanti dei nuovi contenuti dovranno essere identiche a quelle dei vecchi, al fine di consentire la continuità dell’indicizzazione dei motori di ricerca, e il corretto funzionamento delle url che erano state condivise tra gli utenti (nei social, via mail, whatsapp, etc.), messe nei preferiti dei browser, etc. Questo include anche il redirect di url esposte dal portale a seguito di modifiche sul titolo del contenuto o per altre ragioni.
La definizione delle configurazioni per gli ambienti Drupal e la loro applicazione sugli ambienti di sviluppo sono a carico del fornitore. RAS procederà all’applicazione di tali configurazioni sugli ambienti di stage e produzione.
Per aiutare i partecipanti nella definizione dell’offerta economica sono allegati al presente capitolato i documenti elencati in appendice.
Tali documenti vanno intesi come non esaustivi e non sono prescrittivi rispetto alle modalità di implementazione che il fornitore deciderà di adottare.
Le attività di migrazione dovranno essere articolate secondo le seguenti fasi:
1. l’aggiudicatario predispone un’estensione del Piano Operativo delle Attività introdotto nell’art. 5 che dettaglia le tempistiche e le risorse umane coinvolte nell’ambito delle attività di migrazione;
2. la RAS valuta le estensioni al Piano Operativo delle Attività e, se necessario, chiede di modificarle prima dell’approvazione;
3. l’aggiudicatario procede a un’analisi della situazione esistente (As Is) e alla definizione della strategia di migrazione sotto il profilo organizzativo e tecnico mediante la redazione di un documento denominato “Piano di Migrazione”; in questo documento potranno essere proposte eventuali differenze tra la nuova versione dei portali e quella originale;
4. la RAS valuta il Piano di migrazione e, se necessario, chiede di modificarlo prima dell’approvazione;
5. l’aggiudicatario procede alle attività di migrazione in base a quanto indicato nel Piano Operativo e nel Piano di Migrazione;
6. l'aggiudicatario produce un documento denominato Piano dei test di migrazione, in cui riporta la lista dei test automatici e manuali necessari per verificare l’esito della migrazione sotto ogni profilo e lo sottopone a RAS;
7. la RAS valuta il Piano dei test e, se necessario, chiede di modificarlo prima dell’approvazione;
8. a seguito del completamento della migrazione si dovrà procedere alla verifica dei risultati raggiunti mediante l’esecuzione dei test automatici e manuali definiti nel piano dei test e alla messa in linea dei nuovi portali in sostituzione di quelli originali opportunamente allineati alla più recente versione dei contenuti.
Nella realizzazione dei servizi, RAS fornirà le risorse cloud necessarie per tutti gli ambienti (sviluppo, stage e produzione).
Nella realizzazione degli interventi di migrazione, il fornitore dovrà garantire l'aggiornamento della documentazione eventualmente esistente o la produzione di nuova idonea documentazione, laddove necessario e secondo le richieste di RAS.
La tabella seguente riporta l’elenco dei deliverable che dovranno essere prodotti con le relative descrizioni.
Cod. Deliverable | Nome | Descrizione |
MIG-POA | Estensione del Piano Operativo delle Attività | Dettaglia le tempistiche e le risorse umane coinvolte nell’ambito delle attività di migrazione. |
MIG-PMST | Piano migrazione Sardegna Turismo | Fornisce un’analisi della situazione esistente (As Is) e la definizione della strategia di migrazione sotto il profilo organizzativo e tecnico. |
MIG-PMOTAC | Piano migrazione Osservatorio Turismo, Artigianato e Commercio | Fornisce un’analisi della situazione esistente (As Is) e la definizione della strategia di migrazione sotto il profilo organizzativo e tecnico. |
MIG-PT | Piano di test | Riporta la lista dei test automatici e manuali necessari per verificare l’esito della migrazione sotto ogni profilo. |
MIG-ST | Portale Sardegna Turismo | Portale Sardegna Turismo correttamente migrato e disponibile online. |
MIG-OTAC | Portale Osservatorio Turismo, Artigianato e Commercio | Portale Osservatorio Turismo, Artigianato e Commercio correttamente migrato e disponibile online. |
MIG-COD | Codice Sorgente | Codice sorgente di tutto quanto viene realizzato |
MIG-DT | Documentazione Tecnica | Documentazione tecnica che descrive i nuovi portali e il sistema CI/CD in dettaglio per consentire la loro manutenzione. |
MIG-BO | Documentazione Back Office | Documentazione utente che spiega il funzionamento del back-office. |
MIG-CI/CD | Sistema CI/CD | Sistema di Continuous Integration (CI) e Continuous Deployment (CD) |
MIG-TR | Report di esecuzione dei test | Documento che riporta il report dei test eseguiti e il loro esito |
MIG-TEST | Test realizzati | Codice dei test realizzati automaticamente e schede di test per quelli realizzati manualmente. |
4.2. Implementazione del sistema di integrazione con il Tourism Digital Hub
Il progetto TDH prevede la realizzazione di un meccanismo tecnologico per la fornitura al portale Xxxxxx.xx di contenuti con le seguenti caratteristiche principali:
- una struttura dati simile ma non uguale a quella definita nel Portale
- dei contenuti attinenti alle linee guida definite per xxxxxx.xx ma diversi da quelli pubblicati su xxxxxxxxxxxxxxx.xx, al fine di evitare di incorrere in penalizzazioni dal punto di vista del ranking dei principali motori di ricerca in caso di contenuti uguali pubblicati da sistemi diversi.
I tipi di contenuto che TDH si aspetta sono 4: destination, article, itinerario, evento; essi sono analoghi ed abbastanza simili a tipi di contenuto già definiti nel Portale, di seguito una tabella riepilogativa:
Tipo di contenuto TDH | Tipo di contenuto Portale |
destination | attrattore |
article | ispiratore / ispiratore must see |
evento | evento da non perdere |
itinerario | itinerario |
Pertanto il fornitore dovrà creare sul Portale dei tipi di contenuto ad hoc per TDH, ed aggiungere le relative funzionalità per la loro gestione nel backend, in modo del tutto analogo a quelle già presenti per gli altri tipi di contenuto: creazione, modifica, cancellazione, ricerca, gestione tassonomie e tag, traduzione, gestione revisioni e più in generale del flusso redazionale fino alla pubblicazione. Il fornitore dovrà inoltre creare un meccanismo automatico in grado di propagare i contenuti pubblicati al sistema TDH, come pure tutte le modifiche successive, inclusa l’eventuale cancellazione o rimozione dalla pubblicazione, attraverso apposite API. Tutti i dettagli sulla struttura dati di ciascun tipo di contenuto da creare, e sulle modalità di funzionamento delle
API esposte da TDH, sono allegati al presente capitolato. Il fornitore è comunque tenuto a rispettare le specifiche più recenti che saranno fornite da RAS in fase di avvio delle attività.
Le attività di sviluppo del sistema di integrazione dovranno essere articolate secondo le seguenti fasi:
1. l’aggiudicatario predispone un estensione del Piano Operativo delle Attività introdotto nell’art.5 che dettaglia le tempistiche e le risorse umane coinvolte nell’ambito delle attività di sviluppo e integrazione;
2. la RAS valuta le estensioni al Piano Operativo delle Attività e, se necessario, chiede di modificarle prima dell’approvazione;
3. l’aggiudicatario procede a un’analisi della situazione esistente (As Is) e alla definizione della strategia di implementazione sotto il profilo organizzativo e tecnico mediante la redazione di un documento denominato “Piano di sviluppo e integrazione”;
4. la RAS valuta il Piano di sviluppo e integrazione e, se necessario, chiede di modificarlo prima dell’approvazione;
5. l’aggiudicatario procede alle attività di sviluppo e di integrazione in base a quanto indicato nel Piano Operativo e nel Piano di Integrazione;
6. l'aggiudicatario produce un documento denominato Piano dei test TDH, in cui riporta la lista dei test automatici e manuali necessari per verificare l’esito delle implementazioni sotto ogni profilo e lo sottopone a RAS;
7. la RAS valuta il Piano dei test e, se necessario, chiede di modificarlo prima dell’approvazione;
8. a seguito del completamento delle implementazioni si dovrà procedere alla verifica dei risultati raggiunti mediante l’esecuzione dei test automatici e manuali definiti nel piano dei test e alla messa in linea delle nuove funzionalità.
Nella realizzazione dei servizi, RAS fornirà le risorse cloud necessarie per tutti gli ambienti (sviluppo, stage e produzione).
Nella realizzazione degli interventi di migrazione, il fornitore dovrà garantire l'aggiornamento della documentazione eventualmente esistente o la produzione di nuova idonea documentazione, laddove necessario e secondo le richieste di RAS.
La tabella seguente riporta l’elenco dei deliverable che dovranno essere prodotti con le relative descrizioni.
Cod. Deliverable | Nome | Descrizione | ||||
TDH-POA | Estensione del Piano Operativo delle Attività | Dettaglia le tempistiche e le risorse umane coinvolte nell’ambito delle attività di sviluppo e integrazione per TDH. | ||||
TDH-PSI | Piano di integrazione | sviluppo | e | Fornisce un’analisi della situazione esistente (As Is) e la definizione della strategia di implementazione sotto il profilo organizzativo e tecnico. | ||
TDH-PT | Piano di test | Riporta la lista dei test automatici e manuali necessari per verificare l’esito delle implementazioni sotto ogni profilo. | ||||
TDH-EST | Estensione Sardegna Turismo per integrazione TDG | Nuove funzionalità del portale Sardegna Turismo per l’integrazione con il TDH. | ||||
TDH-COD | Codice Sorgente | Codice sorgente di tutto quanto viene realizzato | ||||
TDH-DT | Documentazione Tecnica | Documentazione funzionalità in manutenzione. | tecnica dettaglio | che per | descrive le consentire | nuove la loro |
TDH-BO | Documentazione Back Office | Documentazione utente che spiega il funzionamento del back-office. | ||||
TDH-TR | Report di esecuzione dei test | Documento che riporta il report dei test eseguiti e il loro esito | ||||
TDH-TEST | Test realizzati | Codice dei test realizzati automaticamente e schede di test per i quelli realizzati manualmente. | ||||
Articolo 5. Modalità operative di realizzazione della fornitura
Sono di seguito definite le modalità operative di realizzazione e di coordinamento da stabilirsi tra l'Assessorato ed i referenti designati dall'impresa aggiudicataria.
La RAS metterà a disposizione dell'impresa aggiudicataria un repository per la condivisione del codice sorgente degli applicativi della piattaforma SardegnaTurismo e dell'Osservatorio del Turismo, Artigianato e Commercio.
Attraverso questo repository, anche sulla base delle policy definite e condivise con l'impresa aggiudicataria, verrà garantito l'accesso ad aree per l'interscambio dati ed il deposito di pacchetti applicativi per le finalità di cui alla presente fornitura.
L'aggiudicatario si impegna, nella realizzazione dei servizi, a mantenere un costante coordinamento con RAS ed a restituire prodotti finali che siano:
● aderenti alle indicazioni ed alle specifiche generali contenute nel presente capitolato;
● coerenti con le specifiche definite nei documenti tecnici forniti da RAS o costituenti deliverable delle attività di analisi e progettazione rientranti nella presente fornitura; salvo diversa ed espressa indicazione di RAS, i deliverable di analisi e progettazione prodotti dal fornitore dovranno essere approvati dalla stazione appaltante preliminarmente all'avvio della fase di sviluppo;
● verificati, sulla base dei relativi piani di test, prima del loro formale rilascio/consegna per le verifiche di conformità (collaudo);
● verificati rispetto alla condizione che ciascun rilascio o eventuali modifiche apportate a funzionalità preesistenti non introducano compromissioni o malfunzionamenti dei sistemi che li accolgono ed in quelli cui sono eventualmente collegati.
Successivamente all'aggiudicazione, l'impresa aggiudicataria dovrà presentare formalmente a RAS, entro i 15 gg solari successivi alla stipula del contratto, un Piano Operativo delle Attività
(di seguito anche POA) che dovrà specificare, coerentemente con quanto previsto dal presente Capitolato:
● Il nominativo, il ruolo e le competenze dei componenti del team di lavoro responsabile dell'esecuzione dei servizi in base a quanto indicato nell art. 7;
● La metodologia e le modalità organizzative che intende applicare, con particolare riferimento:
○ alle procedure che saranno proposte, compatibilmente ed in coerenza con le policy indicate da RAS, per:
■ l'accesso e l'utilizzo degli ambienti di sviluppo;
■ le operazioni di rilascio, installazione, configurazione e test negli ambienti di sviluppo degli interventi realizzati;
○ all'uso di piattaforme web di Issue & Project Tracking (Jira o equivalente);
● Un’analisi dei rischi potenziali e delle relative azioni correttive e/o di mitigazione.
Per quanto attiene la definizione delle modalità proposte per le operazioni di rilascio, installazione, configurazione e test degli sviluppi e degli aggiornamenti software, si precisa che l'aggiudicatario dovrà attenersi alle linee guida definite da RAS.
Il POA dovrà essere formalmente approvato da RAS per accettazione dei suoi contenuti. Alla versione approvata dovranno fare riferimento le relazioni di avanzamento lavori relativamente alle forniture prodotte collaudate e rendicontate.
Il POA dovrà tenere in considerazione la seguente articolazione del progetto in Stati di Avanzamento Lavori (SAL):
- SAL 1: all’approvazione del POA viene corrisposta il 20% dell’importo totale dell’appalto;
- SAL 2: al rilascio Sardegna Turismo migrato da realizzarsi entro 5 mesi dall’inizio dei lavori viene corrisposto il 50% dell’importo totale dell’appalto;
- SAL 3: al rilascio del sistema di integrazione con TDH e della migrazione del portale Osservatorio del Turismo, Artigianato e Commercio da realizzarsi entro la fine dei lavori viene corrisposto la quota finale pari al 30% dell’importo totale dell’appalto.
L’approvazione dei SAL comporta il superamento di un’apposita verifica di conformità (collaudo) e il rilascio del certificato di regolare esecuzione da parte del RUP.
Il periodo di manutenzione correttiva obbligatoria di 12 mesi parte dalla verifica di conformità con esito positivo delle componenti rilasciate e sarà coperta dalla garanzia fideiussoria, che potrà essere svincolata solo al termine del completamento del periodo di manutenzione correttiva obbligatoria.
XXX potrà concordare con l'impresa eventuali aggiornamenti del Piano Operativo delle Attività che dovessero rendersi necessari in corso d'opera per cause non previste o al verificarsi di condizioni tecniche o di contesto che dovessero influire sull'esecuzione delle attività. Le eventuali modifiche o rimodulazioni del piano delle attività dovranno essere formalmente approvate da RAS.
Articolo 6. Livelli di servizio (SLA)
Si riportano di seguito i livelli di servizio attesi dalla stazione appaltante.
SLA di riferimento per la le richieste correttive in garanzia | |||
Indicatore | Definizione | Severità | Valori di soglia |
P_COR | Tempo di evasione richieste correttive a garanzia degli interventi realizzati | Bloccante | Almeno il 95% entro 1g (8h) ed il 100% entro 2 giorni lavorativi. Media rilevata nel bimestre |
Grave | Almeno il 90% entro 2gg ed il 100% entro 4 giorni lavorativi. Media rilevata nel bimestre | ||
Lieve | Almeno il 90% entro 3gg ed il 100% entro 6 giorni lavorativi. Media rilevata nel bimestre | ||
Legenda
Errore bloccante: errore che determina blocco applicativo, o comporta l'interruzione del funzionamento totale o parziale di una specifica funzionalità da cui consegue un blocco del flusso di lavoro.
Errore grave: errore su una funzionalità che può essere aggirato tramite una soluzione temporanea/alternativa.
Errore lieve: errore minore che non impedisce il "normale" funzionamento delle funzionalità su cui è rilevato, in genere riscontrabile con imprecisioni sulle etichette, disallineamenti del layout grafico anche dipendenti dal browser, ecc.
I livelli di servizio saranno misurati rispetto alla finestra di osservazione di seguito definita:
Indicatore | Definizione | Severità | Valori di soglia |
P_COR | Finestra di osservazione dello SLA | - | ore 09.00 - 18.00 da lun a ven |
Ai casi di inadempienza si applicano le disposizioni indicate nell’apposito articolo del disciplinare di gara inerente la Disciplina delle Penali.
Articolo 7. 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. I requisiti richiesti devono essere documentati dal fornitore, mediante attestazioni redatte singolarmente da ciascuno dei soggetti in conformità al modello allegato al presente capitolato e descritto in Appendice.
Un medesimo esperto può essere indicato per ricoprire un solo profilo professionale tra quelli sotto indicati. Devono essere coperti tutti i profili professionali riportati di seguito.
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 una 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 sovrappongano temporalmente.
Si riportano di seguito i profili professionali minimi richiesti:
● Programmatore / Drupal site builder con almeno 5 anni di esperienza professionale documentata in almeno una delle nelle seguenti aree:
○ configurazione e personalizzazione della piattaforma open source Drupal;
○ sviluppo PHP su piattaforma open source Drupal;
● Programmatore front end con almeno 5 anni di esperienza professionale documentata in almeno una delle nelle seguenti aree:
○ sviluppo front-end su tecnologie HTML5 / CSS3 / JavaScript;
○ sviluppo front-end su Drupal;
● Sistemista con almeno 5 anni complessivi di esperienza professionale documentata nella seguente area:
○ realizzazione di sistemi di Continuous Integration (CI) e Continuous Deployment (CD).
● Project manager con almeno 5 anni di esperienza professionale documentata nello specifico ruolo.
Anche nel corso di realizzazione della fornitura, la RAS potrà richiedere la sostituzione di uno o più prestatori d'opera del fornitore, con adeguata motivazione, qualora se ne rilevi la non adeguatezza.
Articolo 9. Verifica di conformità
La verifica di conformità (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 contraddittorio con il fornitore secondo le modalità che l'Amministrazione riterrà più utili.
Nel caso in cui le operazioni di collaudo evidenziassero errori, difetti o mancanze, a giudizio dell'Amministrazione, l'Impresa assume l'obbligo di eliminarli entro 5 giorni lavorativi. La puntualità nei rilasci correttivi è misurata dallo SLA P_SVI definito dall'articolo 6 del presente Capitolato. La gestione delle inadempienze contrattuali e dei ritardi sono trattati nel Disciplinare di Gara agli articoli “Aggiudicazione dell’appalto e stipula del contratto” e “Disciplina delle penali”.
Il collaudo si intenderà effettuato positivamente dopo che l'Amministrazione avrà riscontrato la rimozione degli errori, difetti o mancanze segnalati ed il completamento della totalità dei servizi richiesti. L'esito positivo del collaudo, con l’emissione della certificazione di verifica di conformità da parte del RUP, comporta l'accettazione della fornitura da parte della stazione appaltante.
Appendice. Elenco allegati.
Allegati relativi al portale Sardegna Turismo:
○ Allegato 1 - XxxxxxxxXxxxxxx.xx - Manuale di backend - generale v1: riporta il manuale utente per il back office della redazione;
○ Allegato 2 - XxxxxxxxXxxxxxx.xx - Manuale di backend - traduzione v3: riporta il manuale utente per il back office dei traduttori;
○ Allegato 3 - XxxxxxxxXxxxxxx.xx - Documento di analisi preliminare migrazione: riporta un’analisi preliminare degli attuali portali e delle attività di migrazione da realizzare per il porting su Drupal 10;
○ Allegato 4 - Linee guida per il testing automatico: riporta i requisiti del sistema CI/CD e sulle tecnologie di testing;
○ Allegato 5 - API xxxxxxxxxxxxxxx.xx: riporta le specifiche delle API esposte verso la app SARDINIA;
○ Allegato 6 - API DMS: riporta le specifiche delle API del DMS esposte verso sardegnaturismo.
Allegati relativi al portale Osservatorio Turismo, Artigianato e Commercio:
○ Allegato 7 - xxxxxxxxxxxx.xxxxxxxxxxxxxxx.xx - Documento di analisi preliminare migrazione: riporta un’analisi preliminare della struttura degli attuali portali e delle attività di migrazione da realizzare.
Allegati relativi all’integrazione con il TDH:
○ Sito documentazione progetto TDH: xxxxx://xxxx.xxxxxx.xx/xxxxxx/xxxxx/xx-xxxxxxx-xxxxxxx-xxx-xxxxxxxxxxxxxxxx-xxxx/xx/xxxxx/xx dex.html
○ Allegato 8 - it.mintur.aem_1.2.6_prod.yaml: file swagger con le specifiche tecniche per l’invocazione delle API TDH.
Competenze, esperienze e qualificazione del team di progetto:
○ Allegato 9 - Autocertificazione Gruppo di lavoro: il documento che sarà utilizzato per certificare le competenze professionali di ciascuno dei componenti del team tecnico proposto dal fornitore.
XXXXXXX XXXXXXXXXX XXXXX
2023.11.13 17:32:03
CN=XXXXXXX XXXXXXXXXX XXXXX C=IT
2.5.4.4=OROFINO
2.5.4.42=XXXXXXXXXX XXXXX
RSA/2048 bits