Contract
RDO aperta per la fornitura di un software e dei servizi necessari per la realizzazione del bene CitizenScience nell’ambito del progetto LifeWatchPLUS PIR01_00028 – Importo complessivo 176.000,00 €
CUI 80054330586201900677
CIG 8904600461
CUP B67E19000030007 CPV: 48810000-9
CAPITOLATO TECNICO
1 Premessa
Il presente appalto è disposto dalla Stazione Appaltante Dipartimento Scienze del Sistema Terra e Tecnologie per l'Ambiente – CNR del Consiglio Nazionale delle Ricerche (nel seguito, per brevità, Stazione Appaltante), sede di Roma, nell’ambito del Progetto “LifeWatchPLUS”.
1.1 Contesto Operativo
LifeWatch è un’infrastruttura europea di eScience (e-Infrastructure) per la ricerca su biodiversità e ecosistemi, istituita dall’UE il 17/03/2017, come Consorzio Europeo di Infrastruttura di Ricerca (LifeWatch XXXX). Fa parte dei landmark dell’area Ambiente presenti nella roadmap di ESFRI, ed occupa una nicchia ben definita tra le infrastrutture del settore, unica infrastruttura di eScience distribuita a concentrarsi sullo studio della biodiversità e degli ecosistemi. In quanto tale, LifeWatch XXXX costruisce i suoi ambienti e laboratori virtuali di ricerca (VRE) con una combinazione di tecnologia digitale, dati e risorse computazionali, e comunicazione a supporto del lavoro e della ricerca collaborativi. Pertanto, questi costituiscono gli strumenti e gli apparati di ricerca che LifeWatch XXXX sta implementando e rendendo operativi sul web per i suoi utenti. Sostenendo reperibilità, accessibilità, interoperabilità e riutilizzo dei dati già raccolti, LifeWatch XXXX ha un impatto positivo sia sull'efficienza complessiva del finanziamento della ricerca, sia sulla scoperta di settori della conoscenza con informazioni di base carenti e per i quali è necessaria una nuova e più intensa raccolta di dati. Come ESFRI distribuita, LifeWatch XXXX ha un hub centrale, distribuito tra Spagna, Italia e Paesi Bassi, e Nodi Tematici Nazionali. Ospitando il Service Centre, che, come componente dell’hub centrale, è l’unico punto di accesso per gli utenti dell'infrastruttura, l'Italia ha un ruolo di primo piano in LifeWatch XXXX, cui contribuisce con il Nodo Tematico Nazionale LifeWatch ITA.
L'ampliamento e l'approfondimento delle conoscenze attuali sull’organizzazione della biodiversità e sulla salute degli ecosistemi sono essenziali per affrontare le principali sfide ambientali e sociali, quali: conservazione di biodiversità ed ecosistemi, sfruttamento delle risorse della biosfera, riscaldamento e cambiamenti globali, sviluppo sostenibile. Negli ultimi decenni, progetti finanziati dall'UE, reti di osservatori europei, sistemi di osservazione della Terra, compresi sensori in situ e satellitari, infrastrutture di ricerca, organizzazioni e iniziative su scala mondiale hanno prodotto e producono dati sulla biodiversità e sugli ecosistemi ad una velocità e frequenza senza precedenti, con un potenziale d’uso per la conservazione di hotspot di particolare valore (Xxxxxxx et al., 2018, Rapporti scientifici 8). Tuttavia, le tecnologie digitali macchina-macchina per la gestione e l'analisi dei dati non sono sufficientemente avanzate da consentire uno sfruttamento pienamente redditizio di big data ed approfondire la nostra conoscenza della biodiversità e l'organizzazione e conservazione degli ecosistemi.
2 Descrizione della fornitura oggetto dell’appalto
Il presente appalto ha per oggetto la fornitura del software CitizenScience. La suddetta fornitura andrà ad estendere i domini di applicazione dell’infrastruttura LifeWatch, ed include tutti i beni e servizi necessari alla realizzazione e messa in opera del software CitizenScience.
Le caratteristiche indicate al successivo paragrafo 2.1 “Caratteristiche tecniche minime obbligatorie” identificano i requisiti tecnici minimi che il sistema oggetto dell’appalto deve possedere a pena di esclusione. Il mancato “possesso” o il mancato raggiungimento anche di uno solo dei requisiti di seguito indicati comporterà l’esclusione dalla gara. È facoltà del concorrente inserire all’interno della Relazione Tecnica, oltre a tutte le informazioni che illustrano compiutamente la fornitura offerta, la disponibilità di eventuale documentazione integrativa e/o accessoria.
2.1 Caratteristiche tecniche minime obbligatorie a pena di esclusione
Si evidenziano le caratteristiche tecniche minime obbligatorie che devono essere rispettate a pena di esclusione nella stesura della relazione tecnica:
● la progettazione esecutiva al fine di definire in dettaglio i requisiti del sistema da realizzare: Adozione di una metodologia di progettazione e di un linguaggio/notazione di modellazione standard per l’ingegneria del software (es. UML, BPMN);
● la realizzazione della piattaforma applicativa:
Sviluppo di una piattaforma applicativa multifunzione che faciliti il coinvolgimento dei cittadini in attività di citizen science;
● l’integrazione della piattaforma applicativa con le altre componenti dell’infrastruttura: Realizzazione di un livello di integrazione machine-to-machine;
● la produzione della documentazione tecnica di architettura e del codice sorgente:
Produzione di un documento di progetto per ogni modulo e codice sorgente commentato in dettaglio;
● i servizi di assistenza, formazione e messa in esercizio:
II servizio deve prevedere la disponibilità in tempo reale dalle ore 9 alle ore 18, dal lunedì al venerdì, escluse le festività, sia telefonica che tramite e-mail. L’attività di formazione deve prevedere almeno l’erogazione di n. 2 corsi di formazione con le caratteristiche dettagliate nei paragrafi successivi.
Tutti i componenti dei servizi dovranno essere dimensionati al fine del raggiungimento degli obiettivi di progetto, secondo stime numeriche e valutazioni effettuate dall’Operatore Economico affinché l’intera attuazione del progetto stesso ed il suo mantenimento funzionale, per l’intero periodo di aspettativa di vita operativa del bene, venga effettuato senza alcun onere aggiuntivo a carico dell’Amministrazione e senza necessità di acquisizione di ulteriori licenze o sottoscrizione di contratti di fornitura e servizi con altri soggetti.
2.2 Ulteriori elementi obbligatori della fornitura a pena di esclusione
La fornitura dovrà comprendere le seguenti prestazioni:
a) consegna ed installazione da remoto presso il data centre dell’Istituto di Nanotecnologia del Consiglio Nazionale delle Ricerche, X.X. Xxxxx-Xxxxxxxxx xx 0.0, 00000 Xxxxx, Xxxxxx nel rispetto della vigente normativa in materia;
b) test di accettazione/verifica di conformità da remoto presso il luogo di consegna ed installazione, secondo procedure concordate con la Stazione Appaltante, che comprenda una verifica di conformità tecnica e funzionale. Si ritiene necessario eseguire un adeguato e approfondito test di accettazione a cura del personale CNR in collaborazione con il personale dell’Operatore economico aggiudicatario e di porre in essere tutti gli atti necessari per verificare le specifiche tecniche della fornitura dichiarate dall’Aggiudicatario e comprese nelle clausole contrattuali;
c) garanzia a copertura totale, assistenza tecnica, manutenzione ordinaria e manutenzione straordinaria di almeno 12 mesi a partire dall’emissione del certificato di verifica di conformità, con interventi da remoto quando applicabile, entro 5 giorni lavorativi dal ricevimento della richiesta. Nell’offerta dovrà essere esplicitata con chiarezza la validità della garanzia per l’Italia.
2.3 Caratteristiche tecniche e/o elementi opzionali della fornitura
Saranno valutate nell’ambito dell’offerta le seguenti componenti e funzionalità opzionali aggiuntive rispetto a quanto previsto dalle caratteristiche minime descritte nel presente capitolato:
- manutenzione evolutiva della piattaforma sviluppata per tutta la durata del contratto;
- estensione del periodo di garanzia;
- ulteriori giornate aggiuntive di training da remoto con personale qualificato.
Per le modalità di valutazione di queste componenti dell’offerta tecnica si rimanda al disciplinare di gara.
3 Piano di Progetto
La durata complessiva del progetto è di mesi 8 dalla firma del contratto e comunque entro e non oltre il 24 agosto 2022. Sono previsti ulteriori 12 mesi, decorrenti dalla data del verbale di conformità, per attività di assistenza tecnica e manutenzione. Il progetto prevederà il rilascio della piattaforma applicativa e delle componenti aggiuntive in momenti diversi:
○ sezione dedicata alle conoscenze di base sulla citizen science, le sue potenzialità e le sue applicazioni;
○ sezione dedicata alle best practices e ai tutorial sullo sviluppo e la gestione di attività di
citizen science;
○ sezione dedicata alle Q&A sulla citizen science che includa un BOT di risposta, capace di soddisfare le richieste più comuni senza l’intervento di un operatore;
○ sezione dedicata alla catalogazione di progetti sia esistenti che nuovi di citizen science con un webGIS Open Source per la visualizzazione delle iniziative di Citizen Science;
○ strumento per la creazione di siti per nuovi progetti di citizen science;
○ WebApp personalizzabile da parte degli utenti, utilizzabile in qualsiasi attività di citizen science che preveda la raccolta di segnalazioni georiferite;
○ sistema di gestione, validazione e verifica delle segnalazioni raccolte con la WebApp;
○ integrazione tra le varie componenti e i vari servizi di LifeWatch.
3.1 Pianificazione del progetto
Le attività necessarie al raggiungimento dell’obiettivo previsto nell’oggetto della fornitura si articolano nelle seguenti 4 fasi.
3.1.1 Architettura del Sistema
L’obiettivo risiede nell’elaborazione delle specifiche tecniche e funzionali dell’architettura dell’ambiente, derivandole dai bisogni espressi dall’utenza, dalle soluzioni tecnologiche disponibili sul mercato e dalle soluzioni tecnologiche risultanti dallo stato dell’arte della ricerca nelle tecnologie del software, rispettando le linee guida sia architetturali che relative al disegno dell’Information Architecture specificate nella sezione corrispondente.
Si richiede di sviluppare le seguenti attività:
● la definizione dei requisiti utente;
● l’analisi delle soluzioni tecnologiche già disponibili sul mercato o nell’ambito della ricerca;
● la definizione delle specifiche funzionali di ogni sezione della piattaforma;
● la definizione delle specifiche funzionali del back-end della piattaforma software;
● la predisposizione delle specifiche architetturali dell’ambiente integrato.
Alla fine della fase saranno conseguiti i seguenti risultati:
● rapporto sui requisiti utente;
● specifiche funzionali di ogni singola sezione della piattaforma “CitizenScience”;
● specifiche tecniche e architetturali del sistema “CitizenScience”.
3.1.2 Sviluppo dell’Applicazione
L’obiettivo consiste nella completa realizzazione, sperimentazione e validazione della piattaforma applicativa “CitizenScience” e delle componenti aggiuntive, secondo le specifiche e le modalità definite nella fase precedente.
In questa fase si richiede di sviluppare le seguenti attività:
● setup dell’infrastruttura tecnologica di sviluppo applicativo e di comunicazione;
● progettazione di dettaglio e sviluppo di ogni sezione e modulo della piattaforma software;
● progettazione di dettaglio e sviluppo del backend della piattaforma software;
● progettazione di dettaglio e sviluppo delle possibili interazioni tra il sistema sviluppato e i vari servizi di LifeWatch.
Alla fine della fase si dovranno conseguire i seguenti risultati:
● documento di progetto comprendente ogni sezione e modulo software;
● sistema “CitizenScience”, composto da un’infrastruttura software e dal complesso dei servizi previsti dalla fornitura;
● integrazione del sistema con i servizi di LifeWatch;
● ambiente di sviluppo. In particolare l’Aggiudicatario dovrà rilasciare l’ambiente di sviluppo configurato e tutti i codici sorgente prodotti corredati da adeguata documentazione.
3.1.3 Fase di test
L’obiettivo consiste nell’esecuzione di un piano di test della piattaforma fornita. In questa fase si richiede di sviluppare le seguenti attività:
● individuazione del campione di utenza pilota di accesso ai servizi;
● formazione e addestramento dei soggetti coinvolti nella sperimentazione circa l’uso dei servizi e la gestione e manutenzione dell’ambiente prodotto;
● erogazione del servizio “CitizenScience”;
● valutazione dei risultati.
Alla fine saranno conseguiti i seguenti risultati:
● piano di erogazione/gestione del servizio;
● rapporto di validazione e valutazione dei risultati. In particolare l’Aggiudicatario dovrà rilasciare alla Stazione Appaltante l’ambiente di testing, tutti i test di unità prodotti, tutto lo “scaffolding” di test di sistema.
3.1.4 Rilascio
L’obiettivo della fase consiste nell’erogazione della piattaforma “CitizenScience”. L’erogazione dovrà esser garantita in due istanze del portale: una relativa al Network di LifeWatch Italia e l’altra al Network Europeo di LifeWatch XXXX.
In questa fase saranno condotte le seguenti attività:
● installazione e configurazione dei sistemi presso il Data Centre del progetto LifeWatchPLUS (anche su server di replica – test di ripristino);
● rilascio del software e di manuali operativi utili alle operazioni di installazione e configurazione, ripristino e gestione dei differenti moduli e servizi;
● collaudo del software: tale attività sarà accompagnata da un piano di collaudo strutturato in una sezione generale, nella quale verranno elencate le varie componenti del sistema da collaudare unitamente alla strategia di collaudo ed in varie parti specifiche (una per componente) con le singole attività, tecniche, strumenti di collaudo.
3.1.5 Schedulazione temporale delle fasi
L’azienda dovrà rispettare almeno le seguenti scadenze:
# Fase | #Task | M1 | M2 | M3 | M4 | M 5 | M 6 | M 7 | M 8 |
1 | Pianificazione del progetto | X | |||||||
2 | Sezione dedicata alle conoscenze di base sulla citizen science | X | X | X | |||||
3 | Sezione dedicata alle best practices e ai tutorial | X | X | X | |||||
4 | Sezione dedicata alle Q&A sulla citizen science | X | X | X | X | ||||
5 | Sezione dedicata alla catalogazione di progetti sia esistenti che nuovi di citizen science con un webGIS Open Source per la visualizzazione delle iniziative di Citizen Science | X | X | X | X | ||||
6 | Strumento per la creazione di siti per nuovi progetti di citizen science | X | X | X | |||||
7 | WebApp per la raccolta di segnalazioni georiferite e sistema di gestione, validazione e verifica delle segnalazioni raccolte | X | X | X | X | ||||
8 | Sistema di gestione, validazione e verifica delle segnalazioni raccolte con la WebApp | X | X | X | X | ||||
9 | Integrazione tra le varie componenti e i vari servizi di LifeWatch | X | X | X | |||||
10 | Rilascio | X | X | ||||||
11 | Formazione | X | X |
4 Caratteristiche tecnico/applicative del sistema richiesto
Premesso che l’architettura definitiva del prodotto “CitizenScience”, dei suoi servizi e funzionalità verrà definita a seguito dell'analisi di dettaglio e sarà il risultato delle attività di analisi e disegno previste dal piano di lavoro, questo paragrafo descrive in sintesi le principali sezioni e moduli che “CitizenScience” dovrà offrire agli stakeholder. In particolare per ciascuna sezione e modulo si descriveranno le principali caratteristiche e macro funzionalità.
L’architettura ad alto livello del bene “CitizenScience” è presentata in figura 1.
Figura 1. Architettura CitizenScience
“CitizenScience” rappresenterà il sistema di supporto per la Citizen Science dell’Infrastruttura LifeWatch e integrerà una serie di sezioni e strumenti utili per il coinvolgimento dei cittadini in attività di citizen science e lo sviluppo di nuove attività sviluppate interamente dai cittadini: dall’editing dei progetti, alla loro catalogazione, pubblicazione e ricerca, dalla raccolta di segnalazioni alla loro gestione e validazione, ecc.
La soluzione individuata per l'attuazione dell'infrastruttura telematica alla base del progetto “CitizenScience”, oltre a soddisfare le esigenze applicative indicate già in fase progettuale, dovrà essere impostata nel rispetto dei principi di modularità, estendibilità, scalabilità e integrazione applicativa:
• modularità: la modularità della soluzione è data da un'architettura aperta in cui le responsabilità e le interfacce di ciascun componente sono chiaramente identificate, e dove, nel rispetto di tali responsabilità ed interfacce, i componenti possono essere sostituiti singolarmente con soluzioni equivalenti, garantendo così la necessaria flessibilità al cliente;
• estendibilità: intesa sia dal punto di vista delle funzionalità da offrire agli utenti e sia dal punto di vista degli strumenti di gestione. Nuovi servizi e nuove entità potranno essere aggiunti in modo da integrarsi senza sforzo con l'architettura esistente;
• scalabilità: il sistema realizzato sarà in grado di scalare all'aumentare del traffico in termini di numero di utenti che visiteranno la piattaforma.
• integrazione applicativa: l’integrazione applicativa tra la piattaforma “CitizenScience” e le applicazioni di terze parti dovrà esser resa possibile attraverso la disponibilità e l’utilizzo di API e l’utilizzo (e l’estensione dove necessario) di modelli per metadati già sviluppati e testati nell’ambito della Citizen Science (es. il Public Participation in Scientific Research Core metadata Model – PPSR Core, in particolare il Project Metadata Model, sviluppato dalla Citizen Science Association e già utilizzato in piattaforme quali XxxXxxxxxx.xxx ed Atlas of Living Australia – BioCollect ed esteso per l’integrazione nelle piattaforme XX-Xxxxxxx.Xxxxxxx e Measuring Impact of Citizen Science – MICS).
4.1 Caratteristiche della sezione dedicata alle conoscenze di base sulla citizen science
La sezione in oggetto dovrà prevedere strumenti come video tutorial, documenti, lezioni online, moduli di e-learning, ecc., che diano ai cittadini tutte le informazioni necessarie per comprendere appieno la citizen science, e che quindi consenta loro di partecipare consapevolmente a progetti esistenti, o di progettare e sviluppare, usando le risorse e gli strumenti di questo portale, nuovi progetti in cui coinvolgere altri cittadini. La panoramica fornita ai cittadini tramite questa sezione deve essere il più completa possibile, spaziando dalla storia della citizen science, alle sue più recenti applicazioni in tutti i campi, con particolare focus a quello della biodiversità e della sua tutela. Tutte le risorse di questa sezione dovranno essere sviluppate con la collaborazione di esperti del settore.
4.2 Caratteristiche della sezione dedicata alle best practices e tutorial sullo sviluppo e la gestione di attività di citizen science
La sezione in oggetto dovrà contenere materiali sviluppati in precedenti progetti di citizen science in Italia e nel resto del mondo, organizzati secondo una logica di complessità e di tematica, in formato di documenti o multimedia. Lo scopo della sezione è quello di approfondire le conoscenze acquisite nella sezione conoscenze di base, e quindi di permettere una consapevole gestione di iniziative di citizen science. L’esperienza acquisita da iniziative esistenti, infatti, può essere usata per evitare di ripetere errori, e per replicare azioni virtuose, che si siano dimostrate particolarmente efficaci. L’organizzazione per tematica consentirà una ricerca facilitata da parte dei partecipanti, che all’occorrenza potranno anche ripescare esperienze in tematiche diverse per cercare di replicarle. In questa sezione sarà fondamentale anche consentire il caricamento di nuovi materiali, al fine di permettere ai partecipanti di arricchire l’archivio, e quindi di fornire ulteriori conoscenze a chi vorrà partecipare in futuro. La sezione potrà contenere tutorial didattici che dovranno risiedere fisicamente sulla Piattaforma di Training di LifeWatch e grazie alle interfacce machine-to-machine essere referenziate all’interno della stessa. Tale sezione può esser vista come una particolare sezione del catalogo ragionato descritto al successivo punto 4.4.
4.3 Caratteristiche della sezione dedicata alle Q&A sulla citizen science
Allo stato dell’arte LifeWatch possiede già un Help Desk realizzato su piattaforma Wordpress, con funzioni di knowledge base e F.A.Q. La sezione richiesta in oggetto dovrebbe essere aperta alle domande dei cittadini che volessero approfondire le conoscenze acquisite nelle prime due sezioni (4.1 e 4.2), andando ad utilizzare gli strumenti già presenti nel LifeWatch Help Desk sfruttando le interfacce machine-to- machine ed estendendole laddove necessario. Un importante valore aggiunto sarebbe dato dallo sviluppo di un BOT di risposta, capace di soddisfare le richieste più comuni senza l’intervento di un operatore. Lo sviluppo di tale strumento dovrebbe essere tale da garantirne una “crescita” nel tempo, con acquisizione della capacità di rispondere a nuove domande, qualora alcune richieste non previste nella programmazione originale divenissero frequenti. Questa sezione dovrebbe anche dare la possibilità di interagire con un operatore, anche se non in tempo reale.
4.4 Caratteristiche della sezione dedicata alla catalogazione di progetti sia esistenti che nuovi di citizen science con un webGIS Open Source per la visualizzazione delle iniziative di Citizen Science
Il servizio richiesto è quello di implementare un catalogo ragionato delle iniziative di Citizen Science esistenti e nuove. Dovrà esser definito un set di metadati per la catalogazione dei progetti (in accordo con la stazione appaltante) e diversi strumenti per la discovery e la fruizione delle iniziative. Oltre alla classica
vista ad elenco ordinabile per differenti tipologie di parametri (es. temporale, spaziale, tematica, buona prassi, ecc.) è richiesta una vista spaziale delle iniziative basata su un sistema G.I.S. In base ad una selezione di prossimità geografica (tipo xxxxx://xxx.xxxxxxxxxxxxx.xxx) utilizzando gli strumenti GIS messi a disposizione dall’architettura LifeWatch, arricchiti dalle interfacce per il dominio specifico. All’utente basterà disegnare un poligono sulla mappa e il sistema estrarrà tutti i progetti, le campagne di segnalazione e i materiali che insistono sulla porzione di territorio selezionata. Tutte le strutture di fruizione dovranno consentire ai cittadini di scegliere se partecipare a iniziative in atto, o dare la possibilità di svilupparne di nuove.
Caratteristiche dello strumento per la creazione di nuovi progetti di citizen science ll software in oggetto deve essere in grado di offrire agli utenti che lo desiderino di proporre un nuovo progetto di citizen science e di creare nella piattaforma di LifeWatch un sito web per il progetto stesso. Tuttavia, questo processo non deve essere indipendente da una valutazione da parte del comitato scientifico di LifeWatch. Di conseguenza, l’utente che volesse proporre un nuovo progetto, dovrebbe avere a sua disposizione un sistema di invio di una proposta, avere un continuo feedback sulla sua valutazione, che dovrà essere fatta alla stregua della revisione di un lavoro scientifico, da parte di un gruppo di esperti (ad esempio afferenti alla Joint Research Unit di LifeWatch Italia). Il gruppo di esperti farà una prima revisione, che prevederà un rifiuto, una richiesta di modifiche (e quindi un’ulteriore revisione all’invio delle modifiche richieste), o una accettazione. Una volta accettata la proposta, il proponente avrà a disposizione uno strumento per la creazione della pagina Web dell’iniziativa, in cui includere contenuti esistenti nella sezione 4.1 del portale, i dettagli del progetto, e ogni altro contenuto esterno necessario. Inoltre, avrà accesso a tutti gli altri strumenti e servizi dell’infrastruttura LifeWatch, e in particolare alla WebApp customizzabile di cui al punto 4.5.
4.5 Caratteristiche della WebApp customizzabile per la raccolta di segnalazioni georiferite
La WebApp in oggetto dovrà consentire l’invio di segnalazioni georiferite sfruttando il GPS del device su cui viene usata e dovrà essere personalizzabile da parte degli utenti che gestiscono un progetto di citizen science sviluppato usando gli strumenti del portale come dal punto 4.4. Inoltre la WebApp dovrà garantire l’usabilità tramite qualsiasi Web Browser. L’interfaccia deve riportare il logo di LifeWatch (a seconda dell’istanza LifeWatch Italia o LifeWatch XXXX) e eventualmente il logo dell’iniziativa sviluppata dai cittadini, se disponibile. Deve consentire l’invio delle segnalazioni con un set minimo di metadati che dovrà contenere data e ora, coordinate geografiche e loro margine di incertezza, come stimato dal dispositivo in uso, oltre a ogni altro dato incluso nell’interfaccia di segnalazione customizzata ad hoc. Questa dovrà essere appunto customizzabile scegliendo quali e quanti campi includere (fino a un massimo di 50). I campi dovranno essere scelti tra un pool pre-definito (es. il Dataset Metadata Model ed il Observation Metadata Model del PPSR-Core) grazie al contributo di esperti nel settore e considerando quelli già in uso nella piattaforma BE-XXXXX. Inoltre, i creatori di iniziative di citizen science potranno aggiungere fino a un massimo di 5 campi testuali completamente nuovi, specifici delle loro attività. La WebApp dovrà anche essere in grado di lavorare almeno parzialmente offline, quando le attività di segnalazione dovessero svolgersi in ambienti dove la connessione mobile è limitata. I dati raccolti saranno memorizzati e catalogati tramite l’uso di opportune interfacce REST nel sistema di gestione, verifica e validazione descritto di seguito.
4.6 Caratteristiche del sistema di gestione, validazione e verifica delle segnalazioni raccolte
Il sistema in oggetto dovrà garantire la gestione, validazione e verifica dei dati raccolti tramite la WebApp.
Il servizio richiesto è quello di implementare un processo di verifica dei dati che seguirà uno di tre possibili protocolli: crowdsourced, expert, o misto. Il primo protocollo prevede che la verifica delle segnalazioni sia fatta da altri citizen scientist. In questo caso, tutti i partecipanti a un progetto di citizen science possono vedere le segnalazioni raccolte dagli altri partecipanti a quel progetto, e verificarne la correttezza, normalmente controllando che l’immagine dell’oggetto/organismo segnalato corrisponda al suo nome. Il secondo protocollo prevede invece che la verifica delle segnalazioni sia affidata a esperti (superusers), che sono i soli a vedere le segnalazioni non ancora verificate di tutti gli altri utenti, e che possono verificarle. Solo una volta che un esperto ha verificato una segnalazione, questa è visibile a tutti gli altri. Il terzo protocollo prevede che sia i citizen scientist che gli esperti possano verificare le segnalazioni, ma in questo caso il “peso” dei pareri è diverso. Il processo di validazione delle segnalazioni invece dovrebbe essere automatizzato e segnalazioni senza i necessari metadati dovrebbero essere rigettate a priori, senza essere verificate. Tra i metadati, l’obbligatorietà della foto deve essere decisa dal coordinatore della specifica attività.
Come già introdotto nel paragrafo 4, il bene “CitizenScience” è parte della più complessa architettura dell’Infrastruttura di Ricerca LifeWatch illustrata ad alto livello nella figura 2. Una volta validate le segnalazioni queste, a discrezione dell’amministratore, dovranno poter confluire nella base dati del prodotto BE-XXXXX per esser rese disponibili sul Portale Dati di LifeWatch XXXX e nei laboratori Virtuali dell’Infrastruttura di ricerca. Gli scienziati potranno, quindi, utilizzarle con i servizi di analisi e modellistica per comparale con gli altri dati scientifici dei gruppi di ricerca internazionali. Il formato di interscambio dei dati con il bene BE-XXXXX e le speifiche dell’interfaccia di comunicazione verranno resi noti nella prima fase di pianificazione del progetto.
Figura 2. Architettura LifeWatch
4.7 Caratteristiche dell’Integrazione tra le varie componenti e i vari servizi di LifeWatch
È stata più volte evidenziata la necessità di riuso ed integrazione dei moduli esistenti all’interno dell’architettura LifeWatch, questo per evitare ridondanza, appesantire i processi di manutenzione del software e presentare all’utente un ambiente quanto più omogeneo e user-friendly possibile. I prodotti richiesti dovranno esser quindi integrati su tutti i livelli con i prodotti esistenti. In particolare considerando anche gli strumenti di accesso e di sicurezza (Single-sign-on, Accountability, Access Policies, Sicurezza, ecc.).
5 Caratteristiche di dettaglio del software applicativo
5.1 Proposta grafica e organizzazione dei contenuti
Nella progettazione della veste grafica della piattaforma “CitizenScience” si dovranno prendere in considerazione almeno i seguenti punti:
- la progettazione grafica dovrà tener conto delle indicazioni contenute nel manuale di immagine coordinata di LifeWatch XXXX disponibile tra i documenti allegati;
- è requisito indispensabile prevedere che nella strutturazione delle pagine nelle diverse sezioni e nei diversi livelli delle applicazioni web oggetto della fornitura possano essere adottati layout diversificati, pur nel rispetto dei principi di uniformità di immagine, capaci di assicurare la riconoscibilità delle diverse applicazioni come unità contenutistiche indipendenti ed al contempo l’associazione di queste con il marchio e l’ambiente LifeWatch.
Ogni aspetto grafico dovrà comunque essere approvato dal responsabile dell’infrastruttura LifeWatch per la comunicazione e la grafica.
6 Servizi di avviamento ed esercizio
6.1 Manutenzione ed assistenza
L'avviamento del sistema informativo gestionale non è sufficiente a garantire il suo mantenimento e la sua produttività; per questo, l'attività di assistenza post-avviamento, che deve essere assicurata per un anno dopo il collaudo, rappresenta il costante monitoraggio della funzionalità dello stesso. Tali competenze verranno trasferite dall’Aggiudicatario alle risorse interne del CNR e allo staff di LifeWatch, consentendo agli stessi di poter analizzare, governare e soprattutto di poter verificare i risultati finali in termini quantitativi e qualitativi. Il servizio di assistenza on-site dovrà garantire le prestazioni di seguito descritte:
• iI servizio deve prevedere l'assistenza in tempo reale (dalle ore 9 alle ore 18, dal lunedì al venerdì, escluse le festività) sia telefonica che tramite e-mail;
• assistenza telefonica per l'installazione di nuove release di aggiornamenti e correzioni rese disponibili dal Fornitore e dalle case produttrici coinvolte per i moduli software oggetto della presente fornitura;
• assistenza telefonica e/o in collegamento remoto al sistema per la soluzione di eventuali inconvenienti e difetti inerenti i moduli software oggetto della presente fornitura;
• risoluzione dei problemi "bloccanti" (interruzione del servizio) entro 12 ore decorrenti dal momento della segnalazione con servizio h24 7/7;
• risoluzione dei problemi "severi" (per cui il servizio è raggiungibile ma con compnenti malfunzionanti) entro 48 ore lavorative decorrenti dal momento della segnalazione;
• risoluzione dei problemi "minori" entro 72 ore lavorative decorrenti dal momento della segnalazione;
• sviluppo di correzioni temporanee o soluzioni alternative;
• forniture degli aggiornamenti e/o nuove release disponibili;
• eliminazione di errori, anomalie e malfunzionamenti di qualunque tipo che dovessero evidenziarsi;
• assistenza telefonica per problemi di utilizzo e installazione inerenti i moduli software oggetto della presente fornitura.
6.2 Formazione
L’Aggiudicatario dovrà garantire un’attività formativa al personale informatico dell'Ente o dell’Infrastruttura LifeWatch, con percorsi differenti a seconda degli obiettivi stabiliti, per raggiungere l'operatività completa e diversificata del personale coinvolto.
L'alternanza di sessioni teoriche con quelle pratiche servirà alla verifica immediata di quanto appreso dalle singole risorse e dal servizio erogato. Il Fornitore dovrà dare tutto il materiale didattico (ivi inclusi i manuali utente e manuale tecnico della piattaforma sviluppata) e strumentale occorrente per la perfetta riuscita dei corsi. Il personale docente dovrà essere di solida e documentata esperienza nell'insegnamento delle materie oggetto dei corsi stessi.
Si richiede, pertanto, l’erogazione di n. 2 Corsi di formazione da remoto con le caratteristiche di seguito riportate:
1. corso di formazione destinato al personale utente della piattaforma applicativa “CitizenScience” per l'utilizzo dei servizi sviluppati. Il corso, della durata di almeno 12 ore da erogare in 3 giorni lavorativi consecutivi e rivolto a circa 20 persone con competenze informatiche e coinvolte nel progetto, deve illustrare le funzionalità della piattaforma e deve mettere in grado l'utente di poter svolgere autonomamente la propria attività;
2. Corso di formazione per l’Amministrazione della piattaforma applicativa “CitizenScience” che deve consentire al personale tecnico dell'Ente e dell’infrastruttura LifeWatch di rendersi autonomo nella funzionalità di amministrazione della piattaforma; sarà rivolto a 5 tecnici informatici e avrà una durata di almeno 40 ore distribuite su 5 giorni lavorativi consecutivi.
7 Termini e luogo di consegna ed installazione
I termini di consegna ed installazione dei beni e servizi, sono da intendersi in giorni naturali e consecutivi decorrenti dal giorno successivo alla sottoscrizione del contratto. Il rilascio di tutti i servizi con la messa in produzione e la formazione dovrà avvenire entro la fine del nono mese.
La consegna e l’installazione dei beni e servizi della fornitura dovrà essere effettuata presso l’indirizzo indicato in tabella, in accordo con il Direttore esecutivo del Contratto:
# Prodotto Luogo di consegna e installazione | |
CitizenScience | Istituto di Nanotecnologia del Consiglio Nazionale delle Ricerche, X.X. Xxxxx- Xxxxxxxxx xx 0.0, 00000 Xxxxx, Xxxxxx, codice NUTS ITF45 |
8 Avvio e termine dell’esecuzione del contratto
Il Direttore dell’esecuzione del contratto (DEC), sulla base delle disposizioni del Responsabile Unico del Procedimento (RUP), dopo che il contratto è divenuto efficace, dà avvio all’esecuzione della prestazione, fornendo all’Aggiudicatario tutte le istruzioni e direttive necessarie e redigendo, laddove sia indispensabile in relazione alla natura e al luogo di esecuzione delle prestazioni, apposito verbale come meglio disciplinato all’Art. 19 del DM n° 49 del 7 marzo 2018 del Ministero delle Infrastrutture e dei Trasporti. In tutti i casi in cui ricorrano circostanze speciali che impediscano in via temporanea l’esecuzione dell’appalto si applicano le disposizioni di cui all’Art. 107 del D. Lgs. 50/2016 e s.m.i. e all’Art. 23 del già citato DM. L’Aggiudicatario è
tenuto a comunicare alla Stazione Appaltante l’intervenuta ultimazione delle prestazioni contrattuali. Il DEC, entro 5 giorni da tale comunicazione, effettua, in contradditorio con l’Aggiudicatario medesimo, i necessari accertamenti e trasmette al RUP, entro i successivi 5 giorni, il certificato di ultimazione della prestazione, che ne rilascerà copia conforme all’Aggiudicatario.
9 Penalità
Per ogni giorno solare di ritardo nell’esecuzione della fornitura (e consegna e installazione) oggetto del presente contratto si applicherà una penale pari all’1‰ (uno per mille) dell’importo contrattuale, al netto dell’IVA.
Nel caso in cui la prima verifica di conformità della fornitura abbia esito sfavorevole non si applicano le penali; qualora tuttavia l’Aggiudicatario non renda nuovamente la fornitura disponibile per la verifica di conformità entro i 30 giorni solari successivi al primo esito sfavorevole, ovvero la verifica di conformità risulti nuovamente negativa, si applicherà la penale sopra richiamata per ogni giorno solare di ritardo.
Nell’ipotesi in cui l’importo delle penali applicabili superi l’importo pari al 10% (dieci per cento) dell’importo contrattuale, al netto dell’IVA, l’Ente risolverà il contratto in danno all’Aggiudicatario, salvo il diritto al risarcimento dell’eventuale danno patito.
Gli inadempimenti contrattuali che daranno luogo all’applicazione di penali di cui ai precedenti periodi verranno contestati all’Aggiudicatario per iscritto.
L’Aggiudicatario dovrà comunicare in ogni caso le proprie deduzioni nel termine massimo di 5 (cinque) giorni lavorativi dalla stessa contestazione. Qualora dette deduzioni non siano accoglibili a giudizio della Stazione Appaltante ovvero non vi sia stata risposta o la stessa non sia giunta nel termine indicato, si applicheranno le penali sopra indicate.
Le penali verranno regolate dalla Stazione Appaltante, o sui corrispettivi dovuti all’Aggiudicatario oppure sulla garanzia definitiva. In quest’ultimo caso la garanzia definitiva dovrà essere reintegrata entro i termini fissati dalla Stazione Appaltante.
10 Oneri ed obblighi dell’Aggiudicatario
L’aggiudicatario si impegna ad eseguire le prestazioni oggetto del presente contratto, senza alcun onere aggiuntivo, salvaguardando le esigenze della Stazione Appaltante e di terzi autorizzati, senza recare intralci, disturbi o interruzioni all’attività lavorativa in atto.
Rinuncia a qualsiasi pretesa o richiesta di compenso nel caso in cui lo svolgimento delle prestazioni contrattuali dovesse essere ostacolato o reso più oneroso dalle attività svolte dalla Stazione Appaltante e/o da terzi.
È direttamente responsabile dell’inosservanza delle clausole contrattuali anche se questa dovesse derivare dall’attività del personale dipendente di altre imprese a diverso titolo coinvolto.
Deve avvalersi di personale qualificato in regola con gli obblighi previsti dai contratti collettivi di lavoro e da tutte le normative vigenti, in particolare in materia previdenziale, fiscale, di igiene ed in materia di sicurezza sul lavoro.
Risponderà direttamente dei danni alle persone, alle cose comunque provocati nell’esecuzione dell’appalto che possano derivare da fatto proprio, dal personale o da chiunque chiamato a collaborare. La Stazione Appaltante è esonerata da ogni responsabilità per danni, infortuni o altro dovesse accadere al personale di cui si avvarrà l’Aggiudicatario nell’esecuzione del contratto.
Si fa carico, intendendosi remunerati con il corrispettivo contrattuale, di tutti gli oneri ed i rischi relativi alle attività ed agli adempimenti occorrenti all’integrale espletamento dell’oggetto contrattuale, ivi compresi, a mero titolo esemplificativo e non esaustivo, gli oneri relativi ad eventuali spese di viaggio e di missione per il personale addetto alla esecuzione della prestazione, nonché i connessi oneri assicurativi.
Inoltre l’aggiudicatario si obbliga a quanto segue:
- ad eseguire le prestazioni oggetto del presente contratto a perfetta regola d’arte e nel rispetto di tutte le norme e le prescrizioni tecniche e di sicurezza in vigore e di quelle che dovessero essere emanate nel corso del presente contratto, nonché secondo le condizioni, le modalità, i termini e le prescrizioni contenute nel presente contratto e nei suoi allegati;
- per consentire il corretto svolgimento del progetto entro i termini indicati nel presente capitolato, tutte le persone coinvolte nello svolgimento delle attività dovranno, quindi, operare in stretto coordinamento con lo staff preposto allo svolgimento delle attività del progetto LifeWatchPLUS e con lo staff della sede del Service Centre dell’infrastruttura LifeWatch di Lecce;
- per tutta la durata delle attività saranno necessari aggiornamenti sul progresso delle attività mediante riunioni da remoto tra il personale dell’azienda assegnataria e quello di progetto. La cadenza delle riunioni sarà mensile. Sarà consentito l’utilizzo di strumentazione digitale per effettuare le riunioni (Skype, Webex, ecc.). Il linguaggio utilizzato durante le riunioni sarà italiano o in inglese. Al termine della riunione dovrà essere stilata apposita minuta in italiano;
- il tempo rimanente dovrà essere utilizzato da remoto in affiancamento al personale di progetto, per la messa a punto di tutte le procedure, mediante debugging del software e delle funzionalità necessarie alla corretta integrazione della piattaforma con le restanti componenti software previste nell’ambito del progetto LifeWatchPLUS;
- tutte le attività di consulenza, inclusa l’installazione e la personalizzazione del software necessario, saranno condotte sui sistemi hardware di cui il progetto LifeWatchPLUS dispone;
- l’aggiudicatario dovrà fornire adeguata descrizione tecnica delle soluzioni progettuali ed implementative dettagliate utilizzando gli strumenti comuni dell’Ingegneria del Software quali UML, etc. o di Basi di Dati quali Modello Entità/Relazioni, etc.;
- l’aggiudicatario dovrà riportare inoltre la sequenza temporale di tutte le attività. Tutto il lavoro svolto dovrà essere documentato mediante deliverables di progetto come da Piano di Progetto da consegnare al responsabile scientifico indicato al successivo art. 11, con cadenza trimestrale, a partire dalla data di aggiudicazione;
- i moduli software dovranno essere tutti corredati da manuale di installazione su macchine Linux/Unix e manuale utente.
- Costituzione della garanzia definitiva ai sensi dell’art. 103 del Codice degli Appalti
11 Indicazione dei soggetti coinvolti
Per il CNR:
- un responsabile tecnico per il collaudo della fornitura erogata;
- la Dott.ssa Xxxxxx Xxxxxx, in qualità di responsabile scientifico dell’obiettivo realizzativo “Estensione dei domini di applicazione dell’infrastruttura” (O.R. 5) del progetto LifeWatchPLUS;
- un responsabile dell’infrastruttura LifeWatch per tutti gli aspetti relativi alle tecnologie;
- un responsabile dell’infrastruttura LifeWatch per tutti gli aspetti relativi alla presentazione grafica e all’organizzazione dei contenuti;
- un responsabile dell’infrastruttura LifeWatch per il supporto tecnico nelle varie attività del progetto;
- il Direttore dell’Esecuzione del Contratto.
Il suddetto personale sarà individuato e comunicato all’aggiudicatario contestualmente alla stipula del contratto
Per l’Aggiudicatario:
- il Gruppo di Lavoro (GdL) dovrà essere composto da persone dotate delle competenze individuate nel proseguo del paragrafo;
- i componenti del GdL potranno far parte dell’organico aziendale oppure essere collaboratori incaricati all’uopo, nei tempi e nei modi ritenuti opportuni dall’Aggiudicatario. In nessun caso potranno formarsi e derivare a carico del CNR oneri aggiuntivi di qualsiasi natura come conseguenza di azioni intraprese dall’Aggiudicatario per la realizzazione del progetto, ivi comprese le eventuali azioni per la formazione dei rapporti di collaborazione professionale con i componenti del gruppo di lavoro; la presentazione dei curricula dei componenti del GDL è obbligatoria e dovrà essere fornita prima della stipula del contratto;
- il gruppo di lavoro presentato in sede di offerta tecnica non potrà essere modificato nei suoi componenti durante la fase di esecuzione del contratto senza la previa approvazione della stazione appaltante;
- i nuovi componenti che sostituiscono dovranno, in ogni caso, possedere requisiti o esperienza professionale equivalenti o superiori a quelli delle persone sostituite, da comprovare mediante l’esibizione di curricula adeguati.
Segue la composizione del gruppo di lavoro:
- un responsabile di progetto, con almeno 5 anni di esperienza nella conduzione di commesse di fornitura di servizi ICT con i requisiti riportati in tabella:
Responsabile di progetto | |
Titolo di Studio | Laurea in discipline tecnico-scientifiche |
Esperienze Lavorative | • Anzianità lavorativa di almeno 5 anni, con almeno 4 di provata esperienza lavorativa nella specifica funzione su progetti complessi, con periodi di permanenza continuativa presso lo stesso cliente non inferiori a 6 mesi. |
Conoscenze | • Metodologie di project management e risk management • Metodologie di sviluppo SW • Redazione di specifiche di progetto • Controllo realizzazione procedure • Stima di risorse per realizzazione di progetto • Stima di tempi di consegna • Analisi e progettazione di sistemi informativi, package, procedure complesse • Conoscenze ed uso di tecniche e prodotti SW per project management • Responsabilità su gruppi di progetto |
- un responsabile tecnico con almeno 5 anni di documentata esperienza nella progettazione e realizzazione di sistemi e servizi informatici e nella conduzione tecnica di progetti ICT simili all’oggetto della fornitura con i requisiti riportati in tabella:
Responsabile tecnico | |
Titolo di Studio | Laurea in discipline tecnico-scientifiche |
Esperienze Lavorative | • Minimo 5 anni, di cui almeno 3 nella funzione • Analisi, progettazione e realizzazione di sistemi informativi, package, procedure complesse • Partecipazione a gruppi di lavoro nella definizione delle soluzioni • Redazione di specifiche di progetto • Progettazione test integrati • Installazione e configurazione di applicativi di front-office e di back-office • Installazione e configurazione di software di base in ambiente distribuito e di architetture di rete • Progettazione soluzioni di system integration • Integrazione di prodotti e/o componenti • Redazione di studi di fattibilità ad alto contenuto innovativo, di specifiche di gestione e procedure • Spiccata attitudine all’analisi dei malfunzionamenti e al problem solving • Completa autonomia nell’individuare, pianificare e progettare adeguamenti tecnologici infrastrutturali |
Conoscenze | • Metodologie di analisi e disegno di prodotti SW • Tecniche di progettazione di test su funzionalità di prodotti • Framework di sviluppo: .NET, J2EE, Ruby on Rails • Modellazione di dati in ambienti multidimensionali e disegno cruscotti • Elevata conoscenza di architetture hardware e prodotti software; in particolare, risultano di interesse: o Prodotti di virtualizzazione e Service Management (VMWare) o apparecchiature HW Enclosure, Server blade, Server tradizionali e Storage, Tape Library • Sistemi di Configuration Management • Conoscenza di Ambienti di Sviluppo Integrati (IDE) |
- un esperto di citizen science con almeno 3 anni di documentata esperienza con i requisiti riportati in tabella:
Esperto in citizen science | |
Titolo di Studio | Laurea in discipline tecnico-scientifiche |
Esperienze Lavorative | • Almeno 3 anni di attivtà in ambito di progetti Citizen Science, o che abbiano una forte componente di partecipazione dei cittadini. |
Conoscenze | • Principi di Citizen Science; • Principali strumenti per favorire la partecipazione dei cittadini a attività di Citizen Science, non solo in campo naturalistico; • Sviluppo di protocolli di monitoraggio degli organismi; • Uso dei principali strumenti di social media. |
- uno sviluppatore Front-end con almeno 3 anni di esperienza documentata nell’implementazione di layout ed elementi grafici in siti internet per desktop e per mobile, conoscenza documentata di HTML, JavaScript (JS) e fogli di stile CSS con i requisiti riportati in tabella:
Sviluppatore Front-end | |
Titolo di Studio | Diploma di perito informatico o cultura superiore in ambito tecnico scientifico |
Esperienze Lavorative | • Minimo 3 anni di esperienza documentata nell’implementazione di layout ed elementi grafici in siti internet per desktop e per mobile, conoscenza documentata di HTML, JavaScript (JS) e fogli di stile CSS, ulteriore esperienza come programmatore in ambiente J2EE e .NET e 1 nella funzione • Documentazione di procedure • Verifica della corretta applicazione di metodi e standard • Sviluppo di analisi tecnica di media complessità • Realizzazione di siti Web accessibili • Documentazione di procedure • Programmazione strutturata, in ambiente client-server, Web e SOA • Preparazione casi di test ed esecuzione di test • Predisposizione di script per il testing automatico con i principali prodotti per il testing automatico • Partecipazione a gruppi di progetto di medie/grandi dimensioni • Tecnologie emergenti • Metodologie di analisi e disegno di prodotti SW • Installazione e personalizzazione di sistemi anche complessi • Progettazione ed integrazione di sistemi • Pacchetti software relativi al progetto |
Conoscenze | • HTML, JavaScript (JS) e fogli di stile CSS • Strumenti di modellazione dati • Tecniche di programmazione Object Oriented • Conoscenza dei principali Design Pattern • Conoscenze della metodologia UML • Conoscenza dei sistemi operativi Microsoft e Linux • Web design (grafico) |
Per tutto il personale che costituisce il Gdl dovranno essere forniti i curricula che attestano il possesso dei requisiti precedentemente specificati.
12 Proprietà Intellettuale e diritti di privativa
Il CNR acquista la proprietà piena ed esclusiva di tutto il materiale sviluppato per l’esecuzione del servizio, della proprietà intellettuale del software prodotto ad hoc con la sola eccezione dei diritti morali ove applicabili. Sono fatti salvi in ogni caso i diritti connessi al software open source e alle licenze di software libero utilizzati per la realizzazione dei prodotti o servizi.
Il CNR non assumerà alcuna responsabilità nel caso in cui l’Aggiudicatario fornisca soluzioni tecniche, estetiche o funzionali ed in genere opere dell’ingegno, simboli, segni distintivi o trovati, di cui altri detengano la privativa. L’Aggiudicatario assumerà l’obbligo di tenere indenne la Stazione appaltante da tutte le rivendicazioni, le responsabilità, perdite e danni pretesi da chiunque, nonché da tutti i costi, le spese o responsabilità ad essi relativi a seguito di qualsiasi rivendicazione di violazione dei diritti d’autore o di qualsiasi marchio italiano o straniero, derivante o che si pretendesse derivare dalla prestazione.
Ciascuna parte si obbliga a dare immediato avviso all’altra di qualsiasi azione di rivendicazione o altri atti o fatti di terzi di cui al precedente comma, della quale sia venuta a conoscenza.
13 Divieto di cessione del contratto
È vietata la cessione del contratto ai sensi dell’art. 105, comma 1 del D. Lgs. 50/2016 e s.m.i.
Per quanto riguarda le modificazioni soggettive che comportino cessioni di azienda e atti di trasformazione, fusione e scissione relative all’Aggiudicatario, si applicano le disposizioni di cui all’art. 106 del D. Lgs. 50/2016 e s.m.i.
L’Aggiudicatario è tenuto a comunicare tempestivamente alla Stazione Appaltante ogni modificazione intervenuta negli assetti proprietari e nella struttura organizzativa.
14 Verifiche e Controlli
Durante l’esecuzione del contratto, il Direttore dell’Esecuzione del Contratto si riserva la facoltà e il diritto di effettuare in qualunque momento verifiche e controlli sulla regolare esecuzione dei medesimi e di eseguire accertamenti sui prodotti e sulle attrezzature utilizzate, riservandosi la facoltà di ricusarli, ove fossero ritenuti non idonei nonché il diritto di fare ripetere l’esecuzione dei servizi qualora svolto senza osservare le prescrizioni del presente capitolato. La Stazione Appaltante si asterrà dal formulare osservazioni direttamente ai dipendenti dell’Appaltatore e rivolgerà le eventuali osservazioni al referente tecnico dell’Appaltatore.
15 Verifica di Conformità della fornitura
La fornitura sarà soggetta a verifica di conformità per certificare che l'oggetto del contratto in termini di prestazioni, obiettivi e caratteristiche tecniche, economiche e qualitative sia stato realizzato ed eseguito nel rispetto delle previsioni contrattuali e delle pattuizioni concordate in sede di aggiudicazione, ai sensi dell’art. 102 del D. Lgs. 50/2016 e s.m.i..
Le attività di verifica saranno effettuate entro 30 (trenta) giorni solari dalla data di consegna della fornitura.
16 Fatturazione e condizioni di pagamento
La fatturazione avverrà come di seguito indicato:
• 30% dell’importo contrattuale a titolo di anticipo. L'erogazione dell'anticipazione, consentita anche nel caso di consegna in via d'urgenza, ai sensi dell'articolo 32, comma 8, del presente codice, è subordinata alla costituzione di garanzia fideiussoria bancaria o assicurativa di importo pari all'anticipazione maggiorato del tasso di interesse legale applicato al periodo necessario al recupero dell'anticipazione stessa secondo il cronoprogramma della prestazione. Il pagamento dell’anticipo avverrà entro 15 giorni dal ricevimento della garanzia suindicata;
• 70% dell’importo contrattuale al termine dei nove mesi previa consegna del bene e pagamento entro 30 giorni dal positivo esito della verifica di conformità.
La fattura dovrà essere emessa in forma elettronica ai sensi e per gli effetti del Decreto del Ministero dell’Economia e delle Finanze N. 55 del 3 aprile 2013, inviando il documento elettronico al Sistema di Interscambio che si occuperà di recapitare il documento ricevuto all’Ente destinatario, identificata dal seguente Codice Univoco Ufficio – CUU “LVHDFJ”. Le fatture sono soggette a “Split Payment”. La fattura, intestata all’Ente, dovrà contenere, pena il rifiuto della stessa:
- La partita IVA dell’Ente: 02118311006;
- Il riferimento al contratto (n° di protocollo e data);
- CUI 80054330586201900677CIG 8904600461
- CUP B67E19000030007
- Il CUU (Codice Univoco Ufficio): LVHDFJ;
- L’importo imponibile;
- L’IVA;
- Il totale della fattura;
- L’oggetto del contratto;
- Il codice IBAN del conto corrente dedicato di cui alla Legge 136/2010.
Ai fini del pagamento del corrispettivo l’Ente procederà ad acquisire il documento unico di regolarità contributiva (D.U.R.C.), attestante la regolarità in ordine al versamento dei contributi previdenziali e dei contributi assicurativi obbligatori per gli infortuni sul lavoro e le malattie professionali dei dipendenti. L’Ente, in ottemperanza alle disposizioni previste dall’art. 48-bis del D.P.R. 602 del 29 settembre 1973, con le modalità di cui al Decreto del Ministero dell’Economia e delle Finanze del 18 gennaio 2008 n. 40, parzialmente modificati dalla Legge 205/2017, per ogni pagamento di importo superiore ad euro 5.000,00 procederà a verificare se il beneficiario è inadempiente all’obbligo di versamento derivante dalla notifica di una o più cartelle di pagamento per un ammontare complessivo pari almeno a tale importo. Nel caso in cui
la società Equitalia S.p.A. comunichi che risulta un inadempimento a carico del beneficiario l’Ente applicherà quanto disposto dall’art. 3 del decreto di attuazione di cui sopra. L’Operatore economico, sotto la propria esclusiva responsabilità, renderà tempestivamente note all’Ente le variazioni che si verificassero circa le modalità di accredito di cui sopra. In difetto di tale comunicazione, anche se le variazioni venissero pubblicate nei modi di legge, l’Operatore economico non potrà sollevare eccezioni in ordine ad eventuale ritardo del pagamento, né in ordine a pagamento già effettuato. In sede di liquidazione delle fatture potranno essere recuperate le spese per l’applicazione di eventuali penali, di cui all’articolo 16 del presente contratto, l’Ente potrà sospendere, ferma restando l’applicazione delle eventuali penali, i pagamenti all’Operatore economico cui sono state contestate inadempienze nell’esecuzione della fornitura, fino al completo adempimento degli obblighi contrattuali (art. 1460 C.C.). Tale sospensione potrà verificarsi anche qualora insorgano contestazioni di natura amministrativa.
17 Tracciabilità dei Flussi finanziari
L’Aggiudicatario assume tutti gli obblighi di tracciabilità dei flussi finanziari di cui all’art. 3 della legge 13 agosto 2010 n. 136 e successive modificazioni ed integrazioni.
Il mancato utilizzo del bonifico bancario o postale ovvero degli altri strumenti di incasso o pagamento idonei a consentire la piena tracciabilità delle operazioni costituisce causa di risoluzione del contratto ai sensi dell’art. 3, comma 9-bis, della legge 13 agosto 2010 n.136.
L’Aggiudicatario si impegna a dare immediata comunicazione alla Stazione Appaltante e alla prefettura- ufficio territoriale del Governo della provincia di Roma della notizia dell’inadempimento della propria controparte (subappaltatore/subcontraente) agli obblighi di tracciabilità finanziaria.
18 Risoluzione e Recesso
Ai sensi e per gli effetti dell’art. 108 del d.lgs. 50/2016, la stazione appaltante, fatto salvo quanto previsto ai commi 1, 2 e 4, dell’articolo 107 del d.lgs. 50/2016, può risolvere il contratto durante il periodo di sua efficacia, se una o più delle seguenti condizioni sono soddisfatte:
a) l’aggiudicatario si è trovato, al momento dell’aggiudicazione dell’appalto in una delle situazioni di cui all’articolo 80, comma 1, per quanto riguarda i settori ordinari ovvero di cui all’articolo 170, comma 3, per quanto riguarda le concessioni e avrebbe dovuto pertanto essere escluso dalla procedura di appalto o di aggiudicazione della concessione, ovvero ancora per quanto riguarda i settori speciali avrebbe dovuto essere escluso a norma dell’articolo 136, comma 1, secondo e terzo periodo;
b) l’appalto non avrebbe dovuto essere aggiudicato in considerazione di una grave violazione degli obblighi derivanti dai trattati, come riconosciuto dalla Corte di giustizia dell’Unione europea in un procedimento ai sensi dell’articolo 258 TFUE, o di una sentenza passata ingiudicato per violazione del presente codice.
c) rifiuto ingiustificato per almeno 3 (tre) volte anche non consecutive, delle richieste della Stazione Appaltante; si evidenzia che, a titolo esemplificativo, può ritenersi “giustificato” quel rifiuto derivante da obiettive e ragionevoli difficoltà tecniche nell’eseguire la prestazione richiesta.
In caso di risoluzione del contratto sarà facoltà del CNR di procedere allo scorrimento automatico della graduatoria approvata con determinazione di aggiudicazione definitiva, oppure di indire una nuova procedura di gara.
Ai sensi dell’articolo 1455 Codice Civile, il CNR si riserva la facoltà di risolvere unilateralmente il presente contratto nei seguenti casi di gravi inadempimenti:
a) per sopravvenuti motivi di pubblico interesse;
b) in caso di frode, di grave negligenza, di contravvenzione nell’ esecuzione degli obblighi e condizioni contrattuali;
c) in caso di cessione dell’attività, oppure nel caso di concordato preventivo, di fallimento, di stato di moratoria e di conseguenti atti di sequestro o di pignoramento a carico dell’Aggiudicatario;
d) per violazione degli obblighi di riservatezza;
e) nel caso in cui la prestazione non sia stata eseguita nei termini prescritti, ovvero in caso di esito negativo dei controlli delle verifiche in corso di esecuzione, dai quali emerga un grave e reiterato inadempimento;
f) qualora la Società perda i requisiti di carattere generale richiesti per l’affidamento del servizio previsti dall’articolo 80 del D. Lgs. n. 50 del 2016;
g) per mancata osservanza delle disposizioni di cui alla Legge 13/08/2010, n. 136.
Ove il CNR ravvisi la sussistenza di una delle cause sopra descritte, provvederà a contestarle per iscritto all’impresa, tramite PEC fissando un termine non inferiore a 10 (dieci) giorni per le eventuali controdeduzioni. Decorso tale termine l’Amministrazione adotterà le determinazioni ritenute più opportune, dandone notizia motivata alla Società. La risoluzione del contratto viene disposta con atto del Direttore della Stazione Appaltante.
Con la risoluzione del contratto sorge il diritto della Stazione appaltante di affidare a terzi la fornitura o la parte rimanente di questa, in danno della Società inadempiente. Allo stesso, pertanto, saranno addebitate le spese sostenute in più dal CNR rispetto a quelle previste dal contratto risolto. La risoluzione del contratto non esime la Società dalla responsabilità civile e penale in cui la stessa può incorrere per i fatti che hanno motivato la risoluzione.
mente subiti.
19 Regole di Condotta per l’utilizzazione del sistema
I concorrenti e, comunque, tutti gli utenti del Sistema sono tenuti ad utilizzare il Sistema stesso secondo buona fede ed esclusivamente per le finalità consentite e sopra specificate, e sono altresì responsabili per le violazioni delle disposizioni di legge e regolamentari, in materia di acquisti di beni e servizi della Pubblica Amministrazione e per qualunque genere di illecito amministrativo, civile o penale.
I concorrenti e, comunque, tutti gli utenti del Sistema si obbligano a porre in essere tutte le condotte necessarie ad evitare che attraverso il Sistema si attuino turbative nel corretto svolgimento delle procedure di gara con particolare riferimento a condotte quali, a titolo esemplificativo e non esaustivo: la turbativa d’asta, le offerte fantasma, gli accordi di cartello.
In caso di inosservanza di quanto sopra, l’Amministrazione segnalerà il fatto all’autorità giudiziaria, all’Autorità Nazionale Anticorruzione, all’Osservatorio sui contratti pubblici di lavori, forniture e servizi per gli opportuni provvedimenti di competenza.
Salvo il caso di dolo o colpa grave, Consip S.p.A. e il Gestore del Sistema non saranno in alcun caso ritenuti responsabili per qualunque genere di danno, diretto o indiretto, per lucro cessante o danno emergente, che dovessero subire gli utenti del Sistema, e, comunque, i concorrenti e le Amministrazioni o terzi a causa o comunque in connessione con l’accesso, l’utilizzo, il mancato utilizzo, il funzionamento o il mancato funzionamento del Sistema e dei servizi dallo stesso offerti.
Tutti i contenuti del sito xxx.xxxxxxxxxxxxxxx.xx e, in generale, i servizi relativi al Sistema, forniti dal MEF, dalla Consip S.p.A. e dal Gestore del Sistema sono resi disponibili e prestati così come risultano dal suddetto sito e dal Sistema.
Il MEF, la Consip S.p.A. ed il Gestore del Sistema non garantiscono la rispondenza del contenuto del sito xxx.xxxxxxxxxxxxxxx.xx ed in generale di tutti i servizi offerti dal Sistema alle esigenze, necessità o aspettative, espresse o implicite, degli altri utenti del Sistema.
La Consip S.p.A. ed il Gestore del Sistema, non assumono alcuna responsabilità nei confronti delle Amministrazioni per qualsiasi inadempimento dei Fornitori e per qualunque danno di qualsiasi natura da essi provocato.
Con la Registrazione e la presentazione dell’offerta, i concorrenti manlevano e tengono indenne il MEF, la Consip S.p.A., l’Amministrazione ed il Gestore del Sistema, risarcendo qualunque pregiudizio, danno, costo e onere di qualsiasi natura, ivi comprese le eventuali spese legali, che dovessero essere sofferte da questi ultimi e/o da terzi, a causa di violazioni delle regole contenute nel presente Disciplinare di gara, dei relativi allegati, di un utilizzo scorretto od improprio del Sistema o dalla violazione della normativa vigente.
A fronte di violazioni di cui sopra, di disposizioni di legge o regolamentari e di irregolarità nell’utilizzo del Sistema da parte dei concorrenti, oltre a quanto previsto nelle altre parti del presente Disciplinare di gara, il MEF, la Consip S.p.A., l’Amministrazione ed il Gestore del Sistema, ciascuno per quanto di rispettiva competenza, si riservano il diritto di agire per il risarcimento dei danni, diretti e indiretti, patrimoniali e di immagine, eventualmente subiti.
Xxxxxxxxxxx Xxxxx 18.09.2021
22:38:22
GMT+00:00