Servizi di manutenzione correttiva, adeguativa, evolutiva
00.07.01.00 - Direzione Generale del Turismo 00.07.01.04 - Servizio Marketing e Comunicazione
Servizi di manutenzione correttiva, adeguativa, evolutiva
ed erogazione della piattaforma SardegnaTurismo
e dell’Osservatorio del Turismo, Artigianato e Commercio
CAPITOLATO TECNICO
Approvato con DDS n. 320 - Protocollo n. 5668 del 10/05/2021
Sommario
Articolo 1. | Premessa | 4 |
5 | ||
Oggetto della fornitura | 18 | |
19 dei servizi | 18 | |
Articolo 5. | Valore dei servizi richiesti | 19 |
Articolo 6. | 20 | 19 |
210 | ||
265 | ||
2826 | ||
2927 | ||
3028 | ||
355 | ||
7.1. | Errore. Il segnalibro non è definito.7 | |
7.2. | Documenti a corredo | 39 |
40 | 40 | |
4242 | ||
Articolo 10. | Errore. Il segnalibro non è definito.3 | |
455 | ||
48 | ||
Articolo 13. | Conoscenza delle condizioni e revisione dei prezzi | 48 |
4849 | ||
Articolo 15. | Divieto di sospensione dei servizi | 49 |
Articolo 16. | Errore. Il segnalibro non è definito.49 | |
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 |
VM | Virtual Machine |
CSR | Centro Servizi Regionale (infrastruttura RAS) |
AWS | Amazon Web Services |
Articolo 1. Premessa
Il servizio indicato nel presente Capitolato verrà affidato a seguito delle risultanze indagine di mercato tramite richiesta di offerta (RDO) sul MEPA, Mercato Elettronico della Pubblica Amministrazione, a tutti gli operatori che presentano la propria manifestazione d’interesse e siano in regola con i requisiti di cui all’Avviso Pubblico Esplorativo (titolo dell’avviso), ed abilitati all’iniziativa MEPA SERVIZI “Area Merceologica Informatica, Elettronica, Telecomunicazioni e macchine per l’ufficio” – Categoria merceologica “Servizi per l'Information Communication Technology”.
Nel rispetto dei principi di cui all’art. 30 del D.lgs 50/2016, al fine di garantire la più ampia partecipazione dei soggetti economici, l’Assessorato si riserva la piena facoltà di integrare l’elenco degli operatori da invitare individuandoli tra quelli regolarmente iscritti al MEPA nella categoria sopraindicata, anche laddove questi non abbiano presentato manifestazione di interesse.
L’aggiudicazione avverrà in base al criterio dell’offerta economicamente più vantaggiosa ai sensi dell’art. 95 comma 3 b-bis del D.Lgs n. 50/2016 ss.mm.ii.
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 del soggetto partecipante ovvero con firma olografa dello stesso rappresentante accompagnata da copia di un suo documento d’identità in corso di validità.
Il presente Capitolato, controfirmato nelle modalità indicate sopra, dovrà essere obbligatoriamente allegato alla domanda di manifestazione d’interesse, a pena di esclusione. Saranno esclusi dalla successiva procedura di RdO, gli operatori economici che
presentino la propria manifestazione di interesse senza allegare il presente Capitolato.
Articolo 2. Descrizione del contesto
L’Assessorato del Turismo, Artigianato e Commercio - tramite l’ex Servizio Sistemi Informativi - ha realizzato e messo in uso la piattaforma tecnologica SardegnaTurismo, ecosistema digitale, che a seguito della riorganizzazione delle competenze interne all’Assessorato, è attualmente gestito dal Servizio Marketing e Comunicazione. I sistemi della piattaforma sono strumentali alle funzioni ed agli adempimenti amministrativi di competenza anche degli altri Servizi dell’Assessorato.
Le applicazioni che costituiscono la piattaforma sono state oggetto di specifici affidamenti per la loro evoluzione infrastrutturale e tecnologica. Inoltre sono caratterizzate da una integrazione operativa e fanno riferimento dal punto di vista tecnologico ad una comune infrastruttura di erogazione.
Dato il carattere istituzionale della piattaforma SardegnaTurismo, nella realizzazione delle forniture di siti web, si dovranno osservare i principi generali e le indicazioni operative contenute nelle Linee guida per i siti web delle PA previste dall’art. 71 “Regole Tecniche” del CAD istituito con il decreto legislativo 7 marzo 2005, n. 82 e ss.mm.ii.
La piattaforma è ospitata su infrastrutture Cloud AWS, Acquia Drupal e CSR. Queste diverse infrastrutture saranno integrate nel prossimo futuro in un Cloud Ibrido Multi-Tenant il cui sviluppo e messa in produzione è in capo alla Società in-house SardegnaIT.
Le applicazioni della piattaforma SardegnaTurismo e dell’Osservatorio del Turismo, Artigianato e Commercio costituiscono un “ecosistema” informativo complesso in continua fase di evoluzione le cui componenti principali sono rappresentate di seguito:
- Identity Management System (IDM) e Access Manager (AM): sono i sistemi di autenticazione regionali che implementano diversi meccanismi di autenticazione, anche forte, basati ad esempio sull’utilizzo della CNS (Carta Nazionale dei Servizi) o di SPID. Molti dei sistemi della piattaforma SardegnaTurismo sono integrati con tali
sistemi allo scopo di consentire agli utenti il passaggio tra sistemi senza necessità di ripetere l’autenticazione (SSO).
- 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 data base (MongoDB), degli indici su un motore di ricerca (ElasticSearch), code (AWS SQS), delle funzioni serverless (AWS Lambda Function). L’ASR si interfaccia con l’Area Operatori (AO), il Destination Management System (DMS) e il sistema di autenticazione regionale Access Manager. Il frontend 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 consentire un buon livello di flessibilità nel caso fossero necessarie eventuali modifiche. 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 data base 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 sistemi esterni.
- Registro delle Locazioni Occasionali (RLO): è il sistema di gestione dell'anagrafe degli alloggi privati, utilizzati per le locazioni brevi a 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 RLO inoltre, a differenza dell'ASR, è stato pensato per dare la possibilità ai cittadini, o a eventuali delegati, di occuparsi in prima persona della registrazione e consultazione dei propri immobili, con la logica dell'autocertificazione.
Le tecnologie del RLO sono le medesime utilizzate per la realizzazione dell'ASR: un frontend rappresentato da una web app Angular che espone dei webform definiti tramite delle strutture Json, un backend server sviluppato in NodeJS, un data base MongoDB e gli indici su un motore di ricerca Elasticsearch. Il servizio Monstache consente di tenere sincronizzate le informazioni presenti sul data base MongoDB e quelle presenti negli indici Elasticsearch.
− Registro IUN (xxxxx://xxx.xxx.xx): sito web per la consultazione degli IUN. Lo IUN è il codice Identificativo Unico Numerico assegnato alle strutture ricettive extra- alberghiere e agli alloggi privati utilizzati per le locazioni occasionali a fini turistici, che deve essere esposto in ogni strumento di comunicazione e di commercializzazione on line.
Il registro IUN espone i dati presenti nei 2 sistemi appena descritti ASR e RLO. Il sistema è composto da un'applicazione Angular che gestisce il rendering della pagina "client-side", invocando una funzione lambda. Per aumentare le performance, le interrogazioni sui data base MongoDB dei 2 sistemi sono sostituite da un indice Elasticsearch che integra i dati presenti negli indici Elasticsearch dei singoli sistemi.
- L’Area Operatori (AO), xxxx://xxxxxxxxx.xxxxxxxxxxxxxxx.xx/, applicazione web Drupal 7 che costituisce un canale di comunicazione tra le diverse categorie di operatori turistici sul territorio regionale e la RAS. L’AO è l’hub di accesso ai vari servizi disponibili per gli operatori; consente a questi ultimi di gestire il proprio profilo anagrafico e commerciale e costituisce lo strumento attraverso il quale conferire contenuti certificati e qualificati, anche in chiave di dematerializzazione delle procedure e di redazione diffusa (foto, testi, 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. L’Area Operatori è connessa al sistema IDM della Regione Sardegna (xxxx://xxx.xxxxxxx.xxxxxxxx.xx/xxxxxxx-xxx/) tramite protocollo SAML 2 ed è in via di connessione, via OAuth, al nuovo sistema Access Manager che intermedierà gli accessi tramite Spid (Sistema Pubblico di Identità Digitale). L’Area Operatori ha una infrastruttura costituita dai seguenti macrocomponenti:
- Varnish cache (sistema di caching lato frontend xxx.xxxxxxx-xxxxxxxx.xxx)
- Apache Solr (motore di indicizzazione dei contenuti xxx.xxxxxx.xxxxxx.xxx/xxxx);
- Database (MySQL)
- CMS Drupal (Content Management System xxxxx://xxx.xxxxxx.xxx/)
- Il Destination Management System (DMS), piattaforma tecnologica per la promo- commercializzazione della destinazione turistica; consente agli operatori il caricamento della propria anagrafica commerciale e delle proprie offerte, esposte tramite API, per la
- Portale SardegnaTurismo (xxx.xxxxxxxxxxxxxxx.xx), portale turistico ufficiale della Regione Sardegna, accoglie tutte le informazioni su punti di interesse, eventi, itinerari, articoli di approfondimento e strutture ricettive presenti in Sardegna. Il sistema è ospitato su piattaforma Acquia Drupal la cui infrastruttura è costituita dai seguenti macrocomponenti:
- Varnish cache (sistema di caching lato frontend xxx.xxxxxxx-xxxxxxxx.xxx)
- Apache Solr (motore di indicizzazione dei contenuti xxx.xxxxxx.xxxxxx.xxx/xxxx);
- Database (MySQL)
- CMS Drupal (Content Management System xxxxx://xxx.xxxxxx.xxx/)
- FILIERA PROPAGAZIONE DATI: si tratta di un processo trasversale che integra tra loro alcune componenti della piattaforma SardegnaTurismo. 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 da ASR e AO, 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 propagazione dei dati avviene secondo i seguenti meccanismi:
- Da ASR ad AO e DMS mediante code alimentate da ASR sulla base di eventi di operazioni CRUD sui dati; le code vengono consumate attraverso le operazioni di import su AO e DMS;
- Da DMS a ST mediante un processo batch che importa su ST solo i dati modificati dopo la precedente attività di import.
- Il SIRED, xxxxx://xxxxx.xxxxxxxxxxxxxxx.xx/, è un sistema informativo di raccolta ed elaborazione dei dati sul movimento turistico e sulla capacità ricettiva fornito dalla RAS alle Province ed alle strutture ricettive anche 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 CSR. Nella figura seguente si riporta lo schema architetturale del sistema.
Il SIRED, nella sua versione attuale, non è oggetto di attività di evoluzione da parte del fornitore che dovrà semplicemente conoscere e utilizzare le API che tale sistema espone al fine di poter sviluppare nuove modalità di integrazione applicativa con gli altri sistemi della piattaforma SardegnaTurismo.
Verrà invece realizzato un nuovo sistema di raccolta dati totalmente open source all’interno del ADP 4 che vede coinvolte diverse regioni italiane. Quando il sistema sarà realizzato dal vincitore di uno specifico bando rientrerà tra quelli oggetto di manutenzione del presente bando.
- Il sito dell’Osservatorio del turismo, 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- dati); questi ultimi sono sistemi interattivi di analisi e visualizzazione dei dati dei flussi turistici in Sardegna, basati anche su dati provenienti dal SIRED.
L’architettura del sistema è costituita da diverse componenti distinte:
● Sito internet Drupal 8 e DB Mysql
● Applicazioni dashboard interattive basate su applicazioni Shiny (xxxxx://xxxxxx.xxx/xxxxxxx/xxxxx)
● Infrastruttura di autenticazione basata su infrastruttura serverless AWS. Il flusso logico che realizza l'autenticazione è il seguente:
a. l'utente, per accedere al servizio desiderato, chiama una URL, esposta tramite servizio API Gateway di AWS;
b. 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;
c. verificati i permessi, le richieste dell'utente autorizzato vengono inoltrate 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 da dati quali quelli sugli arrivi e sulle presenze 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:
a. 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;
b. Lambda Function, implementate in Python 2.7 o Python 3.6, tramite le quali vengono scaricati i dati su un data lake ospitato su S3 AWS. Gli eventi generati dalla presenza di nuovi file JSON permettono l'invocazione a cascata di una serie di Lambda Function, attraverso le quali il dato viene normalizzato e ripulito per poter essere correttamente interrogato tramite il servizio Athena AWS;
c. 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): è 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. da SardegnaTurismo) secondo una logica top-down, e produce contenuti che nascendo dal basso possono essere riusati centralmente secondo una logica bottom-up. Il sistema, basato su tecnologie Drupal, Elasticsearch, Kibana, Logstash, CiviCRM e Ionic, è ospitato su Acquia Drupal e su Cloud AWS ed è costituito dai seguenti componenti: HCMS, HIS-INFONET, HIS-API, CRM e MONIT.
HCMS
Il componente HCMS sviluppato su Drupal, implementa le funzioni di content management del sistema HIS e fornisce gli ambienti di back office dedicati alla redazione e all'infopoint delle comunità hyperlocal. L'accesso è consentito ai soli utenti autenticati (IdM) e autorizzati (Area Operatori). Il sistema è ospitato su Acquia Drupal.
HIS-INFONET
La componente HIS-INFONET comprende le applicazioni mobile (Here Is Sardinia) disponibili sugli store pubblici e realizzate con tecnologia Ionic su piattaforme iOS e Android, oltre all’applicazione SPA (Single Page Application) visualizzata dai dispositivi infopoint e sviluppata su tecnologia AngularJS.
HIS-API
La componente HIS-API, sviluppata su Drupal ed Elasticsearch, consente l'invocazione di servizi e lo scambio di informazioni tra i diversi attori del sistema HIS. Ogni chiamata API è oggetto di autenticazione mediante sistema OAUTH e, in particolare quelle realizzate per la mobile app, contengono le coordinate del dispositivo anonimizzate in fase di memorizzazione.
CRM
Il componente CRM rappresenta il CRM del sistema HIS la cui principale funzione è la raccolta di contatti-utente e l'invio di newsletter. Il CRM utilizzato è CiviCRM, basato su Drupal e consente di utilizzare le metodologie e gli strumenti definiti per il componente HCMS.
MONIT
Il componente MONIT, sviluppato su stack ELK (Elasticsearch+Logstash+Kibana), ha il compito di raccogliere, analizzare, presentare e conservare le informazioni sulle attività svolte dagli altri componenti del sistema Hyperlocal.
La figura seguente illustra l’architettura del sistema.
- 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. Il sistema è attualmente ospitato su CSR.
- VETRINA ARTIGIANATO ARTISTICO: si tratta di un sito Drupal7 (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 7, che sarà integrato nella piattaforma SardegnaTurismo. Il sito è ospitato sul CSR 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/)
- DATA LAKE: sistema per la raccolta, l'integrazione e l'elaborazione di dati eterogenei. L'architettura del Data Lake è una soluzione Hadoop Hortonworks, che si avvale di strumenti Open Source per la realizzazione dei vari layer applicativi. La piattaforma è ospitata su infrastruttura di cloud pubblico Amazon AWS in modalità IaaS. Lo storage distribuito fa uso sia di risorse HDFS che del servizio S3 di AWS, sia per i dati strutturati che per quelli non strutturati, provenienti da fonti eterogenee, da sorgenti real-time o batch. I layer di storage e di elaborazione sono disaccoppiati. La piattaforma è predisposta per il trattamento dei dati nel rispetto del GDPR, con la possibilità di impostare diversi livelli di accesso su dati e attributi in maniera fine. La piattaforma integra lo strumento di elaborazione Spark, utilizzato principalmente per la fase di pre-processing finalizzata alla preparazione del dato per le analisi successive. Di seguito uno schema e una breve descrizione delle componenti della piattaforma:
● Apache NiFi/Kylo: connettori per l'acquisizione di dati dalle varie fonti.
● Spark: framework per elaborazioni distribuite in-memory su larga scala, in grado di sfruttare le caratteristiche di data locality sul cluster Hadoop, utilizzato per il pre-processing dei dati.
● Dataplane: software per la Data Governance, che si basa sia su Ranger (per la sicurezza) che su Atlas per la Data Governance.
● HDFS: storage di Hadoop: file system distribuito e ridondante, predisposto all’elaborazione di datasets di grandi dimensioni con elevato throughput di accesso ai dati in modalità full-scan.
● Apache Zeppelin: strumento per la predisposizione di notebook in modalità REPL.
● Knowage: strumento per la data visualization, mette a disposizioni funzionalità per il reporting, la self-service BI, la pubblicazione di data set / open data, l'embedding e mash-up con altre applicazioni.
- INFRASTRUTTURA CLOUD AMAZON AWS: tutte le componenti sopra riportate (ad esclusione del SIRED nella sua versione attuale) sono ospitate su Cloud AWS o dovranno essere migrate su tale cloud. Tutte le infrastrutture cloud AWS sono oggetto di manutenzione nel presente capitolato. Sono comprese le eventuali operazioni di migrazione sul cloud AWS dell’Assessorato di componenti ospitati su CSR o su altri sistemi esterni.
Si specifica che l’elenco di cui sopra non deve intendersi come completo ed esaustivo in quanto rappresenta solo le principali componenti dell’architettura, ed ha uno scopo puramente informativo volto a consentire ai partecipanti un’adeguata conoscenza ad alto livello dei sistemi e delle tecnologie coinvolte, al fine ultimo dell’acquisizione della consapevolezza del grado di complessità delle attività e delle professionalità richieste dal presente bando. Si intendono quindi inclusi nel presente affidamento anche i sistemi non elencati, compresi gli eventuali nuovi sistemi e componenti che dovessero essere realizzati in futuro, anche da parte di altri fornitori.
Articolo 3. Oggetto della fornitura
Il presente Capitolato regolamenta la fornitura di servizi professionali di manutenzione correttiva, adeguativa ed evolutiva per i sistemi applicativi che compongono la piattaforma SardegnaTurismo e l’Osservatorio del Turismo, Artigianato e Commercio, come descritti nel presente Capitolato. Sono altresì oggetto del presente appalto i servizi di erogazione e gestione sistemistica degli stessi sistemi su cloud Amazon AWS e Acquia Drupal, nonchè su ulteriori Platform As A Service (PAAS) identificati da RAS.
Articolo 4. Durata dei servizi
Le attività saranno rendicontate a consumo come meglio specificato nei punti successivi, pertanto il periodo effettivo di erogazione dei servizi – e quindi conseguentemente la durata del contratto - sarà funzionale alle esigenze evidenziate da RAS nel corso dell’operatività del contratto medesimo, e potrà pertanto risultare diverso da quello stimato.
Articolo 5. Valore dei servizi richiesti
Per la realizzazione dei servizi sopra indicati e di seguito dettagliati, l’importo a base d’asta sarà di euro 170’000,00 (euro centosettantamila/00) oltre l’IVA dovuta ai sensi di legge, e comprende la somma non soggetta a ribasso di euro 40’000,00 (Euro Quarantamila/00) corrispondente all’acquisizione esterna di servizi cloud di cui alla linea 3_EXT e 4 HW che verrà rimborsata all’Appaltatore dalla Stazione Appaltante e si configura quale anticipazione fatta in nome e per conto di quest’ultima, ai sensi dell’art. 15 del DPR. 26 ottobre 1972, n. 633.
Articolo 6. Descrizione dei servizi richiesti
L'Assessorato del Turismo, Artigianato e Commercio della Regione Autonoma della Sardegna - Servizio Marketing e Comunicazione, nell'ambito del contesto precedentemente illustrato, ha necessità di mantenere, aggiornare, far evolvere e garantire la gestione in esercizio dei suoi sistemi informativi. A tal fine intende acquisire i seguenti servizi:
ID fornitura | Descrizione fornitura |
1_MAN | Servizi di manutenzione correttiva, adeguativa ed evolutiva |
2_SYS | Servizi di gestione sistemistica |
3_EXT | Acquisizione esterna servizi cloud |
4_HW | Manutenzione hardware |
Tale impostazione richiede al fornitore aggiudicatario elevati livelli di professionalità, competenza ed esperienza in particolare nelle attività di manutenzione e sviluppo in ambiente Drupal, oltre che nelle applicazioni web Java based, nelle applicazioni mobile basate su tecnologie html/javascript, nell’erogazione e nella gestione sistemistica delle applicazioni su cloud (sia AWS che cloud ibrido multi tenant in fase di realizzazione), anche attraverso PAAS dedicati quali Acquia Drupal e GitHub.
Si forniscono di seguito i principali requisiti per le forniture secondo l’identificativo attribuito.
6.1. 1_MAN Servizi di manutenzione correttiva, adeguativa ed evolutiva.
I servizi riguardano la manutenzione correttiva, adeguativa ed evolutiva delle componenti descritte nel contesto (Articolo 3 del presente Capitolato), attraverso la realizzazione di interventi sulle applicazioni, sui frontend web, sui backend e sull’interfacciamento tra le componenti medesime, incluso lo sviluppo e l’estensione di tutte le API necessarie. Sono compresi i servizi legati:
- all’evoluzione delle componenti esistenti;
- allo sviluppo di nuove componenti e nuovi sistemi;
- alla manutenzione di eventuali nuove componenti realizzate da terzi.
Sono compresi la progettazione anche grafica e le relative attività di test utente legate a uno sviluppo interattivo che segua i paradigmi dello user centered design.
Le attività di manutenzione potranno inoltre includere attività che implichino l’utilizzo dell’infrastruttura di cloud ibrido in fase di realizzazione.
XXX metterà a disposizione dell’aggiudicatario la documentazione di analisi e progettazione tecnica associata alle varie componenti della piattaforma nelle loro attuali versioni. Laddove possibile, RAS metterà a disposizione dell’aggiudicatario anche il supporto di altri fornitori che possano fornire attività di formazione e passaggio di consegne su specifici sistemi di propria competenza. A partire da tale stato di fatto, il fornitore dovrà garantire i servizi di manutenzione che soddisfino le esigenze espresse da RAS.
Sarà inoltre compito del fornitore l’acquisizione dei nuovi sviluppi realizzati da RAS anche per il tramite di altri fornitori da questa individuati. I nuovi sviluppi, una volta completati e portati in produzione, dovranno entrare a far parte della piattaforma e saranno quindi oggetto di manutenzione. A tal fine, laddove possibile saranno definite specifiche attività di passaggio di consegne a favore dell'aggiudicatario.
Sono oggetto di questa voce di fornitura, anche se richieste in modo indipendente e non correlato a veri e propri interventi di manutenzione, le seguenti attività:
- Documentazione: Nella realizzazione degli interventi sopra indicati, il fornitore dovrà garantire l’aggiornamento della documentazione eventualmente esistente o la produzione di nuova documentazione, laddove necessario e secondo le richieste di RAS.
- Formazione/affiancamento: Dovranno essere inoltre effettuate, a richiesta di RAS, le attività di presentazione/affiancamento remoto agli operatori della committenza o di altri tecnici da questa indicati; tali attività dovranno essere temporalmente contigue quando correlate al rilascio degli interventi manutentivi.
- Supporto: al fornitore potrebbe essere richieste attività di supporto e verifica sia verso il personale RAS che verso terzi, compresi eventuali altri fornitori impegnati nella realizzazione di altre attività.
- Passaggio di consegne: potrà essere richiesto da RAS un passaggio di consegne, totale o parziale, verso altri soggetti.
- Altre attività: Ras potrà richiedere qualunque ulteriore attività non esplicitamente prevista nell’elenco di cui sopra (ad esempio attività di grafica, interrogazione database, etc.), purchè essa possa essere realizzabile sia quantitativamente che qualitativamente dalle figure professionali messe a disposizione dal fornitore.
La fornitura si svilupperà su più interventi, articolati secondo le richieste di RAS, che indicherà:
● la natura della richiesta: manutenzione (correttiva, adeguativa o evolutiva), attività di altra natura (supporto, formazione, etc.);
● gli eventuali requisiti funzionali e gli ambiti di attività richiesti al fornitore (analisi, progettazione, sviluppo) in relazione alla natura dell’intervento;
● le ulteriori indicazioni eventualmente necessarie.
Il fornitore, anche attraverso un’attività preliminare di analisi e raccolta requisiti, rilascerà, per ogni richiesta, una scheda attività (definita SA-xx dove “xx” è il codice univoco della scheda) nella quale dovrà riportare laddove possibile:
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 e per le fasi di analisi, progettazione e sviluppo;
3. Cronoprogramma di realizzazione, con l’articolazione temporale delle attività e la specifica della data di rilascio;
4. Tabella riepilogativa dei deliverables previsti.
Potrà essere utilizzata, ove concordato con RAS, una versione semplificata della scheda di attività che includa:
1. quotazione delle attività richieste in termini di ore uomo o loro frazioni, distintamente per figura professionale e per le fasi di analisi, progettazione e sviluppo.
2. Data di completamento delle attività;
3. Elenco degli output previsti.
L’amministrazione, 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 la 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 procede 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 ad adeguamenti funzionali che a 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à, sulla base delle indicazioni da parte di RAS e del tipo di attività richiesta, produrre almeno i seguenti deliverable minimi:
a. Analisi dei requisiti, con studio della user experience ove applicabile;
b. Documento di progettazione applicativa e delle interfacce;
c. Codice sorgente documentato;
d. Configurazione/implementazione;
e. Eventuale realizzazione dei test aggiuntivi nel sistema di continuous integration;
f. Report di esecuzione dei test funzionali e di non regressione volti alla verifica del corretto funzionamento di tutte le nuove funzionalità aggiunte al sistema;
g. Deploy nei vari ambienti di sviluppo, stage e produzione;
h. Manualistica;
Tutti gli interventi prestati dovranno garantire la soddisfazione dei seguenti requisiti trasversali:
1. 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;
2. 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;
3. il supporto di interfacce applicative (API) per esporre flussi dati potenzialmente riutilizzabili dai sistemi interconnessi;
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. 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;
6. 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, la documentazione e tutti i deliverable prodotti nell’ambito dell’appalto saranno di proprietà RAS.
Quanto sviluppato sulla linea 1_MAN dovrà essere oggetto dei necessari interventi sistemistici di cui alla linea 2_SYS, secondo le indicazioni di RAS, per garantire il mantenimento della piattaforma tecnologica e l’erogazione dei relativi servizi.
Resta inteso che, ai fini della collaudabilità, gli interventi della linea 1_MAN dovranno garantire non solo il pieno funzionamento delle componenti oggetto di intervento ma anche la loro corretta integrazione rispetto all’intero ecosistema SardegnaTurismo, a fronte dei diversi momenti in cui avverrà il rilascio delle componenti medesime e dei reciproci ambiti di interazione tra queste e l’ecosistema. 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.
6.1.1 Garanzia degli interventi realizzati
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 dei malfunzionamenti interni alle componenti manutenute 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 verificavano prima. Supponendo quindi 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à chiedere 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.
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. 11 e secondo le tipologie di errore da questo definite.
6.1.2 Quantificazione e rendicontazione delle attività 1_MAN
La modalità di rendicontazione della fornitura 1_MAN è a consumo, così come dettagliata nel paragrafo 6.5 ‘Quantificazione, rendicontazione, workflow ed effort minimo delle attività a consumo’.
6.2. 2_SYS Servizi di gestione sistemistica
Sono oggetto della presente voce di fornitura i servizi di tipo sistemistico relativi all’installazione, setup e mantenimento dell’infrastruttura necessaria ad erogare gli applicativi della piattaforma SardegnaTurismo e dell’Osservatorio del Turismo, Artigianato e Commercio.
Essi sono attualmente ospitati su sistemi CSR, cloud AWS e Acquia Drupal. I sistemi nell’ambito del CSR sono in carico alla società in house Sardegna IT, che ne cura la gestione e il mantenimento sia sotto il profilo applicativo che sistemistico. L’aggiudicatario dovrà garantire il supporto per le eventuali operazioni di migrazione degli applicativi tra CSR e sistemi cloud esterni e la loro integrazione nel cloud ibrido multi tenant in fase di sviluppo, anche garantendo il necessario ed adeguato raccordo con Sardegna IT.
Il fornitore dovrà inoltre proporre a RAS, secondo le modalità previste dal successivo art. 7, le policy e le procedure che saranno adottate nello svolgimento dei servizi di cui alla presente voce di fornitura.
Si precisa che la gestione sistemistica riguarderà anche i nuovi sviluppi e gli aggiornamenti agli applicativi della piattaforma SardegnaTurismo già realizzati, in fase di realizzazione o che saranno realizzati in futuro da altri fornitori. Tali fornitori rilasceranno gli aggiornamenti secondo le procedure proposte dall’aggiudicatario del presente appalto ed approvate da RAS.
Rientrano inoltre in questa fornitura tutte le attività inerenti la gestione degli ambienti CLOUD AWS e Acquia Drupal affidati al fornitore. Sono compresi quindi il monitoraggio continuo degli ambienti, gli aggiornamenti dei sistemi, la modifica delle configurazioni, e tutto quanto necessario a garantire la piena e corretta operatività degli applicativi RAS, adeguati standard di sicurezza e performances, e la migliore razionalizzazione dei costi dell’architettura. Rientra quindi in questa fornitura il controllo dei costi degli ambienti e dei servizi cloud, volto ad ottimizzare la spesa, anche con interventi riorganizzativi degli ambienti, e ad evitare che, per qualunque motivo, compresi errori nello sviluppo applicativo, i costi sostenuti aumentino, rispetto alla media, in modo imprevisto e non esplicitamente voluto.
Sono comprese inoltre tutte le attività di deploy e supporto che dovessero essere necessarie per il rilascio di eventuali sistemi sviluppati da terzi nella piattaforma cloud AWS gestita e controllata dall’aggiudicatario, a meno di accordi diversi tra i fornitori concordati esplicitamente con RAS.
Rientra infine in questa fornitura la gestione e la configurazione del sistema di tracking JIRA dell’assessorato, al fine di implementare i processi necessari alla gestione dei vari task, le estrazioni dati e le reportistiche richieste da RAS relativamente a questo e ad eventuali altri progetti dell’assessorato.
6.2.1 Quantificazione e rendicontazione delle attività 2_SYS
La modalità di rendicontazione della fornitura 2_SYS è a consumo, così come dettagliata al punto 6.5 ‘Quantificazione, rendicontazione, workflow ed effort minimo
delle attività a consumo’.
6.3. 3_EXT Acquisizione esterna servizi cloud
A corollario delle voci di fornitura 1_MAN e 2_SYS, il presente Capitolato prevede la voce di fornitura 3_EXT relativa all’acquisizione di due diversi servizi esterni:
EXT_CLOUD: servizio su cloud AWS o altri servizi equivalenti se approvati da RAS.
EXT_PAAS: Sistema PAAS tipo GitHub, Acquia Drupal o altri servizi analoghi che dovessero rendersi utili.
RAS si riserva il diritto di richiedere in ogni momento modifiche sulla configurazione delle singole istanze acquistate.
6.3.1 Quantificazione e rendicontazione delle attività 3_EXT
Le attività comprese nella fornitura 3_EXT saranno rendicontate dal fornitore a piè di lista. Le somme rendicontate non dovranno essere superiori al prezzo di mercato offerto per i medesimi servizi dai listini dei fornitori esterni individuati, riscontrabile ad esempio negli strumenti di preventivazione online dei fornitori medesimi. La RAS potrà effettuare richieste di acquisizioni esterne nella misura massima del 25% dell’importo a base d’asta, pari ad € 40.000,00 (Euro Quarantamila/00).
Le acquisizioni potranno essere rendicontate una volta effettuate e attive e nel rispetto di quanto previsto nel presente Capitolato. In fase di rendicontazione il fornitore dovrà indicare le fatture o le ricevute che comprovino la spesa effettuata, e che siano univocamente riconducibili alle risorse consumate per RAS.
Il fornitore dovrà anche produrre uno schema riepilogativo con la ripartizione degli importi rendicontati rispetto ai diversi sistemi applicativi ospitati. Nel caso di costi indivisi, ovvero quelli non direttamente imputabili a uno o più sistemi, il fornitore dovrà proporre e concordare con RAS i criteri di ripartizione tra i diversi sistemi applicativi RAS, al fine di raggiungere una quantificazione il più possibile attendibile dei costi di ciascun sistema RAS.
6.4. 4_HW Servizi di manutenzione hardware
Sono oggetto della presente voce di fornitura i servizi di manutenzione hardware dei dispositivi dislocati sul territorio regionale e collegati funzionalmente alla fruizione degli applicativi della piattaforma SardegnaTurismo e dell’Osservatorio del Turismo, Artigianato e Commercio. A titolo esemplificativo, si possono citare gli 8 dispositivi InfoTouch del sistema hyperlocal dispiegati nei 3 aeroporti della Sardegna e negli uffici informativi turistici.
E’ parte della fornitura di cui al presente appalto la sostituzione di pezzi difettosi o l’intervento di manutenzione software su sistema operativo Windows/Linux, anche in loco laddove non sia possibile un intervento remoto. L’aggiudicatario dovrà inoltre garantire il supporto per le eventuali operazioni di installazione di nuovi dispositivi o di un dispositivo esistente in altra sede.
6.4.1 Quantificazione, rendicontazione ed effort minimo delle attività 4_HW
La modalità di rendicontazione della fornitura 4_HW è mista: a consumo, così come dettagliata nel paragrafo 6.5 ‘Quantificazione, rendicontazione, workflow ed effort minimo delle attività a consumo’, per gli interventi professionali, e piè di lista per l’acquisizione dei dispositivi hardware o di pezzi sostitutivi.
Se si tratta di attività di manutenzione da effettuare in loco il fornitore potrà rivedere la propria stima durante il sopralluogo richiedendo, ove si presentassero costi superiori a quelli preventivati, conferma telefonica a RAS prima di procedere.
Ai fini della rendicontazione e del successivo pagamento, sarà computato:
1. il costo di intervento sul luogo, se necessario, forfettariamente individuato in 80€ + IVA;
2. il costo dei dispositivi o delle parti di ricambio acquisite e rendicontate a pié di lista;
3. il tempo complessivo effettivamente impiegato dal personale del fornitore nel completamento delle attività, con le modalità dettagliate nel paragrafo 6.5 ‘Quantificazione, rendicontazione, workflow ed effort minimo delle attività a consumo’.
Gli interventi a piè di lista potranno essere rendicontati se completati, attivi e funzionanti
e nel rispetto di quanto previsto nel presente Capitolato.
La RAS potrà effettuare richieste di manutenzioni hardware nella misura massima del 5% dell’importo a base d’asta, pari ad € 8’000,00 non soggetti a ribasso.
6.5. Quantificazione, rendicontazione, workflow ed effort minimo delle attività a consumo;
Tutte le attività a consumo sopra descritte saranno quantificate e rendicontate con le modalità descritte in questo paragrafo.
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 SardegnaIT, dell’importo di € 265,00/giorno, costituisce parametro di riferimento per la quantificazione economica degli interventi richiesti da RAS. 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 nei singoli interventi, 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 | 1,00 |
Programmatore senior Drupal | 1,63 |
Analista/Web Architect /Cloud Architect/UX Designer | 1,63 |
Operatore/Software tester | 1,00 |
Project manager | 1.98 |
Grafico | 1,09 |
sistemista | 1,44 |
manutentore HW | 1,44 |
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;
2 h/uomo di grafico;
1 h/uomo di operatore;
è rendicontabile con un effort complessivo di [8 + (3x1,63) + (2x1,09) + (1x1,00)], ovvero di 16,07 h/uomo di Programmatore junior.
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 manager non potranno essere rendicontate in misura superiore all’8% in valore.
Sulla base delle figure professionali coinvolte dovrà essere garantito un effort minimo mensile, ovvero un numero minimo di giorni/uomo che il fornitore si impegna ad erogare su
richiesta di XXX, così come dettagliato nella seguente tabella; si evidenzia che per ciascuna figura professionale devono essere soddisfatti i requisiti professionali minimi definiti dal successivo art. 11. La giornata si intende di 8 ore di lavoro.
figura professionale | Effort minimo (giorni uomo/mese) |
Programmatore junior / Drupal site builder | 15 |
Sistemista / manutentore HW / Programmatore senior Drupal | 12 |
Analista/Web Architect / Cloud Architect / UX Designer | 8 |
Project manager | 4 |
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à, così 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. L’approvazione dell’effort delle attività di analisi (punti 4 e 6) 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 rivelino 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 nei vari ambienti. Nel caso in cui l’attività consista nello sviluppo di software, l’aggiudicatario provvederà per step ai deploy negli ambienti di sviluppo, stage e produzione. Quest’ultimo potrà avvenire solo a seguito di autorizzazione da parte di RAS, a meno di casi di estrema urgenza. L’aggiudicatario potrà richiedere verifiche e chiarimenti intermedi a RAS qualora lo ritenga necessario.
11. RAS – chiusura task. Al termine dell’attività RAS provvederà a verificare la correttezza di quanto realizzato e a chiudere il task. La chiusura del task 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 collaudo a partire dal quale ha inizio il periodo di garanzia di 12 mesi da parte del fornitore.
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à.
Si specifica che se, ai sensi dell’art. 106, comma 11 del D.Lgs 50/2016 ss.mm.ii, l’amministrazione proroga l'esecuzione per il tempo strettamente necessario alla conclusione delle procedure necessarie per l’individuazione del nuovo contraente, l’affidatario è tenuto all’esecuzione delle prestazioni oggetto del contratto agli stessi prezzi, patti e condizioni. Pertanto costituirà parametro per la rendicontazione, 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 sopraindicati.
Anche nel caso in cui l’Amministrazione, a proprio insindacabile giudizio, decidesse di attivare le risorse del sesto quinto, la rendicontazione delle somme dovute avverrà utilizzando le medesime modalità sopra descritte. Pertanto anche in questo caso 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 indicati sopra.
Ai fini della rendicontazione e del successivo pagamento, sarà computato il tempo complessivo effettivamente impiegato dal personale del fornitore nel completamento dei sub- task del singolo intervento, come tracciato sulla piattaforma, entro i limiti dell’effort complessivo indicato nella scheda di attività approvata da RAS. L’unità minima per la rendicontazione è il minuto.
Potranno essere rendicontate a consuntivo le prestazioni relative ai soli interventi positivamente collaudati. Fanno eccezione:
- tutte le attività di analisi, preliminari e di dettaglio, entro l’effort autorizzato da XXX, anche se non dovessero concludersi con la realizzazione della scheda attività come sopra descritta, nei casi in cui l’attività dovesse rivelarsi non fattibile o comunque eccessivamente complessa, rischiosa e/o onerosa;
- tutti i casi in cui il fornitore, in corso d’opera, incontri problemi non dipendenti dalla sua volontà che impediscano il completamento dell’attività (es. correlazione con altri
fornitori, o con altre attività propedeutiche non ancora completate, etc.); questi casi dovranno comunque essere comprovati dal fornitore ed approvati esplicitamente da RAS a suo insindacabile giudizio;
- tutte le attività che, per qualunque motivo e a suo insindacabile giudizio, XXX decida di non portare a termine. A titolo esemplificativo potrebbero essere attività considerate non più utili, o superate da altre attività, o che in corso d’opera si sono rivelate eccessivamente complesse, rischiose o onerose.
Articolo 7. Modalità operative di realizzazione della fornitura
Per l’esecuzione ed il controllo delle forniture richieste, sono di seguito definite le modalità operative di realizzazione e di coordinamento da stabilirsi tra l’Assessorato ed i referenti designati dall’impresa aggiudicataria.
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 e il deposito di pacchetti applicativi per le finalità di cui alla presente fornitura.
L’aggiudicatario si impegna 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;
● verificati, sulla base dei relativi piani di test, prima del loro formale rilascio/consegna, anche ai fini dell’eventuale collaudo;
● 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.
L’impresa aggiudicataria dovrà presentare formalmente a RAS, entro i 15 gg solari
successivi alla stipula del contratto, un Piano Operativo delle Attività (POA) che dovrà specificare, coerentemente con quanto previsto dal presente Capitolato e dalla successiva offerta tecnica presentata:
● Il nominativo degli esperti di dominio individuati dalla società offerente quali responsabili dell’esecuzione delle voci di fornitura ed i nominativi, il ruolo e le competenze degli altri componenti del gruppo di lavoro;
● La metodologia e le modalità organizzative che intende applicare, con particolare riferimento:
- alle procedure ed alle policy della linea 2_SYS che saranno adottate per:
- l’accesso e l’utilizzo dei vari ambienti;
- i sistemi di condivisione dei file delle applicazioni e dei dump dei database;
- le modalità adottate per le operazioni di rilascio, installazione, configurazione e test degli sviluppi e degli aggiornamenti software;
- l’erogazione dei sistemi ed i relativi livelli di servizio, in conformità con i livelli minimi attesi da RAS.
- alle modalità d’uso e di configurazione della piattaforma web di Issue & Project Tracking Jira, 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.
Il POA dovrà essere formalmente approvato da RAS per accettazione dei suoi contenuti. Alla versione approvata dovranno fare riferimento le relazioni di avanzamento lavori
emesse dal fornitore.
XXX potrà concordare con l’impresa eventuali aggiornamenti del piano 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.
Nella realizzazione delle forniture l’impresa aggiudicataria dovrà mantenere un costante coordinamento con RAS.
7.1 Tempi attesi di esecuzione
Di seguito si definiscono le tempistiche di realizzazione attese dalla RAS, misurate in giorni lavorativi.
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 di esecuzione delle 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 la soluzione proposta e/o averne fatto il deploy in un certo ambiente;
- il fornitore, impegnato in un’attività della fornitura 4_HW, è in attesa di reperire i componenti hw necessari alla riparazione, o sono presenti cause di varia natura che impediscono il suo intervento in loco. Tali sospensioni non potranno eccedere di norma i 10 giorni lavorativi salvo comprovati motivi di difficoltà del fornitore indipendenti dalla sua volontà;
- 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.5 ;
- 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.
7.2 Documentazione a corredo
L’aggiudicatario dovrà tenere costantemente aggiornata e rilasciare la seguente documentazione:
● il codice sorgente, ivi inclusi gli eventuali script di configurazione, inizializzazione,
● reimpostazione, ecc. Si specifica che il codice dovrà essere adeguatamente
● documentato;
● la guida di messa in produzione, con indicazione delle procedure da seguire e le,
● eventuali, operazioni di ripristino delle versioni precedenti (rollback);
● il manuale utente in lingua inglese e francese.
Articolo 8. Livelli di servizio (SLA)
Si riportano di seguito i livelli di servizio attesi dalla stazione appaltante.
Indicatore | Definizione | Valori di soglia |
P_MAN | Puntualità nel completamento di tutte le attività previste nella scheda attività del singolo intervento approvata da RAS rispetto alla scadenza concordata nella scheda medesima. | Almeno il 90% dei rilasci entro la scadenza concordata ed il 100% entro 5 giorni lavorativi dalla scadenza concordata. Media rilevata su base bimestrale |
SLA di riferimento per la linea 1_MAN
Indicatore | Definizione | Valori di soglia |
P_SYS | Puntualità nell’evasione degli interventi sistemistici della voce di fornitura 2_SYS | Almeno il 95% degli interventi entro i termini definiti dall’art. 9 del presente Capitolato ed il 100% entro 3 giorni lavorativi dai termini suddetti. Media rilevata su base bimestrale |
SLA di riferimento per gli interventi sistemistici della linea 2_SYS
Indicatore | Definizione | Severità | Valori di soglia |
P_CLD | Disponibilità delle infrastrutture 3_EXT | - | Disponibilità dell’infrastruttura 24x7x365 almeno pari al 99,00%. |
Media rilevata su base annuale
SLA di riferimento per le acquisizioni della linea 3_EXT
P_EFF | Erogazione dell’effort minimo garantito in capitolato (o in sede di offerta se migliorativo) per ogni figura professionale. | - | Effort minimi definiti per le linee 1_MAN, 2_SYS, 4_HW |
SLA di riferimento per l’effort minimo garantito
Indicatore | Definizione | Severità | Valori di soglia |
Bloccante | Almeno il 95% entro 1g (8H) ed il 100% entro 2 giorni lavorativi. Media rilevata nel bimestre | ||
P_COR | Tempo di evasione richieste correttive a garanzia degli interventi realizzati | 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 bypassato 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, etc.
SLA di riferimento per la le richieste correttive in garanzia
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. Corrispettivi e condizioni di fatturazione
I servizi resi saranno rendicontati dal fornitore secondo stati di avanzamento. Potranno essere rendicontate le prestazioni effettuate sulla base degli ordini ricevuti da RAS e nel rispetto di quanto previsto nei paragrafi da 6.1 a 6.4 del presente capitolato, che siano completate, attive e funzionanti. Gli stati di avanzamento matureranno nel momento in cui le attività rendicontabili afferenti alle linee 1_MAN, 2_SYS e 4_HW raggiungeranno un importo complessivo pari ad almeno il 20% dell’importo contrattuale.
Il fornitore potrà provvedere all’emissione di relazioni sullo stato di avanzamento dei lavori (SAL) anche per importi inferiori alla soglia del 20% dell’importo contrattuale, laddove siano trascorsi tre mesi dalla data di esecutività del contratto o dalla precedente relazione di SAL. Potrà essere in tal caso portato a rendicontazione quanto maturato nel periodo di riferimento.
Per ciascuno degli stati di avanzamento definiti, le rispettive relazioni di SAL dovranno riportare come allegati i report delle attività effettuate, al fine di documentare la realizzazione delle forniture associate ai vari ambiti di intervento.
In particolare i SAL dovranno riportare il dettaglio dei task rendicontati, compresa la
quantificazione e la valorizzazione economica delle attività condotte nel periodo di riferimento a seguito degli ordini ricevuti da RAS, come pure i documenti comprovanti i costi da rimborsare a piè di lista sostenuti per le forniture 3_EXT e 4_HW.
La fattura relativa agli stati di avanzamento potrà essere emessa dal fornitore previa approvazione del SAL da parte della stazione appaltante.
Altresì, ai sensi dell’art. 103 c.6 del D.Lgs 50/2016 ss.mm.ii., il pagamento del saldo delle attività della linea 1_MAN potrà avvenire solo a seguito di presentazione da parte del fornitore di idonea fidejussione bancaria o polizza assicurativa irrevocabile, incondizionata ed escutibile a prima richiesta della Stazione Appaltante, pari all'importo della medesima rata di saldo maggiorato del tasso di interesse legale applicato per il periodo intercorrente tra la data di emissione del certificato di collaudo o della verifica di conformità nel caso di appalti di servizi o forniture e l'assunzione del carattere di definitività dei medesimi.
Secondo quanto previsto dal D.Lgs. n° 231/2002 art.4, c.4, le fatture emesse dal Fornitore verranno pagate entro 60 giorni dalla data di presentazione delle fatture relativamente alle quali risulti attestata la regolarità della fornitura.
Ai sensi dell'art. 3 comma 7 della L.136/2010, il fornitore dovrà comunicare gli estremi identificativi del c/c dedicato, anche in via non esclusiva, alle commesse pubbliche nonché le generalità e il CF delle persone delegate ad operare su di esso. Il fornitore dovrà altresì assolvere a tutti gli obblighi previsti dall'art. 3 della L.136/2010 al fine di assicurare la tracciabilità dei movimenti finanziari relativi all’appalto; qualora non assolva a detti obblighi, il contratto si risolverà di diritto ai sensi del comma 8 del medesimo art. 3 della L. 136/2010.
Articolo 10. Penalità e recesso dal contratto
Qualora l’Impresa non rispetti i livelli di servizio sopra definiti, l’Amministrazione potrà applicare delle penali, fatto comunque salvo il risarcimento dell’eventuale maggior danno subito.
Il superamento di uno o più SLA dovrà essere comunicato dall’Amministrazione, ai fini dell’applicazione delle penali, in forma scritta. All’impresa è concesso un termine di 10 giorni
solari per controdedurre in forma scritta; trascorso tale termine, ove non venga addotta alcuna giustificazione oppure questa, a insindacabile giudizio dell’Amministrazione, non venga riconosciuta sufficiente, potrà essere applicata la penale.
La penale potrà essere applicata al verificarsi del mancato raggiungimento dei valori di soglia degli SLA indicati nel precedente articolo. All’interno del valore di soglia non saranno applicate penalità: queste varranno per i soli contenuti eccedenti tale limite. In particolare:
o Mancato raggiungimento SLA P_MAN l’importo delle penali è pari, per ciascun giorno di ritardo nel completamento di tutte le attività previste nella scheda attività del singolo intervento approvata da RAS rispetto alla scadenza concordata, all’uno per mille dell’importo contrattuale; il ritardo è computato a partire dal momento in cui si verifica il mancato raggiungimento dello SLA.
o Mancato raggiungimento SLA P_SYS: l’importo delle penali è pari, per ciascun giorno di ritardo nell’evasione degli interventi sistemistici della voce di fornitura 2_SYS, all’uno per mille dell’importo contrattuale; il ritardo è computato a partire dal momento in cui si verifica il mancato raggiungimento dello SLA.
o Mancato raggiungimento SLA P_CLD: l’importo delle penali è pari, per ciascun decremento dello SLA di un decimo di punto percentuale (0.1%) - o sua frazione - nella disponibilità delle infrastrutture, all’uno per mille dell’importo contrattuale; il ritardo è computato a partire dal momento in cui si verifica il mancato raggiungimento dello SLA.
o Mancato raggiungimento SLA P_EFF: l’importo delle penali è pari, per ciascun giorno uomo richiesto da RAS e non erogato rispetto ai giorni minimi garantiti, quale che sia la figura professionale, all’uno per mille dell’importo contrattuale;
o Mancato raggiungimento SLA P_COR: l’importo delle penali è pari, per ciascun giorno di ritardo nell’evasione delle richieste correttive a garanzia degli interventi realizzati, all’uno per mille dell’importo contrattuale; il ritardo è computato a partire dal momento in cui si verifica il mancato raggiungimento dello SLA.
Gli importi delle penalità, calcolate come sopra specificato, non potranno superare complessivamente il 10% dell’importo contrattuale e saranno trattenuti, di preferenza, sul primo mandato di pagamento utile.
L’Assessorato si riserva la facoltà di recedere dal contratto qualora si determini il superamento degli SLA sopraindicati per più di 5 volte, indipendentemente dalle penalità da applicare e fatta salva ogni tutela e facoltà prevista per legge.
L’Assessorato si riserva inoltre la facoltà di recedere dal contratto qualora uno o più valori di soglia rilevati in corso di realizzazione con riferimento agli SLA sopraindicati, scendano al di sotto del 75%, indipendentemente dalle penalità da applicare e fatta salva ogni tutela e facoltà prevista per legge.
Articolo 11. Competenze, esperienze e qualificazione del team di progetto
La ditta aggiudicataria dovrà dispiegare un team di progetto composto da esperti con competenze, esperienze e qualificazione almeno pari a quelle di seguito indicate.
Per i singoli profili professionali 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. La singola esperienza non potrà essere attinente a più figure professionali.
Saranno computati un’unica volta i periodi nei quali due o più esperienze attestate si sovrappongano temporalmente. Nel caso in cui esse si riferiscano a figure professionali diverse sarà considerata solo una di esse a piena discrezionalità di RAS.
Si riportano di seguito i profili professionali minimi richiesti:
● Programmatore junior/Drupal site builder con almeno 2 anni di esperienza professionale documentata nelle seguenti aree:
o sviluppo su piattaforma open source Drupal;
o sviluppo applicazioni web e mobile su tecnologie javascript/HTML5.
● Programmatore senior/Drupal con almeno 5 anni di esperienza professionale documentata nelle seguenti aree:
o sviluppo su piattaforma open source Drupal;
o sviluppo applicazioni web e mobile su tecnologie javascript/HTML5;
o sviluppo di applicazioni web Java based;
o integrazione applicativa nell’ambito di un ecosistema complesso.
● Analista/Web Architect/Cloud Architect con almeno 5 anni di esperienza documentata nelle seguenti aree:
o raccolta requisiti, analisi e disegno di architetture web;
o raccolta requisiti, analisi e disegno di architetture di architetture cloud.
● Sistemista con almeno 5 anni di esperienza professionale documentata nelle seguenti aree:
o gestione sistemistica di reti e architetture cloud Amazon AWS, nella loro configurazione ed erogazione;
o gestione delle problematiche di sicurezza e di performance, con particolare riferimento a sistemi informatici interoperabili e mutuamente integrati in un ecosistema complesso;
o utilizzo di Container e sistemi di orchestrazione (ad esempio Docker + Kubernetes).
● Manutentore HW con almeno 3 anni di esperienza professionale documentata nelle seguenti aree:
o gestione sistemistica di personal computer e server in ambiente Windows e Linux;
o manutenzione hw di personal computer e server.
● Project manager con almeno 5 anni di esperienza professionale documentata nello specifico ruolo.
Si precisa che l’assenza anche solo di uno dei profili professionali richiesti comporterà la non ammissibilità dell’offerta durante la successiva procedura di RdO sul MEPA.
I requisiti posseduti devono essere documentati dal fornitore, mediante attestazioni redatte singolarmente da ciascuno dei soggetti in conformità al modello che verrà individuato dall’Amministrazione per la successiva fase della procedura di RdO su MEPA, ma che dovrà comunque riportare per ciascuna esperienza lavorativa elencata:
- le date di inizio e fine esperienza dovranno obbligatoriamente essere complete di giorno, mese e anno;
- dovrà essere selezionata un’unica figura professionale alla quale l’esperienza si ritiene attinente;
- dovrà essere selezionata almeno un’area tematica relativa alla figura professionale alla quale l’esperienza si ritiene attinente;
- non dovranno essere selezionate aree tematiche relative a figure professionali diverse da quella prescelta.
La RAS potrà rifiutare, con adeguata motivazione, una o più delle candidature proposte dal fornitore nel caso in cui rilevi la mancanza dei requisiti sopra indicati. Inoltre la RAS potrà richiedere l’esclusione di uno o più prestatori d’opera del fornitore, con adeguata motivazione, qualora se ne rilevi l’inadeguatezza nel corso di realizzazione della fornitura.
Fermo restando che l’effort massimo erogabile mensilmente da ciascun membro del team è pari a 20gg/uomo, una stessa persona può ricoprire più ruoli a patto che sia documentato, per ciascun profilo professionale, il possesso dei requisiti minimi sopra descritti e che ciò sia compatibile con i livelli di effort minimo previsti per ciascuna figura professionale dall’art. 6. A titolo esemplificativo, una persona può ricoprire sia il ruolo di programmatore junior che quello di programmatore senior solo se ha avuto almeno 5 anni di esperienza in ciascun ruolo in periodi temporali separati.
Si precisa inoltre che l’eventuale sostituzione in corso d’opera, a qualunque titolo e per qualunque motivo, di una o più figure professionali tra quelle presentate in sede di offerta,
dovrà essere sottoposta ad approvazione di XXX. Il passaggio di consegna interno al fornitore, dovuto all’avvicendamento di proprie figure professionali, dovrà avvenire a cura del fornitore e senza alcun onere aggiuntivo per RAS.
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 perseguiti dalla Regione.
Articolo 13. Conoscenza delle condizioni e revisione prezzi
L’assunzione dell’appalto di cui al presente capitolato implica da parte dell’Impresa aggiudicataria la conoscenza perfetta non solo di tutte le norme generali e particolari che lo regolano, ma altresì di tutte le condizioni locali, di tutti i fatti e le circostanze che possono influire in generale sulla convenienza di assumere l’appalto.
Resta pertanto convenuto che l’appalto si intenderà assunto dall’Impresa aggiudicataria ad esclusivo suo rischio in base a calcoli di sua convenienza e con implicita rinuncia ad ogni rivalsa per caso fortuito, nonché di qualsiasi altra circostanza che possa verificarsi dopo l’aggiudicazione.
Non è pertanto ammessa alcuna revisione dei prezzi unitari indicati dall’art.6 del presente Capitolato che resteranno fissi ed invariabili.
Il collaudo potrà riguardare la totalità della fornitura e/o, a discrezione
dell’Amministrazione, essere eseguito in corso d’opera su parti della fornitura stessa. Il collaudo sarà effettuato in contraddittorio con il fornitore secondo le modalità che l’Amministrazione riterrà più utili.
Nel caso in cui le operazioni di collaudo ponessero in evidenza errori, difetti o mancanze, a giudizio dell’Amministrazione, l’Impresa assume l’obbligo di eliminarli entro 5 giorni lavorativi.
Il collaudo si intenderà effettuato positivamente dopo che l’Amministrazione avrà riscontrato la rimozione degli errori, difetti o mancanze segnalati. L’esito positivo del collaudo comporta l’accettazione della fornitura da parte della stazione appaltante.
Articolo 15. Divieto di sospensione dei servizi
L’Appaltatore non può sospendere i servizi forniti in seguito a decisione unilaterale, nemmeno nel caso in cui siano in atto controversie con la Stazione Appaltante.
L'eventuale sospensione dei servizi per decisione unilaterale dell’Appaltatore costituisce inadempienza contrattuale e conseguente causa di risoluzione del contratto per colpa.
In tal caso la Stazione Appaltante procederà all’incameramento della garanzia definitiva, fatta comunque salva la facoltà di procedere nei confronti dell’Appaltatore per tutti gli oneri conseguenti e derivanti dalla risoluzione contrattuale, compresi i maggiori oneri contrattuali eventualmente sostenuti dalla Stazione Appaltante e conseguenti a quelli derivanti dal nuovo rapporto contrattuale.
Articolo 16. Esonero responsabilità
L’Assessorato è esonerato da qualsiasi responsabilità derivante da rapporti instaurati a qualsiasi titolo dal fornitore con terzi in dipendenza delle attività connesse con l’espletamento del presente appalto.
Il fornitore garantisce inoltre la committenza che nell’ambito della fornitura non sarà
violato alcun diritto di terzi (essendo compresi, a titolo esemplificativo e non esaustivo diritti d’autore, diritti su segni distintivi, diritti di proprietà, etc) e si impegna a manlevare e tenere indenne la RAS da qualsivoglia eventuale pretesa di terzi al riguardo.