UFFICIO DEL SINDACO – PROTEZIONE CIVILE DIREZIONE RISORSE TECNOLOGICHE
UFFICIO DEL SINDACO – PROTEZIONE CIVILE DIREZIONE RISORSE TECNOLOGICHE
Progetto GEPC
Gestione Emergenze Protezione Civile
CAPITOLATO SPECIALE D’APPALTO
SOMMARIO
1. Premessa e presentazione generale dell'esigenza 3
2. Definizioni, abbreviazioni e convenzioni generali 5
3. Natura ed elementi della fornitura 6
3.1 Natura e linee guida della fornitura 6
3.2 Elementi specifici della fornitura 8
4. Sistemi messi a disposizione dall’Ente 11
5. Interazioni con gli altri sistemi informativi 13
5.1 BDPI (Banca Dati Patrimonio Informativo) 13
5.2 SIT (Sistema Informativo Territoriale) 14
5.3 SIGEDO (Protocollo dell’Ente) 14
5.4 PIUSS – Città dei Saperi 15
5.5 Progetto ELI4U 16
5.6 Progetto X.X.Xx.Xx 17
5.7 Altre banche dati 17
6. Caratteristiche dettagliate della fornitura 18
7. Servizi di assistenza e di manutenzione 18
7.1 Manutenzione ordinaria (compresa) 19
7.2 Manutenzione straordinaria (non compresa) 20
7.3 Condizioni per lo svolgimento delle attività di manutenzione 20
7.4 Affidamento servizi di assistenza e di manutenzione ordinaria dopo il periodo di durata contrattuale 21
8. Organizzazione e gestione del rapporto contrattuale 21
8.1 Vincoli contrattuali 21
8.2 Referenti del Fornitore e dell’Ente 22
8.3 Obblighi del Fornitore 23
8.4 Obblighi dell’Ente 24
8.5 Codici sorgente 24
9. Modalità, tempi e luoghi di espletamento della fornitura 25
10. Test, verifiche e collaudo 26
10.1 Test di accettazione e verifiche ufficiali 27
10.2 Collaudo 29
11. Penali 30
12. Diritti di proprietà 32
13. Modalità di pagamento 33
14. Trattamento dei dati personali e sensibili 34
15. Foro competente 34
1. Premessa e presentazione generale dell'esigenza
La Protezione Civile del Comune di Firenze ha necessità di dotarsi di un sistema capace di rispondere in modo proattivo e compiuto a tutte le esigenze in ambito di gestione emergenze o di organizzazione di grandi eventi che si possono presentare nell'area fiorentina, ma anche poter disporre di un supporto affidabile, funzionale ed adeguato per gestire la quotidiana attività dell’ufficio e della sala operativa; quindi di tematiche e di ambiti di rilevanza maggiore che vanno anche oltre a quanto espressamente individuato e richiesto nella Legge 225 del 1992, ss.mm.ii .
Si fa riferimento alla predisposizione di un sistema complesso sotto diversi aspetti:
• infrastrutturalmente articolato e tecnologicamente evoluto;
• in grado di interfacciarsi e di interoperare, quindi bidirezionalmente, con altri applicativi legacy già in possesso dell’Ente o forniti da soggetti terzi;
• capace di trattare informazioni proprie o recuperate da diverse banche dati sia interne che esterne all’Ente, coinvolgendo dati georeferenziati o meno e, eventualmente, generando anche degli opportuni feedback verso i diversi sistemi sorgente coinvolti;
• affidabile, sicuro, adeguatamente ridondato e multifunzionale;
• dotato di messaggistica integrata a livello di e-mail, dati, SMS e FAX (elenco esemplificativo, ma non esaustivo);
• capace di interconnettersi in modo nativo con il (nuovo) centralino ed il (nuovo) sistema di ponti radio impiegati dalla Protezione Civile del Comune;
• accedibile in modo semplice ed adeguato attraverso dispositivi fissi e mobili quali notebook e netbook, ma anche attraverso palmari e tablet;
• capace di tracciare e di geolocalizzare gli automezzi, le squadre ed i diversi sistemi mobili dislocati sul territorio.
Pertanto si richiede di realizzare un sistema che sia in grado di assicurare un supporto specifico e mirato a tutti gli eventi gestiti, agli interventi coordinati ed a tutte le tipologie di operazioni condotte dalla Protezione Civile per far fronte in modo sempre più efficiente, efficace e puntuale alle diverse situazioni, agli eventi ed alle segnalazioni normalmente prese in carico, sia di piccola, media che grave entità.
Il Comune di Firenze è attualmente dotato di alcune applicazioni software che, a livello base e parziale, permettono una gestione molto semplificata delle attività della sala operativa della Protezione Civile (d’ora in avanti anche indicata come PC) ed una correlata gestione delle anagrafiche di servizio collegate alle stesse attività. Si tratta di applicazioni che non riescono a rispondere compiutamente e puntualmente a tutte le esigenze manifestate dalla PC e che necessitano di un intervento consistente per supportare tutte le funzionalità richieste oltre alla realizzazione di moduli per l’integrazione con il sistema di centralino, con la rete di ponti radio e con i futuri dispositivi di geolocalizzazione. Si pone, pertanto, l’esigenza di superare l’attuale situazione con un investimento mirato ed
omnicomprensivo per la realizzazione di un sistema unico, integrato, tecnologicamente evoluto e funzionalmente adeguato a rispondere indistintamente a tutte le diverse necessità rilevate, comunque salvaguardando gli investimenti già condotti dall’Ente nel tempo e riutilizzando, ad esempio, lo stesso hardware e le medesime licenze del software di base.
Il Comune si propone di giungere a questo risultato attraverso l’acquisizione di un nuovo sistema informativo di gestione della sala operativa e delle predette attività che, nel rispondere a requisiti quali la piena integrazione di dati e di funzionalità, la sicurezza a tutti i livelli, il supporto alla completa interoperabilità e la maggior efficienza del personale contempli anche l’offerta e l’implementazione di aspetti importanti quali la cooperazione applicativa nei confronti di altri applicativi/uffici interni dell’Ente o, eventualmente, una futura estensione di utilizzo, tramite moduli specifici e personalizzazioni ad hoc, del sistema proposto anche ad altre Direzioni. Il tutto senza tralasciare la possibilità di erogare servizi mirati on-line e web-based ai cittadini, ad esempio per la consultazione delle segnalazioni effettuate, del piano neve, del piano ghiaccio o del piano forti piogge dell’Ente, la visualizzazione dell’eventuale stato di attivazione e di evoluzione dello stesso (parzialmente) in tempo reale, delle reportistiche appositamente messe a disposizione dall’Amministrazione, etc., quindi, in previsione, la possibilità di realizzare anche un portale tematico.
Tale nuovo sistema informativo è, di qui in avanti, denominato GEPC o Gestione Emergenze (Grandi Eventi) Protezione Civile.
Si precisa che l’Ente non intende porre in essere una mera fornitura con l’obiettivo dei mezzi, ma richiede il raggiungimento dell’obiettivo del risultato finale quindi l’effettiva messa in esercizio di un sistema complesso che soddisfi tutti i requisiti e le necessità dettagliate in questo Capitolato e nell’Allegato Tecnico.
Obiettivi principali del GEPC sono i seguenti:
- Consentire la gestione unitaria ed integrata di tutte le informazioni, le procedure e di tutti i processi della Protezione Civile del Comune di Firenze e di tutto ciò che è pertinente alla relativa sala operativa. Si precisa che obiettivo del GEPC è anche disegnare l’infrastruttura informatica di tale gestione in collaborazione con i tecnici dell’Ente.
- Assicurare il trattamento dei summenzionati dati e delle informazioni a tutti gli utenti del Comune per i quali ciò venga ritenuto necessario, secondo ruoli e privilegi specifici, mediante diverse profilazioni (ad esempio supervisore, coordinatore di squadra, operatore di sala, operatore generico, cittadino, etc.). L’impostazione di ruoli e privilegi sarà configurabile da parte dell’utente avente il ruolo di amministratore del GEPC, nel rispetto di quanto previsto dalla normativa vigente sulla tutela dei dati personali.
- Fornire precisi strumenti per l’interoperabilità con gli altri sistemi e le banche dati coinvolti a vario titolo specificati in seguito;
- Offrire cruscotti riepilogativi e quadri di sintesi orientati al supporto alle decisioni, sia in gestione ordinaria che in emergenza operativa, al fine di condurre analisi critiche sulle procedure attuate; produrre report statistici e a consuntivo delle attività svolte e sui sistemi coinvolti in determinati eventi ed
emergente; poter generare rapporti di servizio delle attività svolte; gestire ed effettuare anche simulazioni semplificate, ma estremamente necessarie alla progettazione ed alla redazione dei diversi piani di emergenza (neve, ghiaccio, forti piogge, alluvione, etc.).
2. Definizioni, abbreviazioni e convenzioni generali
In questo Capitolato d’Appalto e nell’Allegato Tecnico sono utilizzate, tra le altre, le seguenti abbreviazioni e sigle:
• Capitolato, Capitolato d’Appalto, Capitolato Speciale di Appalto: si intende sempre il presente documento, a cui è associato l’Allegato Tecnico.
• Comune, Ente, Amministrazione, Committente: il Comune di Firenze;
• Concorrenti, Ditte Offerenti o Partecipanti: le aziende partecipanti alla gara ammesse alla fase di valutazione delle rispettive offerte tecniche;
• Ditta Aggiudicataria, Fornitore, Aggiudicatario: la società, la ditta od il raggruppamento temporaneo di imprese (RTI) che, al termine dell’intero procedimento di gara, ne risulterà vincitrice;
• GEPC: il progetto complessivo riguardante il sistema Gestione Emergenze (o Grandi Eventi) della Protezione Civile del Comune di Firenze; nel seguito, nel far riferimento al GEPC, si utilizzeranno come suoi sinonimi assolutamente equivalenti anche i termini Applicazione, Software, Procedura o Sistema, generalmente riportati con la prima lettera in maiuscolo;
• DRT: la Direzione Risorse Tecnologiche del Comune, con sede in xxx Xxxxxxxxx Xxxxxxxx 000 – Firenze, sede secondaria di espletamento della fornitura;
• PC: la Protezione Civile del Comune, con sede in xxx Xxxxxxxxx 00 – Firenze, sede principale di espletamento della fornitura;
• Referenti dell’Ente: il Referente amministrativo ed i Referenti tecnici individuati dal Comune per questo progetto;
• Referenti del Fornitore: il Referente commerciale e il Capo progetto della Ditta Aggiudicataria, da essa indicati ai fini dell’esecuzione del contratto;
• SAL: Stato Avanzamento Lavori;
• SLA: Service Level Agreement;
• SPC: Servizi Professionali Correlati alla presente fornitura;
• API: Application Programming Interface;
• UML: Unified Modeling Language, è un linguaggio standard di modellazione, di specifica e di progettazione secondo il paradigma OO (Object-Oriented) o CBSD (Component Based Software Development);
• banche dati e procedure di particolare interesse per il progetto:
o BDPI – Banca Dati Patrimonio Informativo;
o SIT – Sistema Informativo Territoriale;
x XXXXXX – Sistema Innovativo di gestione della Mobilità nelle aree metropolitane (progetto multiente);
o SIGEDO – SIstema GEstione DOcumentale;
• sigle ed organismi internazionali di interesse:
o ECMA – European Association for Standardizing Information and Communication Systems, cioè la ex European Computer Manufacturers Association;
o ETSI – European Telecommunications Standards Institute;
o FLOSS – Free Libre Open Source Software;
o GIS – Geographic Information System;
o GPS – Global Positioning System;
o GPRS – General Packet Radio Service;
o GSM – Global System for Mobile communications;
o IEEE – Institute of Electrical and Electronics Engineers;
o IETF – Internet Engineering Task Force;
o OASIS – Organization for the Advancement of Structured Information Standards;
o OGC – Open Geospatial Consortium;
o OMG – Object Management Group;
o W3C – World Wide Web Consortium;
o WS-I – OASIS Web Services Interoperability.
Altre sigle ed acronimi più specifici, o di uso limitato nel testo, saranno utilizzati e descritti nei rispettivi contesti di interesse.
3. Natura ed elementi della fornitura
3.1 Natura e linee guida della fornitura
Il Sistema GEPC proposto dai Concorrenti deve essere in grado di gestire al meglio le specifiche esigenze di automazione relative ai servizi, in attività normale e di emergenza, ed alle diverse necessità dell’Ufficio di Protezione Civile di un Ente Locale quale il Comune di Firenze, quindi, già dotato di un sistema informativo aziendale composito anche se non presente nel particolare ambito di interesse per questa fornitura.
A livello legislativo, il Sistema offerto dovrà essere conforme e rispettare i vincoli, le indicazioni e tutto quant’altro previsto dalla normativa vigente in ambito di Protezione Civile, in tal senso è opportuno citare almeno i seguenti riferimenti (vedere xxxx://xxx.xxxxxxxxxxxxxxxx.xx/):
• Legge n. 225 del 24/021992, istituzione del servizio nazionale della protezione civile;
• Legge n. 401 del 9/11/2001, disposizioni urgenti per il coordinamento operativo delle strutture preposte alle attività di protezione civile;
• Legge Xxxxxxx Xxxxxxx x. 00 del 29/12/2003, ordinamento del sistema regionale della Protezione Civile e disciplina della relativa attività;
• Legge n. 152 del 26/07/2005, disposizioni urgenti in materia di Protezione Civile;
• Delibera di Giunta del Comune di Firenze n. 16 e pubblicata il 24/02/2011, piano per la gestione integrata dell’emergenza neve/ghiaccio.
Le funzionalità offerte ed i dati gestiti dal Sistema GEPC devono rispondere, sia in termini qualitativi che quantitativi, a livelli di interoperabilità e di integrazione adeguati ed almeno pari a quelli assicurati e già presenti negli altri applicativi con cui il Sistema si dovrà interfacciare; aspetti successivamente ripresi ed opportunamente approfonditi nel prosieguo del documento.
Per tale motivo il Sistema GEPC va inteso e considerato come un insieme funzionale complesso, composto non solo dal Sistema oggetto della presente fornitura, ma anche da ogni altro eventuale e ulteriore programma a corredo, accessorio, componente, parte, modulo, libreria, specifica macchina o dispositivo hardware, documento, manuale, procedure operative e, in genere, ogni altra parte necessaria alla regolare installazione, funzionamento e proficuo uso di tale insieme funzionale da parte del personale dell'Amministrazione. A questo proposito si ricorda che l’aggiudicazione avverrà sulla base della valutazione degli aspetti funzionali, progettuali, economici, di integrazione, di interoperabilità, etc. rilevabili dalle offerte delle Ditte Concorrenti. La valutazione riguarderà sia l’analisi dell’eventuale prodotto originario sia l’attitudine (per come riscontrabile dalla documentazione e dalle referenze presentate in sede di gara) ad adeguare, se necessario, tale prodotto al livello di compiutezza funzionale richiesto nel presente capitolato, mediante specifiche attività di personalizzazione e adeguamento applicativo. Ci si riferisce col termine di GEPC (o Sistema, Applicativo, Applicazione, etc.) al prodotto risultante dalle varie attività implementative previste dal progetto.
Saranno a carico del Fornitore tutti gli apparati, i componenti hardware e/o software specializzati che dovessero rivelarsi, successivamente, indispensabili per assicurare una qualsiasi tra le funzionalità del Sistema GEPC, a regime, ma che non sono state espressamente indicati preventivamente come tali nella sua offerta tecnica e riportate chiaramente sul documento “Progetto GEPC”. Tale situazione può comportare un collaudo negativo del Sistema o di alcune sue parti.
Inoltre, tenuto conto che il Sistema GEPC dovrà fornire delle interfacce di accesso e di utilizzo improntate sul paradigma web-based sia ad utenze interne che, molto probabilmente, a cittadini (in questo caso per operazioni limitate e/o di sola consultazione), lo stesso dovrà essere assolutamente in linea con le ultime norme e le leggi emanate in tale ambito. In particolare dovrà essere conforme a:
• il D.P.R. 1 marzo 2005, n. 75, regolamento di attuazione della Legge Stanca per favorire l’accesso dei soggetti disabili agli strumenti informatici;
• il Decreto Ministeriale 8 luglio 2005 contenente i requisiti tecnici ed i diversi livelli per l’accessibilità agli strumenti informatici (sono già pubblicati, ed aperti alla consultazione, i nuovi requisiti tecnici a cura del gruppo di lavoro per la revisione del documento A del D.M. 8 luglio 2005);
• la Direttiva del Ministro per la Pubblica Amministrazione e Innovazione 26 novembre 2009, n. 8, per la riduzione dei siti web delle pubbliche amministrazioni e per il miglioramento della qualità dei servizi e delle informazioni on-line al cittadino e alle imprese;
• il Decreto legislativo n. 235/2010, ovvero le modifiche e le integrazioni al decreto legislativo 7 marzo 2005, n. 82, recante Codice dell'Amministrazione Digitale, a norma dell'art.33 della legge 18 giugno 2009;
• tutte le circolari, vademecum, le linee guida e/o le linee attuative emanate in tal senso dall’Autorità per l'Informatica nella Pubblica Amministrazione (AIPA), sostituita poi dal Centro Nazionale per l'Informatica nella Pubblica (CNIPA), ad oggi DigitPA (riferimenti sul sito xxxx://xxx.xxxxxxx.xxx.xx/) e dal Garante per la Privacy.
3.2 Elementi specifici della fornitura
Gli elementi specifici, affrontati in dettaglio nei successivi paragrafi del presente documento e nell’Allegato Tecnico, da comprendere nella presente fornitura e totalmente coperti dall’importo messo a gara, sono i seguenti:
1) SOFTWARE
Il software ed i relativi moduli saranno descritti brevemente nel seguito di questo Capitolato ed approfonditi nell’Allegato Tecnico. Nello specifico, tutti i requisiti e le caratteristiche generali, tecnologiche, architetturali e funzionali cui il Sistema dovrà aderire sono completamente specificate nell’Allegato Tecnico.
E’ ammessa la possibilità di utilizzare componenti software, middleware, framework e librerie prodotte da terze parti, integrate nel Sistema proposto, nel pieno rispetto delle seguenti condizioni:
✓ piena responsabilità della Ditta Aggiudicataria per quanto attiene tutta la gestione ed il corretto funzionamento di tali componenti;
✓ compresa nel prezzo della fornitura, la cessione all’Ente della loro licenza d’uso, se prevista, illimitata e permanente, rispettando sia il numero che la tipologia di utenze sopraindicate.
Da questi vincoli sono escluse le eventuali librerie o le specifiche API necessarie per l’integrazione con i sottosistemi hardware descritti nel prosieguo, ovvero inerenti il (nuovo) centralino, la (nuova) rete di ponti radio ed i dispositivi di geolocalizzazione sugli automezzi di interesse. Generalmente la specifica di tali interfacce e delle relative API, corredate dalla relativa documentazione tecnica, sono fornite dal produttore/fornitore dell’apparato hardware di interesse contestualmente con la fornitura dello stesso.
2) LICENZE
La fornitura include la licenza d’uso complessiva associata al Sistema GEPC che sarà permanente, cioè non soggetta a scadenza ed obbligatoriamente intestata a questa Amministrazione. Nello specifico, oltre alla figura tipica dell’amministratore dell’applicazione, si distinguono poi più tipologie di utenze diverse che potranno utilizzare il Sistema:
• utente evoluto/operatore di sala che potrà esercitare ed utilizzare a pieno tutte le funzionalità previste dal Sistema offerto senza alcuna limitazione o
vincolo operativo;
• utente di sola consultazione/operatore semplice che potrà usufruire di un insieme ristretto di funzionalità, ad esempio senza accesso alle specifiche funzioni di sala, vincolandone le capacità operative e di interazione con il Sistema, consentendo specifici inserimenti “semplificati e limitati” o solo attività di consultazione;
• utente anonimo che potrà usufruire solo di funzionalità ben precise ed estremamente limitate e solamente in consultazione/visualizzazione.
Nella presente fornitura devono essere previste almeno:
✓ numero 20 (venti) licenze concorrenti di utenti evoluti/operatori di sala;
✓ licenze illimitate concorrenti per utenze di sola consultazione/semplici od utenze anonime.
Se il Sistema offerto non distingue tale tipologia di operatori, rimane totalmente a carico della Ditta Concorrente descrivere e proporre soluzioni adeguate in grado di rispondere a tale specifica esigenza dell’Ente; ad esempio offrire licenze concorrenti in numero illimitato per tutte le tipologie di utenze previste dal Sistema offerto in gara risponde completamente a tale necessità.
Nell’offerta economica {VELU} viene richiesto di indicare il costo per la fornitura di ulteriori numero 5 (cinque) LICENZE UTENTI concorrenti di tipo evoluto. Si ribadisce che nel caso un Concorrente indichi che la fornitura prevede già licenze illimitate o che il costo associato alla fornitura di queste ulteriori licenze è pari a 0 € (zero euro), implicitamente dichiara che il Sistema GEPC proposto all’Ente è già dotato di una licenza illimitata relativamente a qualsiasi tipologia concorrente di utenza e/o di operatore che, di conseguenza, potranno utilizzarlo nell’esercizio di qualsiasi funzionalità esistente senza alcun vincolo o limitazione.
3) SERVIZI PROFESSIONALI CORRELATI
L’appalto include l’erogazione dei Servizi Professionali Correlati, d’ora in avanti anche SPC, elencati nel seguito e dettagliati in modo approfondito nell’Allegato Tecnico, sostanzialmente finalizzati alla personalizzazione ed alla messa in opera del Sistema, all’assistenza sullo stesso ed all’addestramento degli utenti:
a) Eventuale predisposizione, in forma definitiva, del “Progetto GEPC”.
Il progetto definitivo conterrà l’indicazione esaustiva degli SPC ed il dettaglio dei relativi tempi di attuazione del progetto, nonché dei prodotti/moduli e dei relativi tempi di rilascio, con i vincoli delle verifiche previste dal presente Capitolato. Esso si baserà su quanto già indicato nel documento di progetto presentato dal Concorrente in sede di gara, quindi solo con eventuali modifiche minimali, e verrà aggiornato apportandovi tutte le modifiche occorrenti per una migliore e più completa aderenza alle esigenze del Committente.
b) Importazione ed adeguamento dei dati.
Questo servizio si concretizza dapprima nell’analisi dei dati necessari e già
contenuti negli archivi gestiti dall’Ente (applicativi presso la PC, SIT, BDPI, etc.) e delle azioni necessarie al fine della loro importazione nel database poi impiegato dal Sistema offerto. Successivamente a tale analisi il Fornitore svilupperà appositi programmi e script di importazione schedulabili. Nel caso in cui l’analisi dei dati pregressi accerti l’esistenza di insormontabili incompatibilità strutturali o, per alcuni di tali dati, una qualità eccessivamente bassa, il Fornitore si impegna comunque, compreso nel costo, a mettere a disposizione del Comune risorse – di qualifica e in quantità che saranno da concordare congiuntamente fra le Parti – atte ad agevolare comunque l’Ente nei tentativi di recupero il più possibile automatico delle più importanti informazioni da quest’ultimo individuate.
c) Servizio di personalizzazione applicativa del prodotto originario offerto.
Sono comprese in tale servizio tutte le attività del Fornitore necessarie per “costruire” il GEPC, ovverosia adeguare completamente il prodotto originario alle esigenze dell’Ente, con principale e prioritario riguardo alle funzionalità espresse nel presente capitolato.
d) Formazione degli utenti.
Il servizio riguarda la formazione degli utenti del Comune, per tutte le tipologie di utenza successivamente indicate, con la produzione dei relativi manuali e la realizzazione di una guida operativa utilizzabile on-line. Il numero totale di utenti da formare non supererà le 50 (cinquanta) unità.
e) Assistenza all'avviamento (startup).
Questo servizio consiste nell’attività di affiancamento di personale del Fornitore agli utenti gestionali del Comune nella fase di avviamento del GEPC oltre alle attività di aggiornamento, di configurazione e di tuning correlate con il rilascio delle versioni successive, corrette od aggiornate del Sistema stesso.
f) Assistenza applicativa agli utenti
g) Manutenzione ordinaria
h) Gestione del software applicativo
i) Garanzia e canoni sottosistemi
Si intende qui il periodo di garanzia comprendente le attività di assistenza e di manutenzione ordinaria del Sistema realizzato, da svolgersi su richiesta del Comune per un periodo non inferiore a 12 (dodici) mesi dal collaudo positivo oltre a tutti gli eventuali costi e/o canoni richiesti per utilizzare il framework, il motore GIS e/o il DBMS impiegati dal Sistema.
j) Documentazione
E’ inclusa tra gli SPC la fornitura e l’aggiornamento della documentazione tecnica e operativa relativa al Sistema GEPC durante tutto l’espletamento della fornitura.
Tutti i punti sopraelencati, trattati qui a livello di elenco riepilogativo o comunque in modalità estremamente sintetica, verranno dettagliati ed approfonditi nei successivi paragrafi.
Gli elementi sopra esposti dovranno essere forniti entro i tempi massimi specificati nel presente documento, salvo minimi ed eventuali successivi aggiustamenti
riportati nel “Progetto GEPC” definitivo e, quindi, ratificati nel contratto che verrà sottoscritto col Fornitore.
L’espletamento della fornitura dovrà avvenire principalmente presso la sede della Protezione Civile (PC) del Comune di Firenze, via Olmatello 25, con alcune attività minori presso la sede della Direzione Risorse Tecnologiche (DRT), xxx Xxxxxxxx 000, quali, ad esempio, la formazione degli utenti.
Nell’Allegato Tecnico sono indicati i requisiti minimi e tutte le caratteristiche vincolanti a cui l’offerta dei Concorrenti dovrà rispondere in modo compiuto e puntuale. Si precisa che la piena rispondenza a tutte le caratteristiche vincolanti è assolutamente tassativa ed obbligatoria, e la loro non ottemperanza inibisce la partecipazione alla gara o, nel caso esse non vengano salvaguardate in fase di progetto, determina la rescissione immediata del contratto e la cessazione di ogni impegno da parte del Committente nei confronti del Fornitore.
4. Sistemi messi a disposizione dall’Ente
Per la fornitura oggetto della presente gara, il Comune di Firenze si impegna a mettere a disposizione tutta una serie di apparecchiature hardware e di sistemi software di base che devono essere utilizzati nella realizzazione del Sistema GEPC, nel suo complesso, e che permettono di salvaguardare anche una serie di investimenti pregressi fatti negli anni. Nel successivo paragrafo verranno poi trattati i principali sistemi informativi e le banche dati con le quali dovrà essere assicurato un adeguato livello di interoperabilità, cioè di interscambio bidirezionale di informazioni e quindi non solo basato su dati grezzi.
Nello specifico sono previsti i seguenti sistemi IT dedicati completamente al progetto:
• 2 (due) server biprocessore Intel Xeon L5320 Quad Core con 8 GB di RAM ed 1 (una) unità di storage Fujitsu-Siemens FibreCat SX80 con un totale di circa 1,3 TB di disco RAW, tutti i riferimenti dettagliati sono riportati nel seguente atto amministrativo (determina 11556 del 2007) e nell’offerta allegata: xxxx://xxxxxxxxx.xxxxxx.xx.xx/XxxXxxxxxxxxx/XXXXXXxx0.xxx/XxxxXXX/0000X00 5B2A3D139C12573AD004405DE/$File/2007_DD_11556.pdf xxxx://xxxxxxxxx.xxxxxx.xx.xx/XxxXxxxxxxxxx/XXXXXXxx0.xxx/xx0x000xx0x00000 c1256d57004357ef/f35dfb76a0f8d918c12573a60031b186/$FILE/offerta%20infor matica%20commerciale.pdf
• 2 (due) licenze di Windows Server 2003 R2 Enterprise Edition a 32 bit in inglese con Service Pack 2;
• switch di rete (LAN) e in fibra (SAN) con opportuni livelli di ridondanza, la cui gestione è totalmente in carico a personale tecnico dell’Ente.
I 2 (due) server citati sono attualmente dislocati presso la sede della PC in una sala adeguatamente condizionata, protetta da UPS (Uninterruptible Power Supply) e gruppo elettrogeno (di edificio) e sono gestiti direttamente dai tecnici del Comune. La gestione, la configurazione e la manutenzione del software di base, degli aggiornamenti e delle politiche di dominio rimangono in carico all’Ente a meno che la Ditta Aggiudicataria non abbia proposto un diverso sistema operativo, nel qual caso la gestione dovrà essere concordata con i tecnici del Comune e condotta, almeno inizialmente, congiuntamente
coinvolgendo personale di entrambe le Parti.
I due server sono inseriti nel dominio interno del Comune (tecnologia Active Directory di Microsoft in modalità nativa “Windows Server 2003”) e già configurati in un cluster Microsoft con la modalità attiva-passiva. Su tali sistemi è stato previsto il deployment del nuovo applicativo GEPC ed in particolare, tenuto conto dei vincoli imposti dal cluster, si ipotizzava di dedicare un nodo alle funzionalità di “application server” e l’altro di “database server”, configurando ed assicurando il fail-over incrociato tra i due nodi coinvolti.
La Ditta Concorrente può chiaramente progettare, descrivere e proporre una soluzione propria, sia come impiego dell’hardware messo a disposizione (o di hardware nuovo offerto in gara) che come configurazione del sistema operativo ospitato sullo stesso, salvo il fatto che nessun ulteriore onere o costo può essere addebitato all’Ente oltre a quanto complessivamente previsto per questa fornitura. Quindi se il Sistema offerto necessita, ad esempio, ulteriori apparati hardware, di licenziare e/o di acquistare ulteriore software, middleware, framework o un DBMS specifico, il costo deve sempre rientrare nell’importo offerto e gli eventuali canoni annuali richiesti devono essere espressamente contenuti nel costo annuale della manutenzione ordinaria offerta.
Oltre ai sistemi già indicati, sono coinvolti e messi a disposizione altri apparati hardware nel progetto:
• postazioni client degli operatori di sala con dotazioni quali multi-monitor, microfoni, cuffie, etc.;
• (eventuali) linee dirette PSTN, ISDN, schede GSM e modem DATA/VOICE/FAX;
• il (nuovo) centralino della Protezione Civile;
• il (nuovo) sistema di ponti radio della Protezione Civile;
• i (nuovi) dispositivi di geolocalizzazione (GPS) a bordo degli automezzi.
Nella valutazione e nell’attribuzione del punteggio tecnico al Sistema offerto in gara saranno presi in considerazione aspetti generali quali l’interoperabilità supportata, la maturità tecnologica, il livello di integrazione presentato, la quantità e la tipologia di protocolli/standard di interfacciamento supportati, la quantità di sale in esercizio, l’esperienza presentata dal team di lavoro, etc.. Sicuramente il Sistema proposto in gara dovrà garantire un alto livello di integrazione con i sottosistemi citati, interconnettersi in modo completo ed offrire tutte le funzioni richieste, dal Capitolato d’Appalto e dall’Allegato Tecnico, che coinvolgono tali dispositivi.
L’Amministrazione si impegna a fornire alla Ditta Aggiudicataria, senza imputarle alcuna spesa, la documentazione tecnica, il dettaglio dei protocolli e degli standard di comunicazione adottati, le API, le librerie software (nei principali linguaggi di programmazione recenti) e tutto quanto necessario per consentire una piena integrazione bidirezionale tra tutti i sistemi indicati ed il software GEPC.
Rimane totalmente a carico dell’Aggiudicataria lo sviluppo, la personalizzazione e l’implementazione dei moduli applicativi necessari a realizzare l’interconnessione e l’interfacciamento con gli apparati hardware ed i sottosistemi indicati. In tal senso ogni Concorrente deve affrontare, nel documento “Progetto GEPC”, questa particolare problematica, descrivendo le proprie esperienze maturate in tali ambiti,
elencando le realtà operative e gli hardware già gestiti dal Sistema offerto in gara, ipotizzando le possibili criticità associate alle attività di interfacciamento, con particolare riferimento alle tempistiche in gioco molto strette, e proponendo le migliori pratiche di integrazione e le strategie risolutive da impiegare per la piena riuscita del progetto.
5. Interazioni con gli altri sistemi informativi
In questo paragrafo vengono evidenziate le interazioni alle quali il GEPC dovrà adempiere al fine sia di ottenere una corretta integrazione con la realtà dei sistemi e delle banche dati già in essere o in divenire all’interno del Comune di Firenze, sia di minimizzare la quantità di operazioni che gli utenti finali devono effettuare a video, garantendo un recupero mirato di dati ed evitando la duplicazione o la doppia gestione di informazioni già presenti in altri sistemi informativi.
5.1 BDPI (Banca Dati Patrimonio Informativo)
Il progetto BDPI prevede la costruzione di una banca dati unificata o datawarehouse di tutti i dati ritenuti rilevanti presenti nelle banche dati degli applicativi del Comune di Firenze o anche da fonti esterne, normalizzati e bonificati. La Banca Dati del Patrimonio Informativo, o BDPI appunto, è il risultato atteso di questo progetto, con l'intendimento di farne nel tempo la fonte unica e unitaria di tutti i dati condivisi fra gli applicativi e le banche dati del Comune, mediante la graduale confluenza dei dati contenuti in tutti i database applicativi attuali. BDPI si configura pertanto come un sistema terzo, di livello intermedio e intermediario in grado di ottenere i dati di tutte le applicazioni comunali e di ri-trasmetterli (naturalmente secondo determinate regole di protezione della privacy, etc.). Su tale banca dati potranno essere definite le “business rules” di interscambio e di collaborazione applicativa per fornire accessi a banche dati di particolare interesse per il Sistema GEPC; a titolo esemplificativo e non esaustivo si può ricordare l’anagrafe della popolazione, le strade ed i numeri civici, il catasto ed i proprietari, le strutture comunali e le sedi, etc.
BDPI è già in fase molto avanzata di attuazione ed è in corso un continuo adattamento ed evoluzione del progetto, specialmente per implementare od adattare le necessarie “business rules” e per la generazione di nuove statistiche e reportistica ottenute correlando ed incrociando dati provenienti da diverse fonti, oltre a presentare dei cruscotti mirati di supporto decisionale e di visualizzazione delle funzionalità descritte.
In tale contesto, la comunicazione dal Sistema GEPC verso BDPI, per tutti i dati di interesse concordati tra le Parti, dovrà prevedere e permettere alcune funzionalità:
• estrazione del “differenziale dei dati” (modifiche dalla precedente esportazione) su tabelle di database, in grado di alimentare la BDPI;
• importazione in automatico delle bonifiche sui dati effettuate su BDPI, tramite aggiornamenti automatici o semi-automatici delle informazioni;
• le principali tabelle del GEPC dovranno possedere un insieme minimo di attributi obbligatorio per favorire tale interscambio e comunque la possibilità di integrazione con banche dati differenti, che sarà dettagliato in seguito;
• fornire a corredo una dettagliata documentazione della logica applicativa ed essere in grado di gestire e storicizzare “la eventuale segnalazione di bonifica” proveniente dalla BDPI, almeno tramite campi note su tutti i record o, meglio, tramite soluzioni più strutturate.
5.2 SIT (Sistema Informativo Territoriale)
Il SIT, all’interno del Comune di Firenze, ha il compito di gestire la conoscenza del territorio sia dal punto di vista della sua rappresentazione che della misura di tutti quegli oggetti, delle entità e degli eventi che su di esso insistono. Il SIT fornirà, tra l’altro, la cartografia aggiornata nei formati più opportuni (vettoriali e raster).
Il Sistema GEPC utilizzerà specifiche funzionalità offerte dal SIT, sempre attraverso modalità di collaborazione applicativa espressamente concordata con l’Ente (standard OGC, web services, shapefile, accesso diretto in sola lettura alla relativa tabella o vista, etc.), in modo da poter accedere ai tematismi ritenuti necessari a seconda delle esigenze gestionali. Tra queste a livello esemplificativo e non esaustivo si possono ricordare:
• le ortofoto storicizzate;
• la cartografia raster a colori e bianco/nero
• la CTR (Carta Tecnica Regionale);
• il grafo stradale, gli ingombri strade e le aree di circolazione;
• la toponomastica ed i numeri civici;
• il catasto (particelle catastali);
• i limiti comunali e dei quartieri;
• le attività economiche;
• l’informazione anagrafica ed i dati alfanumerici collegati a quanto sopraelencato.
5.3 SIGEDO (Protocollo dell’Ente)
Il GEPC dovrà essere in grado di integrarsi col nuovo sistema di protocollazione unico dell’Ente (progetto SIGEDO, fornito dalla ditta ADS S.p.A.), offrendo le funzionalità che consentano di effettuare le registrazioni di protocollo e dei dati minimi, se richiesti, ovverosia di tutti i dati previsti dal DPR 445/2000 (Disposizioni legislative in materia di documentazione amministrativa) e ss.mm.ii., in particolare l’art. 53, per quanto riguarda il nucleo minimo di protocollo. La tecnologia da impiegare è quella degli web service.
Quindi ogni documento con rilevanza giuridico-istituzionale (su tale aspetto dovrà essere avviata una piena collaborazione di analisi tra il personale dell’Ente e del Fornitore) verrà protocollato, rispettivamente in uscita ed in ingresso, con un numero attribuito da tale sistema centralizzato. Quest’ultimo dunque, funzionerà primariamente e sostanzialmente come motore unico di numerazione. Il GEPC potrà acquisire tale numero unico e lo utilizzerà come riferimento per tutte le funzioni per le quali si renda necessario il riferimento ad un documento, essenzialmente per comunicazioni con gli altri uffici interni o con gli altri Enti, sempre in piena ottemperanza alla normativa di riferimento.
E' da prevedere anche l’utilizzo od il riferimento ai numeri di pratica (o faldone o incartamento). Una pratica consiste in un raggruppamento omogeneo di documenti, protocollati singolarmente in momenti diversi, che si riferiscono a un unico procedimento o un’unica posizione contributiva ed aventi un’unica classificazione. Il SIGEDO prevede la possibilità di definire tali pratiche e gestirne la numerazione, sicché l’eventuale interazione richiesta tra GEPC e SIGEDO dovrà consentire anche l’uso di tali numeri di pratica.
Il SIGEDO, in tale contesto, prevede, attraverso un sistema integrato di gestione documentale, la storicizzazione completa delle informazioni relative a pratiche ed ai documenti protocollati ed archiviati, nonché dei riferimenti, dei parametri e dei codici tabellari che consentono di effettuare elaborazioni di situazioni storiche pregresse. Le funzione di acquisizione, inoltro ed archiviazione dei documenti, degli atti e di eventuali allegati ad essi dovranno essere integrate all’interno del GEPC tramite chiamate ad apposite librerie che saranno messe a disposizione dal SIGEDO.
Il Sistema GEPC dovrà inoltre mettere a disposizione, tramite BDPI, al sistema SIGEDO le anagrafiche dei mittenti o dei destinatari delle comunicazioni relative ad esempio ad una pratica, nel rispetto dei canoni di sicurezza della trasmissione dei dati personali, utilizzando cioè protocolli di trasmissione sicura. Tramite l’integrazione richiesta, si potrà tenere ulteriore traccia delle comunicazioni interne/esterne all’Ente effettuate dal GEPC.
5.4 PIUSS – Città dei Saperi
Il GEPC dovrà eventualmente integrarsi con il progetto PIUSS-Sistema Informativo Città dei Saperi (SICS), presentato alla Regione Toscana in risposta ad un avviso emesso da tale Ente. Il progetto è attualmente al vaglio della Regione Toscana per l’approvazione.
Le componenti fondamentali del Sistema Informativo per la Città dei Saperi:
• rafforzare e integrare le politiche di accessibilità della Città dei Saperi in favore di City User, Turisti Target, Xxxxxxxxx evoluti, studenti, ricercatori, imprenditori, classe creativa, professori;
• rendere più accessibili i servizi e le informazioni della Città dei Saperi;
• qualificare e rinnovare le informazioni sull'offerta di servizi culturali e turistici;
• aumentare le informazioni sugli eventi e la vita sociale della Città dei Saperi;
• aumentare la coesione sociale e la rete relazionale all'interno della Città dei Saperi;
• rafforzare i legami relazionali e sociali fra la città dei saperi e i visitatori e city user non residenti.
Il bacino di utenza previsto per il SICS sono i cosiddetti City Users, includendo sia i turisti, che la tipologia di utenza che risiede in città per un periodo più lungo (studenti universitari, non residenti in visita di lavoro, etc.). In tale contesto, per tutti i dati di interesse concordati tra le Parti, la comunicazione dal sistema GEPC verso il sistema PIUSS dovrà almeno prevedere e permettere alcune funzionalità:
• immettere nel sistema di diffusione dei contenuti del SICS-PIUSS su diversi canali (Wi-Fi, Digital Signage, web, apps per mobile) i flussi dati di interesse per la cittadinanza provenienti dal GEPC riguardanti ad esempio dati di infomobilità, aree interdette per situazioni di emergenza, eventuali consigli per la viabilità e l’uso di mezzi pubblici, etc;
• ricevere eventuali flussi di informazioni generate dagli utenti sul territorio cittadino (mediante i canali di social networking previsti nel SICS), che possano essere utili alla sala controllo del GEPC per valutare la situazione in città in caso di emergenza o grande evento.
5.5 Progetto ELI4U
In risposta al III Avviso del Dipartimento Affari Regionali, del 2 Dicembre 2009, il Comune di Cesena ha presentato una proposta progettuale dal titolo “Enti Locali Innovazione for User - ELI4U”, in qualità di capofila di un raggruppamento che vede coinvolti diversi Enti, tra cui il Comune di Firenze.
La conclusione del Progetto ELI4U è prevista nel Settembre 2012. Coerentemente con la dinamica normativa in atto, le attività che il Progetto intende sviluppare desiderano coltivare e promuovere l’innovazione nella PA, fornendo strumenti, metodologie e modelli tecnologico – organizzativi finalizzati ad ottimizzare la gestione e l’erogazione dei servizi. Partendo da questi presupposti, ELI4U attiva un nuovo fronte progettuale, sempre più caratterizzato dal tema della centralità dell’utente, protagonista di tutte le fasi del ciclo della relazione Ente – Utente. È in questo contesto che ELI4U si articola in un set eterogeneo e unitario di interventi.
Nel Progetto Eli4U, ciascun Ente Pilota ha la responsabilità di produrre alcuni atti progettuali (siano essi documentali o software), ed il Comune di Firenze ha responsabilità del Work Package 3 (WP3) del progetto Eli4U stesso. Obiettivo del WP3 del Progetto Eli4U è quindi la realizzazione di una nuova modalità di erogazione di servizi online, che, in linea con l’evoluzione del web e della normativa, offra agli enti la possibilità di aggiungere, con l’approccio a “mashup”, nuovi contenuti nella “rete civica” personalizzata del cittadino e nella “scrivania dell’operatore” (accesso a servizi transazionali tramite “widget”, dati sulle pratiche riguardanti il cittadino, contenuti “push” profilati, etc). Obiettivo specifico del Comune di Firenze nell’ambito della presente Fornitura è la realizzazione di un’interfaccia profilabile, con un’avanzata user experience, sia lato extranet che lato intranet, da arricchire in modo scalabile e dinamico con una filosofia a “widget” tipica di nuovi social media nel web (iGoogle, Facebook, etc).
In quest’ottica, il GEPC avrà nella Mia Pagina costituita dal Fascicolo del Cittadino un possibile ulteriore canale di distribuzione via web e mobile apps di contenuti verso l’utenza e dovrà essere prevista una modalità di integrazione adeguata, basandosi sui principali standard di interoperabilità. I contenuti selezionati e di pubblico interesse provenienti dal GEPC saranno in tale contesto una delle possibili risorse esposte dal Comune nella Mia Pagina sia lato cittadino che, se valutate di interesse, lato operatore/dipendente comunale; in tale contesto si inserisce la distinzione di utenze prevista per il Sistema richiesto.
Per favorire questa condivisione dei contenuti, il GEPC dovrà esporre dati di pubblico interesse in formati open, con metadati/tags associati, in modo che sia il sistema Eli4U (che anche il sistema PIUSS-SICS già citato) possano recepire, interpretare e pubblicare nei canali corretti i contenuti provenienti dal GEPC da distribuire a tutta la cittadinanza.
5.6 Progetto X.X.Xx.Xx.
Il progetto X.X.Xx.Xx è un progetto co-finanziato dal Dipartimento degli Affari Regionali (DAR) nell’ambito del primo bando del programma ELISA. Al progetto partecipano i Comuni di Torino (capofila del raggruppamento), Genova, Bologna e le Province di Cagliari e di Firenze. Nell’ambito del progetto è prevista la realizzazione di un supervisore del traffico per l’area metropolitana.
Attraverso l’acquisizione e l’elaborazione dei dati provenienti da diverse fonti (sensori di traffico, sistemi AVM installati sui mezzi del TPL, FCD, ecc.) il sistema sarà in grado di ricostruire in tempo reale lo stato della rete stradale. Il progetto X.X.Xx.Xx, nella sua totalità, mira a realizzare un’architettura possibilmente aperta e generalizzabile di supervisione del traffico che possa acquisire dati da fonti molteplici, e su questa base identificare e predire lo stato del traffico sulla rete, con il duplice obiettivo di utilizzare queste informazioni a fini di infomobilità (cioè di diffusione di informazioni al pubblico) e al fine di migliorare la capacità di governo del traffico da parte degli Enti Locali preposti. L’ambito territoriale di applicazione del Supervisore, in questo caso, è quindi quello dell’intera Provincia di Firenze, inclusi il Comune capoluogo ed i Comuni limitrofi.
Il progetto prevede altresì la realizzazione di una piattaforma di distribuzione delle informazioni riguardante specificamente la mobilità (per brevità anche “piattaforma di infomobilità”). Questa piattaforma sarà strettamente integrata con il Supervisore sopra descritto, da cui attingerà dati, e si interfaccerà anche con altre applicazioni. Fra gli obiettivi del progetto, quindi, vi è anche quello di erogare – tramite la piattaforma di cui trattasi – servizi di infomobilità al pubblico attraverso un pluralità di canali (Internet, SMS, MMS, call centre, etc.).
Il Sistema GEPC dovrà pertanto interoperare con il Supervisore tramite formati open e servizi WS, in standard W3C/OASIS, con metadati/tags associati, in modo che tra i due sistemi si possa instaurare uno scambio di informazioni al fine di recepire, interpretare e gestire opportunamente i contenuti di comune interesse, come concordato tra le Parti.
5.7 Altre banche dati
In generale, si richiede che il GEPC renda possibile sia l’esecuzione di attività di verifica e controllo, offrendo servizi che consentano di esportare i suoi dati, di interesse non esclusivo della Protezione Civile, allo scopo di incrociarli con quelli di altre banche dati di soggetti esterni e/o dell’Ente, oltre alla già citata BDPI, sia di importare dati da tali banche dati, sempre allo scopo di realizzare un adeguato livello di integrazione funzionale ed organizzativa, evitando il più possibile la (ri)digitazione e la gestione duplicata dei medesimi dati, col rischio concreto di potenziali errori, facili incoerenze, disallineamenti ed inefficienze.
A titolo esemplificativo e non esaustivo si riporta un elenco di alcune banche dati di interesse che dovranno essere trattate correttamente dal Sistema offerto:
• Elettromedicali - lista di luoghi o aree dove sono in funzione dei dispositivi elettromedicali con informazioni quali indirizzo e tipologia di apparato (banca dati gestita dall’Azienda Sanitaria di Firenze – ASF);
• PET - tipologia e localizzazione dei Professionisti Emergenza Territoriale sul territorio comunale (banca dati gestita dal Servizio 118);
• viabilità di competenza della Provincia nel territorio comunale, reticolo invasi collinari e specchi d'acqua (banche dati gestite dalla Provincia di Firenze);
• Rischio Idraulico e Rischio Frana (banche dati gestite dall’Autorità di Xxxxxx).
Tali funzionalità potranno essere assicurate dal Sistema GEPC essenzialmente realizzando, gestendo ed esponendo web services in standard W3C, OASIS o fonti dati secondo i dettami dell’OGC. Si precisa che tali aspetti rientrano tra i requisiti tecnologici a cui il Sistema offerto deve rispondere e sono, pertanto, anche oggetto di valutazione e di assegnazione di punteggio tecnico da parte della commissione.
6. Caratteristiche dettagliate della fornitura
Per quanto riguarda tutti gli aspetti e gli approfondimenti su:
- i requisiti minimi e le caratteristiche vincolanti;
- i requisiti di qualità (generali e tecnologico-architetturali);
- i requisiti funzionali e le caratteristiche applicative;
- i servizi professionali correlati (SPC);
- i criteri di valutazione ed il punteggio tecnico;
- la presentazione e la struttura dell’offerta tecnica;
si rimanda espressamente a tutto quanto indicato nell’Allegato Tecnico.
7. Servizi di assistenza e di manutenzione
Con il termine “manutenzione” si ha un’accezione molto ampia in ambito ICT e relativamente ai sistemi e/o al software. Relativamente a questa fornitura, per manutenzione si intende ogni modifica dei programmi, della struttura della base di dati e della documentazione dell’applicazione, finalizzata a ripristinare il corretto funzionamento dei prodotti software che rivelassero difetti o incorressero in guasti, errori, malfunzionamenti, "bug" e/o ogni altra imperfezione, ad esempio il degrado delle prestazioni fornite dal software stesso.
In particolare, se durante il normale esercizio il Sistema facesse rilevare delle prestazioni insoddisfacenti od un degrado significativo, su segnalazione dei Referenti di progetto o di altri Responsabili dell’Ente la Ditta Aggiudicataria, collaborando con personale sistemistico dell’Ente, è tenuta ad effettuare un’indagine approfondita volta ad individuare le cause della situazione e/o a restringere il più possibile l’ambito delle possibilità, producendo una relazione tecnica basata su valutazioni oggettive e, soprattutto, su misurazioni e test riproducibili ed indicando contestualmente gli interventi necessari, sia correttivi che di potenziamento dell’infrastruttura impiegata. Quindi generiche indicazioni di
capacità computazionale inadeguata, dimensione della memoria RAM insufficiente, prestazioni dello storage al limite, eventuale ambiente virtualizzato penalizzante, etc. dovranno essere sempre supportate e suffragate da opportuni rilevamenti/test e da misurazioni delle prestazioni ottenute negli scenari già corretti e/o potenziati che il Fornitore può predisporre nei propri laboratori e che sono stati ipotizzati e descritti dalla relazione stessa come risoluzione del problema. Si può prevedere anche un eventuale potenziamento dell’infrastruttura esistente presso l’Ente, con moduli e dispositivi temporaneamente messi a disposizione sempre dal Fornitore, per poter condurre test esaustivi e misurazioni più puntuali per accelerare la diagnosi ed arrivare ad una proposta delle soluzioni tecniche da implementare.
Inoltre, tenuto conto del particolare ambito in cui si inserirà il Sistema per la gestione delle emergenze, la manutenzione relativa ai software e/o ai moduli si applica anche nel caso che modifiche legislative, normative o dipendenti da regolamenti (intervenute indipendentemente dalla volontà dell'Amministrazione, ad es. da Organi centrali dello Stato o dalla Regione) rendano l'applicazione non più conforme e/o adeguata alle nuove condizioni. Di conseguenza il Fornitore dovrà intervenire per ripristinare il corretto funzionamento e la capacità di svolgere adeguatamente tutto quanto richiesto dalle normative in vigore, sulla base della reingegnerizzazione dei processi e delle modifiche di cui sopra.
La manutenzione deve pertanto comprendere la fornitura delle versioni, “release”, etc. (di seguito comunque “versioni”) più recenti introdotte sul mercato durante la vita operativa dei prodotti software di interesse.
Ai fini della gestione contrattuale quindi, la manutenzione si distingue nelle tipologie di servizio descritte, in modo puntuale, nei seguenti sottoparagrafi e viene compresa solo la manutenzione ordinaria.
7.1 Manutenzione ordinaria (compresa)
Manutenzione adattativa: rientrano in questa categoria sia gli adeguamenti e le estensioni del Sistema e/o dei suoi moduli necessari per ottemperare a nuove e vincolanti norme, aventi valenza soprannazionale, nazionale o regionale, sia la fornitura di nuove versioni, o release, via via introdotte sul mercato dal Fornitore durante la vita operativa del Sistema, in quanto tali aggiornamenti offrono ulteriori funzioni e correggono, generalmente, anche gli eventuali errori, i difetti evidenti e/o latenti presenti nei programmi precedenti (c.d. “bug fix”).
Manutenzione tecnologico-evolutiva: fanno parte della manutenzione evolutiva, in ambito tecnologico, tutti gli interventi funzionali dipendenti da novità esterne al Fornitore, quali ad esempio le variazioni al software d’ambiente, i miglioramenti evolutivi del middleware e/o le modifiche prodotte per adeguare il software a nuovi standard tecnologici e di mercato, nonché variazioni sui programmi di integrazione e/o di trasmissione dati forniti da soggetti esterni o direttamente dall’Ente.
Manutenzione preventiva e correttiva: essa è finalizzata sia a prevenire il manifestarsi di difetti (originari o intervenuti in seguito senza colpa imputabile all'Amministrazione) o di guasti, errori, malfunzionamenti, bug e/o ogni altra imperfezione, compreso il degrado delle prestazioni fornite dai software applicativi rispetto ai livelli abituali (di seguito comunque "guasto"); sia a ripristinare il
corretto funzionamento dei prodotti software che rivelassero uno o più guasti. In quest’ultimo caso si tratta, pertanto, degli interventi necessari per riparare a comprovati difetti e/o anomalie della fornitura, dove:
• difetto congenito è la causa di ogni errore o malfunzionamento che provochi indesiderate e comprovabili perdite, alterazioni o errato trattamento dei dati gestiti e sia suscettibile di generare output errati;
• anomalia è la causa di ogni errore o malfunzionamento che fa sì che il comportamento si discosti da quello atteso in base a quanto specificato nel presente documento e alle specifiche ricavate dall’analisi di dettaglio.
7.2 Manutenzione straordinaria (non compresa)
Manutenzione migliorativa, personalizzazioni e software-evolutiva: si tratta degli interventi richiesti dal referente del progetto e dal personale autorizzato dell’Ente per adeguare il Sistema oggetto dell’appalto a nuove esigenze sorte in corso d’esercizio o per l’introduzione di funzionalità del tutto nuove; questi interventi possono attuarsi, per esempio, attraverso l'estensione delle capacità del Sistema nella sua interezza o di singoli moduli software coinvolti. Rientrano in tale ambito anche gli interventi dovuti a normative di ambito esclusivamente locale ovvero i Regolamenti Comunali.
7.3 Condizioni per lo svolgimento delle attività di manutenzione
A partire dal rilascio in esercizio del primo modulo software o di un qualsiasi componente dell'intero Sistema, e per tutta la durata del contratto, la Ditta si impegna a mettere a disposizione del Comune idoneo personale (analisti, sistemisti programmatori, ecc. con specializzazione senior o junior) capace di identificare, risolvere e prevenire rapidamente problemi applicativi.
Le attività saranno richieste dai referenti/responsabili dell’Ente, con le stesse modalità previste per l’attività di assistenza agli utenti attraverso uno specifico sistema di trouble ticketing, concordato e messo a disposizione dal Fornitore stesso, o qualora esso ne fosse sprovvisto, attraverso uno predisposto dall’Ente.
Nello specifico, tutti gli interventi di manutenzione ordinaria dovranno essere effettuati minimo con la formula “11x5xNBD”, fatto salvo tutte le casistiche proprie del servizio di reperibilità; si faccia riferimento al paragrafo VTIGA sui criteri di valutazione e l’assegnazione del punteggio nell’Allegato Tecnico.
Il servizio di manutenzione ordinaria è compreso: dovrà essere assicurato per tutta la durata del contratto, cioè comprendendo la prima installazione, la messa in esercizio, la garanzia (12 mesi) e l’anno di manutenzione ordinaria (12 mesi), quindi fino al termine del dodicesimo mese successivo ai dodici mesi di garanzia e dovrà risultare omnicomprensivo e senza alcun ulteriore onere a carico dell’Ente.
Gli interventi tecnici di manutenzione preventiva, adeguamento, aggiornamento e in genere tutti quelli che comportino un intervento con “fermo programmato” del Sistema, dovranno essere preventivamente concordati ed effettuati nei giorni e con gli orari esplicitamente autorizzati dai responsabili dell'Amministrazione Comunale.
Durante il periodo di vigenza contrattuale, il Comune si riserva la facoltà di richiedere all'Aggiudicatario anche interventi di manutenzione straordinaria da
realizzare secondo modalità da concordare tra le parti ed applicando le tariffe offerte, costo a giorno per persona, per le figure professionali coinvolte.
Per tutta la durata della commessa la Ditta Aggiudicataria fornirà con periodicità concordata (mensile, bimestrale, etc.) ai referenti dell’Ente una documentazione dettagliata sulle attività svolte, anche solamente in formato elettronico,. La documentazione conterrà gli elementi di riscontro principali per la valutazione del servizio e dell'operatività del Sistema.
Per tutti i ritardi nello svolgimento delle attività di manutenzione, di cui al presente paragrafo, saranno applicate le penali come previsto da questo Capitolato d’Appalto al paragrafo 11.
7.4 Affidamento servizi di assistenza e di manutenzione ordinaria dopo il periodo di durata contrattuale
Al termine del periodo di garanzia, la Ditta è tenuta a stipulare con l’Ente, nel caso l’Ente stesso lo ritenga opportuno, un contratto per l’erogazione dei servizi di assistenza e di manutenzione ordinaria per l’anno successivo ed eventualmente per un ulteriore anno. L’eventuale affidamento avverrà sulla base del costo del canone annuo comunicato nell'offerta economica per tali attività, previa presentazione di idonea garanzia (calcolata nella misura del 10% - dieci percento - dell’importo complessivo della manutenzione), aumentato della quota di rivalutazione dovuta all’inflazione verificatasi nell’anno precedente, calcolata in base all'indice ISTAT dei prezzi al consumo.
Per le attività di servizio è data facoltà al Fornitore di avvalersi, previa autorizzazione dei referenti dell’Ente, anche di personale esterno alla sua organizzazione, ferma restando la sua responsabilità nei confronti dell’Ente, nei limiti e alle condizioni previsti dal presente capitolato.
Nel caso in cui, per l’anno in corso, l’Ente non abbia sottoscritto la copertura tramite canone di uno dei servizi di assistenza e manutenzione ordinaria, le prestazioni professionali ad essi relative possono essere attivate dall’Ente, in caso di necessità, applicando le modalità e le tariffe previste per la manutenzione straordinaria, eventualmente rivalutata come stabilito al punto precedente.
8. Organizzazione e gestione del rapporto contrattuale
8.1 Vincoli contrattuali
Fanno parte del contratto:
• il presente Capitolato d’Appalto ed il relativo Allegato;
• l'offerta presentata dalla Ditta Aggiudicataria, completa di ogni SPC, di tutti i documenti prodotti e di tutto il materiale documentale;
• il “Progetto GEPC” fornito in fase di offerta, realizzato secondo quanto indicato in questo Capitolato e nell’Allegato Tecnico e via via aggiornato se necessario.
Con la sua partecipazione alla gara, la Ditta Aggiudicataria espressamente riconosce ed accetta tutte le condizioni poste dall'Amministrazione in proposito.
Le condizioni, di cui al presente Capitolato d’Appalto e all’Allegato Tecnico, hanno validità per tutta la durata contrattuale, come indicato nel bando di gara. L'Amministrazione non riconosce, infatti, formalmente assolta l'obbligazione di consegna da parte della Ditta Aggiudicataria fino al positivo superamento del collaudo, in quanto qualsiasi prodotto non ancora funzionante, difettoso, viziato o comunque inadeguato non può fornire all'Amministrazione l'utilità che la stessa si è prefissa e che costituisce lo scopo stesso della presente fornitura.
8.2 Referenti del Fornitore e dell’Ente
Al fine di seguire, controllare e coordinare le attività di realizzazione del progetto, garantendo la continuità dello scambio di informazioni tra l’Ente e il Fornitore, si seguiranno le modalità di seguito indicate.
Per la gestione operativa del contratto il Comune nominerà, subito dopo la stipula del contratto, un referente amministrativo e 2 (due) referenti tecnici, quali responsabili dei rapporti con il Fornitore per l’esecuzione del contratto, con funzioni d'interfaccia per il rispetto delle esigenze e delle priorità del Comune e la supervisione ed il controllo dell'avanzamento della fornitura nelle sue diverse fasi e componenti. In particolare, i referenti tecnici dell’Ente svolgeranno precise attività di coordinamento e saranno un responsabile della Direzione Risorse Tecnologiche (Responsabile IT), per supportare e seguire il progetto nella sua interezza, la parte infrastrutturale ed il relativo deployment applicativo, ed un responsabile dell’Ufficio di Protezione Civile (Responsabile PC), per occuparsi di tutte le tematiche più specifiche della fornitura, gli aspetti inerenti la sala operativa, la formazione del personale coinvolto e gestire gli aspetti di perfezionamento delle funzionalità e di integrazione con la realtà operativa esistente.
Allo stesso modo il Fornitore nominerà almeno un responsabile operativo (Capo Progetto) e un referente commerciale con il compito di rappresentare e impegnare il Fornitore stesso nella fase esecutiva del contratto. Tali responsabili saranno gli unici interlocutori dei referenti dell’Ente ogniqualvolta si presentino problemi sia nella fase realizzativa che in quelle successive di avviamento, personalizzazione ed assistenza, di tutto quanto è oggetto della presente fornitura.
In particolare, il responsabile operativo della Ditta Aggiudicataria sarà il capo progetto indicato dalla Ditta stessa nella propria offerta. Tale capo progetto dovrà mantenere il proprio incarico per tutta la durata del contratto. L'eventuale ed eccezionale cambiamento del capo progetto da parte del Fornitore dovrà essere da quest'ultimo adeguatamente motivato. In tal caso la Ditta si impegna a designare un nuovo capo progetto, provvisto di un curriculum equivalente o superiore. Il nuovo capo progetto, referente della Ditta, in ogni caso dovrà essere formalmente accettato dal Comune.
I referenti si serviranno, ciascuno per la propria parte, di team di progettisti e di tecnici, i cui componenti potranno partecipare alle attività di pianificazione del progetto, di deployment del Sistema e di monitoraggio delle diverse attività.
Tutte le comunicazioni ufficiali della Ditta in merito alla fornitura dovranno essere indirizzate ai referenti dell’Ente ed, eventualmente, in copia a terzi come richiesto. Analogamente tutte le comunicazioni del Comune saranno indirizzate ai referenti
della Ditta.
I referenti dell’Ente, ove verifichino che una fornitura o un'attività non abbiano raggiunto i risultati previsti o siano state eseguite in modo difforme dalle prescrizioni del presente capitolato, ne dispongono il rifacimento; tale facoltà si può esercitare durante tutta la fase esecutiva, allorché si vengano ad evidenziare disfunzioni operative nell'integrazione del progetto, anche se la fornitura o l'attività in questione dovesse riguardare uno stato di avanzamento già approvato.
I referenti dell’Ente possono:
• dare disposizioni ai referenti del Fornitore di sostituire una o più risorse umane impegnate nella realizzazione;
• imporre al fornitore particolari prescrizioni tese alla piena riuscita delle attività nel rispetto delle finalità generali del progetto, tali eventi non daranno luogo a variazioni dell'importo della fornitura.
• disporre la temporanea sospensione di alcune o di tutte le attività, sia per carenze imputabili al Fornitore, sia per motivi organizzativi dell'Amministrazione, senza per questo dare adito a riserve da parte del Fornitore medesimo.
• autorizzare deroghe rispetto alla successione delle attività prevista dal progetto ove, pur senza il completamento dell'attività precedente, sia possibile ed opportuno intraprendere quella successiva; tali deroghe sono esclusivamente di natura organizzativa e non possono influire sulla valutazione dell'avanzamento ai fini dei pagamenti.
I referenti dell’Ente hanno l'obbligo di segnalare tempestivamente (per e-mail, FAX, PEC, ecc.), ogni inadempienza od anomalia imputabile al Fornitore, anche nel caso si presentino situazioni non chiare o ben delineate che potrebbero comportare ritardi od un’influenza negativa sul progetto.
8.3 Obblighi del Fornitore
La Ditta Aggiudicataria ha l'obbligo di stipulare in forma pubblica amministrativa il contratto relativo alla presente fornitura, assumendosene le spese.
E' responsabilità del Fornitore scegliere, dimensionare ed assemblare i vari componenti e/o moduli del Sistema offerto per assicurarne la perfetta integrazione e compatibilità al fine di ottenere il miglior funzionamento complessivo possibile a livello di stabilità, prestazioni, scalabilità, affidabilità, disponibilità, etc..
La Ditta Aggiudicataria dovrà installare, integrare ed attivare, con proprio personale tecnico e a proprie spese, tutto il Sistema oggetto della presente fornitura sulle piattaforme hardware/middleware/software messe a disposizione e concordate con l'Ente, inclusa la configurazione ed il collegamento con i posti di lavoro, con il centralino, con i ponti radio della Protezione Civile, con i sistemi di rilevamento a bordo degli automezzi e con gli altri apparati o dispositivi esterni esistenti, se necessario. Tra le operazioni d'installazione a carico del Fornitore sono incluse, in quanto necessarie al pieno collaudo della fornitura, le attività di pianificazione, analisi, trasferimento dei dati dagli archivi dell’Ente al nuovo database ed ogni altra attività necessaria a mettere in grado l'Amministrazione di sfruttare al meglio le potenzialità del nuovo Sistema GEPC.
Il Fornitore dovrà curare l'addestramento e la formazione, eventualmente anche con le modalità “training on the job”, del personale dell'Amministrazione in modo da metterlo in condizione di provvedere autonomamente al funzionamento corrente del Sistema, ricavando il maggior beneficio dall'uso di tutti i programmi.
Il Fornitore assume l'obbligo di tenere indenne in ogni tempo l'Ente da tutte le rivendicazioni, responsabilità, perdite, danni, costi, risarcimenti e quanto altro chiunque possa avanzare e/o pretendere per la presunta violazione di diritti d'autore, marchi di fabbrica, brevetti e simili, italiani o stranieri, derivanti dalla presente fornitura o dal suo uso. Le Parti si impegnano a darsi reciprocamente immediata notizia di qualsiasi azione o questione di Xxxxx di cui siano venute a conoscenza relativamente a quanto sopra. La Ditta aggiudicataria assumerà a sue spese la difesa contro tale azione e terrà a suo carico gli oneri eventualmente conseguiti nei confronti del terzo attore.
Il Fornitore si assume tutte le responsabilità inerenti eventuali infortuni o danni a persone o cose arrecati all’Ente o a terze parti, durante lo svolgimento di attività legate alla fornitura.
Il Fornitore si impegna ad ottemperare a tutti gli obblighi verso i propri dipendenti, derivanti da disposizioni legislative, regolamenti e norme contrattuali vigenti in materia di lavoro, assicurazioni sociali e previdenza, assumendo a suo carico tutti gli oneri relativi.
8.4 Obblighi dell’Ente
L'Amministrazione metterà a disposizione della Ditta Aggiudicataria solo la piattaforma hardware e software, comprensiva di licenze, descritta nel presente documento, od una sostanzialmente equivalente, stimata assolutamente in grado di eseguire efficacemente un'Applicazione del tipo oggetto della presente fornitura. Eventuali espansioni e future evoluzioni del Sistema, di una certa consistenza, potranno comunque richiedere una valutazione congiunta e condivisa tra le Parti per la rivisitazione tecnologica della stessa o per la sua riprogettazione nell’ottica di un opportuno adeguamento infrastrutturale o del coinvolgimento di altri Uffici o Direzioni dell’Ente.
L’Amministrazione metterà a disposizione del Fornitore il proprio personale tecnico per collaborare alle operazioni preliminari al collaudo e all'avviamento operativo, nonché per facilitare il trasferimento di tutti gli archivi precedentemente descritti.
8.5 Codici sorgente
In relazione ai codici sorgenti dell’Applicazione, ferma restandone la proprietà da parte del Fornitore, il contratto dovrà prevedere quanto segue:
la cessione all’Ente, senza oneri aggiuntivi per lo stesso, dei codici sorgenti completi e aggiornati all’ultima versione del Sistema e di tutti i moduli coinvolti almeno in tutti i casi di
• fallimento;
• liquidazione;
• cessazione di attività;
• cessione del ramo d'azienda;
• concordato preventivo.
Il Fornitore, entro la data del collaudo e a suo totale onere, deve predisporre il deposito dei codici sorgente di tutto il Sistema, insieme con la loro documentazione più aggiornata, presso studio notarile di fiducia dello stesso. Con cadenza almeno semestrale, prima del collaudo, durante il periodo di garanzia e negli anni di attivazione del servizio di manutenzione ordinaria, se nel tempo intercorso la Ditta Aggiudicataria avrà effettuato interventi sul Sistema comportanti modifiche dei codici sorgenti, dovrà inviare comunicazione scritta all’Amministrazione di aver provveduto all’aggiornamento degli stessi presso lo studio notarile scelto, con tutte le modifiche e le personalizzazioni nel frattempo apportate. Tale comunicazione sarà anche condizione per il rinnovo annuale del contratto di manutenzione.
L’Ente ha il diritto:
• alla piena conoscenza dei codici sorgente, senza però possibilità di cessione a terzi di questi ultimi. Tale diritto si potrà esplicare anche attraverso la formulazione, su richiesta dell’Ente, di apposita offerta per la formazione del suo personale tecnico, allo scopo di approfondire la conoscenza del Sistema utilizzato;
• a seguito di tali attività formative, il personale a ciò formato dell’Ente avrà facoltà di modificare i sorgenti, sempre al solo scopo di uso interno e senza possibilità di cessione a terzi e fermo restando che l’intervento sui codici sorgenti da parte di altro personale causa il decadere di ogni forma di garanzia o di copertura manutentiva, sia pure in vigenza del contratto di assistenza e manutenzione con il Fornitore;
• alla proprietà dei singoli moduli di programma sviluppati dal Fornitore per le funzionalità e le finalità specifiche del progetto GEPC, quindi di tutte le variazioni e le integrazioni sulla “versione standard” normalmente commercializzata dallo stesso, e la titolarità di ogni diritto loro relativo, ivi compresa la proprietà dei codici sorgenti.
Ai sensi dell’art. 69 del D. Lgs. 7 marzo 2005 n. 82, per come modificato dall’art. 50 del
D. Lgs. 30 dicembre 2010 n. 235, l'Ente ha obbligo di fornire i programmi informatici o singoli moduli realizzati su sue specifiche indicazioni, ivi compresi i codici sorgenti, per il riuso a titolo gratuito da parte di altri Enti.
9. Modalità, tempi e luoghi di espletamento della fornitura
L’esecuzione della fornitura, l’installazione, la configurazione, l’assistenza e la messa in esercizio dell’intero sistema e l’erogazione dei servizi richiesti (SPC) deve essere resa dall’Aggiudicatario presso la seguente sede:
Protezione Civile del Comune, xxx xxxx’Xxxxxxxxx x. 00, 00000 Xxxxxxx (XX) Xxxxxx.
La formazione degli operatori e degli utenti sull’utilizzo del nuovo sistema potrà essere richiesta presso la medesima sede o presso altra sala attrezzata messa a disposizione dall’Ente in un’altra sede, sempre sul territorio comunale.
Per le modalità di realizzazione dell’intera fornitura, nel suo complesso, sono posti diversi termini contrattuali e precise tempistiche di attuazione, che costituiscono requisiti minimi e caratteristiche vincolanti dell’intera fornitura, sulle quali saranno eventualmente applicate le relative penali, come dettagliato in seguito:
• installazione, configurazione, attivazione e messa in esercizio di tutto il Sistema in versione sperimentale entro e non oltre 40 (quaranta) giorni solari dalla data di comunicazione ufficiale dell’aggiudicazione della fornitura, ovvero installazione del sistema “standard/sperimentale” già predisposto o in dotazione all’Aggiudicatario; il sistema sperimentale deve, in ogni caso, prevedere e fornire in modo affidabile almeno il 60% (sessanta percento ovvero almeno 20 requisiti) delle caratteristiche di qualità e delle funzionalità richieste, già descritte ed identificate con le sigle VTRxxx;
• verifica completa di tutte le funzionalità e pre-collaudo di tutto il Sistema entro e non oltre 40 (quaranta) giorni solari dalla verifica di cui sopra; il sistema di pre-collaudo deve implementare correttamente almeno l’85% (ottantacinque percento ovvero almeno 28 requisiti) delle qualità e funzionalità richieste, identificate con le sigle VTRxxx, per ritenere tale scadenza adempiuta;
• collaudo definitivo di tutto il Sistema descritto nella presente fornitura e dall’offerta dell’Aggiudicataria entro e non oltre 40 (quaranta) giorni solari dal pre-collaudo; il Sistema oggetto del collaudo deve presentare tutte le funzionalità e le caratteristiche di qualità richieste al presente Capitolato, sigle di identificazione VTRxxx, e quelle migliorative inserite in offerta dall’Aggiudicataria con un grado di affidabilità, di qualità e di correttezza operativa ritenuto adeguato in tutti gli ambiti di interesse e di utilizzo del Sistema stesso.
Tutte le tempistiche e le scadenze sopraindicate dovranno essere formalizzate dall’Aggiudicataria nella stesura del documento “Progetto GEPC” definitivo ed approvate dall’Amministrazione. In sede di stipula contrattuale, per la definizione temporale riferita alle suddette fasi si farà riferimento all’eventuale proposta migliorativa presentata in offerta dall’Aggiudicatario; le condizioni migliorative relative ai termini di realizzazione proposti in offerta saranno inoltre considerate ai fini dell’applicazione delle penali per ritardata esecuzione delle forniture e dei servizi, specificate nel Capitolato d’Appalto, paragrafo 11.
10. Test, verifiche e collaudo
Nel seguito vengono esplicitate le diverse attività previste per i test di accettazione provvisoria dei SAL, per le verifiche degli SPC e per il collaudo finale del Sistema nella sua interezza.
Tenuto conto della complessità del Sistema da realizzare e della necessità di integrare e/o di interconnettere lo stesso con sistemi esterni come centralini, reti di trasmissione radio e cellulare, dispositivi di geolocalizzazione, etc. che devono essere messi a disposizione direttamente dall’Ente attraverso l’espletamento di gare specifiche, può risultare che l’apparato necessario all’interfacciamento o il relativo sottosistema hardware non siano ancora pronti per l’attivazione ad una delle scadenze oggetto di verifica del Sistema GEPC. In tal caso tutte le relative funzionalità del Sistema oggetto della presente fornitura non possono essere testate o lo possono essere solo in modo molto parziale e, generalmente, insoddisfacente.
In tal caso, il Fornitore potrà:
1) far sottoporre a verifica le parti del Sistema che non necessitano del particolare sottosistema non ancora disponibile od operante in modo corretto, sospendendo le funzionalità coinvolte e demandando a data successiva da concordare tra le Parti il relativo test, scalando numericamente dal totale complessivo delle funzionalità VTRxxx il numero di quelle non valutabili e ricalcolando in tal modo la soglia per ritenere la verifica superata o meno, a livello di percentuale, rispettivamente con esito positivo o negativo.
2) fornire temporaneamente un apparato sostitutivo o simularne le funzioni, in modo da consentire una verifica simulata del Sistema. Tale verifica è da intendersi sottoposta a riserva in quanto la verifica definitiva verrà effettuata dall’Ente al momento in cui l’apparato previsto dall’Ente sarà effettivamente disponibile ed operante presso la Protezione Civile. E’ consentito che gli apparati sostitutivi messi a disposizione per questo scopo specifico da parte della Ditta Aggiudicataria forniscano performance ridotte o siano in quantità numerica inferiore a quanto previsto.
La sopra esposta metodologia è prevista allo scopo di progredire con la realizzazione dell’Applicazione assicurando sia un opportuno feedbak sull’operato del Fornitore che un livello di riscontro minimo sul Sistema GEPC, nel suo complesso e realizzato fino a quella particolare verifica, all’Amministrazione stessa.
L’Amministrazione si riserva di prendere in esame altre modalità di verifica proposte dall’Aggiudicatario nell’offerta tecnica.
10.1 Test di accettazione e verifiche ufficiali
Secondo quanto sopra specificato, il Sistema sarà oggetto di rilasci successivi, da espletare in diverse fasi nel rispetto di precise scadenze fissate nel paragrafo 9 o nell’offerta presentata dal Fornitore, solo se migliorativa. A ciascuna delle milestones corrisponderà obbligatoriamente una precisa verifica ufficiale del relativo SAL (per il collaudo definitivo è prevista una trattazione di approfondimento anche nel successivo paragrafo), ovvero dello stato complessivo del Sistema, dei singoli moduli software che lo compongono, delle funzionalità che deve garantire e dell’adempimento a tutti i SPC previsti e da svolgere durante la fase di interesse. In ogni caso l’Ente si riserva la facoltà di condurre ulteriori test intermedi significativi per controllare il progressivo sviluppo e la realizzazione del Sistema che, di conseguenza, potrà essere sottoposto a continue verifiche in corso d’opera.
I SAL verranno effettuati da un gruppo di lavoro appositamente nominato, di volta in volta, dai referenti dell’Ente a seconda delle specifiche funzionalità oggetto di verifica, pertanto non necessariamente composto sempre dai soliti dipendenti dell’Ente. E’ richiesto che durante tutte le verifiche ufficiali sia sempre presente almeno il referente del Fornitore. I restanti test intermedi potranno essere effettuati anche in assenza di rappresentanti della Ditta Aggiudicataria, purché il loro esito sia opportunamente verbalizzato e controfirmato dai diversi partecipanti, riportandolo contestualmente sul relativo rapporto.
La Ditta Aggiudicataria si impegna a recepire le eventuali mancanze rilevate nei test e nelle verifiche ufficiali, non necessariamente coincidenti con i milestones, e
dettagliate nei rapporti, entro il termine massimo di 15 (quindici) giorni solari. Scaduto tale termine senza che la Ditta nulla abbia fatto per rimediare ai difetti riscontrati, alle inadeguatezze delle funzionalità del Sistema ed alle carenze rilevate riguardo all’erogazione degli SPC, si applicano le penali giornaliere previste nel Capitolato d’Appalto al paragrafo 11 e tutte le conseguenze ad esse collegate.
Nello specifico, i generici test di accettazione provvisori e le verifiche ufficiali sono prove di funzionalità volte ad accertare, nel loro complesso, la rispondenza delle funzionalità rilasciate dal Fornitore:
• alle specifiche ed i requisiti (qualità, tecnologici, funzionali) del Capitolato;
• alle specifiche migliorative presenti nell’offerta dell’Aggiudicataria;
• a quanto successivamente concordato e fissato nell’eventuale progetto definitivo;
• alle specifiche risultanti dall’analisi di dettaglio maturata in corso d’opera;
• alla rispondenza ed alla qualità della documentazione fornita a corredo.
I test verranno svolti su insiemi adeguati di dati di prova, precaricati sugli archivi del Sistema secondo le modalità e nei tempi previsti dalla fornitura o concordati tra le Parti durante la realizzazione della stessa. Quando espressamente richiesto dai referenti dell’Ente, il Fornitore è tenuto a dare, senza alcun onere aggiuntivo, l’assistenza necessaria all’effettuazione dei test e delle verifiche ufficiali.
Le verifiche ufficiali (milestones) sono caratterizzate da una tempistica precisa di scadenza e da un minimo di copertura da garantire sulle funzionalità realizzate ed attivate (aspetti trattati paragrafo 9) oltre ad una modalità di assegnazione della valutazione tramite punteggio, come descritto in questo paragrafo.
Dell'esito delle verifiche ufficiali verrà redatto apposito verbale, con particolare riguardo per l'efficacia, la completezza, la facilità d'uso, l'efficienza, la qualità ed ogni altro aspetto significativo del Sistema oggetto di verifica. Per quanto riguarda i test intermedi condotti dall’Ente od anche concordati congiuntamente tra le Parti, generalmente incentrati su un sottoinsieme selezionato o su singole funzionalità per le quali si intenda portare un’evidenza nei confronti della Ditta Aggiudicataria, si dovranno compilare dei documenti riepilogativi o dei rapporti di accettazione provvisoria, se soddisfacenti, o di contestazione, se tali funzioni risultassero inadeguate. Dei modelli di documento da utilizzare come verbale e come rapporto, eventualmente anche coincidenti, saranno proposti dal Fornitore ed accettati dal Comune o, comunque, appositamente predisposti e concordati tra le Parti.
Il verbale ed i singoli rapporti potranno raccogliere l’esito di più sessioni di prova sulla medesima funzionalità o requisito. Per tutte le verifiche ufficiali condotte, i referenti dell’Ente attesteranno: il grado di congruità delle soluzioni adottate dal Fornitore per il soddisfacimento dei requisiti sottoposti a test oppure quello di correttezza ed efficacia nell'esecuzione delle attività sottoposte a verifica ed attribuiranno un punteggio variabile da 1 a 5 (uno a cinque) con intervalli minimi di incremento pari a 1 (uno). Sono da ritenere funzionalità o requisiti non soddisfatti dal Fornitore o servizi non eseguiti correttamente, a causa di soluzioni o attività non congrue, quelli alla cui valutazione viene attribuito nell’atto di approvazione e di verifica un punteggio inferiore o uguale a 2 (due). Le verifiche ufficiali, escluso il collaudo finale, sono ritenute superate con punteggio pari a 3 (tre) o superiore in tutte le voci che
concorrono a coprire la percentuale vincolante, come indicato nel paragrafo 9, delle funzionalità e dei requisiti codificati sinteticamente come VTRxxx.
In caso di esito negativo di una verifica ufficiale, la Ditta dovrà provvedere entro il termine massimo di 10 (dieci) giorni lavorativi all'eliminazione delle difformità e dei vizi riscontrati. Successivamente a tale termine, se la verifica non è superata, saranno applicate le penali previste nel Capitolato d’Appalto, paragrafo 11.
L'attività di docenza, eventualmente erogata nella modalità di training on the job, e di espletamento per i corsi di formazione sarà verificata sia in forma preventiva sia in corso d'opera con le stesse modalità di rilevamento. La verifica coinvolgerà anche tutta la documentazione e la manualistica che la Ditta Aggiudicataria è tenuta a compilare, tenere costantemente aggiornata e fornire a corredo del rilascio o dell’attivazione delle diverse funzionalità.
10.2 Collaudo
Il collaudo è inteso a verificare, per tutti gli elementi della fornitura, che essi siano assolutamente conformi alle caratteristiche tecniche offerte in gara e, comunque, non inferiori ai requisiti ed alle funzionalità richieste dall’Ente e descritti in questo Capitolato d’Appalto e nell’Allegato Tecnico (requisiti codificati come VTRxxx), a quanto successivamente concordato e fissato nell’eventuale progetto definitivo ed a quanto stabilito nell’analisi maturata in corso d’opera.
Il collaudo definitivo dovrà essere eseguito entro la scadenza fissata nel paragrafo 9 del Capitolato d’Appalto od entro la scadenza migliorativa offerta dal Fornitore, non sono previste proroghe di alcun tipo salvo ritardi determinanti e direttamente imputabili solo all’Amministrazione Comunale.
Il Sistema oggetto del collaudo sarà considerato inclusivo delle funzionalità aggiuntive e dei moduli software nel frattempo realizzati tramite l’attività di adeguamento applicativo e di manutenzione migliorativa e/o di personalizzazione.
Al collaudo sovrintenderà un gruppo di lavoro dell'Ente, nominato dai responsabili del medesimo, e tutte le prove che lo costituiscono verranno effettuate presso la sede di espletamento della fornitura.
Durante il collaudo verranno esercitate le funzionalità e tutti i requisiti richiesti da questo Capitolato od offerti dal Fornitore, come miglioria funzionale o prestazionale, al livello di profondità e di specificità valutato dai componenti del gruppo di lavoro. Ogni singola prova sarà relativa a validare puntualmente la singola funzionalità od un predeterminato insieme delle stesse (in tal caso la prova consisterà di uno o più specifici test) o al rilevamento della corretta esecuzione di un particolare SPC (es. svolgimento di una giornata di formazione). La Ditta Aggiudicataria fornirà, inoltre, dei test di stress mirati che consentano di rilevare e valutare la rispondenza del Sistema ai requisiti prestazionali, verifica da condurre a livello complessivo, ad esempio carichi simulati del lavoro concorrente di più operatori, rilevamento continuo di diversi automezzi in movimento sulla mappa (anche simulando la cosa in mancanza degli appositi dispositivi di geolocalizzazione a bordo degli stessi), ricezione e smistamento di più comunicazioni multicanale, etc..
Il collaudo definitivo si ritiene superato solo se TUTTE le voci descritte in questo Capitolato d’Appalto e nell’Allegato Tecnico, ovvero i requisiti generali, tecnologico-architetturali e funzionali identificati dalle sigle sintetiche VTRxxx, presentano un punteggio pari a 4 (quattro) o superiore.
In caso di primo esito negativo del collaudo definitivo, ma con nessuna voce inferiore a 3 (tre) punti, non saranno immediatamente applicate le penali. La Ditta dovrà provvedere, entro il termine massimo non prorogabile di 10 (dieci) giorni lavorativi, all'eliminazione dei vizi, alla risoluzione delle difformità riscontrate e ad alle necessarie correzioni sul Sistema per adeguare tutte quelle funzionalità, ovvero quelle voci, con votazione inferiore a 4 (quattro) punti. Successivamente a tale termine, quindi dalla ripetizione del collaudo definitivo ed in caso di ulteriore responso negativo, saranno immediatamente applicate le penali.
Gli eventuali moduli realizzati successivamente al collaudo tramite manutenzione migliorativa, saranno collaudati separatamente applicando le stesse modalità.
Considerata l’articolazione e la complessità del Sistema in esame, in particolare in aspetti critici quali l’interfacciamento con i centralini, con il sistema di ponti radio, con i dispositivi di geolocalizzazione, etc. (funzionalità specifiche VTRF21, VTRF22, VTRF23), è possibile che alcune funzioni, o loro parti, siano testate in seguito o sfuggano proprio a verifiche esaustive durante i test di cui sopra, ma tali omissioni, anche se avvenute con il consenso o per scelta dell'Amministrazione (ad esempio in caso di ritardi nelle forniture correlate), non potranno in nessun caso essere addotte dalla Ditta Aggiudicataria per giustificare un qualsiasi imperfetto funzionamento scoperto a posteriori, rientrando anche in questo caso negli obblighi di fornitura.
La fornitura e la sua realizzazione globale, si intende accettata solo dopo l'esito positivo delle corrispondenti verifiche ufficiali e, soprattutto, del collaudo definitivo.
11. Penali
Le penali sono applicabili per mancato rispetto delle condizioni e della qualità di erogazione dei servizi e dei prodotti (Sistema GEPC ovvero i sottosistemi software/middleware, i componenti, i moduli e le funzionalità specifiche) previste nella presente fornitura, accertate dall’Ente durante la normale attività lavorativa o in operazioni di test e di verifica condotte durante tutta la durata del contratto o contestuali al non superamento di specifiche scadenze, ovvero una qualsiasi delle fasi previste per l’installazione del Sistema iniziale/sperimentale, il pre-collaudo od il collaudo definitivo; fare riferimento ai paragrafi 9 e 10.
Tali condizioni possono riferirsi a mancato svolgimento delle attività, ritardo nella loro esecuzione, insufficienza ed inadeguatezza delle funzionalità realizzate o mancato raggiungimento degli obiettivi di qualità e di affidabilità prefissati. Per mancato svolgimento delle attività o ritardo nella loro esecuzione si intendono quelli non giustificati e non sanati con sospensioni o proroghe accordate dal Comune ed esclusivamente imputabili a cause dovute alla Ditta Aggiudicataria o da essa provocate per dolo, colpa e negligenza; in ogni caso si fa riferimento sempre a cause non imputabili all’Ente.
Il Fornitore prende atto che il Comune di Firenze applicherà, in conformità a quando indicato dal D.P.R.207/2010, le penali di seguito riportate espresse in forma di frazione (numeri e lettere) e riferite proporzionalmente all’importo totale di aggiudicazione della fornitura (cioè il valore ottenuto sommando il costo complessivo del sistema ed il canone annuale di manutenzione, importi netti):
1. per ogni giorno lavorativo di ritardo rispetto all’espletamento delle attività collegate alla predisposizione del progetto definitivo, all’importazione dei dati ed alle personalizzazioni applicative (paragrafi 7.1, 7.2 e 7.3 dell’Allegato Tecnico) è stabilita una penale di 1/3000 (un tre millesimo o 0,33‰);
2. per ogni giorno lavorativo di ritardo rispetto a quanto previsto al paragrafi 9 e 10 del Capitolato d’Appalto e relativi ai test, alle verifiche, al pre-collaudo ed al collaudo è stabilita una penale di 1/1000 (un millesimo o 1,00‰);
3. per ogni giorno/persona di mancata prestazione o di ritardo nell’espletamento di un intervento richiesto o rispetto alle diverse calendarizzazioni previste delle attività di assistenza all'avviamento, di generica assistenza agli utenti o sul Sistema stesso (paragrafi 7.5, 7.6, 7.8 e 7.9 dell’Allegato Tecnico) è stabilita una penale di 1/3000 (un tre millesimo o 0,33‰); tale penale verrà calcolata in riferimento alla finestra minima di erogazione del servizio o in quella migliorativa offerta dal Fornitore;
4. per ogni giorno lavorativo, ovvero per i giorni previsti come offerta migliorativa fatta dalla Ditta Aggiudicataria, di ritardo rispetto all’erogazione dei servizi di garanzia, di assistenza e di manutenzione sul software, sull’eventuale hardware e/o sui moduli (paragrafo 7 del Capitolato e relativi sottoparagrafi) è stabilita una penale pari ad 1/2000 (un due millesimo o 0,50‰);
5. per ogni giorno lavorativo di ritardo rispetto ai termini di recepimento delle osservazioni e delle segnalazioni comunicate o delle modifiche richieste dall’Ente è stabilita una penale di 1/3000 (un tre millesimo o 0,33‰);
6. per ogni ora solare di ritardo nell’espletamento dello specifico servizio di reperibilità (presa in carico, intervento e risoluzione) dall’Ente è stabilita una penale di 1/25000 (un venticinque millesimo o 0,04‰ – pertanto a livello giornaliero si ottiene lo 0,96‰);
7. per ogni giorno solare di indisponibilità del Sistema GEPC, oltre il limite indicato e nel rispetto dei vincoli previsti dal presente Capitolato d’Appalto e dall’Allegato Tecnico, dall’Ente è stabilita una penale di 1/1500 (un millecinquecentesimo o 0,67‰);
8. qualora il Sistema non risponda compiutamente al Capitolato o presenti un livello qualitativo insufficiente, delle funzionalità inadeguate, delle prestazioni applicative non accettabili o delle carenze strutturali sostanziali, il Comune invierà una prima comunicazione di richiamo alla Ditta con l’indicazione dettagliata delle anomalie rilevate. Il Fornitore deve rispondere entro 5 (cinque) giorni lavorativi indicando i comportamenti e le soluzioni poste in essere, entro al massimo 10 (dieci) giorni lavorativi a decorrere dalla data della risposta, per risolvere tutte le criticità e le carenze rilevate. Qualora si verificassero successivamente i medesimi problemi di qualità o le stesse carenze già segnalate, il Comune potrà inviare una seconda comunicazione di richiamo ed applicare contestualmente una penale di 1/3000 (un tre millesimo o
0,33‰) al giorno lavorativo per ogni episodio contestato. Al perdurare dei problemi l’Ente potrà continuare ad applicare le penali con le modalità sopra specificate.
9. qualora il personale impiegato dal Fornitore non risulti adeguato, non risponda ai livelli di professionalità richiesti o non sia in possesso delle certificazioni indicate oppure un qualsiasi servizio richiesto dalla fornitura (ad esempio i servizi di formazione degli utenti, quelli di assistenza all'avviamento del sistema, quelli di assistenza funzionale agli utenti, etc.), non sia erogato secondo i livelli di qualità previsti e concordati, il Comune invierà una prima comunicazione di richiamo alla Ditta con l’indicazione dettagliata delle carenze rilevate. Il Fornitore deve rispondere entro 5 (cinque) giorni lavorativi indicando i comportamenti e le soluzioni che verranno poste in essere, entro al massimo 10 (dieci) giorni lavorativi a decorrere dalla data della risposta, per risolvere le criticità e le carenze rilevate. Qualora si verificassero successivamente i medesimi problemi di qualità o le stesse carenza già segnalate, il Comune potrà inviare una seconda comunicazione di richiamo ed applicare contestualmente una penale di 1/3000 (un tre millesimo o 0,33‰) al giorno lavorativo per ogni episodio contestato. Al perdurare dei problemi l’Ente potrà continuare ad applicare le penali con le modalità sopra specificate.
Le penali di cui sopra sono definite salvo risarcimento del maggior danno.
Per il calcolo delle penali, i valori ottenuti saranno arrotondati sempre per difetto al numero intero tralasciando, quindi, i decimali.
12. Diritti di proprietà
Tutto ciò che sarà prodotto “ad hoc” nell'esecuzione delle attività contrattuali (analisi di dettaglio, applicazioni, codici sorgente, documentazione, etc.) sarà di esclusiva proprietà dell’Ente che, in base alle vigenti norme di legge, potrà avvalersi della facoltà di riutilizzare completamente o in parte quanto prodotto. Tale materiale dovrà essere consegnato dalla Ditta Aggiudicataria al Comune, su richiesta di quest'ultimo, anche prima della scadenza del contratto o della garanzia. Quindi, l’intero Sistema in uno stato di coerenza e di allineamento tra i sottosistemi utilizzati, cioè comprensivo delle librerie, del middleware, dei frame work, degli eventuali software di base, anche se di tipo open source ovvero rilasciati sotto licenza non commerciale, deve essere fornito su supporto CD/DVD in duplice copia, contenente:
• i binari/eseguibili pronti all'installazione;
• procedura di installazione guidata per tutte le componenti;
• i sorgenti di ogni componente sviluppata ad-hoc;
• manualistica e documentazione associata a quanto sopra.
Tutti i dati gestiti dal Sistema realizzato sono di ESCLUSIVA PROPRIETA’ del Comune di Firenze e l’Aggiudicatario è tenuto a fornire tutte le informazioni, le indicazioni di accesso e le relative utenze di amministrazione dell’applicazione e del database atte a garantirne la piena ed incondizionata fruibilità, oltre a permettere la completa ed autonoma gestione di tutto il Sistema realizzato nella sua interezza.
A tal proposito, qualsiasi utilizzo delle informazioni e/o dei dati gestiti dal Sistema, anche in forma parziale o “resi anonimi”, al di fuori del progetto oggetto della fornitura, ad esempio in demo, presentazioni, reportistiche, ricerche statistiche, etc., deve essere espressamente autorizzato per iscritto dall’Amministrazione Comunale. La stessa si riserva di agire in giudizio nelle sedi competenti per la tutela dei propri diritti e interessi.
13. Modalità di pagamento
Il pagamento in favore della Ditta Aggiudicataria sarà effettuato secondo le norme di legge in vigore. Il Fornitore dovrà sempre indicare nelle fatture le modalità di pagamento e riportare obbligatoriamente gli estremi del contratto e della determinazione dirigenziale che impegna la spesa, che sarà tempestivamente comunicata dall'Ente.
Il corrispettivo pattuito verrà fatturato successivamente alla data di sottoscrizione del contratto ed erogato in diverse tranche con le modalità di seguito indicate:
• 10% (dieci percento) del costo complessivo del Sistema, indicato nell’offerta economica (Modulo C, valutazione VECC), dopo la firma del contratto sottoscritto dall’Ente e dall’Aggiudicatario nel rispetto delle indicazioni del Capitolato d’Appalto;
• 20% (venti percento) del costo complessivo del Sistema, indicato nell’offerta economica (Modulo C, valutazione VECC), dopo il pre-collaudo positivo sottoscritto dall’Ente e dall’Aggiudicatario secondo le indicazioni, le verifiche ed i vincoli riportati nel Capitolato Speciale;
• 50% (cinquanta percento) del costo complessivo del Sistema, indicato nell’offerta economica (Modulo C, valutazione VECC), dopo il collaudo positivo sottoscritto dall’Ente e dall’Aggiudicatario secondo le indicazioni, le verifiche ed i vincoli riportati nel Capitolato Speciale;
• restante 20% (venti percento) del costo complessivo del Sistema, indicato nell’offerta economica (Modulo C, valutazione VECC), dopo un anno dal collaudo positivo ovvero alla conclusione del periodo di garanzia di 12 (dodici) mesi;
• 80% (ottanta percento) del canone di manutenzione e di assistenza, indicato nell’offerta economica (Modulo C, valutazione VECA), alla data di inizio dell’anno di manutenzione previsto dalla presente fornitura, cioè dopo la conclusione dei 12 (dodici) mesi di garanzia;
• restante 20% (venti percento) del canone di manutenzione e di assistenza, indicato nell’offerta economica (Modulo C, valutazione VECA), al termine dell’anno di manutenzione richiesto dalla fornitura e successivo alla garanzia.
Le fatture dovranno essere inviate per posta ordinaria a:
Direzione Risorse Tecnologiche Comune di Firenze
via Giuliani n. 250 – 00000 Xxxxxxx
e contemporaneamente per posta elettronica certificata al seguente indirizzo PEC già attivato dal Committente: xxxxxxxxxx@xxx.xxxxxx.xx.xx.
Il pagamento, al netto delle eventuali penali applicate, verrà effettuato entro 90 (novanta) giorni dalla data di ricevimento della relativa fattura. Non si darà corso al
pagamento delle fatture qualora risultassero dai controlli di rito inadempimenti degli obblighi contributivi, assicurativi, antinfortunistici e retributivi da parte del Contraente; il pagamento avverrà solo dopo che sia stato accertato il pagamento degli oneri suddetti.
Ai fini del pagamento del corrispettivo l’Aggiudicatario dovrà utilizzare uno o più conti correnti bancari o postali dedicati alle commesse pubbliche, secondo quanto previsto dall’art. 3 della Legge n. 136 del 13/08/2010, dal D.L. n. 187/2010 e ss.mm.ii. .
14. Trattamento dei dati personali e sensibili
Per la presentazione dell'offerta, nonché per la stipula del contratto con la Ditta Aggiudicataria, è richiesto alle Ditte concorrenti di fornire dati e informazioni, anche sotto forma documentale, che rientrano nell'ambito di applicazione del D.Lgs. 196/2003.
Le Parti si obbligano, per quanto di rispettiva competenza, ad effettuare il trattamento dei dati personali dei quali entreranno in possesso nella piena e totale osservanza di quanto disposto dal Codice in materia di protezione dei dati personali, approvato con D.Lgs. 30.6.2003, n° 196 e successive modificazioni ed integrazioni, con particolare riguardo al trattamento dei dati personali che verranno forniti dall’Ente al Fornitore. Si intendono qui espressamente richiamate ed applicate tutte le disposizioni in materia dettate dal menzionato D.Lgs. 196/2003, e successive modificazioni ed integrazioni, per il completo espletamento della fornitura ed anche per quanto riguarda la gestione e la trattazione dei dati personali (ed eventualmente sensibili) da parte del software offerto.
Inoltre, salvo diversa comunicazione dalla Ditta Aggiudicataria, si prevede che il legale rappresentante della Ditta sia anche il Responsabile per la Privacy.
15. Foro competente
In caso di controversia riguardante la fornitura in oggetto, si farà ricorso all’Autorità Giudiziaria. E’ escluso il ricorso all’arbitrato per la definizione delle controversie nascenti dal presente appalto. E’ vietato in ogni caso il compromesso.
Il Foro competente è quello di Firenze.