CAPITOLATO
PROVINCIA DI SALERNO
Servizi ai Comuni
Via Roma, 104 – Xxxxxxx X. Xxxxxxxx 00000 Xxxxxxx tel. 000 000000 fax 000 0000000
Gara per l'affidamento della fornitura dei servizi di assistenza tecnica, customizzazione, manutenzione, evoluzione, caricamento dati, hosting in cloud e conduzione della piattaforma SW per il Progetto "C2CM: Coast To Coast Moving"
CAPITOLATO
CIG: 7648541FB0
CUP: H89C18000000007
Indice
4 Livelli di Servizio (SLA) 11
6 Struttura della relazione da presentare come offerta tecnica 11
7 Avvio anticipato del servizio 12
11 Garanzie e responsabilità 14
13 Obbligazioni dell’appaltatore 15
14 Obbligazioni derivanti dal rapporto di lavoro 15
15 Obblighi di riservatezza 15
18 Risoluzione del contratto 17
Allegato 1 – Linee guida per la creazione del “Kit del Riuso” 19
Allegato 2 – Architettura e caratteristiche della piattaforma Apulia Moving 23
Allegato 3 – SLA del servizio i hosting il cloud 25
Nella prima parte, il documento riporta una descrizione sintetica del progetto finanziato, successivamente verranno definiti i punti salienti della fornitura con particolari attenzione al luogo e durata della stessa.
Nel seguito con i termini “Stazione Appaltante”, “Ente”, “Amministrazione” o simili si intenderà la Provincia di Salerno, mentre con i termini “Appaltatore”, “Fornitore”, “aggiudicatario” e simili si intenderà l’operatore economico aggiudicatario del presente appalto se non diversamente specificato.
1 Descrizione del Progetto
Il progetto C2CM intende realizzare un sistema di infomobilità multimodale aperto ed interoperabile per fornire informazioni pre-trip e on-trip relativamente all’offerta di trasporto, POI (Point of Interest) e servizi sul territorio, personalizzate sulla base delle esigenze dell’utente.
La finalità di C2CM è l'estensione dei servizi di Infomobilità a tutto il territorio dell'Italia Meridionale ricco di attrazioni turistiche, eccellenze e tipicità mediante la messa a fattor comune di un “kit di riuso”. Intende promuovere a questo scopo una Open Community per la standardizzazione dei servizi di infomobilità.
1.1 PON Governance e Capacità Istituzionale 2014-2020
Il PON Governance e Capacità Istituzionale 2014-2020 concorre al raggiungimento degli obiettivi di crescita intelligente e sostenibilità definiti da Europa 2020, con la strategia di rafforzare la capacità istituzionale e amministrativa della Pubblica Amministrazione e offrire uno strumento di supporto ai processi nazionali di riforma della PA.
Il Programma finanzia interventi per la modernizzazione del sistema amministrativo con riferimento agli aspetti gestionali, organizzativi, di semplificazione e digitalizzazione di processi e servizi verso cittadini e imprese (e-government) e rafforzando la trasparenza e la partecipazione civica attraverso lo sviluppo e la diffusione dei dati pubblici (open government). In questo quadro il PON prevede anche azioni mirate al miglioramento dell’efficienza e delle prestazioni degli uffici giudiziari.
La strategia del Programma prevede anche – attraverso l’Asse 3 - il sostegno alla ridefinizione del sistema di governance multilivello delle politiche di investimento pubblico, capace di superare l’attuale frammentazione ed eccessiva articolazione delle competenze amministrative e di consentire, in questo modo, una migliore qualità nell’azione della PA. Una governance che funzioni in modo organico, mettendo a sistema tutti gli attori, a tutti i livelli, coinvolti nell’attuazione dei programmi di investimento pubblico, per agire in modo coordinato, più efficiente, più efficace, per una migliore capacità di realizzare gli interventi e di raggiungere i risultati attesi.
Funzionale alla ridefinizione del sistema di governance delle politiche di investimento pubblico è anche l’azione che il Programma intende attuare a supporto dei processi di costruzione di reti di cooperazione e dei meccanismi di scambio tra Pubbliche Amministrazioni, con l’obiettivo di individuare, implementare e diffondere soluzioni e buone pratiche amministrative tra le più innovative realizzate nel Paese, anche attraverso il contributo delle risorse comunitarie.
1.2 Avviso per progetti di cooperazione e scambio fra PA
Nel mese di aprile 2017, l’Autorità di Gestione del PON Governance e Capacità Istituzionale 2014- 2020 ha pubblicato il primo avviso pubblico per il finanziamento di interventi volti al trasferimento, all’evoluzione e alla diffusione di buone pratiche attraverso Open Community PA 2020
Tale avviso si inserisce nell’ambito del più ampio percorso di azioni volte al miglioramento della governance multilivello e della capacità amministrativa e istituzionale delle Pubbliche Amministrazioni, con lo scopo di finanziare in prima istanza un insieme di interventi che risultino coerenti con i risultati attesi previsti da alcuni degli Obiettivi Tematici (OT) individuati ai fini del presente Avviso come esclusivi, che sono:
• OT1 - Rafforzare la ricerca, lo sviluppo tecnologico e l'innovazione;
• OT2 - Migliorare l'accesso alle tecnologie dell'informazione e della comunicazione, nonché l'impiego e la qualità delle medesime;
• OT3 - Promuovere la competitività delle piccole e medie imprese, il settore agricolo e il settore della pesca e dell’acquacoltura.
Nello specifico, l’avviso ha lo scopo di finanziare interventi che, coerentemente con gli OT di riferimento, prevedano lo scambio di buone pratiche, ossia il trasferimento di prassi, esperienze, metodologie, sistemi organizzativi e gestionali innovativi eventualmente supportati da sistemi tecnologici – o una combinazione di questi – realizzati da un Ente per risolvere una determinata criticità. Le buone pratiche dovranno caratterizzarsi effettivamente come caso di eccellenza, originale e innovativo, in grado di produrre risultati effettivi e/o risolvere criticità reali, determinando un concreto miglioramento nell’azione amministrativa (efficienza/efficacia operativa) dell’Ente riusante.
1.3 Il Progetto C2CM – Coast to Coast Moving
Il Progetto C2CM, di cui la provincia di Salerno è Ente Capofila, è risultato tra i progetti ammessi a finanziamento. Obiettivo del progetto è il riuso della piattaforma Apulia Moving realizzata dal Comune di Lecce nell’ambito del progetto Infocity finanziato completamente nell'ambito del Programma Nazionale ELISA (Programma Enti Locali - Innovazione di Sistema - 3° Avviso).
Il progetto Apulia Moving ha come obiettivo lo sviluppo di un sistema di infomobilità multimodale e multicanale personalizzato, in grado di mettere a sistema le banche dati dei diversi operatori di trasporto collettivi e privati.
Tale sistema consente agli utenti di accedere, prima e durante lo spostamento, ad informazioni (statiche e dinamiche) personalizzate e in tempo reale sul sistema dei trasporti e della mobilità, anche correlate ad indicazioni di carattere turistico e culturale.
E’ un modo nuovo di concepire e organizzare la mobilità in un più ampio contesto di “Smart Mobility” che soddisfa le mutanti esigenze di trasporto in maniera efficace, efficiente, sicura e sostenibile ottimizzando l’uso delle risorse economiche, umane ed ambientali.
Infatti, un fattore pregnante della Smart Mobility è la valorizzazione dei dati e delle informazioni anche attraverso sistemi in rete che consentono elaborazioni ed erogazione di servizi in tempo reale.
Secondo un sondaggio Piepoli il 67% dei nostri connazionali trova affidabili e vantaggiose le App per servizi di trasporto come la possibilità di prenotare (39%) e pagare (42%) da smartphone in ogni momento e il vantaggio di risparmiare tempo (41%).
Per intercettare questo trend il progetto C2CM intende sviluppare una piattaforma multicanale di servizi per la mobilità pubblica e privata sperimentandola su un territorio (regioni meridionali) connotato da eccellenze, tipicità e patrimoni storico/culturali di livello internazionale.
Intende, inoltre ed in prospettiva, arricchirla con verticalizzazioni per la promozione di eventi, tipicità, turismo, produzioni di eccellenza e commercio erogando anche servizi di vendita di prodotti e servizi che ne garantiranno l'auto-sostenibilità economica mentre la sostenibilità tecnica sarà affidata ad una Open Community che ne curerà la manutenzione ed evoluzione.
I partner del progetto sono:
• Provincia di Salerno, capofila/beneficiario per il coordinamento, gestione procedure e rendicontazione;
• Comune di Lecce, ente cedente con maggiori attività di natura tecnica;
• Comune di Agropoli
• Comune di Bellosguardo
• Comune di Bracigliano
• Comune di Centola
• Comune di Corbara
• Comune di Matera
• Comune di Xxxxxxxxx sulla Marcellana
• Comune di Padula
• Comune di Pollica
• Comune di Roccadaspide
• Comune di Sala Consilina
• Comune di Sarno
• Comune di Torchiara
2 Contenuti della fornitura
Nel presente capitolo verranno elencate le attività necessarie alla realizzazione del progetto C2CM:
• Progettazione
• Architettura Cloud
• Manutenzione
• Customizzazione
• Standardizzazione dei processi di caricamento dei dati
• Riuso
• Community
• Rendicontazione
Infine si fa presente che il Comune di Lecce, attraverso un protocollo d’intesa con la Provincia di Salerno, fornisce sia il codice sorgente del portale ApuliaMoving che tutta la documentazione in suo possesso. Tutta la documentazione fornita dal comune di Lecce sarà visionabile su richiesta.
2.1 Progettazione
Nella fase di progettazione l’aggiudicatario dovrà fornire un progetto preliminare dove indicare tutte le fasi di realizzazione del presente appalto. Nel progetto preliminare dovranno essere indicate le attività e la tipologia di personale impiegato. Tale progetto preliminare, successivamente all’aggiudicazione, si dovrà trasformare nel progetto esecutivo indicando anche i tempi di realizzazione delle varie fasi in questione. L’aggiudicatario dovrà produrre anche un piano di monitoraggio, controllo e valutazione interna delle attività. E dovrà presentare anche un piano delle eventuali implementazioni correttive.
2.2 Architettura Cloud
Il portale Apulia Moving è un applicazione Web-Based, di conseguenza compatibile con i principali browser. L’applicazione è stata sviluppata con tecnologia Microsoft DotNet e il repository dei dati è un database Microsoft SQL Server. L’aggiudicatario dovrà fornire, per ospitare tale portale, un ambiente in cloud costituito da almeno i seguenti elementi.
1. Due server virtuali bi-processore con almeno 8GB di ram e almeno un 1TB di disco che dovranno fungere da frontend. Sulle macchine verranno installati i due Microsoft IIS quest’ultimi configurati in loadbalancer.
2. Un server virtuale bi-processore con almeno 12GB di ram e almeno un 1TB di disco per ospitare il database Microsoft SQL Server.
3. Un server virtuale bi-processore con almeno 12GB di ram e almeno un 2TB di disco quest’ultimo dovrà fungere da repository della cartografia.
Si precisa che la manutenzione sia Hardware che software dell’intera architettura dovrà essere completamente a carico dell’aggiudicatario. Infine si intende che l’aggiudicatario dovrà fornire a proprie spese un ambiente in cloud capace di ospitare e quindi di erogare in completa autonomia il servizio, comprensivo di tutte le licenze di terze parti, tipo sistemi operativi, database ecc, garantendo ottime prestazioni. Le eventuali licenze così acquisite rimarranno di proprietà della Provincia di Salerno insieme a tutto il codice. L’aggiudicatario dovrà farsi carico di tutti i costi di presa in carico del codice sorgente da parte del comune di Lecce di installazione e configurazione dello stesso nell’ambiente oggetto della fornitura.
2.3 Manutenzione
L'assistenza e la manutenzione del sistema dovranno essere assicurate per il SW fornito sia di base che di terze parti e dovrà essere garantita ogni consulenza tecnico sistemistica necessaria per il suo corretto funzionamento.
In caso di aggiornamento o migrazione delle piattaforme SW ovvero di cambiamento delle architetture HW, ovvero di scelta da parte della Provincia di Salerno di un diverso provider di servizi di hosting, housing o connettività, l’aggiudicatario fornirà alla Provincia di Salerno l’assistenza necessaria alla migrazione del sistema. Tali prestazioni restano a carico dell’aggiudicatario. Resta a carico dell’aggiudicatario l’onere nel caso in cui l’aggiornamento o la migrazione delle piattaforme SW o il cambiamento dell’architettura HW dipendano dalla necessità di rimediare a problemi di funzionamento del sistema.
L’aggiudicatario dovrà occuparsi anche della manutenzione correttiva, cioè il processo di diagnosi e di rimozione di errori rilevati durante l’esercizio del sistema al fine di garantirne il corretto funzionamento. Tale manutenzione sarà innescata da impedimenti all’utilizzo delle funzionalità da parte degli operatori, degli amministratori o degli utenti finali o da differenze riscontrate tra l’effettivo funzionamento della piattaforma e quello atteso.
La Provincia comunicherà al Fornitore le disfunzioni riscontrate al fine di permettere una corretta valutazione del problema, assegnando un codice di urgenza per ogni problema riportato.
Per manutenzione correttiva si intende altresì il processo di analisi e rimozione di malfunzionamenti del sistema rilevati dallo stesso Fornitore nell’ambito della fase di test ovvero nell’ambito di normali routine di controllo periodico. Il Fornitore assume l’obbligo di portare a soluzione i problemi segnalati o autonomamente rilevati nei tempi indicati successivamente nel presente capitolato in funzione del codice di urgenza assegnato.
2.4 Customizzazione
Nell’attività di customizzazione sono incluse le attività di personalizzazione della piattaforma software acquisita dal Comune di Lecce, per personalizzazioni si intende modifica delle vesta grafica e tipologia di evoluzione dell’architettura secondo le esigenze che la Provincia di Salerno indicherà in fase di esecuzione. A tal proposito per ciò che concerne la messa a fattor comune dei dati di Apuliamoving, detenuti dal Comune di Lecce, con quelli della nuova installazione al fine di elaborare percorsi globali, sono previsti due possibili scenari fra loro alternativi la cui scelta da parte dell’Amministrazione avverrà in fase di esecuzione.
Scenario 1: Questo scenario prevede che l’ente riusante installi in toto una nuova istanza della piattaforma presso l’infrastruttura cloud oggetto della gara e i dati presenti nell’installazione del Comune di Lecce dovranno essere caricati e aggiornati mediante automatismi quindi lo stesso Comune assume il ruolo di fornitore di dati ed invierà, o renderà disponibili, periodicamente gli stessi.
Scenario 2: Questo scenario prevede che l’ente riusante installi in toto una nuova istanza della piattaforma presso l’infrastruttura cloud oggetto della gara e i dati presenti nell’installazione del Comune di Lecce dovranno essere interrogati mediante automatismi. In questo scenario dovrà essere realizzato un TP-HUB per le linee dorsali. Introducendo il TP-HUB, che ha la conoscenza delle tratte dorsali ( Trenitalia, autobus GT ), si possono risolvere viaggi door to door da Salerno a Lecce.
Allo stato attuale il progetto ApuliaMoving fornisce un unico mezzo di interrogazione userfriendly cioè attraverso i principali browser, di conseguenza la Provincia vuole integrare questo progetto realizzando un APP che consenta di interrogare, attraverso le medesime chiavi di ricerca del Web e visualizzare le stesse informazioni contenute nel portale web. Quindi l’aggiudicatario dovrà realizzare la su indicata App e pubblicarla sui principali App Store Android, iOS. Resta inteso che l’aggiudicatario dovrà farsi carico di tutti i costi di progettazione, realizzazione e pubblicazione della suddetta App. Il codice della App rimarrà di proprietà della Provincia insieme ad ogni altra licenza eventualmente acquisita per il funzionamento della stessa sulle varie piattaforme.
2.5 Standardizzazione dei processi di caricamento dei dati
In questa paragrafo verrà descritto come il fornitore dovrà creare un processo, standardizzato, di caricamento e aggiornamento dei dati.
Dopo la prima fase di realizzazione del cloud e d’installazione e personalizzazione del portale ApuliaMoving, il fornitore dovrà popolare il database con i dati di interesse del territorio. Quest’ultimi dovranno essere prima raccolti, quindi il fornitore dovrà predisporre un processo costituito da un’attività di preparazione, raccolta, validazione e caricamento di dati TPL, POI, eventi e servizi di pubblica utilità relativi al territorio in oggetto.
Il fornitore dovrà rendere disponibili risorse umane con skill adeguato incluso le attività di supporto e formazione on-site presso i comuni partecipanti al progetto per agevolare la raccolta dei dati necessari al popolamento della piattaforma. In dettaglio il fornitore dovrà:
• Predisporre schede per il caricamento dei dati necessari al popolamento della piattaforma C2CM.
• Contattare gli enti interessati nella raccolta dei dati per incontri focalizzati alla formazione e supporto della compilazione delle schede e alla raccolta del materiale multimediale. Per ogni ente contattato dovrà essere prodotta una “relazione di raccolta” in cui devono essere riportati l’ente, le persone contattate e i contenuti consegnati.
• Predisporre le attività per la normalizzazione, il caricamento e gli aggiornamenti dei dati raccolti.
• Predisporre delle procedure per raccogliere dati da tutti gli attori interessati (esempio trenitalia, aeroporti,ecc).
Resta inteso che tutta la raccolta dei dati dovrà essere automatizzata il più possibile.
2.6 Riuso
Il “kit del riuso” rappresenta un pacchetto di strumenti e procedure che consentono il trasferimento delle soluzioni tra Amministrazioni.
Tutte le azioni previste in questa attività devono essere svolte nel rispetto delle linee guida definite nell’ ALLEGATO E – LINEE GUIDA PER LA CREAZIONE DEL KIT DEL RIUSO dell’avviso di
finanziamento di questo progetto riportato integralmente come Allegato 1 al presente capitolato.
Il fornitore dovrà predisporre tutti i documenti e le attività necessarie affinché il pacchetto oggetto dell’appalto sia reso disponibile in riuso per le amministrazioni e dovrà supportare le fasi che compongono tale processo.
2.7 Portale di community
Il fornitore dovrà predisporre tutti gli strumenti e procedure utili alla realizzazione di una community capace di manutenere e aggiornare il portale oggetto dell’appalto. Il fornitore dovrà realizzare un portale inclusivo di :
• funzioni per la creazione di utenti con relativo modulo di adesione alla community;
• funzioni per la gestione dei download del codice sorgente
Di conseguenza dovranno essere predisposti tutti gli strumenti atti alla gestione dei vari attori che partecipano alla community. Per gestione si intende la possibilità di tracciare le operazioni effettuate dai vari attori e la possibilità di effettuare dei rollback sulle stesse. Dovranno essere predisposti strumenti di validazione e approvazione delle attività svolte dagli utenti della piattaforma. Infine il fornitore in fase di presentazione dell’offerta a dovrà presentare un documento con descrizione dettagliata delle funzionalità e un diagramma dei casi d’uso del portale in oggetto.
2.8 Rendicontazione
Tutte le attività di progetto dovranno essere rendicontate su appositi modelli forniti dal committente, in questi modelli saranno inseriti le giornate di attività svolte, i tempi e i costi. Tali prospetti dovranno essere compilati da ogni risorsa professionale attiva sul progetto. Il fornitore dovrà garantire la corretta compilazione degli stessi e la relativa consegna al committente.
3 Gestione delle Richieste
Il Fornitore dovrà garantire un servizio di trattamento delle richieste di intervento da parte dell’Amministrazione. L’Amministrazione, comunicherà al fornitore malfunzionamenti o la necessità di pianificare un intervento correttivo/migliorativo dei sistemi, mediante l’invio di una e-mail o chiamata telefonica ad un apposito numero definito dal fornitore.
L’ora e la data di invio della suddetta richiesta o e-mail costituiranno l’orario di apertura del ticket. Una volta ricevuta la richiesta il fornitore processerà, attraverso il proprio sistema di gestione, ed assegnerà ad essa un identificativo di chiamata – ticket - che dovrà comunicare all’amministrazione contestualmente alla chiamata medesima. Il sistema di gestione dovrà garantire il tracciamento della chiamata in tutte le sue fasi, fino alla chiusura della stessa. Alla chiusura della richiesta, il fornitore dovrà comunicare i dettagli delle attività svolte.
4 Livelli di Servizio (SLA)
Gli interventi di manutenzione dovranno essere effettuati da personale specializzato. Per maggiori dettagli sui tempi si rimanda all’allegato 3 del presente capitolato.
5 Gruppo di lavoro
Il gruppo di lavoro dovrà essere composto, almeno dalle figure professionali di seguito indicate:
• n. 1 Coordinatore di progetto, con almeno 5 anni di esperienza;
• n. 1 Programmatore Senior parte Web, con almeno 5 anni di esperienza;
• n. 3 Figure con esperienza di sviluppo di applicazioni specifiche;
• n. 3 addetti data entry ed interfaccia comuni.
Il personale impiegato nel servizio, così come individuato nell’offerta tecnica, che dovesse abbandonare per qualunque ragione l’incarico, deve essere sostituito, previa approvazione dell’Ente, da personale di pari qualificazione ed esperienza.
In tale ipotesi il Fornitore dovrà:
organizzativa coinvolta nell’esecuzione dell’appalto, indicando analiticamente la variazione intervenuta; qualificazione e la stessa esperienza del membro uscente dal gruppo di lavoro;
tare il curriculum del nuovo membro del gruppo di lavoro e la documentazione riguardante la regolarità del rapporto di lavoro o di collaborazione.
In caso di mancata approvazione da parte dell’Ente per inosservanza delle suddette prescrizioni, il Fornitore dovrà individuare un nuovo membro del gruppo di lavoro e sottoporre la nuova ipotesi di sostituzione all’Ente, con le modalità sopra indicate.
6 Struttura della relazione da presentare come offerta tecnica
Il proponente dovrà strutturare, in max 50 pagine formato A4, il documento di offerta tecnica secondo l’indice seguente:
1 Presentazione dell’azienda: una breve descrizione dell’azienda con un particolare focus sulle esperienze più significative.
2 Progettazione: in questa sezione il proponente deve descrivere il contesto di riferimento in cui si andrà ad inserire il progetto e le attività che saranno svolte, dettagliando per ognuna di esse i risultati che saranno raggiunti, le metodologie di lavoro che saranno adottate e l’articolazione temporale prevista. In questa sezione, inoltre, deve essere descritta l’organizzazione proposta per il progetto e le logiche di interazione con il Committente e deve essere fornito un organigramma strutturato delle risorse messe in campo dal proponente.
3 Cloud: in questa sezione dovranno essere descritte le caratteristiche della piattaforma cloud messa a disposizione per l’hosting del portale C2CM e del portale della Open Community in termini di connettività, sicurezza, affidabilità e backup.
4 Customizzazione: in questa sezione l’azienda dovrà descrivere come saranno implementate le attività richieste nel paragrafo customizzazione includendo anche una descrizione per grandi linee sulla realizzazione dell’app e una panoramica sulle modalità di implementazione dei due scenari richiesti nell’omonimo paragrafo. Descrizione della modalità di pubblicazione dell’App.
5 Standardizzazione dei processi di caricamento dei dati: in questa sezione il fornitore dovrà descrivere come intende raccogliere e normalizzare i dati e le modalità di interfacciamento con i vari attori coinvolti nel progetto.
6 Community: in questa sezione si dovrà descrivere come si intende realizzare il portale della community oggetto d’appalto.
7 Gruppo di lavoro: in questa sezione devono essere elencati i membri del gruppo di lavoro, indicando i relativi ruoli (rispetto all’organizzazione di progetto), una sintesi delle loro competenze ed esperienze (rimandando poi ai CV in allegato). In particolare per ciascuna figura proposta deve essere specificata l’incidenza percentuale delle giornate previste presso il capofila, l’ente cedente, e partecipanti rispetto all’impegno totale previsto per ciascuna figura.
8 Elementi migliorativi proposti: dovranno essere descritti gli elementi migliorativi che si intendono proporre per il perseguimento della maggior qualità ed efficacia delle attività richieste.
9 Modalità di trasferimento del know-how: dovranno essere descritte le modalità con cui il proponente s’impegna a garantire un adeguato trasferimento del know-how e della formazione nei confronti dei soggetti indicati dall’Amministrazione e una continuità di supporto.
10 Allegati: Curriculum Vitae dei componenti del gruppo di lavoro.
Per favorire il lavoro della Commissione si raccomanda la concisione espositiva e si invitano i partecipanti a non superare il limite delle 50 pagine, in formato A4, comprensive di eventuali disegni, schemi, tabelle e allegati, con l’utilizzo del font Times New Roman di dimensione 12 punti.
Sono esclusi da tale conteggio i CV allegati.
7 Avvio anticipato del servizio
L’Amministrazione si riserva la facoltà, in accordo alla normativa sugli appalti, di ordinare l'avvio anticipato del servizio anche prima della formalizzazione del rapporto tramite lettera-contratto; in tal caso, il Fornitore sarà tenuto a dare esecuzione al contratto agli stessi patti e condizioni così come risultanti dal presente capitolato e dalla propria offerta.
8 Condizioni del servizio
Sono a carico dell’appaltatore, intendendosi remunerati con il corrispettivo contrattuale, tutti gli oneri e rischi relativi alla prestazione oggetto del Contratto, nonché ogni attività, fornitura e relativi oneri che si
rendessero necessari per l’espletamento del servizio o, comunque necessari per un corretto e completo adempimento delle obbligazioni previste.
L’appaltatore si obbliga ad eseguire tutte le prestazioni nel rispetto delle norme vigenti e secondo le condizioni, le modalità, i termini e le prescrizioni contenute nel presente capitolato, nonché nella propria offerta se migliorativa.
Le prestazioni dovranno necessariamente essere conformi alle specifiche indicate nel presente capitolato. L’appaltatore si obbliga ad osservare, nell’esecuzione delle prestazioni contrattuali, tutte le norme e tutte le prescrizioni tecniche, di sicurezza e di protezione dei lavoratori in vigore, nonché quelle che dovessero essere emanate.
Gli eventuali maggiori oneri derivanti dalla necessità di osservare le norme e le prescrizioni di cui sopra, anche se entrate in vigore successivamente alla sottoscrizione del contratto, resteranno ad esclusivo carico dell’appaltatore, intendendosi in ogni caso remunerati con il corrispettivo contrattuale e l’appaltatore non potrà, pertanto, avanzare pretesa di compensi, a tal titolo, nei confronti dell’Amministrazione assumendosene ogni relativa alea.
L’appaltatore si impegna espressamente a manlevare e tenere indenne l’amministrazione da tutte le conseguenze derivanti dalla eventuale inosservanza delle norme e prescrizioni tecniche, di sicurezza, di igiene e sanitarie vigenti.
L’appaltatore si obbliga a consentire all’Amministrazione, di procedere, in qualsiasi momento e anche senza preavviso, alle verifiche della piena e corretta esecuzione delle prestazioni oggetto dell’appalto, nonché a prestare la propria collaborazione per consentire lo svolgimento di tali verifiche.
L’appaltatore si obbliga, infine, a dare immediata comunicazione all’Amministrazione di ogni circostanza che abbia influenza sull’esecuzione dell’attività di cui al presente appalto.
9 Penalità
Fatti salvi i casi di forza maggiore (intesi come eventi imprevedibili od eccezionali per i quali l’Aggiudicatario non abbia trascurato le normali precauzioni in rapporto alla delicatezza e la specificità delle prestazioni, e non abbia omesso di trasmettere tempestiva comunicazione all’Amministrazione) od imputabili all’Amministrazione, qualora non vengano rispettati i tempi previsti nell’offerta tecnica e nella progettazione esecutiva predisposti dall’Aggiudicatario, l’Amministrazione applicherà una penale per ogni giorno di ritardo pari allo 0,5‰ (zerovirgolacinque/permille) dell’importo contrattuale.
In caso di mancata messa a punto o adeguamento, oltre 20 (venti) giorni continuativi ed ininterrotti dalla rilevazione, di anomalie e/o errori riscontrati a seguito di collaudi e test di conformità con esito negativo e/o parzialmente negativo, l’Amministrazione applicherà una penale per ogni giorno di ritardo pari allo 0,5‰ (zerovirgolacinque/permille) dell’importo contrattuale.
Infine, in caso di inosservanza dei livelli di servizio (SLA) di cui al Capitolato tecnico, l’Amministrazione applicherà una penale per ogni evento di scostamento o inosservanza dei livelli prescritti, pari allo 0,5‰ (zerovirgolacinque/per mille) dell’importo contrattuale.
Si precisa che:
a) le penali di cui punti precedenti potranno essere applicate dall’Amministrazione fino alla concorrenza massima del 10% (dieci/percento) dell’importo contrattuale. Superata tale soglia, l’Amministrazione si riserva di procedere alla risoluzione del Contratto ;
b) l’Amministrazione farà precedere l’applicazione della penale da una contestazione scritta indicante l’inosservanza contestata, la quantificazione della penalità e le motivazioni che hanno condotto a tale quantificazione. L’Aggiudicatario potrà proporre le proprie controdeduzioni entro un termine pari a 10 (dieci) giorni lavorativi;
c) l’Amministrazione potrà disporre proroga dei termini il cui mancato rispetto dà luogo all’applicazione delle penali, previo accertamento dell’esistenza e validità della motivazione fornita dall’Aggiudicatario. In ogni caso l’Aggiudicatario non potrà invocare indennizzi, rimborsi o compensi di qualsiasi natura;
d) l’Amministrazione provvederà a compensare gli eventuali crediti derivanti dall’applicazione delle penali con il debito nei confronti dell’Aggiudicatario o avvalersi della cauzione definitiva, senza bisogno di diffida o procedimento giudiziario;
e) l’applicazione delle penali non pregiudicherà il diritto dell’Amministrazione ad ottenere la prestazione e, in ogni caso, sarà fatto salvo il diritto dell’Amministrazione di richiedere il risarcimento del maggior danno.
10 Ambienti
Il Fornitore è tenuto a mettere a disposizione gli strumenti e gli ambienti di sviluppo e di test necessari allo svolgimento delle attività contrattuali, salvo quanto diversamente precisato nel presente Capitolato.
11 Garanzie e responsabilità
Il Fornitore è responsabile e tiene sollevata l’Amministrazione e tutti gli altri soggetti coinvolti da ogni responsabilità dei danni, di qualsiasi natura, arrecati agli stessi o a terzi, durante l’esecuzione del presente Contratto o in connessione con esso. Il Fornitore è altresì responsabile dei danni causati dai propri dipendenti, consulenti e collaboratori.
12 Esecuzione in danno
Nel caso in cui il Fornitore non provveda agli interventi richiesti nei termini e con le modalità di cui ai precedenti articoli, la Stazione Appaltante potrà procedere ad affidare gli interventi ad altra Ditta con spesa a carico del Fornitore. La spesa relativa sarà liquidata dalla Stazione Appaltante e successivamente detratta dall'importo dovuto al Fornitore all'atto del primo pagamento utile o anche dalla garanzia definitiva
13 Obbligazioni dell’appaltatore
L’appaltatore si impegna, oltre a quanto già previsto nel presente capitolato, anche a:
• Effettuare il servizio impiegando, a propria cura e spese, tutte le strutture ed il personale necessario per la realizzazione degli stessi secondo quanto precisato nel presente capitolato;
• Predisporre tutti gli strumenti e le metodologie, comprensivi della relativa documentazione, atti a garantire elevati livelli di servizio, ivi compresi quelli relativi alla sicurezza e riservatezza (manuali operativi interni e sistemi di sicurezza gestione dati);
• Nell’adempimento delle proprie prestazioni ed obbligazioni osservare tutte le indicazioni operative, di indirizzo e di controllo che a tale scopo saranno predisposte e comunicate dall’Amministrazione;
• Mettere a disposizione e garantire il corretto funzionamento dei recapiti fax, telefono ed e-mail utilizzati per l’invio di tutte le comunicazioni;
Al fine di seguire, controllare e coordinare le attività di realizzazione del servizio, prima dell'inizio delle attività, il legale rappresentante del fornitore nominerà, dandone comunicazione scritta alla Stazione Appaltante, un responsabile operativo, il quale avrà specifico mandato di rappresentare ed impegnare il fornitore per tutte le attività inerenti lo svolgimento del servizio.
14 Obbligazioni derivanti dal rapporto di lavoro
Il Fornitore si obbliga ad ottemperare a tutti gli obblighi verso i propri dipendenti derivanti da disposizioni legislative e regolamentari vigenti in materia di lavoro, previdenza e disciplina infortunistica, assumendo a proprio carico tutti gli oneri relativi.
Il Fornitore si obbliga altresì ad applicare, nei confronti dei propri dipendenti occupati nelle attività contrattuali, le condizioni normative e retributive non inferiori a quelle risultanti dai contratti collettivi di lavoro applicabili, alla data della stipulazione del contratto, alla categoria e nelle località di svolgimento delle attività, nonché le condizioni risultanti da successive modifiche ed integrazioni.
Il Fornitore si obbliga altresì, fatto in ogni caso salvo il trattamento di miglior favore per il dipendente, a continuare ad applicare i suindicati contratti collettivi anche dopo la loro scadenza e fino alla loro sostituzione.
Gli obblighi relativi ai contratti collettivi nazionali di lavoro di cui ai commi precedenti vincolano Il Fornitore anche nel caso in cui questo non aderisca alle associazioni stipulanti o receda da esse per tutto il periodo di validità del contratto.
15 Obblighi di riservatezza
Il Fornitore dovrà garantire che l’eventuale trattamento dei dati per conto dell’Amministrazione sono prestati in piena conformità a quanto previsto dal D.Lgs. 196/2003.
Il Fornitore ha l’obbligo di mantenere riservati i dati e le informazioni di cui venga a conoscenza per l’esecuzione del contratto, di non divulgarli in alcun modo, né di farne oggetto di comunicazioni e trasmissioni senza l’espressa autorizzazione dell’Amministrazione Provinciale.
L'appaltatore risponde nei confronti della Provincia di eventuali violazioni dell’obbligo di riservatezza commesse da propri dipendenti.
16 Trattamento dei dati
Ai sensi del D. Lgs. n. 196/2003 e del GDPR UE 2016/679, i dati forniti dai concorrenti sono raccolti e trattati esclusivamente per lo svolgimento della procedura di gara e dell’eventuale successiva stipula e gestione del contratto.
Il conferimento di tali dati, compresi compresi eventuali dati sensibili e/o “giudiziari”, ai sensi del D. Lgs. n. 196/2003 e GDPR UE 2016/679, ha natura obbligatoria, connessa all’adempimento di obblighi di legge, regolamenti e normative comunitarie in materia di contratti pubblici relativi a lavori, servizi e forniture.
Il trattamento dei dati avverrà con l’ausilio di supporti cartacei, informatici e telematici. Il Titolare del trattamento dei dati personali è La Provincia di Salerno
L’aggiudicatario ai sensi dell’ Articolo 28 del GDPR UE 2016/679 è individuato come Responsabile del trattamento per i dati personali ed è tenuto a tutti gli obblighi previsti dalla normativa per tale figura.
17 Danni e responsabilità
Il Fornitore solleva la Committente da ogni eventuale responsabilità penale e civile verso terzi comunque connessa alla realizzazione ed all’esercizio delle attività di servizio affidate. Nessun ulteriore onere potrà dunque derivare a carico della Stazione Appaltante, oltre al pagamento del corrispettivo contrattuale.
Il Fornitore è responsabile dei danni derivanti e/o connessi all’esecuzione del servizio.
Il Fornitore è responsabile dei danni di qualsiasi natura, materiali o immateriali, diretti o indiretti, che dovessero essere causati da parte dei propri dipendenti, consulenti o collaboratori nonché da parte dei dipendenti, consulenti o collaboratori di questi ultimi, alla Committente ed al suo personale, ai suoi beni mobili e immobili, anche condotti in locazione, nonché ai terzi, ivi incluso il caso in cui tali danni derivino da informazioni inesatte o false colposamente fornite dal Fornitore nell’ambito dell’erogazione dei servizi di cui all’oggetto
Divieto di cessione del contratto
E’ fatto assoluto divieto al Fornitore di cedere, a qualsiasi titolo, il contratto a pena di nullità della cessione medesima.
La cessione di azienda e gli atti di trasformazione, fusione e scissione relativi al Fornitore non hanno singolarmente effetto nei confronti della Stazione Appaltante contraente fino a che il cessionario, ovvero il soggetto risultante dall’avvenuta trasformazione, fusione o scissione, non abbia comunicato alla Stazione Appaltante l’avvenuta cessione, e ferma restando la responsabilità solidale della società cedente o scissa. Nei novanta giorni successivi a tale comunicazione la Stazione Appaltante può opporsi al subentro del nuovo soggetto nella titolarità del contratto, con effetti risolutivi sulla situazione in essere, laddove ritenga che siano venuti meno i requisiti di carattere tecnico e professionale e i requisiti di carattere economico e finanziario presenti in capo all’originaria concessionaria.
In caso di inadempimento da parte del Fornitore degli obblighi di cui al presente paragrafo, la Stazione Appaltante, fermo restando il diritto al risarcimento del danno, ha facoltà di dichiarare risolto il contratto.
18 Risoluzione del contratto
Si conviene invece che l’ Amministrazione potrà risolvere il contratto di diritto ai sensi dell’art. 1456 cod. civ., previa contestazione degli addebiti al Fornitore e assegnazione di un termine non inferiore a quindici giorni per la presentazione delle controdeduzioni nei seguenti casi:
a. Fatto salvo quanto previsto dall’art. 71 comma 3 del D.P.R. 445/00, qualora fosse accertata la non veridicità del contenuto delle dichiarazioni sostitutive di certificazioni ed atti di notorietà rilasciate dal Fornitore ai sensi e per gli effetti degli artt. 38, 46 e 47 del D.P.R. 445/00, il contratto si intenderà risolto di diritto anche relativamente alle prestazioni già eseguite o in corso di esecuzione;
b. Quando le penalità raggiungono l’importo del 10% del valore contrattuale;
c. Qualora gli accertamenti antimafia presso la Prefettura competente risultassero positivi;
d. Mancata prestazione della garanzia, ove prevista, per responsabilità civile per danni causati a persone e a cose;
e. Mancato adempimento delle prestazioni contrattuali a perfetta regola d’arte, nel rispetto delle norme vigenti e secondo le condizioni, le modalità, i termini e le prescrizioni contenute nel presente Capitolato;
f. Mancata reintegrazione della garanzia eventualmente escussa entro il termine di 10 (dieci) giorni dal ricevimento della relativa richiesta da parte dell’Amministrazione;
g. Azioni giudiziarie intentate da terzi contro l’Amministrazione per fatti o atti compiuti dal Fornitore nell’esecuzione del servizio;
h. Negli altri casi previsti dal presente capitolato.
Per quanto non previsto e regolamentato, si applicheranno le disposizioni di cui agli articoli 1453 e seguenti del codice Civile.
19 Recesso
I primi sei mesi dalla data dell'avvio del servizio saranno considerati quali periodo di prova al fine di consentire all’Amministrazione una valutazione del rapporto. Durante tale periodo, l’Amministrazione potrà, a suo insindacabile giudizio, recedere in qualsiasi momento dal contratto mediante semplice preavviso di 10 giorni, da comunicare alla ditta a mezzo pec o altro strumento telematico.
Nell’eventualità del recesso di cui al periodo precedente, alla ditta appaltatrice spetterà il solo corrispettivo del servizio espletato, escluso ogni altro rimborso, indennizzo o pretesa a qualsiasi titolo o ragione.
L’Amministrazione, inoltre, ha diritto di recedere unilateralmente dal Contratto, in tutto o in parte, in qualsiasi momento, con un preavviso di almeno n. 30 (trenta) giorni solari, da comunicarsi al Fornitore con lettera raccomandata A/R o con Posta Elettronica Certificata nei casi di:
a) giusta causa;
b) reiterati inadempimenti del Fornitore, anche se non gravi;
Si conviene che per giusta causa si intende, a titolo meramente esemplificativo e non esaustivo:
i) qualora sia stato depositato contro il Fornitore un ricorso ai sensi della legge fallimentare o di altra legge applicabile in materia di procedure concorsuali, che proponga lo scioglimento, la liquidazione, la composizione amichevole, la ristrutturazione dell’indebitamento o il concordato con i creditori, ovvero nel caso in cui venga designato un liquidatore, curatore, custode o soggetto avente simili funzioni, il quale entri in possesso dei beni o venga incaricato della gestione degli affari del Fornitore;
ii) qualora il Fornitore perda i requisiti minimi richiesti;
iii) qualora taluno dei componenti l’organo di amministrazione o l’amministratore delegato o il direttore generale o il responsabile tecnico del Fornitore siano condannati, con sentenza passata in giudicato, per delitti contro la Pubblica Amministrazione, l’ordine pubblico, la fede pubblica o il patrimonio, ovvero siano assoggettati alle misure previste dalla normativa antimafia;
iv) ogni altra fattispecie che faccia venire meno il rapporto di fiducia sottostante il presente Xxxxxxxxx.
Dalla data di efficacia del recesso, il Fornitore dovrà cessare tutte le prestazioni contrattuali, assicurando che tale cessazione non comporti danno alcuno alla Committente.
In caso di recesso dell’Amministrazione il Fornitore ha diritto al pagamento delle prestazioni eseguite, purché correttamente ed a regola d’arte, secondo il corrispettivo e le condizioni contrattuali rinunciando espressamente, ora per allora, a qualsiasi ulteriore eventuale pretesa anche di natura risarcitoria ed a ogni ulteriore compenso o indennizzo e/o rimborso delle spese, anche in deroga a quanto previsto dall’articolo 1671 cod. civ.
20 Controversie
In caso di contestazioni o di impossibilità di accordi tra le parti, il foro competente è quello di Salerno.
X.xx Il Dirigente del Settore Servizi ai Comuni Xxxx. Xxxx Xxxxxxxx
Allegato 1 – Linee guida per la creazione del “Kit del Riuso”
•
Allegato 2 – Architettura e caratteristiche della piattaforma Apulia Moving
L’architettura a blocchi della piattaforma Apulia Moving, oggetto del riuso, è costituita da 4 blocchi principali (Canali Erogazione, Front End, Database e Back End) ognuno dei quali contiene moduli SW che implementano le funzionalità della piattaforma. Tutti i moduli SW sono stati realizzati in ambiente di sviluppo .NET utilizzando il DBMS SQL SERVER 12.
La figura, di seguito, presenta i 4 blocchi in cui sono rappresentati i principali moduli SW che saranno oggetto del riuso di seguito sinteticamente descritti per offrire una panoramica ad alto livello dell’organizzazione della piattaforma.
CANALI DI EROGAZIONE
Portale
Questo modulo implementa la presentazione dei contenuti e delle funzionalità utente mediante i principali browser di mercato (Chrome, Edge, Firefox).
FRONT END
TP Services
Questo modulo implementa i servizi (web services) che alimentano i canali di erogazione quando ci sono richieste utente relative ai collegamenti ed agli orari dei trasporti pubblici locali.
Travel Planner
Questo modulo implementa i servizi (web services) che risolvono le richieste utente relative alla costruzione di percorsi multimodali fornendo il punto di partenza ed il punto di arrivo. Restituisce al
canale di erogazione richiedente la lista delle soluzioni e per ciascuna di esse le tratte che la compongono.
Geocoder
Questo modulo implementa per i canali di erogazione i servizi (web services) di localizzazione su mappa delle linee, POI, Servizi pubblici, ed altre entità del territorio.
Search
Questo modulo implementa per i canali di erogazione i servizi (web services) di ricerca relative a: Linee, Fermate, Orari, notifica in tempo reale dei ritardi sulle corse TPL, POI ed Eventi.
DATABASE
Database Produzione TP-Esercizio
E’ la banca dati del Trasporto Pubblico in cui sono memorizzati linee, percorsi, fermate georeferenziate e corse. Per ciascuna linea è anche specificata la modalità di trasporto (gomma, ferro, acqua, aria) ed è aggiornata ogni volta che le aziende di trasporto modificano il servizio. Questa banca dati di produzione soddisfa in tempo reale le richieste che arrivano dai canali di erogazione.
Database Produzione POI/Eventi
E’ la banca dati in cui sono registrati tutti i POI (Point of Interest) e gli eventi programmati sul territorio in modo che l’utente nell’organizzare il viaggio possa anche avere informazioni sui luoghi, servizi pubblici, attività commerciali ed eventi relativi al territorio che intende visitare.
Database Work TP-Esercizio
E’ la banca dati del Trasporto Pubblico in cui sono caricati e preparati i dati che saranno successivamente trasferiti nel corrispondente database TP-Esercizio in ambiente di produzione.
BACK OFFICE
Importer
È il modulo che permette di caricare nel “Database Work TP-Esercizio” i dati del servizio TPL che le Aziende di Trasporto Pubblico forniscono in formato GTFS. Sono incluse in questo modulo anche le API per realizzare dei moduli di aggiornamento automatico dei dati da parte dei sistemi informativi delle aziende TPL.
Builder
È il modulo che permette di creare per il Travel Planner le connessioni tra tutti i percorsi caricati nel “Database Work TP-Esercizio” dall’Importer prima che questi siano pubblicati.
Publisher
È il modulo che pubblica nell’ambiente di produzione i dati preparati nell’ambiente “Work” dopo che sono stati validati e connessi dal Builder.
Allegato 3 – SLA del servizio i hosting il cloud
I livelli di servizio definiti mediante un sistema di indicatori su disponibilità, continuità operativa e performance da assicurare nell’erogazione dei servizi, definiscono un “Service Level Agreement” (SLA) che l’Aggiudicatario si obbliga a rispettare, pena l’applicazione delle penali di cui al Disciplinare di gara.
Quelli definiti di seguito, in particolare, sono da intendersi come prescrizioni minime sui livelli di servizio da rispettare. Resta ferma la facoltà per gli Offerenti, in sede di presentazione dell’offerta, di formulare livelli di servizio target maggiormente restrittivi. Si precisa che il monitoraggio e la verifica di eventuali scostamenti dagli SLA target, e la conseguente applicazione di penali, sarà effettuato nella fase di Mantenimento in Esercizio a regime del Sistema C2CM.
livelli di servizio del sistema “Coast to Coast Moving” | |
DEFINIZIONI | |
Descrizione del Servizio | Oggetto di misurazione è il Sistema C2CM nella sua globalità, ovvero l’intera infrastruttura applicativa e tecnologica dispiegata in Cloud per l’esercizio a regime dello stesso sistema. |
Erogazione del Servizio | h24 (00:00 - 24:00, 7 giorni su 7) |
Servizio in condizioni normali | Il Sistema C2CM deve risultare sempre disponibile ed accessibile in tutte le sue funzionalità, componenti applicative ed interfacce. Eventuali interruzioni sono ammesse esclusivamente per: ▪ cause di forza maggiore (eventi catastrofici); ▪ interventi di manutenzione straordinaria, purché preventivamente pianificati e concordati con l’Amministrazione. |
Disservizio bloccante | Per una qualsiasi ragione il Sistema C2CM non è accessibile o non è disponibile. |
Disservizio non bloccante | Il Sistema C2CM è accessibile e disponibile, anche se le sue prestazioni risultano parzialmente degradate rispetto alle normali condizioni di operatività. |
Periodo di osservazione | Mensile (giorni solari consecutivi ed ininterrotti con decorrenza dal primo giorno del mese). |
INDICATORI | SLA TARGET |
Disponibilità del Servizio | >= 95% della disponibilità teorica (espressa in minuti) del periodo di osservazione. |
Le frazioni di tempo (espresse in minuti) per indisponibilità del servizio (causa disservizi bloccanti o non bloccanti) saranno cumulate nel periodo di osservazione, ai fini della verifica di uno scostamento dallo SLA. | |
Tempo di ripristino di un disservizio bloccante | <= 4 ore dall’inizio del disservizio. |
Ogni frazione di tempo, pari a 2 ore, dell’intero periodo di disservizio, costituirà evento di scostamento dallo SLA target ai fini dell’applicazione delle penali. | |
Tempo di ripristino di un disservizio non bloccante | <= 24 ore dall’inizio del disservizio. |
Ogni frazione di tempo, pari a 24 ore, dell’intero periodo di |
disservizio, costituirà evento di scostamento dallo SLA target ai fini dell’applicazione delle penali. |
livelli di servizio del portale web | |
DEFINIZIONI | |
Descrizione del Servizio | Oggetto di misurazione è il portale web dispiegato per l’erogazione dei servizi del Sistema C2CM. Tale componente riveste carattere di centralità nell’intero sistema e, come tale, deve soddisfare requisiti di disponibilità maggiormente stringenti. |
Erogazione del Servizio | h24 (00:00 - 24:00, 7 giorni su 7) |
Servizio in condizioni normali | Il portale web del Sistema C2CM è di norma sempre disponibile ed accessibile, ed in grado di assicurare i tempi di risposta specificati di seguito. |
Disservizio bloccante | Per una qualsiasi ragione il portale web non è accessibile o non è disponibile. |
Disservizio non bloccante | Il portale web è accessibile e disponibile, anche se le sue prestazioni risultano parzialmente degradate rispetto alle normali condizioni di operatività. |
Periodo di osservazione | Mensile (giorni solari consecutivi ed ininterrotti con decorrenza dal primo giorno del mese). |
INDICATORI | SLA TARGET |
Disponibilità del Servizio | >= 97% della disponibilità teorica (espressa in minuti) del periodo di osservazione. |
Le frazioni di tempo (espresse in minuti) per indisponibilità del servizio (causa disservizi bloccanti o non bloccanti) saranno cumulate nel periodo di osservazione ai fini della verifica di uno scostamento dallo SLA. | |
Tempo di ripristino di un disservizio bloccante | <= 1 ora dall’inizio del disservizio |
Ogni frazione di tempo, pari ad 1 ora, dell’intero periodo di disservizio, costituirà evento di scostamento dallo SLA target ai fini dell’applicazione delle penali. | |
Tempo di ripristino di un disservizio non bloccante | <= 8 ore dall’inizio del disservizio |
Ogni frazione di tempo, pari a 8 ore, dell’intero periodo di disservizio, costituirà evento di scostamento dallo SLA target ai fini dell’applicazione delle penali. | |
Tempo di risposta | <= 5 secondi nel 95% degli accessi nel periodo di osservazione. |
Il tempo di risposta si misura come intervallo temporale tra l’invio di una richiesta al portale web e la ricezione della risposta sul client, al netto della latenza introdotta dalla rete di trasmissione. | |
LIVELLI DI SERVIZIO DELLA MANUTENZIONE CORRETTIVA E ADEGUATIVA |
DEFINIZIONI | |
Descrizione del Servizio | Oggetto di misurazione è il servizio di manutenzione correttiva e adeguativa delle componenti software del Sistema C2CM a qualsiasi titolo dispiegate nella fornitura: componenti applicative; interfacce di cooperazione; componenti middleware; software di base; software RDBMS; ecc.. |
Erogazione del Servizio | Il servizio è di norma erogato in orario lavorativo. |
Richiesta di intervento | La richiesta di un intervento di manutenzione correttiva o adeguativa registrata sul sistema di trouble ticketing. |
Manutenzione correttiva in condizioni di urgenza | Una componente software non opera correttamente a causa di una qualche anomalia o difetto e il suo malfunzionamento produce un disservizio bloccante della stessa e/o di altre componenti software tale da richiedere un intervento di manutenzione e/o di ripristino in condizioni di urgenza. |
Manutenzione correttiva in condizioni normali | Una componente software non opera correttamente a causa di una qualche anomalia o difetto e il suo malfunzionamento non produce disservizi bloccanti o situazioni di degrado della stessa e/o di altre componenti software tali da richiedere un intervento di manutenzione e/o di ripristino in condizioni di urgenza. |
Manutenzione adeguativa | Una componente software che opera correttamente deve essere sostituita o implementata sulla base di un intervento programmato concordato con l’Amministrazione. |
Periodo di osservazione | Trimestrale (giorni solari consecutivi ed ininterrotti con decorrenza dal primo giorno del trimestre). |
INDICATORI | SLA TARGET |
Tempo di intervento per manutenzione in condizioni di urgenza | <= 4 ore nel 95% degli interventi effettuati nel periodo di osservazione. |
Ai fini della verifica di uno scostamento dallo SLA, la tempistica sarà misurata come ore lavorative continuative prestate dalla registrazione della richiesta sul sistema di trouble ticketing. | |
Tempo di intervento per manutenzione in condizioni normali | <= 12 ore nel 95% degli interventi effettuati nel periodo di osservazione. |
Ai fini della verifica di uno scostamento dallo SLA, la tempistica sarà misurata come ore lavorative continuative prestate dalla registrazione della richiesta sul sistema di trouble ticketing. | |
Tempo di intervento per manutenzione adeguativa | <= 5 giorni nel 95% degli interventi effettuati nel periodo di osservazione. |
Ai fini della verifica di uno scostamento dallo SLA, la tempistica dell’intervento sarà misurata come giornate lavorative continuative prestate dalla registrazione della richiesta sul sistema di trouble ticketing. |
LIVELLI DI SERVIZIO DI HELP-DESK
DEFINIZIONI | |
Descrizione del Servizio | Oggetto di misurazione è il servizio di help-desk centralizzato di raccolta e gestione delle richieste di assistenza e supporto. |
Erogazione del Servizio | Il servizio è di norma erogato in orario lavorativo. |
Richiesta di intervento | La richiesta di un intervento di assistenza o supporto registrata sul sistema di trouble ticketing. Si assume che l’orario di registrazione della richiesta coincida con l’orario di apertura del ticket. |
Servizio Help-Desk di I° Livello | Inteso come presa in carico della richiesta di intervento con apertura di un ticket, valutazione, risoluzione e chiusura del ticket - per problematiche e richieste ricorrenti o che trovano rapida soluzione - ovvero smistamento al II° livello per assistenza e supporto di tipo specialistico. |
ServizioHelp-Desk di II° Livello | Inteso come presa in carico della richiesta smistata dal I° livello, valutazione, risoluzione e chiusura del ticket. |
Periodo di osservazione | Mensile (giorni solari consecutivi ed ininterrotti con decorrenza dal primo giorno del mese). |
INDICATORI | SLA TARGET |
Disponibilità del Sistema trouble ticketing. | >= 97% della disponibilità teorica (espressa in minuti) del periodo di osservazione. |
Le frazioni di tempo (espresse in minuti) per indisponibilità del servizio saranno cumulate nel periodo di osservazione, ai fini della verifica di uno scostamento dallo SLA. | |
Percentuale Ticket Evasi | >= 98% dei ticket aperti nel periodo di osservazione. |
Ai fini della verifica di uno scostamento dallo SLA, saranno considerati solo i ticket aperti e chiusi nel rispetto delle tempistiche, con risoluzione positiva della richiesta di intervento. | |
Tempo di chiusura di un ticket al I° livello | <= 2 ore nel 95% dei ticket aperti nel periodo di osservazione. |
Ai fini della verifica di uno scostamento dallo SLA, sarà considerato l’intervallo di tempo lavorativo (espresso in minuti) intercorrente tra l’orario di apertura e chiusura del ticket. | |
Tempo di chiusura di un ticket al II° livello | <= 8 ore nel 95% dei ticket aperti nel periodo di osservazione. |
Ai fini della verifica di uno scostamento dallo SLA, sarà considerato l’intervallo di tempo lavorativo (espresso in minuti) intercorrente tra l’orario di apertura e chiusura del ticket, incluso il tempo di lavorazione al I° livello. |
LIVELLI DI SERVIZIO SUPPORTO REDAZIONALE | |
DEFINIZIONI | |
Descrizione del Servizio | Oggetto di misurazione è il servizio di assistenza e supporto per attività redazionali che interessano il portale web e/o l’APP. Il servizio include interventi di revisione, adattamento di stile, ed |
eventuale integrazione di contenuti grafici e/o multimediali, a partire da un contenuto editoriale o informativo predisposto in bozza dal richiedente. | |
Erogazione del Servizio | Il servizio è di norma erogato in orario lavorativo. |
Richiesta di Pubblicazione | La richiesta di pubblicazione o di aggiornamento di un contenuto editoriale veicolata attraverso processi che saranno formalizzati in fase di progettazione esecutiva e registrata sul sistema di trouble ticketing. |
Periodo di osservazione | Mensile (giorni solari consecutivi ed ininterrotti con decorrenza dal primo giorno del mese). |
INDICATORI | SLA TARGET |
Disponibilità del Database epr la registrazione dei contenuti | >= 97% della disponibilità teorica (espressa in minuti) del periodo di osservazione. |
Le frazioni di tempo (espresse in minuti) per indisponibilità del servizio saranno cumulate nel periodo di osservazione, ai fini della verifica di uno scostamento dallo SLA. | |
Tempo di pubblicazione | <= 8 ore nel 95% delle richieste di pubblicazione pervenute nel periodo di osservazione. |
Ai fini della verifica di uno scostamento dallo SLA, sarà considerato l’intervallo di tempo lavorativo (espresso in minuti) intercorrente tra l’orario di apertura e chiusura del ticket. |
livelli di servizio aggiornamento dATABASE | |
DEFINIZIONI | |
Descrizione del Servizio | Oggetto di misurazione è il servizio di aggiornamento e/o implementazione delle informazioni gestite dal Sistema C2CM e strutturate nel Database sottostante. |
Erogazione del Servizio | Il servizio è di norma erogato in orario lavorativo. |
Richiesta di aggiornamento | Le richieste di aggiornamento e/o implementazione di dati e/o informazioni sono di norma veicolate e registrate attraverso il sistema di trouble ticketing. |
Periodo di osservazione | Trimestrale (giorni solari consecutivi ed ininterrotti con decorrenza dal primo giorno del trimestre). |
INDICATORI | SLA TARGET |
Tempo di aggiornamento | <= 5 giorni nel 95% delle richieste di aggiornamento pervenute nel periodo di osservazione. |
Ai fini della verifica di uno scostamento dallo SLA, la tempistica dell’intervento sarà misurata come giornate lavorative continuative prestate dalla registrazione della richiesta di aggiornamento sul sistema di trouble ticketing. |