CAPITOLATO TECNICO
ASSESSORADU DE SU TURISMU, ARTESANIA E CUMMÈRTZIU ASSESSORATO DEL TURISMO, ARTIGIANATO E COMMERCIO
Manutenzione evolutiva e servizi professionali a corredo dell’ecosistema
tecnologico costituito dalla piattaforma Sardegna Turismo e Osservatorio del Turismo, Artigianato e Commercio
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 S80002870923202200048 CUP E27H24000730002
CIG B2A9E462EB
Servizio Osservatorio, ricerca e sviluppo – Direzione Generale del Turismo, Artigiano e Commercio – Regione autonoma della Sardegna
Sommario
Articolo 2. Oggetto dell'appalto 4
Articolo 3. Durata dei servizi 4
Articolo 4. Descrizione del contesto 5
Articolo 5. Descrizione dei servizi richiesti 15
5.1. Servizi di sviluppo evolutivo e di analisi dati 17
5.2 Quantificazione, rendicontazione ed effort minimo delle attività di sviluppo evolutivo 21
5.3. Quadro di riferimento degli sviluppi evolutivi 25
Articolo 6. Modalità operative di realizzazione della fornitura 28
Articolo 7. Tempi attesi di esecuzione 30
Articolo 8. Livelli di servizio (SLA) 32
Articolo 9. Competenze, esperienze e qualificazione del team di progetto 34
Articolo 10. Documentazione 37
Articolo 11. Verifica di conformità 37
Acronimi e sigle
Acronimo/sigla | Significato |
RAS | Regione Autonoma della Sardegna |
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à |
IUN | Identificativo Unico Numerico |
BDSR | Banca Dati delle Strutture Ricettive |
CIN | Codice Identificativo Nazionale |
Articolo 1. Premessa
Il presente Capitolato ha lo scopo di descrivere i servizi personalizzati di sviluppo evolutivo dell’ecosistema tecnologico costituito dalla piattaforma SardegnaTurismo e dall’Osservatorio del Turismo, Artigianato e Commercio 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 all’indirizzo xxxxx://xxx.xxxxxxx.xxxxxxxx.xx/xxxx-xxxxx-xxxxxxx/xxxx-xxxxxxxxxxxxxx/xxxxx .
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 della manutenzione evolutiva e dei servizi professionali a corredo dell’ecosistema tecnologico costituito dalla piattaforma Sardegna Turismo e Osservatorio del Turismo, Artigianato e Commercio, descritta nell'articolo 4 del presente Capitolato.
I servizi sono acquisiti nell'ambito della programmazione degli acquisti di forniture e servizi pianificata
dal Servizio Osservatorio Ricerca e Sviluppo dell’Assessorato del Turismo, Artigianato e Commercio.
Mediante la presente gara d’appalto l'Amministrazione intende far evolvere ulteriormente i propri sistemi informativi, in particolare per quanto concerne l'obiettivo strategico di potenziamento dei servizi erogati dall'Osservatorio del Turismo, Artigianato e Commercio. L’appalto si suddivide in una parte dedicata allo sviluppo software per poter garantire la continua evoluzione e la manutenzione straordinaria delle piattaforme informatiche in uso all’Assessorato del Turismo, ed una parte di approvvigionamento di servizi a corredo che richiedono il coinvolgimento di nuove figure professionali, in grado di supportare il pieno sviluppo dell’analisi dei dati per lo studio del fenomeno turistico, di pertinenza all’Osservatorio mediante le più moderne tecniche di data engineering e data science. In quest’ambito saranno ulteriormente sviluppate le infrastrutture tecnologiche di acquisizione, raccolta ed elaborazione dei dati provenienti da fonti interne ed esterne all’amministrazione. Saranno inoltre applicate innovative tecniche di machine learning e dell’intelligenza artificiale per supportare la governance dal turismo basata sui dati (data driven governance).
Articolo 3. Durata dei servizi
La durata dei servizi è stimata in 15 mesi con opzione di proroga di eventuali ulteriori 12 mesi come previsto dall'art.120 comma 1 lett. a) del D.Lgs. 36/2023 .
Tuttavia, poiché le attività saranno rendicontate a consumo, come meglio specificato negli articoli successivi, il periodo effettivo di erogazione dei servizi sarà funzionale alle esigenze evidenziate da RAS nel corso dell’operatività del contratto, e potrà essere rimodulato rispetto alla previsione iniziale.
La durata del servizio decorre dalla comunicazione di esecutività del contratto stipulato tra le parti, tramite piattaforma MEPA. L’esecutività del contratto è subordinata alla registrazione del relativo impegno contabile da parte del competente Servizio della Direzione Generale Servizi Finanziari.
Articolo 4. Descrizione del contesto
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.
Successivamente, nell’ambito del POR FESR Sardegna 2014-2020, ed in particolare dell’Asse II Agenda Digitale – Azione 2.2.2, sono stati realizzazione degli interventi di evoluzione della piattaforma, come previsto dagli atti di programmazione della Giunta regionale (Deliberazione n. 49/3 del 6 ottobre 2015).
L'Amministrazione ha necessità di far ulteriormente evolvere e potenziare la piattaforma dei propri sistemi informativi, in particolare per quanto concerne l'obiettivo strategico di potenziamento dell'Osservatorio del Turismo, Artigianato e Commercio. In tale ambito sono ritenute necessarie nuove figure professionali che possano supportare in modo più efficace il pieno sviluppo dell’analisi dei dati in capo all’Osservatorio mediante le più moderne tecniche di data engineering e data science. In quest’ambito saranno ulteriormente sviluppate le infrastrutture tecnologiche di acquisizione, raccolta ed elaborazione dei dati provenienti da fonti interne ed esterne all’amministrazione. Saranno inoltre applicate innovative tecniche di machine learning ed Intelligenza Artificiale per supportare la governance dal turismo basata sui dati (data driven governance).
I sistemi che costituiscono l'Osservatorio del Turismo, Artigianato e Commercio fanno riferimento dal punto di vista tecnologico ad una comune infrastruttura di erogazione. In generale, la realizzazione dei siti web è basata sul framework open source Drupal e sul framework AngularJS. Mentre le componenti di elaborazione dati sono basate su tecnologie cloud AWS di tipo serverless.
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.
Le applicazioni della piattaforma SardegnaTurismo e dell'Osservatorio del turismo costituiscono un "ecosistema" informativo complesso, che è ospitato su infrastrutture Cloud AWS.
Le componenti di tale ecosistema sono rappresentate di seguito:
● Access Manager: si tratta di un servizio di autenticazione regionale, fornito dalla società in house SardegnaIT, che implementa diversi meccanismi di autenticazione basati su CNS (Carta Nazionale dei Servizi), CIE (Carta Identità Elettronica) o agganciati a sistemi terzi come SPID/EIDAS. Molti dei sistemi della piattaforma SardegnaTurismo e dell'Osservatorio del turismo sono integrati con l'Access Manager allo scopo di consentire agli utenti l’autenticazione.
● Anagrafe delle Strutture Ricettive (ASR): è il sistema di gestione dell'anagrafe delle strutture ricettive alberghiere ed extra-alberghiere della Sardegna. L'architettura dell'ASR è composta dalle seguenti componenti principali: un frontend web (Angular), un backend server (NodeJS), un database (MongoDB), degli indici su un motore di ricerca (ElasticSearch), 2 code (AWS SQS), delle funzioni serverless (AWS Lambda Function). L'ASR si interfaccia con Area Operatori (AO), Destination Management System (DMS) e il sistema di autenticazione regionale Access Manager.
Il front-end dell'ASR è stato realizzato mediante una web app in Angular 6, alla quale si accede tramite autenticazione SpID, CNS o IdM, grazie all'Access Manager. Le autorizzazioni necessarie per l'accesso al sistema sono gestite su AO.
I form presenti nella web app, sono stati definiti con delle strutture JSON, per gestire eventuali future modifiche in maniera flessibile.
Le Lambda Function AWS espongono dei servizi attraverso i quali avviene la comunicazione con il backend server. Tramite esse è possibile effettuare operazioni di lettura, ricerca e scrittura delle strutture ricettive sul database MongoDB. L'eliminazione è stata implementata tramite una "soft delete", che conserva i record e registra lo stato di cancellazione.
Contestualmente alla scrittura dei dati, le transazioni vengono registrate in code AWS SQS, che vengono consumate in seguito alla propagazione delle modifiche sui sistemi AO e DMS.
È presente un'ulteriore coda AWS SQS che consente la gestione degli inserimenti e aggiornamenti delle strutture ricettive provenienti da eventuali sistemi esterni.
● Registro delle Locazioni Occasionali (RLO): è il sistema di gestione dell'anagrafe degli alloggi privati, utilizzati per le locazioni brevi con fini turistici. Essa è stata realizzata per creare un ambiente separato dall'Anagrafe delle Strutture Ricettive, nella quale inizialmente confluivano anche questo tipo di strutture. Il Registro delle Locazioni Occasionali, inoltre, a differenza dell'ASR, è stato pensato per dare la possibilità ai cittadini, o ai loro delegati, di occuparsi in prima persona della registrazione e consultazione dei propri immobili, con la logica dell'autocertificazione.
Le tecnologie alla base di RLO sono le medesime utilizzate per la realizzazione dell'ASR, per cui è composto: da un front-end rappresentato da una web app Angular che espone dei webform definiti tramite delle strutture JSON, un backend server sviluppato in NodeJS, un database MongoDB e gli indici su un motore di ricerca Elasticsearch. Il servizio Monstache consente di tenere sincronizzate le informazioni presenti sul database MongoDB e quelle presenti negli indici Elasticsearch.
● Registro IUN ( xxxxx://xxx.xxx-xxx.xx ): il registro IUN è il sito web che consente la consultazione degli IUN delle strutture ricettive extra-alberghiere e degli alloggi privati registrati nelle anagrafi.
Lo IUN è il codice Identificativo Unico Numerico assegnato alle strutture ricettive e agli alloggi privati utilizzati per le locazioni occasionali a fini turistici, che deve essere esposto in ogni strumento di comunicazione e di commercializzazione. Il registro IUN espone sul web i dati presenti nei 2 sistemi appena descritti:
○ Anagrafe delle Strutture Ricettive (ASR);
○ Registro delle Locazioni Occasionali (RLO).
Il sistema è composto da un'applicazione Angular che gestisce il rendering della pagina "client- side", invocando una funzione AWS Lambda. Invece di eseguire delle interrogazioni sui database MongoDB dei 2 sistemi, viene utilizzato un indice Elasticsearch, che integra i dati presenti negli indici Elasticsearch dei singoli sistemi, per aumentare le performance.
● Area Operatori (AO), xxxx://xxxxxxxxx.xxxxxxxxxxxxxxx.xx : Area Operatori è un'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 è ospitato su Cloud AWS. Il 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. Area Operatori è connessa al sistema Access Manager. 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/).
● 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 (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 macro componenti:
○ 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 7 in fase di migrazione su Drupal 10 nell’ambito di un progetto in fase di
esecuzione.
● 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 nei sistemi DMS e Area Operatori. Sulla base di tali informazioni Area Operatori, attraverso un processo di accreditamento, consente l'identificazione degli utenti responsabili delle strutture ricettive autorizzandoli ad effettuare delle operazioni sui sistemi. Parallelamente il DMS, attraverso i dati provenienti dall'Anagrafe delle Strutture Ricettive e da Area Operatori, consente ai responsabili di integrare i dati delle proprie strutture con quelli di natura più commerciale. A sua volta i dati amministrativi e commerciali delle strutture ricettive provenienti dal DMS vengono pubblicati sul portale xxx.xxxxxxxxxxxxxxx.xx per essere presentati al turista. La filiera è realizzata mediante i seguenti macrocomponenti:
○ da Anagrafe ad AO e DMS la propagazione avviene mediante un sistema asincrono basato su eventi generati dall'Anagrafe delle Strutture Ricettive;
○ l'accesso degli utenti al DMS è subordinato ai permessi che essi hanno su AO, che conserva la correlazione tra utenti, ruoli e strutture ricettive;
○ la propagazione dei dati da DMS a Sardegna Turismo avviene mediante un processo batch.
● Sired (Ross1000), xxxxx://xxxxxxxxxxxxxxx.xxxx0000.xx/xxxxx: il Sired è un sistema informativo di raccolta ed elaborazione dei dati sul movimento turistico e sulla capacità ricettiva fornito dalla RAS alle strutture ricettive per adempiere con maggiore semplicità ed efficienza all'obbligo statistico verso l'Istat. Il SIRED infatti innova le modalità di raccolta ed elaborazione dei dati relativi alle indagini Istat sul movimento turistico e sulla capacità delle strutture ricettive, ed al tempo stesso raccoglie informazioni ulteriori sulla profilazione del turista. Al Sired si collegano tramite web service applicazioni web di analisi e interrogazione del dato, che sono messe a disposizione del pubblico e degli operatori. Il sistema in produzione è ospitato su piattaforma SaaS su cloud Aruba.
Il Sired è un sistema proprietario, per cui non è oggetto di attività di evoluzione da parte del fornitore. Quest'ultimo dovrà conoscere e utilizzare le API che tale sistema espone al fine di sviluppare nuove modalità di integrazione applicativa con gli altri sistemi della piattaforma Sardegna Turismo e dell'Osservatorio del turismo.
● Sito dell'Osservatorio del turismo: 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. L'architettura del sistema è costituita da diverse componenti distinte:
○ Sito internet Drupal 8 e DB Mysql (in fase di migrazione a Drupal 10 con affidamento in fase di esecuzione);
○ Applicazioni dashboard interattive basate su applicazioni Shiny (xxxxx://xxxxxx.xxx/xxxxxxx/xxxxx);
○ Infrastruttura di autenticazione basata su servizi AWS. Il flusso logico che realizza l'autenticazione è il seguente:
■ l'utente, per accedere al servizio desiderato viene rediretto su apposita URL, esposta tramite servizio API Gateway di AWS;
■ l'architettura serverless a valle di API Gateway effettua le necessarie chiamate per autenticare e autorizzare l'utente mediante un proxy implementato in Node.js 6.10 tramite una Lambda Function AWS;
■ verificati i permessi, le richieste dell'utente autorizzato vengono girate al servizio richiesto mediante la gestione di callback implementa in Node.js 6.10 tramite una Lambda Function AWS.
○ Sistema di ETL (Extraction Transformation and Load), che approvvigiona di dati le dashboard interattive Shiny a partire dai dati sugli arrivi e sulle presenze degli ospiti nelle strutture ricettive esposti del sistema Sired, accessibili tramite i meccanismi di autenticazione OAuth e basic authentication. Il sistema è basato su un'architettura serverless realizzata mediante i servizi AWS:
■ CloudWatch, tramite il quale si genera quotidianamente un evento che viene gestito dalla prima Lambda Function della catena per il download dei dati dai servizi Sired;
■ Lambda Function, implementate in Python 3.x, tramite le quali vengono scaricati i dati su un data lake ospitato su S3 AWS. Gli eventi generati dalla presenza di nuovi file JSON nelle folder S3 permettono l'invocazione a cascata di una serie di Lambda Function, che hanno il compito di normalizzare e ripulire il dato per essere correttamente interrogato tramite il servizio Athena AWS;
■ Xxxxxx è il servizio che permette di interrogare con un linguaggio SQL i dati memorizzati su folder S3. I risultati prodotti dalle interrogazioni Athena vengono memorizzati in file csv su folder S3 e resi accessibili al server Shiny, ospitato su una macchina EC2 AWS.
○ Tutti i componenti del sistema dashboard sono basati su servizi serverless AWS o installati su container Docker e ospitati su istanze EC2 AWS, come rappresentato nel seguente diagramma:
● Hyperlocal Infopoint Sardegna (HIS): HIS è un 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. dal portale Sardegna Turismo) 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 con tecnologia AngularJS.
○ HIS-API: la componente HIS-API, sviluppata con 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 Customer Relationship Management 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.
● Anagrafi professioni turistiche: sono gli applicativi Java per la gestione informatizzata delle procedure relative agli albi di Agenzie di Viaggio, Guide Turistiche, Guide Ambientali Escursionistiche, Guide Turistico Sportive.
● Vetrina dell'artigianato artistico: la vetrina dell'artigianato artistico si tratta di un sito Drupal 7 (xxxx://xxx.xxxxxxxxxxxxxxxxxxx.xxx/) che acquisisce i propri dati dall'Archivio dei Saperi Artigiani del Mediterraneo (vedi sotto) mediante API REST. Il sito è ospitato su Cloud AWS e 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/).
● Archivio dei saperi artigiani del Mediterraneo: si tratta di un sito Drupal 6 (xxxx://xxx.xxxxxxxxxxxxxxxxxxxxxxxxxx.xx/xx/xxxx) che ospita schede dettagliate degli artigiani della Sardegna e costituisce la base di conoscenza da cui attinge la Vetrina dell'Artigianato Artistico. Il sito è ospitato su Cloud AWS e ha una infrastruttura costituita dai seguenti macrocomponenti:
○ Varnish cache (sistema di caching lato frontend xxx.xxxxxxx-xxxxxxxx.xxx);
○ Database (MySQL);
○ CMS Drupal (Content Management System xxxxx://xxx.xxxxxx.xxx/).
● Sardegna Sentieri: si tratta di un portale tematico sui sentieri delle foreste della Sardegna realizzato in Drupal 10, integrato nella piattaforma Sardegna Turismo. Il sito è ospitato sul AWS e 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/).
● Infrastruttura cloud Amazon AWS: tutte le componenti sopra riportate (ad esclusione del Sired nella sua versione attuale e delle anagrafi professioni turistiche) sono ospitate su Cloud AWS. L'infrastruttura è suddivisa su due root account: uno per i sistemi attualmente in manutenzione, e uno per i sistemi in sviluppo. Potranno essere oggetto del presente capitolato attività connesse alle operazioni di migrazione dei sistemi tra i due root account.
● Data lake AWS: tutti i dati di interesse per le analisi sul turismo isolano sono raccolte in un data lake implementato su sistemi AWS con tecnologie serverless (S3, Glue, Athena, Quicksight). Il bacino informativo è a disposizione di Data Scientist e esperti di statistica per la produzione di modelli di machine learning, report e dashboard di Business Intelligence a favore degli stakeholder pubblici e privati. Le analisi sono realizzate mediante notebook e script basati su Python che fanno leva su servizi gestiti come Amazon SageMaker, mediante macchine virtuali ad hoc o sulle stazioni di lavoro del team di analisi mediante accesso sicuro ai dati.
L’architettura di alto livello del data lake è rappresentata nel seguente diagramma.
Articolo 5. 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 servizi di sviluppo evolutivo necessari al potenziamento dei sistemi facenti parte dell'Osservatorio del Turismo, Artigianato e Commercio. Sono inoltre necessari al completo raggiungimento degli obiettivi e delle funzioni della piattaforma sopra indicata ulteriori servizi legati all’analisi dati, nonché al design di prodotti e servizi per il cittadino e gli uffici amministrativi. Le forniture di sviluppo software ed i servizi professionali sopra descritti, sono acquisiti nell'ambito della programmazione degli acquisti di forniture e servizi pianificata dal Servizio Osservatorio Ricerca e Sviluppo dell’Assessorato del Turismo, Artigianato e Commercio.
Tutti gli sviluppi e le analisi dati dovranno avvenire, oltre che su ambienti locali del fornitore, su servizi Cloud identificati e forniti da RAS (Amazon AWS, Acquia Drupal o simili, etc.).
Conseguentemente, sono richiesti al fornitore aggiudicatario elevati livelli di professionalità, competenza ed esperienza sia nelle tecnologie indicate nel contesto illustrato nell'articolo 4 del presente capitolato che nello sviluppo di applicazioni cloud native (sia AWS che su cloud ibrido multi tenant) anche attraverso l'uso di altri servizi PAAS dedicati, quali Acquia Drupal e GitHub.
In particolare sono richiesti elevati livelli di conoscenza delle seguenti tecnologie in ambiente cloud:
● PHP / Drupal;
● HTML5 / CSS3 / JavaScript;
● Angular o React;
● Node.js;
● MongoDB;
● Elasticsearch;
● Servizi AWS;
● Container e sistemi di orchestrazione (ad esempio Docker + Kubernetes)
● Python ed ecosistema librerie e tool per l’analisi dati (ad esempio Pandas, Scikit-learn, PyTorch).
Sono inoltre richieste competenze di analisi dati e di data visualization ed in particolare:
● data cleaning
● data wrangling
● data quality analysis
● data science (statistical data analysis, statistical learning, machine learning)
● business data analysis
● business intelligence (realizzazione report e dashboard interattive)
Sono infine richieste competenze di product design e UX design per supportare RAS nella progettazione e test dei prodotti destinati ai diversi stakeholder. In particolare il fornitore dovrà fornire competenze relativamente a:
● Product design
● Service design
● UX design
L'evoluzione della piattaforma potrà prevedere, su indicazione di RAS, anche mediante l'introduzione di tecnologie complementari ai framework open source citati nell'articolo 4, finalizzate a:
● la system integration;
● l'applicazione diffusa dell'approccio mobile first;
● la realizzazione di applicazioni web Single Page Application reattive;
● la garanzia di sviluppo di servizi affidabili e sicuri, che prevedano l'applicazione diffusa dell'approccio privacy by design e by default previsto dal GDPR;
● l'aderenza alle linee guida sull’accessibilità degli strumenti informatici dell'AgID;
● la semplicità d'uso per l'utente su tutti i dispositivi, mediante lo sviluppo di interfacce usabili e l'osservazione dell'interazione degli utenti con i servizi;
● il monitoraggio dei servizi nell'ottica del miglioramento dell'esperienza d'uso;
● l'uniformità visiva dei sistemi
● lo sviluppo di pipeline di analisi dati
● lo sviluppo di modelli di statistical learning e machine learning
● sistemi di dashboarding.
Si forniscono di seguito i principali requisiti per i servizi richiesti.
5.1. Servizi di sviluppo evolutivo e di analisi dati
I servizi riguardano sia la realizzazione di nuove componenti che l'evoluzione tecnologica e/o funzionale delle componenti esistenti, come indicate nel contesto illustrato, attraverso la realizzazione di interventi sulle app, sui front-end web, sui back-end e sull'interfacciamento tra le componenti medesime, incluso lo sviluppo e l'estensione di tutte le API necessarie. Sono altresì previsti servizi di design di nuovi prodotti e servizi. Sono infine previsti servizi di analisi dati che coprano la realizzazione di algoritmi, la produzione di report, la realizzazione di dashboard interattive e l’ingegnerizzazione di nuove pipeline di elaborazione dati su data lake AWS.
Nella realizzazione dei servizi, RAS fornirà le risorse software e cloud necessarie, garantendo la disponibilità di tutti gli ambienti (sviluppo, stage e produzione).
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 personalizzazione delle risorse cloud allocate da RAS a suo uso e consumo nell'ambito del progetto, nel rispetto delle linee guida indicate da RAS.
Per quanto attiene le componenti esistenti, RAS metterà a disposizione dell'aggiudicatario la documentazione di analisi e progettazione tecnica associata alle varie componenti della piattaforma nelle loro attuali versioni. A partire da tale stato di fatto, il fornitore dovrà garantire i servizi di analisi, progettazione e sviluppo che soddisfino i requisiti funzionali espressi da RAS.
XXX si riserva la possibilità di effettuare in proprio l'analisi e/o progettazione degli interventi demandando al fornitore le sole attività di sviluppo o la realizzazione delle analisi dati.
Nella realizzazione degli interventi di design, sviluppo e di analisi dati, 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. Dovranno essere inoltre effettuate, a richiesta di RAS, le attività di presentazione/affiancamento remoto agli operatori della committenza o a terzi individuati da RAS per le proprie finalità istituzionali. Tali attività dovranno essere temporalmente contigue rispetto al rilascio degli interventi di sviluppo.
La fornitura si svilupperà su più interventi di sviluppo evolutivo articolati secondo le richieste di XXX, che indicherà:
● l'insieme dei requisiti funzionali o delle esigenze di business e la natura dell'intervento;
● gli ambiti di attività richiesti al fornitore (design, analisi tecnica, progettazione, sviluppo, analisi dati);
● le ulteriori indicazioni eventualmente necessarie.
Le richieste di nuove attività saranno effettuate da RAS attraverso un sistema di task management e bug tracking (JIRA o equivalente) che dovrà essere fornito dall'aggiudicatario o da RAS. In ogni caso il sistema di task manager e bug tracking è compreso nella fornitura senza costi aggiuntivi per RAS.
Il medesimo sistema dovrà essere utilizzato anche per il project management e nello specifico per la gestione delle schede di attività, dei flussi approvativi e documentali, come meglio specificato in seguito.
A fronte di una richiesta di RAS per un intervento di design, sviluppo o analisi dati, il fornitore, anche attraverso un'attività preliminare di analisi e raccolta requisiti, rilascerà una scheda attività (definita SA- xx dove "xx" è il codice univoco della scheda) nella quale dovrà riportare:
1. Storie utente descrittive delle esigenze espresse da RAS;
2. Quotazione di ciascuna delle storie utente in termini di ore uomo o loro frazioni, distintamente per figura professionale;
3. Cronoprogramma di realizzazione, con l'articolazione temporale delle attività e la specifica della data di rilascio;
4. Tabella riepilogativa dei deliverables previsti.
Le scheda di attività dovranno essere prodotte, usando il sistema di task management, entro 5 giorni lavorativi dalla richiesta di RAS, a meno di accordi diversi tra RAS e fornitore per attività particolarmente complesse.
XXX, con piena discrezionalità potrà chiedere al fornitore i ragguagli e/o le analisi e/o le giustificazioni in merito alle quotazioni effettuate. Si precisa che qualora RAS rilevasse l’inadeguatezza delle valutazioni dell'effort effettuate dal fornitore, potrà a proprio insindacabile giudizio non dare avvio alla realizzazione dell'intervento richiesto.
Quando la scheda di attività redatta dal fornitore viene approvata da RAS si determina la formalizzazione dell'ordine di esecuzione ed il fornitore deve procedere alla realizzazione dell'intervento. Si precisa che, nel corso del singolo intervento, RAS ed il fornitore potranno concordare modifiche alla scheda di attività, inerenti sia adeguamenti funzionali che rimodulazioni dell'articolazione temporale dell'intervento e delle quotazioni dell'effort previsto. Le modifiche alla scheda di attività devono essere formalmente approvate da RAS ai fini della loro efficacia.
Per ciascun intervento il fornitore dovrà, salvo diverse indicazioni da parte di RAS, produrre i seguenti deliverable:
a. Analisi dei requisiti, con studio della User eXperience (ove applicabile);
b. Documento di progettazione applicativa e delle interfacce (ove applicabile);
c. Piano dei test;
d. Codice sorgente documentato comprensivo dei test per il sistema di continuous integration (ove applicabile);
e. Documento di configurazione/implementazione di quanto sviluppato (ove applicabile);
f. Report di esecuzione dei test funzionali e di non regressione volti alla verifica del corretto funzionamento nell'ambiente di sviluppo di tutte le nuove funzionalità aggiunte al sistema (ove applicabile);
g. Manualistica.
Tutti gli interventi prestati dovranno garantire la soddisfazione dei seguenti requisiti trasversali:
1. Il supporto di interfacce applicative (API) per esporre flussi dati potenzialmente riutilizzabili dai sistemi interconnessi;
2. L'applicazione diffusa dei metodi di user centered design per migliorare significativamente l'esperienza di interazione dell'utente (User eXperience) in tutti i suoi aspetti anche con l'uso di tecniche di user testing;
3. L'applicazione di metodologie agili per la gestione delle attività di analisi e sviluppo, adottando un approccio iterativo e incrementale in particolare rispetto alle fasi di sviluppo e design;
4. L'applicazione di approcci e tecniche di progettazione basati sui paradigmi mobile first e tecniche di responsive/adaptive design per la realizzazione di interfacce grafiche ottimizzate con i diversi tipi di device (dagli smartphone e tablet ai laptop e desktop) attualmente più diffusi nel mercato;
5. L'applicazione di approcci di privacy by design e privacy by default per il rispetto di quanto previsto dal GDPR e più in particolare delle policy e procedure di applicazione di tale regolamento nell'ambito dell'Osservatorio del Turismo;
6. La diversificazione delle soluzioni in funzione dei livelli di interazione e finalità di utilizzo espressi dall'utente, tenendo conto dei possibili contesti di azione in cui egli è coinvolto e di tutti i ruoli che assume;
7. Il rilascio sotto licenza open di tutto il materiale prodotto nell'ambito del progetto, incluso il codice sorgente, i mockup grafici, i template, i prototipi realizzati nell'ambito della fornitura. Sono incluse eventuali componenti applicative realizzate da terze parti, che devono essere fornite sotto licenza open salvo esplicito accordo scritto con RAS che comunque preveda licenze d'uso senza alcuna limitazione né scadenza né alcun costo aggiuntivo. Il codice e la documentazione e tutti i deliverable prodotti nell'ambito dell'appalto saranno di proprietà RAS.
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.
Resta inteso che, ai fini della collaudabilità, gli interventi di sviluppo evolutivo dovranno garantire non solo il pieno funzionamento delle componenti sviluppate ma anche la loro corretta integrazione rispetto all'intero ecosistema descritto, a fronte dei diversi momenti in cui avverrà il rilascio delle componenti medesime e dei reciproci ambiti di interazione tra queste e l'ecosistema. Nel caso di sviluppo di componenti che interagiscono con altre esterne al suo controllo, è onere del fornitore interfacciarsi con tutti gli altri eventuali soggetti coinvolti, al fine di sincronizzare in modo pianificato tutte le attività e garantire il corretto funzionamento di tutti i sistemi in seguito a ciascun rilascio.
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 dalla verifica di conformità 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. Sono compresi in questa tipologia anche tutti i malfunzionamenti indirettamente causati da interventi del fornitore, ed in generale tutti i malfunzionamenti che si sono manifestati immediatamente dopo una qualunque attività del fornitore e non si verificano prima. Supponendo che dopo il rilascio di una funzionalità da parte del fornitore si crei un malfunzionamento su un’altra funzionalità, componente o sistema non direttamente interessata dall’intervento, esso è da considerarsi comunque una regressione e rientra nella correzione in garanzia senza ulteriori oneri per RAS. Il fornitore potrà comunque dimostrare che il malfunzionamento era presente anche prima del rilascio, o che esso è dovuto a cause a lui non imputabili, come ad esempio l’aggiornamento di librerie esterne utilizzate dal sistema; in tali casi potrà richiedere a RAS di considerare le attività risolutive del problema come rientranti tra quelle necessarie ma non stimate inizialmente; La valutazione finale sarà fatta a insindacabile giudizio di XXX, solo dopo sua esplicita approvazione le attività potranno essere rendicontate.
Le richieste di correzione verranno segnalate dalla stazione appaltante all'impresa, attraverso il sistema task management e bug tracking già descritto nel presente articolo. 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. 8 e secondo le tipologie di errore da questo definite.
5.2 Quantificazione, rendicontazione ed effort minimo delle attività di sviluppo evolutivo
Nella quantificazione economica si utilizzerà come riferimento la figura professionale di Programmatore junior: il costo unitario di quest'ultima, pari a quello applicato dalla società in house Sardegna IT, dell'importo di € 265,00/giorno, costituisce parametro di riferimento per la quantificazione economica degli interventi di analisi, progettazione e sviluppo. Su tale valore sarà applicato il ribasso d'asta offerto dal concorrente.
Dovranno essere rapportate alla figura professionale di Programmatore junior le ulteriori figure professionali da impiegarsi, secondo i coefficienti moltiplicativi riportati nella seguente tabella, calcolati anch'essi rispetto alle tariffe applicate da SardegnaIT.
Figura professionale | Coefficiente moltiplicativo rispetto alla figura professionale di riferimento (Programmatore junior) |
Programmatore junior / Drupal site builder / Data Engineer Junior | 1,00 |
Programmatore senior / Data Engineer Senior | 1,63 |
Data Scientist Junior / Data Analyst Junior | 1,00 |
Data Scientist Senior / Data Analyst Senior | 1,63 |
UX Designer Senior / Service Designer Senior / Product Designer Senior | 1,63 |
Analista Senior / Web Architect Senior / Cloud Architect Senior | 1,63 |
Operatore Junior/ Software Tester Junior | 1,00 |
Sistemista Senior | 1,44 |
Grafico Senior | 1,09 |
Project manager Senior | 1,98 |
Si noti che per alcune figure non sono presenti i livelli di esperienza Junior perché è richiesto
un’esperienza elevata o il livello Senior perché si ritiene sia sempre sufficiente un’esperienza di base.
Pertanto, nella rendicontazione degli interventi, gli effort delle diverse figure professionali coinvolte dovranno essere espressi in giorni di Programmatore junior applicando i rispettivi coefficienti moltiplicativi. A titolo di esempio, una storia utente realizzata con l'effort di:
8 h/uomo di Programmatore junior; 3 h/uomo di Analista Senior;
2 h/uomo di Grafico Senior;
1 h/uomo di Operatore Junior;
è rendicontabile con un effort complessivo di [8 + (3 x 1,63) + (2 x 1,09) + (1 x 1,00)], ovvero di 16,07 h/uomo di Programmatore junior.
In riferimento alla tabella precedente si specifica che, ai fini della rendicontazione, tutti i profili non direttamente mappabili sui profili sopra elencati dovranno essere ricondotti al profilo di operatore, qualora non siano oggetto di specifica espressa diversa disposizione da parte di RAS. Si precisa inoltre che, per ciascun intervento, le attività di project management non potranno essere rendicontate in misura superiore all'8% in valore.
Inoltre, per alcune figure professionali dovrà essere garantito un effort minimo mensile, numero minimo di giorni/uomo che il fornitore si impegna ad erogare su richiesta di RAS. La seguente tabella riassume le figure professionali previste per le quali è richiesto l'effort minimo; si evidenzia che per ciascuna di esse devono essere soddisfatti i requisiti professionali minimi definiti dal successivo art.9.
La giornata si intende di 8 ore di lavoro.
Figura professionale | Effort minimo (giorni uomo/mese) |
Programmatore junior / Drupal site builder | 20 |
Programmatore senior / Data Engineer | 20 |
Analista Sr/ Web Architect Sr/ Cloud Architect Sr/ UX Designer Sr | 20 |
Ux Designer Sr/ Product Designer Sr/ Service Designer Sr | 10 |
Data Scientist Sr/ Data Analyst Sr | 5 |
Data Scientist Jr/ Data Analyst Jr | 10 |
Operatore Jr/ Software tester Jr | 10 |
Project manager Sr | 5 |
Si descrive di seguito il flusso operativo previsto per la realizzazione delle attività:
1. RAS - apertura di appositi task sulla piattaforma JIRA. Tale attività potrà essere fatta anche dall’aggiudicatario qualora egli stesso ne rilevi la necessità. Tutte le interlocuzioni tra RAS e l’aggiudicatario avverranno attraverso tali task.
2. Aggiudicatario - presa in carico della richiesta.
3. Aggiudicatario - stima effort analisi preliminare
4. RAS - approvazione effort stimato per analisi preliminare
5. Aggiudicatario - analisi preliminare della richiesta. Il risultato atteso è dato dalla stima
dell’effort necessario per l’analisi di dettaglio della richiesta.
6. RAS - approvazione effort stimato per analisi di dettaglio
7. Aggiudicatario - analisi di dettaglio della richiesta, il risultato atteso alla fine di questa fase consiste nel caricamento della scheda attività, cosi come sopra descritta, nella piattaforma di tracking, con l’identificazione di tutte le attività, le figure professionali e il relativo effort necessari al soddisfacimento della richiesta. Il fornitore dovrà indicare un piano preliminare di test di accettazione da eseguire in chiusura dell’attività. L’approvazione dell’effort delle attività di analisi non sarà necessaria qualora esse dovessero richiedere meno di 2h. In casi di particolare complessità il fornitore potrà concordare
successivamente con RAS ulteriori attività di analisi qualora in corso d’opera si riveli
necessari ulteriori approfondimenti.
8. RAS - approvazione scheda di attività e relativo effort previsto
9. Aggiudicatario – esecuzione attività. Il fornitore provvederà al caricamento su JIRA dei task derivanti dalla scomposizione (break-down) delle schede di attività approvate. Su tale piattaforma il personale del fornitore dovrà tenere traccia delle attività svolte e del tempo speso in ogni sub-task. Eventuali semplificazioni potranno essere concordate con RAS anche sulla base della complessità dei singoli interventi.
10. Aggiudicatario – deploy in ambiente di stage ed esecuzione dei test di accettazione. Nel caso in cui l’attività consista nello sviluppo di software, l’aggiudicatario provvederà per step ai deploy nell’ambiente di stage. In tale ambiente l’aggiudicatario esegue i test di accettazione e produce un report di verifica finale che sarà condiviso con RAS.
11. RAS - valida il report di verifica finale o richiede di integrare i test di accettazione per coprire casi non previsti inizialmente ma necessari a verificare i risultati raggiunti.
12. Aggiudicatario – Nel caso in cui l’attività consista nello sviluppo di software, l’aggiudicatario procederà per step al deploy nell’ambiente di produzione, solo a seguito di autorizzazione da parte di RAS, a meno di casi di estrema urgenza.
13. RAS – chiusura della scheda di attività. Al termine del deploy in produzione, RAS provvederà a verificare la correttezza di quanto realizzato e a chiudere la scheda di attività. La chiusura della scheda di attività corrisponderà alla verifica da parte di RAS del suo corretto funzionamento, e quindi alla sua accettazione dell’attività realizzata dal fornitore, per cui a partire da quel momento esso potrà essere rendicontato. Inoltre, nel caso di attività di sviluppo software, tale evento rappresenta formale verifica di conformità a partire dal quale ha inizio il periodo di garanzia di 12 mesi da parte del fornitore. RAS potrà chiedere a sua discrezione di effettuare l’esecuzione dei test di accettazione in contraddittorio con il fornitore prima di approvare la scheda di attività.
Su indicazioni di RAS, anche sulla base di eventuali proposte del fornitore, tale flusso potrà essere modificato e affinato, sia in fase iniziale di progetto che in corso d’opera, anche limitatamente a lavorazioni particolari e sulla base della loro complessità.
Ciascuna scheda di attività approvata da RAS e i task derivanti dalla sua scomposizione (break- down), dovranno essere caricati su una piattaforma web di task management e bug tracking di cui all’articolo 5. Su tale piattaforma il personale del fornitore dovrà tenere traccia delle attività svolte e del tempo speso in ogni sub task. Le attività andranno tracciate giornalmente e rispecchiare le reali attività eseguite nella singola giornata di lavoro. Ritardi nel tracciamento delle ore di più di 2 giorni lavorativi dovranno essere segnalati a RAS ed approvati caso per caso.
Ai fini della rendicontazione e del successivo pagamento, sarà computato il tempo complessivo effettivamente impiegato dal personale del fornitore nel completamento dei task del singolo intervento, come tracciato sulla piattaforma, purché non superiore all'effort complessivo indicato nella scheda di attività approvata da RAS. L'unità minima per la rendicontazione è il minuto.
Si precisa che, laddove RAS dovesse decidere, a proprio insindacabile giudizio, di utilizzare le risorse per i servizi opzionali aggiuntivi, la rendicontazione delle ulteriori attività che troverebbero copertura avverrà utilizzando le medesime modalità sopra descritte. Pertanto, costituirà parametro il costo di riferimento della figura professionale di Programmatore junior, decurtato del ribasso d'asta offerto dall'aggiudicatario e, per le ulteriori figure professionali coinvolte, moltiplicato per i coefficienti moltiplicativi sopra indicati.
5.3. Quadro di riferimento degli sviluppi evolutivi
Come precedentemente precisato, gli interventi riguarderanno l'ecosistema dei sistemi dell'Osservatorio del Turismo sia attraverso la realizzazione di nuove componenti che mediante l'evoluzione tecnologica e/o funzionale delle componenti esistenti.
In termini strategici, l'evoluzione tecnologica dei sistemi esistenti e lo sviluppo di nuovi sistemi sarà incardinata sulle seguenti linee:
● sviluppo di backend applicativi basati su microservizi, basati su API REST che consentano un accoppiamento lasco con i front-end e l'integrazione con sistemi interni ed esterni all'ecosistema;
● sviluppo applicativo Cloud native che sfrutti appieno i servizi AWS serverless e l'utilizzo dei container;
● sviluppo basato sui principi di privacy by design e privacy by default per il pieno rispetto del GDPR;
● sviluppo di front-end reattivi basati su approcci single page applications (HTML5 / CSS / JavaScript) e connessi via API ai backend;
● sviluppo di front-end mobile ibridi e/o nativi in grado di interagire tramite API con i backend;
● sviluppo di siti web e portali su piattaforma Drupal con approcci headless (API su backend e front-end HTML5 / CSS / JavaScript).
Per quanto attiene gli interventi evolutivi sulle componenti esistenti, l'elenco che segue ha lo scopo di dare un quadro di riferimento, pur non essendo l'elenco medesimo da considerarsi esaustivo o limitativo o vincolante per RAS in fase di esecuzione del progetto.
Anagrafe delle Strutture Ricettive
L'Anagrafe delle Strutture Ricettive sarà oggetto di ulteriori attività evolutive a seguito della realizzazione del nuovo sistema SUAPE.
All'interno di questo scenario organizzativo emergono alcuni interventi evolutivi:
1. creazione di un flusso per l'acquisizione delle pratiche dal nuovo SUAPE (utilizzo nuovi web service, allineamento nuove strutture dati, nuove funzioni di integrazione applicativa, miglioramento sistemi di riconciliazione e workflow di lavoro semiautomatico). Le specifiche di interoperabilità degli enti con il SUAPE sono disponibili all'indirizzo https://www.sardegnaimpresa.eu/it/sportello- unico/supporto/assistenza-il-suape-ed-enti-terzi;
2. creazione di un sistema che garantisca l'allineamento tra l'Anagrafe delle Strutture Ricettive e l'anagrafe SIRED e che gestisca il flusso di inserimento attraverso procedure automatiche;
3. creazione di un flusso per l'acquisizione degli agriturismi dell'Agenzia LAORE.
Registro delle Locazioni Occasionali
Il Registro delle Locazioni Occasioni è un nuovo sistema, sviluppato in affiancamento dell'Anagrafe delle Strutture Ricettive per la gestione dell'anagrafica degli alloggi privati utilizzati per affitti brevi a fini turistici. Il Registro è composto da una sezione di back-office accessibile al personale RAS e da una sezione dedicata al cittadino, che può fare in autonomia la registrazione dei propri immobili.
In questo contesto si individuano alcuni sviluppi:
1. creazione di un sistema che garantisca l'allineamento tra il Registro delle Locazioni Occasionali e l'anagrafe SIRED e che gestisca il flusso di inserimento attraverso procedure automatiche;
2. definizione di nuove funzionalità di gestione degli immobili;
3. definizione di nuove funzionalità di reportistica
4. Gestione Dichiarazioni da Cittadini e Operatori - Supporto completo per la gestione delle dichiarazioni relative all'apertura, alla modifica e alla cessazione di immobili per fini turistici da parte del cittadino, incluse funzionalità per il rigetto e l'annullamento di pratiche, nonché miglioramenti nella visualizzazione e nell'ordinamento delle dichiarazioni.
5. Miglioramento Funzionalità di Back-office - Estensione delle funzionalità di back-office per includere criteri di ricerca avanzati per immobili e dichiarazioni, e gestione avanzata dello stato delle dichiarazioni "in lavorazione".
6. Gestione Protocolli e Integrazioni - Introduzione o miglioramento della gestione dell'assegnazione di protocolli e l'integrazione con il sistema ROSS1000 per una sincronizzazione efficace dei dati relativi ai posti letto e alla gestione di multipli delegati, nonché l'integrazione di criteri di accredito.
7. Usabilità e Accessibilità per il Cittadino - Miglioramenti specifici per l'usabilità dell'applicazione da parte del cittadino, inclusa la validazione degli indirizzi e aggiornamenti relativi alla visualizzazione delle email e alla stampa delle dichiarazioni, oltre all'obbligatorietà di indicare il periodo di apertura negli annunci.
8. Miglioramenti Amministrativi e Operativi - Sviluppo di funzionalità per la gestione dei delegati per l'apertura di immobili e la realizzazione di miglioramenti operativi come la gestione dei task in attesa di protocollazione e la schedulazione delle attività.
Registro IUN
Il Registro IUN della Regione Sardegna (https://www.iun-ras.eu) è stato sviluppato per raccogliere e mettere a disposizione dei turisti le strutture ricettive extra-alberghiere (provenienti dall'Anagrafe delle Strutture Ricettive) e gli alloggi privati (provenienti dal Registro delle Locazioni Occasionali) dotati di codice IUN e regolarmente registrati nei sistemi RAS.
E’ stata inoltre istituita a livello nazionale la Banca Dati delle Strutture Ricettive (BDSR) e degli immobili destinati a locazione breve o per finalità turistiche, ai sensi dell’articolo 13-quater, comma 4, del decreto-legge 30 aprile 2019, n. 34, convertito, con modificazioni, dalla legge 28 giugno 2019, n. 58. Tramite la BDSR è attivata la procedura telematica di assegnazione del Codice Identificativo Nazionale (CIN), prevista ai sensi della “Disciplina delle locazioni per finalità turistiche, delle locazioni brevi, delle attività turistico-ricettive […]”, all’articolo 13-ter del decreto-legge 18 ottobre 2023, n. 145, convertito, con modificazioni, dalla legge 15 dicembre 2023, n. 191.
Il Decreto Ministeriale prot. n. 16726/24 del 06 giugno 2024 ha consentito l’avvio della fase pilota della BDSR, durante la quale è previsto lo sviluppo dell’interoperabilità con le banche dati territoriali e il coinvolgimento graduale delle Regioni
In questo contesto potrebbero rendersi necessari gli interventi:
1. ridefinizione del processo di attribuzione del codice IUN per l'estensione alle strutture alberghiere;
2. creazione di nuove API per l'interrogazione del Registro regionale;
3. adeguamento del Registro per rispondere alle specifiche definite dal Registro nazionale;
4. incremento dei formati dei file scaricabili dal sito del Registro IUN;
5. creazione di nuovi strumenti di ricerca;
6. monitoraggio e gestione automatica degli errori derivanti dall'invio delle email di notifica.
Osservatorio del Turismo, Artigianato e Commercio
Il sito dell'Osservatorio sarà oggetto di attività evolutive volte a dare nuovi strumenti di acquisizione e analisi dati agli operatori economici, alle istituzioni e ai cittadini.
In particolare emergono alcuni scenari di evoluzione:
1. realizzazione di flussi per l'acquisizione e l'esposizione dei dati provenienti dai web service dell'Anagrafe delle strutture Ricettive, del Registro delle Locazioni Occasionali e del Registro IUN;
2. realizzazione e pubblicazione dell'annuario delle strutture ricettive in diversi formati (csv, pdf, ecc.);
3. realizzazione di funzioni per l'esposizione dei risultati (file, dashboard, ecc.) delle analisi elaborate dal Data lake;
4. realizzazione di nuove dashboard web per l'esplorazione e l'analisi dei dati;
5. realizzazione di dashboard per l'esplorazione e l'analisi dei dati, fruibili su dispositivi mobile;
6. estensione del sito dell'Osservatorio in termini di architettura informativa e di funzionalità.
Interoperabilità
L'evoluzione della piattaforma SardegnaTurismo ha evidenziato l'esigenza di creare un nuovo sistema di gestione, pubblicazione e sviluppo centrale delle API di tutti i sistemi che ne fanno parte. Tale sistema di gestione potrà includere le seguenti funzionalità:
1. Design API mediante framework unico (es. swagger) da parte di un ruolo specifico (creator);
2. Pubblicazione API da parte di un ruolo specifico (publisher);
3. API discovery;
4. API Store (che consente tagging, documentazione, categorizzazione e test da parte dell'utente);
5. QoS (Quality of Service) che fornisca security, rate limit e analytics;
6. Monitoraggio uso API;
7. Secure API con:
a. supporto specifiche OAuth;
b. supporto dei più diffusi tipi di grant quali credenziali, codice, password, implicit, Security Assertion Markup Language (SAML), Windows Authentication (IWA)
c. Aggancio Access Manager RAS;
8. Aggancio API delle singole componenti mediante loro riscrittura, semplice aggancio o wrapping.;
9. Gestione autenticazione OTP.
Area Operatori
Per quanto attiene Area Operatori, possono individuarsi i seguenti sviluppi del back-office:
1. ottimizzazione della gestione dei flussi di dati anagrafici provenienti dalle anagrafi interne dell'Assessorato;
2. nuova versione del sistema di gestione degli operatori in self provisioning (ELIOT);
3. potenziamento funzionalità gestione gruppi e accreditamenti presso aziende;
4. potenziamento dashboard delle pagine utente e sistemi di pubblicazione su bacheche private;
5. porting a Drupal 10.
Articolo 6. 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 gli obiettivi e i deliverable previsti dal fornitore per una specifica attività 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 la verifica di conformità;
● verificati rispetto alla condizione che ciascun rilascio o eventuali modifiche apportate a funzionalità preesistenti non inducano 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 e dall'offerta tecnica presentata:
● Il nominativo degli esperti individuati dalla società offerente quali responsabili dell'esecuzione dei servizi ed i nominativi, il ruolo e le competenze degli altri componenti del gruppo di lavoro secondo le specifiche e modalità indicate nel presente capitolato;
● 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 task management e bug tracking (Jira o equivalente), che consentano di:
■ definire schede di attività e task;
■ organizzare l'attività in sprint;
■ gestire la Quality Assurance;
■ tenere traccia del tempo impiegato da ogni singolo componente del team su ciascun task e corredare il log del tempo con la descrizione delle attività eseguite;
■ produrre, ai fini della rendicontazione, un report dettagliato del tempo erogato per ciascuna scheda di attività;
■ agganciare la documentazione del codice e il sistema di bug tracking;
● L'evidenziazione 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.
RAS 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 7. Tempi attesi di esecuzione
Sulla base della priorità indicata da RAS la presa in carico della richiesta da parte dell’aggiudicatario dovrà avvenire entro le tempistiche sotto indicate. Per consentire al fornitore l’ottimizzazione delle proprie attività e risorse, le tempistiche attività possono essere più lunghe dell’effort stimato, entro un termine espresso in giorni lavorativi e calcolato secondo i moltiplicatori indicati nella tabella seguente, dipendenti dalla priorità della richiesta.
Priorità | Presa in carico (dall’apertura della richiesta). | Analisi preliminare (a partire dalla richiesta), analisi di dettaglio (a partire dalla fine dell’analisi preliminare), esecuzione attività (a partire dalla fine dell’analisi di dettaglio). |
Altissima | 0,5 gg | Effort * 1,2 |
Alta | 1 gg | Effort * 1,5 |
Media | 3 gg | Effort * 3 |
Bassa | 5 gg | Effort * 4 |
Bassissima | 7 gg | Effort * 5 |
Per maggior chiarezza, supponendo l’apertura di una richiesta di priorità media si riportano di seguito
le tempistiche attese:
tempo stimato | Tempo massimo di esecuzione | |
Presa in carico | n.a. | Entro 3gg lavorativi dalla data di creazione |
Analisi preliminare | 0,5 gg | 0,5*3 = 1,5 gg lavorativi dalla data di presa in carico |
Analisi di dettaglio | 2,5 gg | 2,5*3 = 7,5 gg lavorativi dalla data di fine analisi preliminare |
Realizzazione attività | 10 | 10*3 = 30 gg lavorativi dalla data di fine analisi di dettaglio |
La fase finale di realizzazione delle attività volte al soddisfacimento della richiesta – ovvero il completamento di tutte le attività previste nella scheda attività approvata da RAS, inclusi gli eventuali deploy nei vari ambienti – dovrà essere garantita nel pieno rispetto dei tempi sopra indicati, a meno di eventuali diversi accordi espliciti con RAS nei casi in cui le attività richieste abbiano tempi di esecuzione non proporzionali all’effort richiesto, o per altri motivi concordati e condivisi.
Nel calcolo dei tempi sopra descritti non saranno computati i periodi in cui:
❖ il fornitore è impossibilitato a proseguire le attività in quanto in attesa di altre attività propedeutiche, o di un riscontro da parte di RAS o di altri soggetti. Si specifica tuttavia che il fornitore deve fare tutto quanto in suo potere per proseguire l’esecuzione di tutte le attività che possono essere portate avanti, e per rimuovere tempestivamente le cause ostative che bloccano l’esecuzione delle altre. E’ suo onere sollecitare i soggetti responsabili del blocco, preferibilmente attraverso i mezzi di comunicazione breve (meeting, telefono, chat) quando è possibile o quando gli altri canali di comunicazione si rivelano poco efficaci.
❖ il fornitore è in attesa di un riscontro da parte di RAS dopo aver completato anche solo parzialmente ambiente; la soluzione proposta e/o averne fatto il deploy in un certo ambiente.
❖ le richieste contemporaneamente in lavorazione superino la capacità di erogazione delle risorse messe a disposizione dal fornitore, fermo restando l’effort minimo per ciascuna figura professionale che il fornitore si impegna a fornire a RAS come indicato nel paragrafo 6.1;
❖ l’attività è sospesa su indicazione di RAS per proprie esigenze interne o per accordi presi con
il fornitore per motivi diversi da quelli sopra indicati;
Nella scelta dell’ordine cronologico con cui le richieste vengono evase il fornitore dovrà tenere conto delle eventuali indicazioni ricevute da RAS, che potrà anche richiedere la sospensione di un’attività e la lavorazione di un’altra considerata maggiormente urgente rispetto alle proprie esigenze interne. La realizzazione degli interventi di sviluppo evolutivo - intesa come completamento di tutte le attività previste nelle schede attività approvate da RAS - dovrà essere garantita entro la data di rilascio definita nelle medesime schede attività. Gli eventuali collaudi saranno effettuati sugli ambienti di stage/test e/o produzione forniti da RAS.
Articolo 8. Livelli di servizio (SLA)
Si riportano di seguito i livelli di servizio attesi dalla stazione appaltante.
SLA di riferimento per la puntualità nello sviluppo evolutivo | ||
Indicatore | Definizione | Valori di soglia |
P_SVI | Puntualità nel completamento di tutte le attività previste nella scheda attività del singolo intervento approvata da RAS rispetto ai tempi concordati o nel rilascio | Almeno il 90% dei rilasci entro la data concordata ed il 100% entro 5 giorni lavorativi dalla data concordata. Media rilevata su base bimestrale. |
SLA di riferimento per la puntualità nella produzione delle schede attività | ||
Indicatore | Definizione | Valori di soglia |
P_SCH | Puntualità nella produzione delle schede attività, in risposta alle richieste di RAS, in base a quanto previsto nel presente capitolato. | Almeno il 90% delle schede consegnate entro la data concordata ed il 100% entro 2 giorni lavorativi da |
quest'ultima. Media rilevata su base bimestrale. |
SLA di riferimento per l'effort minimo garantito | ||
Indicatore | Definizione | Valori di soglia |
P_EFF | Erogazione, per ciascuna figura professionale prevista, dell’effort minimo garantito indicato nel presente capitolato se richiesti da RAS. | Erogazione, per ciascuna figura professionale prevista, del 100% dei giorni indicati come effort minimo nel presente Capitolato se richiesti da RAS. |
SLA di riferimento per 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 |
MAN-FOS | Finestra di osservazione dello SLA | - | ore 09.00 - 18.00 da lun a ven |
Articolo 9. Competenze, esperienze e qualificazione del team di progetto
La ditta aggiudicataria dovrà indicare nel POA (Piano Operativo Attività) 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 (All. 2).
Un medesimo esperto può essere indicato per ricoprire un solo profilo professionale tra quelli sotto indicati.
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 sovrappongano temporalmente.
Si riportano di seguito i profili professionali minimi richiesti:
● Programmatore junior con almeno 2 anni di esperienza professionale documentata nelle seguenti aree:
○ sviluppo PHP su piattaforma open source Drupal;
○ sviluppo front-end applicazioni web su tecnologie HTML5 / CSS3 / JavaScript;
○ sviluppo front-end applicazioni web e mobile su tecnologie JavaScript Angular o React in ambiente cloud;
○ sviluppo di applicazioni backend di applicazioni web Node.js.
● Programmatore Senior con almeno 5 anni di esperienza professionale documentata nelle seguenti aree:
○ sviluppo PHP su piattaforma open source Drupal in ambiente cloud;
○ sviluppo front-end applicazioni web e mobile su tecnologie HTML5 / CSS3 / JavaScript in ambiente cloud;
○ sviluppo front-end applicazioni web e mobile su tecnologie JavaScript Angular o React in ambiente cloud;
○ sviluppo di applicazioni backend su Node.js in ambiente cloud.
● Analista / Web Architect / Cloud Architect con almeno 5 anni di esperienza documentata nelle seguenti aree:
○ raccolta requisiti, analisi e disegno di architetture web;
○ raccolta requisiti, analisi e disegno di architetture cloud AWS;
○ progettazione di architetture cloud basate su servizi serverless.
● UX Designer Senior con almeno 5 anni di esperienza professionale documentata nelle seguenti aree:
○ Progettazione dell'interazione utente per applicazioni web e mobile.
○ Sviluppo di flussi utente e storyboard dettagliati.
○ Realizzazione di prototipi interattivi per testare e perfezionare le interazioni.
● Data Engineer Senior con almeno 5 anni di esperienza professionale documentata nelle seguenti aree:
○ design e realizzazione di pipeline di trattamento di flussi di dati da differenti sorgenti anche con l'applicazione di algoritmi per l'integrazione dei dati con tecniche di machine learning;
○ progettazione e interrogazione di database su storage Big Data, anche su cloud Amazon AWS;
○ preparazione dei dati per il loro utilizzo analitico e operativo.
● Data Engineer Junior con almeno 2 anni di esperienza professionale documentata nelle seguenti aree:
○ Sviluppo e manutenzione di pipeline di dati in ambienti Big Data.
○ Utilizzo di linguaggi di scripting come Python per l'automazione dei flussi di dati.
○ Conoscenza di base dei principali database SQL e NoSQL.
○ Esperienza iniziale nella progettazione e nell'implementazione di soluzioni di integrazione dati.
● Sistemista Senior con almeno 5 anni complessivi di esperienza professionale documentata nelle seguenti aree:
○ gestione delle problematiche di sicurezza e di performance, con particolare riferimento a sistemi informatici interoperabili e mutuamente integrati in un ecosistema complesso;
○ gestione sistemistica di reti e architetture cloud Amazon AWS, nella loro configurazione ed erogazione;
○ utilizzo di Container e sistemi di orchestrazione (ad esempio Docker + Kubernetes).
● Product Designer Senior/ Service Designer Senior con almeno 5 anni di esperienza professionale documentata nelle seguenti aree:
○ Ideazione e design di prodotti digitali complessi.
○ Creazione di wireframes, mockups e prototipi dettagliati.
○ Conduzione di test di usabilità e ottimizzazione del design in base al feedback degli utenti.
○ Collaborazione trasversale con team di sviluppo e stakeholder per assicurare che il design sia eseguibile e risponda agli obiettivi di business.
○ Design e implementazione di servizi che migliorano l'esperienza degli utenti.
○ Utilizzo di metodologie di design thinking per esplorare e risolvere problemi complessi.
○ Coordinamento con diverse funzioni aziendali per garantire una consegna di servizio efficace.
○ Sviluppo di metriche di successo e monitoraggio dei miglioramenti dei servizi.
● Data Scientist Senior con almeno 5 anni di esperienza professionale documentata nelle seguenti aree:
○ Sviluppo e implementazione di modelli statistici e di machine learning per risolvere problemi aziendali complessi.
○ Analisi di grandi set di dati per estrarre pattern e insight significativi.
○ Utilizzo di strumenti avanzati di analisi dati (Python) e piattaforme di analisi su cloud.
○ Presentazione dei risultati dell'analisi a stakeholder non tecnici.
● Data Scientist Junior con almeno 2 anni di esperienza professionale documentata nelle seguenti aree:
○ Assistenza nella raccolta e pulizia dei dati per analisi successive.
○ Supporto nella realizzazione di modelli di machine learning semplici.
○ Uso di strumenti di analisi dati, conoscenza linguaggio Python e librerie specializzate (es. pandas, scikit-learn).
○ Creazione di visualizzazioni dei dati per facilitare l'interpretazione degli stessi da parte dei team aziendali.
● Data Analyst Senior con almeno 5 anni di esperienza professionale documentata nelle seguenti aree:
○ Conduzione di analisi complesse per supportare decisioni strategiche aziendali.
○ Progettazione e implementazione di dashboard e report di business intelligence per il monitoraggio delle performance aziendali.
○ Guida nella definizione di strategie di raccolta dati e nella scelta di strumenti e tecnologie di analisi avanzate.
● Data Analyst Junior con almeno 2 anni di esperienza professionale documentata nelle seguenti aree:
○ Analisi di set di dati per identificare tendenze, anomalie e opportunità di miglioramento.
○ Utilizzo di strumenti di analisi e visualizzazione dati come Quicksight, Tableau o simili.
○ Collaborazione con team interni per raccogliere requisiti e definire metriche chiave.
○ Preparazione di report periodici e presentazioni dei risultati analitici a team interni.
● 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 10. 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 che ne ha richiesto la produzione tramite il presente Capitolato, e potrà essere pubblicata, rilasciata e diffusa in piena discrezionalità da RAS. Potrà altresì essere utilizzata anche da altre istituzioni facenti parte del Sistema Regionale per gli scopi istituzionali da queste perseguiti.
Articolo 11. 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. La verifica di conformità potrà essere effettuata in contraddittorio con il fornitore secondo le modalità che l'Amministrazione riterrà più utili.
Nel caso in cui le operazioni di verifica 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 8 del presente Capitolato.
La verifica di conformità si intende effettuata positivamente dopo che l'Amministrazione ha riscontrato la rimozione degli errori, difetti o mancanze segnalati. L'esito positivo della verifica di conformità comporta l'accettazione della fornitura da parte della stazione appaltante.
Pierangelo Lucio Orofino 31.07.2024
15:09:39
GMT+02:00
37/38