Capitolato Tecnico

Il presente Capitolato Tecnico d’Appalto è parte integrante della documentazione di gara e definisce le caratteristiche e i requisiti per l’affidamento dei servizi e delle attività volte a garantire l’evoluzione e la piena operatività dei Sistemi Informativi delle attività istituzionali di CSEA.

Le prescrizioni contenute nel presente Capitolato tecnico d’appalto rappresentano gli impegni che l’operatore economico Fornitore (nel seguito Fornitore) dovrà adempiere, con rinvio al resto della documentazione di gara per ogni altra disposizione vincolante.

1.2 Profilo Aziendale

La Cassa per i Servizi Energetici e Ambientali è un ente pubblico economico, così denominato ai sensi dell’art. 1, comma 670, della L. 208/2015 (Legge di Stabilità 2016), che opera nei settori dell’energia e dell’ambiente.

La sua missione principale è la riscossione di alcune componenti tariffarie dagli operatori; tali componenti vengono raccolte nei conti di gestione dedicati e successivamente erogate a favore delle imprese secondo regole emanate principalmente dall’Autorità di regolazione per energia reti e ambiente (ARERA) e del Ministero dello Sviluppo Economico.

La CSEA è sottoposta alla vigilanza ARERA e del Ministero dell’Economia e delle Finanze.

Le prestazioni patrimoniali imposte sono costituite dalle componenti tariffarie e da altri corrispettivi unitari che devono essere applicati al cliente finale in funzione dei dati di consumo e fatturazione; questi dati sono inviati dagli operatori dell’Energia e dell’Ambiente alla CSEA con dichiarazioni mensili, bimestrali, trimestrali e annuali, in parte per mezzo dei diversi servizi di data entry ospitati dal sito Internet della medesima CSEA.

Negli ultimi anni la CSEA, in attuazione delle disposizioni dell’Autorità e del MiSE, ha registrato un significativo incremento dei meccanismi regolatori gestiti, cumulando una serie sempre più ampia di competenze, attività e responsabilità.

Nell’ambito sistemi informativi, CSEA ha inoltre ottenuto le seguenti certificazioni:

- “Progettazione, Sviluppo e Gestione della infrastruttura ICT a supporto dei servizi IT” - ISO/IEC 27001:2017;

- “Continuità operativa della infrastruttura ICT a supporto dei servizi IT” – ISO 22301:2012.

L’incremento quantitativo e qualitativo delle attività richieste alla CSEA impegna rilevanti investimenti economici e di capitale umano sul fronte informatico, con l’apprestamento di portali e sistemi dedicati a specifiche disposizioni regolatorie e una intensa attività di interlocuzione con gli operatori di settore per eventuali chiarimenti, contraddittori e supporti operativi.

Le attività del Sistema Informativo di CSEA hanno origine quindi dalle disposizioni normative e si manifestano fondamentalmente su tre versanti: da un lato vede la nascita di nuove aree di intervento di CSEA; il secondo invece prevede il continuo adeguamento delle aree di intervento già presenti nel novero delle proprie attività; il terzo prevede la gestione stessa del Sistema Informativo includendo in questa le attività di manutenzione correttiva e preventiva.

Il Sistema Informativo CSEA vedrà inoltre una sua progressiva ristrutturazione e adeguamento alle nuove architetture e tecnologie. A titolo meramente esemplificativo, non esaustivo e non vincolante, le revisioni architetturali potranno prevedere un approccio SOA anche tramite microservizi, estensione della gestione tramite bus a tutti gli applicativi di CSEA, gestione di questi tramite container nonché utilizzo del cloud e la predisposizione e l’integrazione per servizi su blockchain.

1.3 Titolarità del software e dei dati, obbligo di riservatezza e tutela della privacy

Il Fornitore sarà nominato Responsabile esterno del Trattamento ai sensi dell’art. 28 del Regolamento UE 2016/679 (GDPR). Il Responsabile esterno del Trattamento o il sub-responsabile tratterà i dati personali in nome e per conto della CSEA in conformità alle finalità definite dalla stessa e nel rispetto delle disposizioni di cui al GDPR. Il Fornitore si impegna, comunque, a garantire la riservatezza in merito a dati, informazioni e documenti di cui venga a conoscenza o entri in possesso nell’esecuzione del servizio, anche ai sensi delle disposizioni previste dal GDPR nonché dal D. Lgs. n. 196/2003 s.m.i.. Il Fornitore adotterà e manterrà un programma sulla sicurezza delle informazioni che includa misure di sicurezza amministrative, tecniche e fisiche, progettate per garantire la sicurezza, la riservatezza e l'integrità dei dati.

La CSEA acquisisce dal Fornitore, in modo perpetuo, esclusivo ed irrevocabile, la proprietà nonché la licenza d’uso illimitata dei software, dei codici sorgenti e delle licenze, sviluppati e/o utilizzati per la realizzazione delle nuove funzionalità dei sistemi oggetto del presente capitolato, fatto salvo:

- l’utilizzo di componenti software già esistenti in modalità Open Source (es: librerie e framework), per le quali il Fornitore si impegna a definire la specifica licenza Open Source (es. GNU GPL, LGPL, Licenza Apache ed altre);

- le componenti coperte da Copyright per le quali è necessario acquisire la licenza d’uso

indicando quali componenti siano state adottate sotto tale licenza.

Il Fornitore dovrà, pertanto, depositare presso la CSEA copia di tutti i sorgenti software sviluppati e/o utilizzati e che non siano riconducibili a prodotti software open source di amplio dominio pubblico o prodotti software commerciali di cui si disponga di semplice licenza d’uso senza disponibilità del codice sorgente. Di quest’ultimi dovrà essere depositata licenza d’uso in originale.

CSEA, atteso l’acquisto della proprietà del software ai sensi di cui sopra, nonché della titolarità del relativo codice sorgente, delle configurazioni adottate e dei dati da esso gestiti, ne dovrà poter disporre a suo piacimento senza che vi sia necessità di ulteriore manutenzione correttiva alla scadenza del presente affidamento.

La CSEA, alla scadenza dell’appalto, avrà piena facoltà di procedere e di concedere, ai sensi della normativa sul riuso del software nelle Pubbliche Amministrazioni, senza alcun onere ad altre Amministrazioni dello Stato, il riuso del software sviluppato per suo conto, affinché queste possano adattarlo alle loro esigenze.

Tutti i dati e i contenuti del sistema di gestione documentale della CSEA, le procedure e le modifiche realizzate nell’alveo del contratto o comunque a supporto dell’operatività sono di esclusiva proprietà della CSEA, che ne detiene la titolarità.

1.4 Glossario

Termine	Definizione
FTE	Full Time Equivalent – “risorsa equivalente a tempo pieno”, ovvero le risorse necessarie per svolgere una determinata attività o realizzare un progetto, dove un FTE corrisponde sostanzialmente ad un giorno-persona. Con riferimento all’organico per un’attività o un progetto un FTE corrisponde ad una risorsa disponibile a tempo pieno per l’intervallo temporale considerato.
Headcount	Numero di persone fisiche, per il contesto di riferimento.
SPOC	Single Point of Contact, referente primario per l’ambito assegnato.
UAT	User Acceptance Test: collaudi (effettuati dall’utente CSEA) per la validazione finale di quanto implementato dal Fornitore.
No regression test	Il test di regressione, o “no regression test”, è una tipologia di software testing con la quale è possibile verificare che le modifiche apportate per una finalità specifica non pregiudichino altre funzionalità già esistenti.
Progetto	Un insieme di attività coerenti finalizzate allo sviluppo o alla più generale gestione di una entità specifica di CSEA (es. “progetto di manutenzione del sistema Energivori” o ad esempio un progetto per una nuova attività assegnata a CSEA).
Attività di progetto	Un insieme di attività inerenti un progetto, finalizzate ad un preciso risultato in un lasso di tempo stabilito; le attività concorrenti allo scopo possono richiedere anche interventi realizzativi, adeguativi, manutentivi o evolutivi.
Il Fornitore	Il soggetto aggiudicatario della presente procedura di affidamento.
ASI	Area dei Sistemi Informativi di CSEA.
Manutenzione adeguativa normativa	A seguito di aggiornamenti normativi (es. delibere ARERA) i sistemi dovranno essere adattati di conseguenza. Alcuni esempi sono: aggiornamento delle componenti tariffarie dei settori elettrico, gas ed idrico; aggiornamento della procedura di gestione del Bonus Sociale; adeguamento dei portali esterni, a vincoli normativi europei, ad es. GDPR.
Manutenzione adeguativa tecnica	A seguito di aggiornamenti tecnologici (es. librerie, sistemi operativi o versioni Java non più supportate ed il cui uso è attualmente sconsigliato in favore di una versione più recente), le componenti dei diversi sistemi dovranno essere aggiornate di conseguenza. Inoltre, definisce anche l’insieme degli adeguamenti necessari per migliorare la fruibilità, la sicurezza e la gestione del sistema. Ad esempio: la separazione su macchine distinte di Application Server e Database; l’aggiornamento della piattaforma della Java Virtual Machine ad una nuova LTS (Long Term Support, supporto a lungo termine); l’aggiornamento di un protocollo di comunicazione tra due sistemi applicativi in favore di termini di sicurezza (es. conversione da http ad https).
Manutenzione correttiva	Rappresenta l’insieme di azioni reattive che non concorrono ad aumentare il valore o la produttività e le prestazioni di un sistema, ma tendono ad un

	semplice ripristino dello status quo ante l’insorgere di un guasto o di un’avaria prevenendo che questa si ripeta ulteriormente. Include anche l’insieme delle azioni reattive atte al funzionamento di un sistema in coerenza con quanto previsto dai requisiti, espliciti ed impliciti.
Manutenzione preventiva	Rappresenta l’insieme di azioni atte a prevenire un guasto/bug/incidente per evitare ricadute sui sistemi. Ad esempio, le azioni per contenere l’utilizzo della memoria da parte di un applicativo durante il suo esercizio. Gestione delle politiche di log rotation e log retenction per prevenire la saturazione dei dischi.
Utenti	Personale CSEA o soggetti esterni ad essa che operano sui sistemi di CSEA, scevri da capacità tecniche-informatiche.
SIEM	Con l’acronimo SIEM (security information and event management) ci si riferisce ad una serie di prodotti software e servizi che combinano/integrano le funzionalità offerte dai SIM (security information management) a quelle dei SEM (security event management).
Supporto all’operatività	Supporto agli utenti per eventuali attività per le quali non siano già previste adeguate funzionalità che consentano all’utente piena autonomia. Ad esempio, la consultazione o la rettifica in base dati di informazioni qualora non esista una interfaccia utente dedicata allo scopo
Modalità on demand	Un servizio effettuabile anche “su chiamata” che garantisce in ogni caso la piena efficacia del servizio al committente, lasciando al contempo al Fornitore la libera organizzazione delle risorse.
PMO	PMO è l’acronimo di Project Management Office/Officer e nel contesto di questo capitolato si riferisce ad una persona fisica (Officer) del Fornitore. Si occupa di analizzare complessivamente l’andamento dei diversi progetti in una unica ottica consolidata. È deputato inoltre alla verifica dell’allineamento strategico con quanto atteso da CSEA, al monitoraggio complessivo dei rischi, dei progressi ed in generale alla governance delle risorse. I diversi Project Manager riportano quindi al PMO lo stato di avanzamento dei progetti gestiti, il livello di completamento delle attività pianificate, l’allocazione ed il rendimento del team di progetto, il risk management e tutte le metriche ed informazioni relative all’andamento del progetto da essi gestito.
SII	Il Sistema informativo Integrato (SII), istituito presso l'Acquirente Unico con la legge del 13 agosto 2010, n. 129/10, ha la finalità di gestire i flussi informativi fra i soggetti che partecipano ai mercati dell'energia elettrica e del gas secondo le regole e i procedimenti definiti dall'Autorità. CSEA definisce ed organizza flussi informativi in sinergia con il SII.
GestioneProgetti	Software Redmine, utilizzato per la pianificazione di progetti e per il tracciamento delle attività, richieste, ticket e bug tramite interfaccia web, nonché per parte della documentazione.

2 Contesto

L’evoluzione del Sistema Informativo della CSEA prevede diverse aree d’intervento, nell’ambito delle quali sono presenti servizi agli utenti, fruibili sia internamente (utenti CSEA e loro collaboratori) che esternamente (aziende, istituzioni o altri soggetti che interagiscono con la CSEA).

Gli interventi, necessariamente integrati tra loro, dovranno per lo meno:

- tener conto dell’infrastruttura già presente in CSEA, e comunque secondo precisi standard operativi, documentali ed in ogni caso secondo l’indirizzamento fornito da ASI;

- tener conto delle metodologie di sviluppo strutturate e già in uso e che ASI indicherà durante lo svolgimento del contratto;

- definire la modalità di intervento anche in visione della potenziale mutazione architetturale che potrà essere definita da ASI, includendo ad esempio: bus (es. enterprise service bus, cloud service bus o altri), virtualizzazione tramite container, utilizzo di DLT, blockchain, integrazione con il cloud;

- seguire i dettami previsti dalle certificazioni di CSEA ISO/IEC 27001:2017 e ISO 22301:2014 e loro successive evoluzioni

Quanto sopra vale e sarà adeguato secondo le nuove direttive che verranno di volta in volta definite dal committente.

Nel presente capitolato sono riportati i vincoli relativi alle metodologie e agli strumenti di supporto per l’esecuzione ed il controllo della fornitura, cui il Fornitore dovrà conformarsi senza oneri aggiuntivi per la CSEA. In fase esecutiva, CSEA potrà comunque valutare l’utilizzo a carico del Fornitore di strumenti a supporto ed integrazione delle procedure in vigore, con il fine di migliorie in merito agli aspetti di efficienza, efficacia, affidabilità, controllo.

2.1 Introduzione al Sistema Informativo CSEA

Il Sistema Informativo CSEA è costituito dall’insieme dei sistemi e delle informazioni utilizzate, prodotte e trasformate nell’ambito dell’esecuzione dei processi e delle procedure aziendali, nonché dai servizi con cui esse sono gestite.

CSEA, per quanto qui esposto e più in generale per quanto presente nel documento, si riserva il diritto di poter aggiornare ed integrare l’infrastruttura e gli elementi tecnologici che la caratterizzano nell’ottica di costante miglioramento delle architetture e delle scelte tecnologiche che su queste sono basate.

2.2 Architettura Tecnologica

L'infrastruttura CSEA è distribuita su due CED, connessi tra di loro mediante VPN; l’ambiente virtuale é basato sulla soluzione di iperconvergenza Simplivity ed é organizzato e diviso in due versioni separate basate sull'hypervisor Vsphere su un totale di 11 nodi.

L’infrastruttura di supporto all’operatività prevede la presenza di NAS che hanno lo scopo di garantire il file sharing tra i sistemi applicativi e quelli dedicati alla conservazione di informazioni, ulteriori sistemi di sicurezza perimetrale e di bilanciamento del carico, questi ultimi basati su tecnologia F5, e sistemi a supporto delle comunicazioni telematiche.

In particolare, nei sistemi in opera nell’infrastruttura di CSEA sui quali il Fornitore potrebbe essere chiamato ad operare sono inclusi:

1) Simplivity per virtualizzazione tramite VMware

2) Microsoft Active Directory, Windows Server e Microsoft 365

3) Commvault, Software di backup centralizzato

4) NetAPP, Nas di rete (usato per i backup di Commvault)

5) F5 Bilanciatori e Firewall applicativi

I sistemi server virtualizzati di CSEA, necessari all’erogazione dei servizi applicativi, sono basati su architettura x86 64bit. Per i servizi applicativi, a livello di sistemi operativi, è presente una infrastruttura mista che comprende sistemi Windows Server e Linux Server.

Le infrastrutture implementano strategie di Disaster Recovery e Business Continuity, parzialmente

anche geografiche, al fine di garantire la continuità nell’erogazione dei servizi.

In ogni caso gli ambienti di sviluppo ed integrazione sono e comunque dovranno essere mantenuti separati dal perimetro di esercizio.

2.3 Architettura Applicativa

Le infrastrutture di calcolo di CSEA si basano, quasi esclusivamente, su sistemi con architetture hardware e con processori multi-core. In questo contesto, il Fornitore deve garantire che il software sia realizzato secondo il paradigma del multithreading in modo da ottimizzare lo sfruttamento di tutte le risorse computazionali dei sistemi di esercizio, ed in ogni caso le soluzioni implementate non devono essere ostative all’applicazione di questo principio. Ogni eventuale deroga dovrà essere preventivamente motivata e concordata con CSEA.

La piattaforma di virtualizzazione è basata su VMWARE. L’utilizzo della piattaforma virtuale è assolutamente preferenziale: l’eventuale ricorso a server fisici deve essere opportunamente motivato o da oggettive esigenze di natura tecnica o da eventuali SLA computazionali stringenti richiesti dal business (ad esempio, elaborazioni che devono concludersi entro un tempo prefissato e che, quindi, richiedono delle risorse dedicate).

L’infrastruttura CSEA prevede l’erogazione di servizi applicativi per la raccolta, la condivisione e l’elaborazione di informazioni, finalizzate alla gestione dei processi di competenza. L’infrastruttura applicativa è prevalentemente basata sulla piattaforma di sviluppo JEE. I servizi applicativi sono erogati tramite il supporto del sistema Apache Tomcat nelle sue versioni più recenti.

Le informazioni raccolte tramite portali dedicati vengono acquisite e conservate in apposite basi di dati ed elaborate nelle fasi successive dei processi aziendali.

L’architettura applicativa di riferimento descritta nel documento è impostata su un modello

organizzativo a più livelli (n-tiers), come da standard e best practice di settore.

L’architettura applicativa è strutturata sulla base dei seguenti livelli logici:

1) Livello di presentazione (interfaccia utente)

2) Livello Logico Applicativo (business logic)

3) Livello di integrazione (integrazione con sottosistemi o con altri sistemi)

4) Livello Dati (persistenza delle informazioni)

Lo scambio di informazioni tra i componenti applicativi avviene principalmente tramite:

• il modello basato sul paradigma SOA;

• alcuni servizi applicativi vengono esposti attraverso un multicanale dedicato (Enterprise Service Bus basato su soluzione open source Mule ESB), che coordina specifici processi di business;

• procedure ETL che gestiscono flussi di dati asincroni costituiti da volumi rilevanti, attraverso il supporto della soluzione open source Hitachi Pentaho data integration.

Il sistema per la gestione del database dei servizi applicativi è attualmente MariaDB/MySQL. Sono altresì presenti soluzioni basate su PostgreSQL ed SQL Server. Le componenti applicative che prevedono l’accesso ai sistemi database dovranno essere supportate necessariamente da framework di gestione della persistenza per l’accesso alle basi di dati (OBR - Object Relational Mapping, Hibernate, MyBatis).

Il framework di riferimento per la realizzazione dei componenti applicativi basati su tecnologia Java è Spring versione 5 e successive, mentre le dipendenze sono gestite attraverso Maven.

Per quanto concerne l’identificazione e l’autorizzazione degli utenti (interni ed esterni) nel contesto di applicazioni WEB, CSEA richiede attualmente di gestire due tipi di identificazione ed autenticazione:

• Utenti CSEA – identificazione attraverso le credenziali presenti nella struttura di Active Directory CSEA. In pratica, sincronizza i gruppi e gli utenti da Active Directory permettendo di usare le medesime informazioni di identificazione che devono comunque essere immesse;

• Utenti Esterni – l’accesso degli utenti esterni avviene attraverso una infrastruttura di gestione dell’identità tramite una catena di autenticazione basata su username e password.

2.4 Aree Applicative

Nel novero di quanto sopra enunciato si evidenziano le seguenti principali aree applicative oggetto del presente capitolato; ove non diversamente indicato i sistemi sono da intendersi legacy:

1) Sistemi applicativi per le dichiarazioni e la raccolta di informazioni da soggetti esterni;

a. Anagrafica

b. Data Entry Elettrico

c. Data Entry Gas

d. Data Entry Idrico

e. Data Entry Rifiuti

f. Portale istanze

g. Portale Energivori

h. Portale per la Perequazione Elettrica

i. Portale per la Perequazione Gas

j. Portale Elenco Esperti

k. RAB (portale dedicato alle aziende con un numero di POD (Point Of Delivery) inferiore a 25.000)

l. PQS (portale per la Qualificazione degli Sportelli delle Associazioni dei Consumatori)

2) Sistemi applicativi di backoffice per il controllo, la verifica ed ogni elaborazione necessaria da parte di CSEA:

a. Gestionale

b. Bonus Gas (Bonus Sociale)

c. Sistema Indennitario

d. Flussi Banca

e. RNA, applicazione desktop Java per l’integrazione e l’interazione con il portale RNA

(Registro Nazionale degli Aiuti di Stato)

3) Sistemi a supporto per il controllo, lo smistamento e lo scambio delle informazioni tra i sistemi, fondamentalmente di carattere finanziario, economico e contabile:

a. Flussi SAP

b. Flussi Banca

c. Flussi Sepa

d. Pago PA (sistema legacy per l’integrazione con i servizi offerti dal partner tecnologico di Pago PA)

4) Integrazioni ed API verso:

a. Sistema di protocollazione e conservazione documentale, applicativo basato su Alfresco

b. Sistema di gestione dei processi amministrativo-contabili, SAP

5) Sistemi di conservazione delle informazioni (database)

a. MariaDB/MySQL

b. PostgreSQL

c. SQL Server

d. Filesystem (NAS)

Si esemplificano di seguito alcuni dei principali flussi informativi di CSEA, da considerarsi meramente indicativi per una prima comprensione delle dinamiche dei dati tra i diversi sistemi:

• Flusso informativo per la Raccolta Dati “Anagrafica Operatori”: tramite il portale “Anagrafica Operatori” i soggetti obbligati procedono alla registrazione e sottomettono le informazioni anagrafiche societarie previste e necessarie alle propedeutiche raccolte dati. Il portale provvede all’archiviazione sulle basi dati permettendo l’applicazione di controlli di merito su quanto inserito.

• Flusso informativo per le Raccolte Dati: tramite i diversi “Data Entry” le aziende sottomettono i dati (richiesti ed organizzati come indicato dalle relative norme); il portale di backoffice “Gestionale” ne esegue le relative archiviazioni sulle basi dati, elaborazioni, eventuali raffronti con altri dati già inseriti in precedenza nonché dei controlli di merito. Nel caso in cui da queste dichiarazioni vengano definiti dei crediti da parte delle aziende, prima di procedere con le

erogazioni il gestionale predispone una dashboard informativa ove sono raggruppate, assieme alla proposta di erogazione, una serie di informazioni al contorno relative all’azienda, allo storico, alle altre dichiarazioni etc. Alla luce delle informazioni raccolte il Comitato di Gestione può ratificare o meno l’erogazione. Per le erogazioni ratificate il flusso banca provvede all’emissione effettiva dei bonifici; la pratica così generata viene acquisita da SAP e, all’ottenimento della conferma di pagamento da parte della banca, si provvede alla riconciliazione con il sistema contabile SAP.

• Flusso informativo per la Raccolta Dati “Perequazione”: tramite i portali di “Perequazione”, le aziende sottomettono i dati (richiesti ed organizzati come indicato dalle relative norme); vengono quindi eseguite le relative archiviazioni sulle basi dati, elaborazioni, eventuali raffronti con altri dati già inseriti in precedenza nonché specifici controlli di merito. Le funzionalità di backoffice di “Perequazione” permettono di effettuare elaborazioni sui dati inseriti denominate “Calcoli”, che vengono acquisite dal portale di backoffice “Gestionale”, il cui ciclo di elaborazione è stato descritto nel Flusso informativo per le Raccolte Dati “Data Entry”.

• Flusso informativo per la Raccolta Dati “Sistema Indennitario”: tramite i “Data Entry” “Elettrico” e “Gas” le aziende sottomettono dati aggiuntivi rispetto al flusso informativo per le Raccolte Dati (richiesti ed organizzati come indicato dalle relative norme); a questi dati si aggiungono ulteriori flussi provenienti dal Sistema Informativo Integrato (da qui in avanti SII), che vengono recepiti dal portale di backoffice “Sistema Indennitario” che ne esegue le relative archiviazioni sulle basi dati, elaborazioni, eventuali raffronti con altri dati già inseriti in precedenza nonché dei controlli di merito. Le elaborazioni suddette vengono acquisite dal portale di backoffice “Gestionale”, il cui ciclo di elaborazione è stato descritto nel Flusso informativo per le Raccolte Dati “Data Entry”. L’esito delle elaborazioni viene infine consuntivato al SII attraverso un flusso di rendicontazione.

• Flusso informativo per la Raccolta Dati “Bonus Sociale”: il portale di backoffice “Bonus Sociale” acquisisce flussi dati inviati dal SII e richiesti ed organizzati come indicato dalle relative norme; i dati vengono archiviati sulle basi dati, elaborati e sottoposti a specifici controlli di merito. Il portale “Bonus Sociale” consente l’invio di richieste flussi dati per l’erogazione ad un soggetto esterno, e permette l’acquisizione del relativo flusso di rendiconto, che dovrà infine essere inviato al SII.

2.5 Dimensionamento dei sistemi

Si riportano di seguito alcune metriche indicative del dimensionamento dei sistemi, in considerazione dell’attuale ricognizione degli stessi di CSEA. Questi volumi o stime ed ulteriori riportate nel presente capitolato sono da ritenersi puramente indicative e non vincolanti in alcun modo per la presentazione dell’offerta e per l’esecuzione del contratto.

• Numero di utenti interni: inferiore a 200;

• Numero di utenti esterni: inferiore a 10.000;

• Sistemi Microsoft: circa 50 server per l’erogazione dei soli servizi qui riportati ed in ambiente di esercizio; complessivamente si contano circa 90 server Windows;

• Sistemi Linux: circa 10 server per l’erogazione dei soli servizi di esercizio qui riportati ed in ambiente di esercizio; complessivamente si contano circa 15 server Linux.

3 Descrizione dei servizi e modalità di erogazione della fornitura

3.1 Introduzione

La complessità dei sistemi CSEA e la dinamicità normativa che ne prevede un continuo aggiornamento, richiedono un approccio strutturato che garantisca la stabilità dei sistemi già in essere ed al contempo la necessaria rapidità e reattività nel creare (ex-novo) o adeguare i sistemi a quanto previsto da ARERA, da altre istituzioni o comunque dalle necessità funzionali che possono insorgere.

Il servizio in oggetto riguarda principalmente le seguenti attività:

• lo sviluppo software e relativi collaudi

• la manutenzione evolutiva

• la manutenzione adeguativa normativa

• la manutenzione adeguativa tecnica

• la manutenzione correttiva

• attività sistemistiche e relativo supporto

• la gestione applicativa (c.d. operation)

• il supporto all’operatività

• attività di Project Management e PMO

• il servizio di PagoPA

Ogni intervento, ad esclusione del supporto all’operatività dovrà essere concordato con l’Area Sistemi

Informativi (ASI) e non dovrà implicare regressioni di alcun tipo nel software attualmente operante.

L’attività implicherà interventi sia sulle interfacce, sia sulle procedure che sui dati presenti nel Sistema Informativo.

Le implementazioni dovranno essere orientate verso soluzioni adeguate alla natura fortemente evolutiva dei sistemi coinvolti nonché dinamicamente adeguate anche ai picchi di carico (principi di scalabilità).

In ogni caso si richiede che i software mantenuti, sviluppati o utilizzati dal Fornitore siano conformi ed aggiornati alle normative vigenti e siano in accordo con le linee guida di AgID inerenti la sicurezza informatica, anche adottando i principi “security by default”, “security by design”, “privacy by default” e “privacy by design” nella scrittura del codice e nelle impostazioni delle possibili configurazioni.

L’insieme delle attività è costituito dai cosiddetti “Servizi a Canone” ed i cosiddetti “Servizi a Consumo”, intendendo per i primi l’insieme dei servizi che saranno erogati dal Fornitore in maniera forfettaria secondo un canone mensile, mentre per l’erogazione dei secondi (i cosiddetti “Servizi a Consumo”), si terrà conto delle giornate uomo (e relative frazioni di queste) riconosciute per lo svolgimento dell’attività.

Con riferimento al complesso delle attività relative all’oggetto del capitolato, CSEA riporta una ripartizione indicativa del 35% per le attività inserite nei c.d. “Servizi a Canone” e del 65% per le attività inserite nei c.d. “Servizi a Consumo”. Questi volumi o stime ed ulteriori riportate nel presente

capitolato sono da ritenersi puramente indicative e non vincolanti in alcun modo per la presentazione

dell’offerta e per l’esecuzione del contratto.

Nel novero delle normative vigenti, lo svolgimento delle attività dei c.d. “Servizi a Consumo” dovrà essere svolto presso la sede CSEA, a meno di espliciti accordi con il Fornitore che la CSEA si riserva di valutare.

I “Servizi a Canone” saranno misurati esclusivamente in termini di raggiungimento degli obiettivi e sarà facoltà del Fornitore valutare la sede dove verrà svolta l’attività. In ogni caso CSEA si riserva la possibilità di richiedere che le attività vengano svolte presso la propria sede, sempre nel rispetto delle normative vigenti.

3.2 Servizi a Canone

Sono parte dei “Servizi a Canone”:

1) La presa in carico del servizio all’avvio del contratto.

2) Il passaggio di consegne al Fornitore subentrante al termine del contratto.

3) L’insieme delle attività di Project Management e PMO quali a titolo esemplificativo e non esaustivo: la pianificazione delle attività, il reporting periodico bisettimanale (SAL intermedi) sia complessivo che separato per ciascuna Attività di Progetto; la creazione di statistiche sui ticket gestiti e sulle loro evoluzioni; ulteriori metriche e considerazioni richieste da CSEA al riguardo.

4) La sola progettazione, esclusa quindi la realizzazione, della nuova architettura CSEA, rappresentando con maggior dettaglio quanto verrà proposto dal Fornitore in risposta alla presente gara o comunque secondo quanto verrà valutato in itinere concordemente con ASI.

5) Le attività di Manutenzione Correttiva e Preventiva, sia per quanto sviluppato dallo stesso Fornitore durante l’erogazione dei “Servizi a Consumo” che per quanto già presente nei sistemi CSEA. Negli ultimi 6 mesi sono stati aperti circa 550 ticket con un effort medio di evasione di 0.14 giornate uomo (circa 70 minuti) a richiesta.

6) La Manutenzione Adeguativa Tecnica (da svolgersi eventualmente anche in modalità on demand). Negli ultimi 6 mesi sono stati effettuati circa 30 interventi con un effort medio di

0.5 giornate uomo ad intervento.

7) La garanzia di quanto sviluppato dallo stesso Fornitore durante l’erogazione dei “Servizi a Consumo”, intendendosi con questa oltre al novero delle manutenzioni correttive, preventive ed adeguative, anche la più generale eliminazione, a sue complete spese, di vizi e difformità rispetto alle specifiche funzionali, anche in caso di uso del sistema accidentalmente non corretto da parte del Cliente; rimane inoltre valida la garanzia anche qualora i programmi vengano modificati dallo stesso Fornitore e/o incorporati in tutto o in parte in altri programmi.

8) Attività sistemistiche e/o supporto a queste (da svolgersi eventualmente anche in modalità on demand) intendendo l’insieme di attività per la installazione, configurazione, gestione, manutenzione, aggiornamento e monitoraggio dei sistemi alla base del Sistema Informativo di CSEA oggetto del presente capitolato, inclusa l’operatività e la corretta gestione dei sistemi operativi, dei sistemi per la virtualizzazione, dei database, delle configurazioni ed interrelazioni, e comunque più in generale l’efficienza e l’efficacia dell'apparato software sottostante gli applicativi, ovvero il supporto ai sistemisti CSEA per il livello strutturale secondo quando riportato nel relativo paragrafo § 2.2 Architettura Tecnologica. Negli ultimi

6 mesi le attività hanno rilevato un effort in un intervallo variabile tra 0,2FTE (periodi di attività ordinaria) e 0,7FTE (periodi di attività straordinaria).

9) La gestione applicativa (da svolgersi eventualmente anche in modalità on demand), che si occupa di attività trasversali ai diversi gruppi di lavoro includendo, a titolo esemplificativo e non esaustivo:

a. la gestione delle informazioni gestite dal SIEM (qualora un sistema SIEM non sia presente include anche la raccolta manuale delle medesime informazioni);

b. le attività di rilascio in esercizio;

c. il monitoraggio, gestione, ottimizzazione e riavvio:

i. dei database (competenze di DBA);

ii. degli Application Server

iii. del sistema di bus;

iv. delle ETL;

v. dei sistemi di interfacciamento, più in generale.

Negli ultimi 6 mesi le attività hanno rilevato un effort in un intervallo variabile tra 0,1FTE (periodi di attività ordinaria) e 0,5FTE (periodi di attività straordinaria).

10) Il “supporto all’operatività” ovvero:

a. il supporto agli utenti per l’inserimento, la modifica e l’estrazione dei dati laddove gli

utenti non possano intervenire in autonomia o comunque in maniera efficiente;

b. il supporto e l’indicazione agli utenti per farli intervenire in autonomia laddove già possibile (es. impostazione per l’esecuzione di una ricerca specifica su una maschera già disponibile);

c. supportare gli utenti per i casi di cui sopra anche tramite la creazione di specifici strumenti.

Negli ultimi 6 mesi sono stati aperti circa 300 ticket con un effort medio di 0.13 giornate uomo (circa 60 minuti) a richiesta.

11) Vulnerability Assessment, ovvero le periodiche analisi di sicurezza finalizzate ad individuare tutte le potenziali vulnerabilità dei sistemi e delle applicazioni di una rete di sistemi, eseguendo anche una identificazione e valutazione dei potenziali danni che l'attaccante potrebbe infliggere all'attività produttiva. La periodicità ed i perimetri di considerazione per l’esecuzione saranno indicati da ASI ed il completamento di ciascuna attività di analisi consisterà nel rilascio di un documento, soggetto ad approvazione di ASI, come meglio riportato nel relativo paragrafo;

12) Servizi di Partner Tecnologico PagoPA, come meglio riportato nel relativo paragrafo.

Rimane da intendersi che tutti i volumi o stime ed ulteriori riportate nel presente capitolato sono da ritenersi puramente indicative e non vincolanti in alcun modo per la presentazione dell’offerta e per l’esecuzione del contratto.

Per una maggior comprensione si riportano di seguito i dettagli necessari alla valutazione delle principali attività qui enumerate, con esplicita esclusione della “garanzia di quanto sviluppato”, della “progettazione dell’architettura”, del “supporto all’operatività” e della “gestione applicativa” in quanto non richiedono ulteriori dettagli per una loro migliore comprensione.

Servizi di Presa in Carico

La fase di presa in carico applicativa ha l’obiettivo principale di consentire l’acquisizione della

conoscenza degli oggetti software e della relativa documentazione, da parte del Fornitore entrante.

CSEA metterà a disposizione del Fornitore le informazioni ad essa disponibili (documentazione, sorgenti, database, procedure, etc.), ferma restando la necessità che il Fornitore si adoperi proattivamente (interviste agli uffici funzionali, lettura della documentazione disponibile, etc.) per la migliore comprensione dei sistemi affidatigli.

Il servizio di presa in carico del Fornitore entrante sarà supportato dalle attività a carico del Fornitore uscente come di seguito riportate (cfr. paragrafo “3.6 Servizio di Passaggio di Consegna (SH)” del precedente Capitolato del Bando di gara trasmesso alla Gazzetta Ufficiale dell’Unione Europea in data 19.02.2019, relativo ad un unico lotto con descrizione “Servizi di programmazione di software di sistemi e di utente”):

“L’erogazione del servizio prevede, innanzitutto, la predisposizione di un documento (Piano per il “Passaggio di Consegna”) che specifichi le modalità che intende seguire (sessioni di formazione, riunioni, affiancamenti, etc.), la stima e la tipologia di risorse professionali coinvolte, il piano attività da svolgere, gli aspetti che saranno oggetto di approfondimento, le informazioni che saranno fornite, i materiali e la documentazione che saranno messi a disposizione. […] Il completamento del passaggio di consegne dovrà essere corredato (pena mancata approvazione) dal rilascio completo di:

• Report di chiusura per le attività svolte e del livello di conoscenza ed autonomia raggiunto dal personale subentrante;

• Documentazione funzionale;

• Documentazione tecnica (componente sviluppi);

• Documentazione tecnica (componente interfacce).”

Nella fase di presa in carico, il Fornitore dovrà produrre almeno i seguenti documenti (la produzione potrà avvenire anche attingendo o integrando la documentazione ricevuta):

• un Piano di Subentro, che veda la conclusione entro e non oltre 2 mesi dall’avvio del contratto;

• documentazione di “specifica applicativa” che dovrà contenere in maniera strutturata, chiara, esaustiva ed intellegibile le informazioni funzionali e tecniche di ciascuna applicazione, con descrizione delle interfacce interne ed/od esterne, eventuali criticità, eventuali aspetti relativi al software e relative metriche dimensionali, alla riusabilità ed alla dipendenza dalle varie versioni delle tecnologie abilitanti inclusi framework o librerie;

• verbale di conclusione della presa in carico, che indichi le competenze acquisite e le risorse formate per ciascuna area di competenza.

La presa in carico dovrà concludersi entro e non oltre 2 mesi dall’avvio del contratto ed il Fornitore entrante è chiamato ad assicurare la continuità del servizio.

Rimane esclusiva responsabilità del Fornitore l’acquisizione delle competenze secondo la documentazione disponibile, gli incontri con il Fornitore uscente e con il personale CSEA (sia funzionale che ASI).

Le attività non sono esonerate nel caso in cui il Fornitore entrante sia lo stesso soggetto del Fornitore uscente.

Passaggio di Consegne

Il servizio di passaggio di consegna (o di hand over) comprende le attività necessarie al trasferimento del know-how sui servizi oggetto dell’appalto al personale di CSEA e/o a terzi da questa designati, con l’obiettivo di rendere CSEA ed un eventuale ulteriore Fornitore totalmente autonomi nella gestione di quanto oggetto del presente capitolato e delle successive evoluzioni.

Il servizio dovrà essere eseguibile, dietro richiesta di ASI, dal Fornitore periodicamente ogni 3 mesi, e comunque da erogare in ogni caso nel corso degli ultimi 2 mesi precedenti il termine del contratto.

L’erogazione del servizio prevede:

- La predisposizione e l’esecuzione di un documento (Piano per il “Passaggio di Consegna”) che specifichi le modalità che si intende seguire (sessioni di formazione, meeting, affiancamenti, etc.), la stima e la tipologia di risorse professionali coinvolte, il piano delle attività da svolgere, gli aspetti che saranno oggetto di approfondimento, le informazioni che saranno fornite, i materiali e la documentazione che saranno messi a disposizione.

- L’aggiornamento della documentazione di specifica applicativa, come già descritta nel paragrafo precedente.

- Il disegno architetturale (infrastrutturale, sistemistico e logico), con pieno dettaglio delle componenti presenti, loro interrelazioni (SOA, bus, ETL, etc.) ed indicazione dei diversi ambienti (es. sviluppo, integrazione, collaudo, esercizio);

- Più in generale tutto l’insieme della documentazione funzionale e tecnica, aggiornata, comprensibile ed esaustiva dei sistemi gestiti dal Fornitore.

I documenti qui riportati potranno essere oggetto di richieste di revisione da parte di ASI e più in generale di CSEA.

Nel caso in cui il passaggio di consegne avvenga al termine del contratto e sia quindi effettuato verso il nuovo Fornitore entrante, il Fornitore uscente dovrà produrre un report di chiusura, dando evidenza delle attività svolte e del livello di conoscenza ed autonomia raggiunto dalla parte discente.

Concluso il passaggio di consegna al Fornitore entrante, il Fornitore uscente dovrà comunque rimanere disponibile per almeno 6 mesi per eventuali richieste specifiche o approfondimenti sulle componenti da esso sviluppate o modificate.

Il completamento del passaggio di consegne dovrà essere corredato (pena il mancato rilascio del benestare al pagamento oltre all’eventuale computo di penali ulteriori) dal rilascio completo di:

• Report di chiusura per le attività svolte e del livello di conoscenza ed autonomia raggiunto dal personale subentrante;

• Il completamento della documentazione prevista;

• Accettazione da parte della CSEA, sentito il fornitore subentrante, della completezza e qualità della documentazione e formazione ricevuta.

Nel caso la CSEA accerti il mancato completo rilascio delle suddette attività il Fornitore è obbligato

ad assicurare comunque l’operatività del servizio.

Attività di Project Management e PMO

Quanto contenuto nel presente paragrafo vale sia per i Servizi a Canone che per i Servizi a Consumo.

Tutto lo svolgimento del contratto dovrà essere attentamente presidiato, gestito e coordinato dalle figure del Fornitore dei Project Manager e del Project Manager Officer, in accordo con le relative metodologie standard. Per ciascun Progetto o per ciascun raggruppamento di attività (“area di intervento”) definita da CSEA, dovrà essere definito un Project Manager (ed un suo sostituto, in coerenza con quanto previsto nel paragrafo § 4.2 Headcount ed FTE) che svolga anche le funzioni di SPOC.

I Project Manager per ciascuna area assegnata, ovvero per ciascun progetto, avranno la responsabilità di supervisionarne l’intero andamento ed avere piena contezza delle dinamiche ad esso inerenti. Saranno chiamati a redigere i SAL operativi intermedi di avanzamento di ciascun progetto/area secondo il modello predisposto da CSEA.

Dovrà quindi essere condiviso con ASI, con cadenza bisettimanale, un breve SAL operativo intermedio per ciascun Progetto o Area di Intervento ed un unico SAL consolidato operativo intermedio (che conterrà anche la somma di tutti i Progetti/Aree di Intervento) finalizzato alla gestione coordinata con ASI del portafoglio applicativo. I SAL operativi intermedi riporteranno – sia che siano i SAL consolidati o meno – l’avanzamento dei cronoprogrammi in modalità Gantt ed i principali KPI di project management che saranno concordati con CSEA quali, a titolo esemplificativo e non esaustivo Capacity Planning, Planned Value, Earned Value, Actual Cost, Schedule Variance (economica e temporale), ticket associati e tipologia, statistiche sugli stessi, gestione delle contingency (economiche e temporali), parametri di qualità (% rework, % compliance con i processi), gestione e matrice dei rischi, azioni di mitigazione, Incident Management ed ulteriori.

La documentazione prodotta sarà oggetto di verifica di CSEA.

La reportistica bisettimanale sarà redatta secondo modelli, che CSEA potrà modificare nel corso del tempo al fine di consentire un migliore controllo e rendicontazione delle attività.

L’insieme delle attività di Project Management dovrà essere eseguita e coordinata principalmente tramite GestioneProgetti o altri strumenti complementari (es. PowerPoint, file di Microsoft Project) che il Fornitore ed ASI valuteranno concordemente.

Manutenzione Correttiva e Preventiva

Sulla base di ciascuna richiesta di manutenzione, il Fornitore predisporrà un piano di intervento considerando la dimensione e la complessità del software, la criticità per il business, indicatori di difettosità residua standard e/o di applicazioni CSEA. Il Piano di Intervento conterrà anche i nominativi delle risorse coinvolte del Fornitore incaricate dell’attività, sia in termini di FTE che di headcount.

Il servizio di manutenzione correttiva comprende tutti gli interventi volti all’eliminazione dei malfunzionamenti del software applicativo di componenti presi in carico o sviluppati dal Fornitore ovvero al ripristino delle funzionalità previste, a fronte di errori, malfunzionamenti, incongruenze nel software o nella documentazione a corredo.

Gli interventi di manutenzione correttiva attivati, a fronte di errori, incongruenze e malfunzionamenti, daranno luogo all’apertura di una segnalazione da parte di CSEA contenente la descrizione dell’errore e/o anomalia, l’ambiente di rilevazione, la data e ora di segnalazione dell’errore e/o anomalia, il livello di severità del problema.

Tale segnalazione andrà censita e monitorata tramite l’apposito strumento di “GestioneProgetti”.

Il Fornitore, ricevuta la segnalazione del malfunzionamento attraverso GestioneProgetti, dovrà provvedere, nel rispetto dei livelli di servizio previsti (come definiti nel relativo paragrafo) alla rimozione dell’errore e/o anomalia e, una volta effettuato l’intervento, dovrà far pervenire a CSEA tramite lo stesso GestioneProgetti la comunicazione di risoluzione dell’anomalia, in cui dovranno essere indicati la data e l’ora di risoluzione, la descrizione degli interventi effettuati sul software, le eventuali modifiche apportate alla documentazione, il dettaglio dei test eseguiti in ambiente di collaudo ed il loro esito.

Per le anomalie bloccanti o significative, qualora il tempo stimato di risoluzione non rientri in quanto richiesto dagli uffici funzionali, dovrà essere fornita una soluzione temporanea accompagnata dalla pianificazione dell’intervento definitivo. L’eventuale soluzione temporanea dovrà garantire il ripristino delle funzionalità del servizio e dovrà comunque essere eseguita nel rispetto delle tempistiche richieste per l’anomalia originaria; delle eventuali soluzioni temporanee adottate ed ancora in essere dovrà essere data evidenza nella rendicontazione periodica dei SAL operativi intermedi.

Nel contesto dell’appalto, sono parte integrante della manutenzione correttiva anche eventuali attività di competenza sistemistica o specialistica di intervento sui database.

Manutenzione Adeguativa Tecnica

La manutenzione Adeguativa Tecnica consiste in una serie di interventi di analisi, progettazione ed implementazione, definiti congiuntamente tra CSEA ed il Fornitore e finalizzati ad adattare le componenti software e le funzioni della piattaforma alle mutate evoluzioni e necessità software al contorno, anche tramite l’implementazione di funzionalità e moduli completamente nuovi in integrazione a quanto già esistente.

Tipici esempi di manutenzione adeguativa tecnica includono l’upgrade di strutture software in uso

(librerie, framework, sistemi operativi) a causa del termine del servizio di manutenzione di questi da

parte dei relativi produttori (Es. End Of Support, End Of Life, etc.). Ulteriori esempi sono le necessità di patching o di adeguamento al fine di migliorare la sicurezza dei sistemi informativi.

Rimane facoltà esclusiva di ASI la valutazione finale, in eventuali contraddittori, sulla classificazione di una attività in Manutenzione Adeguativa Tecnica.

Supporto ed attività sistemistiche

Oltre a quanto già anticipato nel presente Capitolato, nell’ambito della infrastruttura descritta, e di ogni sua evoluzione futura, si richiede l’attuazione del servizio di supporto alla gestione dell’infrastruttura, e alla sua evoluzione, ed ogni manutenzione ordinaria e straordinaria, ivi compreso il supporto nella gestione di interventi aventi particolare carattere di urgenza. Si riporta una lista a titolo meramente esemplificativo:

• Evoluzione infrastruttura: Inserimento nell’architettura di nuovi server e loro configurazione. Supporto alla progettazione della rete dei sistemi e di ulteriori ambiti per il corretto funzionamento dell’infrastrutture complessiva;

• Manutenzione ordinaria dell’infrastruttura e dei sistemi server: controllo degli aspetti manutentivi ordinari quali aggiornamenti, fix software, ripristino configurazioni e backup, configurazioni ed aspetti pertinenti all’autenticazione/autorizzazione, monitoraggio dell’utilizzo di risorse (rete, CPU, disco, RAM, etc.);

• Manutenzione straordinaria dell’infrastruttura e sistemi server: attuazione delle procedure di

Disaster Recovery per la continuità operativa (sia in simulazione che in casi reali).

• Gestione sistemistica dei sistemi SAP.

Gli interventi nell’ambito dell’infrastruttura devono potersi attuare in maniera esaustiva almeno

nell’ambito dei dispositivi facenti parte del perimetro hardware delineato.

Ogni intervento, che dovrà sempre essere comprensivo della relativa documentazione architetturale, tecnica ed operativa, dovrà essere sempre e preventivamente valutato ed approvato preventivamente da ASI.

Vulnerability Assessment

Per Vulnerability Assessment si intende quel processo finalizzato a identificare e classificare i rischi e le vulnerabilità, in termini di sicurezza, dei sistemi informativi aziendali. È una scansione degli asset IT (hardware, software) e mirata a verificare i possibili punti deboli del Sistema Informativo.

Dovranno essere eseguiti almeno con cadenza semestrale. Le indicazioni sul perimetro di CSEA e sul posizionamento del potenziale attaccante (utente esterno, utente interno, DMZ, etc.) saranno di volta in volta comunicate da CSEA al Fornitore. La documentazione prodotta sarà oggetto di validazione da parte di ASI.

Servizio di Partner Tecnologico PagoPA

Nell’ambito dei processi che coinvolgono i sistemi di pagamento basati sulla piattaforma pagoPA, CSEA si avvale di un soggetto terzo (Partner Tecnologico) che, in nome e per conto della stessa CSEA, si occupa di gestire applicativamente il dialogo tecnico con la piattaforma pagoPA, mettendo a disposizione della CSEA strumenti web accessibili dagli utenti e sistemi di scambio automatico tra l’infrastruttura di pagamento CSEA e la piattaforma pagoPA.

Sia l’interfaccia web che le API che il Fornitore mette a disposizione, oltre a garantire adeguati livelli sicurezza, devono permettere di gestire tutta l’operatività prevista nell’ambito dei processi pagoPA in modo continuativo 24x7. Il Fornitore deve inoltre garantire un servizio di supporto ed assistenza 8x5.

L’interfaccia web e le API messe a disposizione dovranno essere documentate in modo esaustivo attraverso manuali tempestivamente aggiornati rispetto ad ogni nuova variazione dei relativi sistemi software.

L’adeguamento dei sistemi CSEA verso diverse modalità di interfacciamento con il Partner Tecnologico, rispetto a quanto già presente, rimangono a carico del fornitore.

3.3 Servizi a Consumo: le Aree e le Attività di Progetto

Sviluppo

Gli interventi di sviluppo di nuove componenti del Sistema Informativo e di manutenzione evolutiva saranno affidati in due diverse modalità:

- Modalità “a task”, ovvero l’assegnazione di una attività -tipicamente di entità minore- sulla base di una stima di effort condivisa tra ASI ed il Fornitore, da verificarsi poi in fase di consuntivazione;

- Modalità “a corpo”, applicabile tipicamente ad un novero di attività che concorrono per una finalità ben definita. In questo caso verrà stilato un cronoprogramma ed una stima complessiva dell’effort dedicato (in unità di misura di giornate-uomo), considerato appunto “a corpo” e quindi non soggetto a verifiche né da parte di CSEA e neanche da parte del Fornitore. Il Fornitore potrà consuntivare le giornate uomo corrispondenti allo stato di avanzamento del Progetto secondo il modello Earned Value, sulla base della pianificazione validata da CSEA.

Più in generale le attività potranno:

- essere associate specificatamente ad un progetto (es. “Sviluppo di un nuovo portale

Energivori”);

- essere associate ad una area di intervento / raggruppamento di attività (es. il raccordo di tutte le attività di Manutenzione Evolutiva o Manutenzione Adeguativa Normativa associate al già esistente portale Energivori”);

- non avere alcun raggruppamento specifico.

Si richiede che i software sviluppati e/o utilizzati dal Fornitore siano conformi ed aggiornati alle normative vigenti e siano in accordo con le evoluzioni delle linee guida di AgID per lo sviluppo di “codice sicuro”.

Manutenzione Evolutiva

La manutenzione evolutiva consiste in una serie di interventi di analisi, progettazione ed implementazione, definiti congiuntamente tra CSEA ed il Fornitore e finalizzati ad adattare le

componenti software e le funzioni della piattaforma alle mutate esigenze degli utenti, oppure ad implementare funzionalità e moduli completamente nuovi in integrazione a quanto già esistente.

Il servizio di sviluppo e manutenzione evolutiva comprende quindi le attività di analisi, progettazione, realizzazione e collaudo di nuove componenti o di funzionalità applicative. Più precisamente, tale servizio può comprendere i seguenti ambiti:

a) Lo sviluppo di nuove componenti costituenti l’area del Sistema Informativo ovvero di nuove applicazioni o parti autonome delle stesse che risolvono esigenze specifiche e circostanziate;

b) La realizzazione di funzionalità su componenti già esistenti e quinti volte a soddisfare esigenze utente che riguardano funzioni aggiuntive, modificate o complementari di una componente applicativa esistente, o comunque ad arricchirla di nuove funzionalità o mutarne la veste grafica e l’interfaccia utente.

Manutenzione Adeguativa Normativa

Analogamente a quanto già rappresentato per la manutenzione evolutiva, la manutenzione adeguativa normativa trae origine dall’evoluzione del contesto normativo in cui CSEA si trova ad operare. A titolo esemplificativo e non esaustivo si considerino i frequenti casi di variazioni delle aliquote per alcune componenti tariffarie.

3.4 Test e Collaudi

Per ogni attività di sviluppo o manutenzione (incluse le manutenzioni a canone) andranno eseguiti i relativi test e collaudi. L’effort impiegato per questi è da considerarsi solidale con l’attività di origine. Di conseguenza, ad esempio, le giornate uomo dedicate ai test e collaudi di attività inerenti la manutenzione adeguativa tecnica saranno considerati facenti parte del novero delle attività a canone. Come ulteriore esempio, opposto, le giornate uomo di collaudo dedicate ai test e collaudi dei servizi di manutenzione evolutiva saranno conteggiate come facenti parte dei Servizi a Consumo.

Applicazione del flusso V-model

Le attività di sviluppo del software (evolutive, progetti) seguiranno le modalità del v-model, prevedendo una continua interazione con gli uffici funzionali di CSEA, che dovrà tenersi, o perlomeno essere annotata, su Gestione Progetti. Si riporta di seguito il V-model:

Di fatto, per ciascuna attività (raccolta dei requisiti, disegno del sistema, disegno architetturale, disegno del modulo) corrisponde specularmente:

- una attività di definizione di test e collaudi interni (attività ad esecuzione del solo fornitore, di seguito per semplicità si adotterà la sola locuzione “test”) e dei collaudi (ad esecuzione di CSEA con il supporto del fornitore, anche detti UAT o con la sola locazione “collaudi”, intendendosi con essi solo quelli eseguiti dall’utente finale);

- la loro successiva esecuzione (rispettivamente per ciascuna attività: UAT, test di sistema, test di integrazione, test di unità).

Iter del software: test, collaudi, messa in esercizio, verifica in esercizio

Il fornitore predispone ed esegue piani di test, i cui contenuti ed esiti devono essere documentati opportunamente, in cui siano progettate verifiche nell’ambito delle seguenti aree: Funzionali, Usabilità, Prestazionali, Sicurezza, Affidabilità. La documentazione dei test e dei relativi esiti potrà anche essere contenuta in un succinto testo all’interno del relativo ticket di GestioneProgetti.

I piani di test dovranno sempre includere i no regression test.

Il fornitore, a valle degli esiti positivi di cui sopra, predispone un Piano di Collaudo, da sottoporre ad approvazione CSEA, che viene utilizzato per la validazione da parte dell’utente, a cui il fornitore dovrà garantire opportuno supporto durante lo svolgimento.

Il collaudo riguarderà quindi la verifica con gli utenti CSEA del corretto funzionamento dell’applicazione, la congruenza di quanto realizzato con le specifiche dei requisiti, le specifiche tecniche approvate, il rispetto degli standard di qualità e il corretto recepimento dei feedback ricevuti nel corso di eventuali momenti di verifica durante i rilasci software intermedi.

Sarà cura del Fornitore, a partire dalla data da cui emerge l’esito negativo del collaudo, comunicare la prima disponibilità a ripetere le operazioni di collaudo.

Affinché un’applicazione possa uscire dalla fase di collaudo ed essere “portata in esercizio”, dovrà rispettare i criteri di accettazione dell’applicazione, avendo già superato tutte le fasi di test previste, che comprendono:

• Verifica della completezza e qualità della documentazione di rilascio, manuali utente, installazione, amministrazione, procedure di installazione, migrazione;

• Non ci siano errori di gravità “high” o superiore in stato non risolto;

• Sia stato raggiunto un livello di copertura del testing adeguato, ad esempio valutando una metrica di copertura che tenga conto della copertura rispetto alla dimensione funzionale (Numero Casi d’Uso esercitati almeno una volta dai test / Numero Casi d’Uso Disponibili).

In caso di esito positivo del collaudo utente e previa autorizzazione da parte di CSEA si procederà al rilascio in esercizio di quanto realizzato; il fornitore dovrà quindi verificare il corretto funzionamento in esercizio.

Anche successivamente al collaudo sarà facoltà, ma non obbligo, di CSEA procedere all’effettuazione di ulteriori verifiche funzionali, prestazionali e di sicurezza per la verifica della rispondenza ai requisiti tecnologici, alla verifica del corretto funzionamento delle interfacce di comunicazione tra l’applicazione e gli altri sistemi coinvolti, alla verifica delle caratteristiche di qualità, della documentazione consegnata e di tutti gli aspetti di installabilità, configurabilità, amministrazione e migrazione dal sistema esistente.

Qualora dai suddetti controlli, i servizi erogati dovessero risultare non conformi a quanto previsto, il Fornitore dovrà provvedere tempestivamente a eliminare le disfunzioni rilevate, fatta salva l’applicazione di eventuali penali.

I controlli e le verifiche non liberano il Fornitore dagli obblighi e dalle responsabilità previste dal contratto.

3.5 Servizio di reperibilità

Nell’ambito della presente fornitura rientra il servizio di reperibilità, che include:

• Disponibilità telefonica

• Intervento da remoto

Attraverso tale servizio, CSEA intende massimizzare l’efficienza operativa e organizzativa, fornendo

tempestivamente soluzioni ai problemi segnalati.

Tale supporto alla gestione operativa dei sistemi dovrà essere erogato oltre il normale orario di servizio e nei giorni festivi, con l’obiettivo di realizzare un servizio “24/7”. Quest’ultimo verrà eseguito in assistenza remota, tramite un accesso VPN messo a disposizione da CSEA.

Il Fornitore erogherà i servizi per la gestione e la risoluzione dei problemi legati a malfunzionamenti/errori propri del sistema e/o a difficoltà operative degli utenti nell’utilizzo delle applicazioni e degli strumenti informatici specifici delle soluzioni applicative.

La reperibilità verrà attivata in caso di anomalie bloccanti sui sistemi critici che a giudizio insindacabile del personale CSEA richiedano il supporto del personale del Fornitore in quanto necessario alla risoluzione dell’anomalia stessa.

La reperibilità verrà attivata mediante chiamata telefonica, per cui il Fornitore deve fornire un numero di riferimento di reperibilità.

Il servizio di reperibilità verrà altresì attivato a fronte di interventi di manutenzione programmata da effettuare oltre l’orario di lavoro standard previsto per il servizio oggetto del presente capitolo.

3.6 Continuità operativa

Il Fornitore si impegna a garantire la continuità dei sistemi ad esso affidati in modalità 24x7, a meno di eventuali attività di manutenzioni programmate o straordinarie che dovranno essere anticipatamente comunicate e concordate con CSEA.

4 Modalità di esecuzione dei Servizi

Scopo del presente capitolo è integrare quanto già esposto con ulteriori informazioni valevoli per tutto il novero delle attività considerate.

4.1 Profili impiegati e loro gestione

Il Fornitore garantirà un alto grado di responsabilizzazione dei profili impiegati, organizzazione, disciplina documentale ed operativa, specifica attitudine a lavorare per obiettivi, capacità di lavorare in team e rispetto delle scadenze pianificate, oltre che una stretta aderenza alle metodologie riportate nel presente Capitolato o comunque successivamente comunicate da parte della sola ASI. Il Fornitore garantirà, altresì, flessibilità applicativa nel fronteggiare eventuali situazioni straordinarie, che dovessero intercorrere durante l’affidamento del contratto, e per le quali dovessero risultare necessarie attività integrative dei servizi previsti e disciplinati dal presente capitolato.

Per ogni attività si richiede che ciascuna risorsa impiegata abbia capacità espressive (scritte, verbali) della lingua italiana pari al livello C2 nel quadro di riferimento europeo Common European Framework of Reference for Languages (CEFR).

4.2 Headcount ed FTE

Al fine di ridurre gli impatti dati dalla centralizzazione del know-how su poche risorse, quali ad esempio:

- Rischio persona, ovvero sensibili impatti in termini di rallentamento operativo a seguito della indisponibilità (temporanea o definitiva) di un’unica persona depositaria di competenze specifiche;

- Ridotta capacità operativa massima, ovvero impossibilità di accelerare l’esecuzione di una

attività, sempre a causa di un numero esiguo di risorse con le competenze necessarie;

CSEA richiede di avere a disposizione da parte del Fornitore un numero di headcount (persone fisiche) maggiore (almeno in misura 1,5:1) del numero di persone-uomo-equivalenti (FTE) mediamente impiegate su ciascuna attività e comunque nel complesso della fornitura. È possibile per il Fornitore prevedere un meccanismo di rotazione e redistribuzione delle competenze tra varie risorse per ottimizzare l’utilizzo di queste, nonché un utilizzo parziale di ciascuna risorsa (FTE<1) laddove appropriato.

Ad esempio, si supponga che esistano due soli progetti: P1 e P2. La risorsa A è allocata per 0,5 FTE sul progetto P1; la risorsa C è allocata per 1 FTE sul progetto P2. In questo caso il Fornitore potrà formare una risorsa B che varrà come secondo headcount per entrambi i progetti. Il totale dell’impegno mediamente richiesto dai progetti è di 1,5FTE ed il numero di headcount è pari a 3: il requisito è soddisfatto. Inoltre, in questo caso, sia il progetto P1 che il progetto P2 potranno usufruire di 2FTE qualora necessario.

Il medesimo approccio in una pluralità di progetti e di risorse consentirà una maggiore flessibilità ed efficienza per il Fornitore, chiamato durante l’esecuzione del contratto ad esporre in maniera chiara le FTE e gli Headcount per ciascun progetto o attività.

Si richiede esplicitamente che tramite una adeguata formazione delle risorse, della loro rotazione sin da subito tra i diversi progetti e della organizzazione del Fornitore nell’utilizzo delle risorse, il Fornitore si impegni ad acquisire entro i termini della presa in carico questa modalità richiesta da CSEA. Il Fornitore si impegna inoltre a adoperarsi per ogni possibile ulteriore modalità che riduca sensibilmente le problematiche sopra citate.

Nei SAL operativi intermedi quindicinali, per ciascuna attività, il Fornitore dovrà fornire i nominativi delle figure professionali adoperate (FTE) e comunque formate (headcount) per l’attività specifica. La medesima rappresentazione dovrà esplicitare anche l’utilizzo futuro delle risorse tramite Capacity Planning. CSEA si riserva di poter rinnovare questa richiesta in ogni momento per poter verificare il soddisfacimento di quanto richiesto.

Rimane fermo che anche per attività che dovessero impegnare una quantità di FTE inferiore ad uno, in ogni caso il Fornitore si impegna a garantire la disponibilità di almeno due headcount con le relative competenze.

I Servizi a Canone: headcount minimi

Per tutto il novero dei “Servizi a Canone” il Fornitore dovrà garantire un numero adeguato di headcount e di FTE. Ai fini della verifica del requisito esposto, in sede di SAL consolidato operativo intermedio con cadenza quindicinale, il Fornitore dovrà indicare i nominativi, il numero di FTE e di headcount impiegato nell’intervallo considerato, nonché il numero ed i nominativi di FTE e di headcount previsto nel futuro per ciascuna attività.

I Servizi a Consumo: headcount minimi e Capacity Planning

Il Fornitore dovrà garantire un numero adeguato di headcount e di FTE per la parte dei Servizi a Consumo

In ogni caso per ciascun progetto o rilevante area di attività – come definito nel paragrafo §3.3 Servizi a Consumo: le Aree e le Attività di Progetto e comunque comunicata al Fornitore come tale da CSEA- il Fornitore si impegna a garantire che le relative competenze siano state acquisite da almeno 3 headcount, fermo restando la necessità di mantenere comunque la competenza di ciascuna singola attività (seppur non associata a progetti o aree) su almeno 2 headcount.

Rimane responsabilità del Fornitore gestire adeguatamente la rotazione delle competenze e delle disponibilità tra le risorse al fine di garantire sempre una adeguata contingency. Il Fornitore è chiamato a rappresentare all’interno dei SAL operativi intermedi con cadenza quindicinale anche il Capacity Planning con l’adeguata contingency richiesta per ciascuna competenza, fornendo i nominativi sia degli headcount che degli FTE considerati.

4.3 Consuntivazione dei servizi

Le attività dovranno essere tracciate su Gestione Progetti e la consuntivazione delle ore/uomo dovrà essere imputata sui relativi ticket. Ad ogni risorsa non potranno essere associate più di 8 ore uomo al giorno.

Per i c.d. “servizi ed attività trasversali” ovvero che possono essere inerenti sia ai “Servizi a Canone” che “ai Servizi a Consumo” quali ad esempio:

• Collaudi;

• Servizi di reperibilità;

• Aggiornamento o redazione della documentazione relativa a qualsiasi attività svolta;

Le attività saranno considerate nel novero dei “Servizi a Canone” oppure “Servizi a Consumo” a seconda della prevalenza dell’intervento richiesto, secondo quanto riportato nel Capitolato.

Ad esempio, quindi, attività di aggiornamento documentale in seguito a sviluppi saranno considerate come Servizi a Consumo e quindi il relativo effort potrà essere consuntivato. Viceversa, la medesima attività svolta a seguito di manutenzione correttiva dovrà essere svolta con la medesima diligenza ma il suo effort rimarrà inclusivo del generale canone dei servizi.

La consuntivazione all’interno di ciascuna giornata uomo dovrà indicare il dettaglio dell’attività svolta, pena il mancato riconoscimento della medesima.

4.4 Ticketing, piano di lavoro e le diverse tipologie di Attività di Progetto

La gestione delle richieste di servizio e incidenti verrà gestita esclusivamente tramite ticket aperti sul sistema GestioneProgetti, messo a disposizione da CSEA.

Si riporta la nomenclatura attualmente in uso. CSEA si riserva di modificarla nel tempo per adeguarla ad eventuali future necessità.

Tipologia della richiesta	Descrizione
Funzionalità Aggiuntiva	rappresenta una richiesta per uno sviluppo minore (es. una nuova maschera o una piccola funzionalità non esistente). Tipicamente questa richiesta non è già censita nel MasterPlan, ovvero nel registro delle attività annuali pianificate da CSEA per l’IT.
Bug	indica un comportamento errato del sistema, per il quale se ne richiede la risoluzione.
Richiesta di Supporto	indica l'inserimento, la modifica o l'estrazione di dati o comunque altre attività che non comportano cambiamenti nelle logiche dei sistemi informatici. Alcuni esempi di richieste di supporto sono l'estrazione, l'inserimento o la rettifica di dati, la generazione di bollettini PagoPA ed altro.
Attività di Progetto	E' una attività di più amplio respiro e tipicamente può includere diverse sotto- attività. Tutte le attività di progetto dovrebbero essere già censite nel MasterPlan, condiviso settimanalmente con le Aree e gli Uffici.

Ogni richiesta, attività o problema rilevato dovrà essere classificata secondo i seguenti livelli di severità:

Low	Deve essere risolto ma presenta una maggiore elasticità temporale.
Normal	Una funzionalità del sistema non risponde correttamente, ma ciò non inficia in maniera rilevante l'attività di business. Esistono soluzioni alternative che possono essere messe in campo sino alla risoluzione dell'attività.
High	Indica un problema che blocca una funzionalità sino a quando non è risolto. La funzionalità bloccata è rilevante per lo svolgimento del business. Esistono dei workaround possibili, sebbene onerosi.
Urgent	Il tema risulta prioritario rispetto ad altre attività. L'orizzonte temporale per il limite della risoluzione è vicino, gli impatti sono gravosi e non gestibili in alcun altro modo.
Immediate	Gli impatti sono immediati, gravissimi e potenzialmente irreversibili. Laddove necessario bisogna abbandonare ogni altra attività di CSEA per concentrarsi su questa richiesta.

La priorità di intervento è stabilita a partire dalla severità del problema, dalle tempistiche richieste dal business per la risoluzione di questo e del tipo di applicazione.

Il Fornitore, sentita CSEA, potrà valutare una riduzione del livello di severità già inserito dall’utente.

Il Fornitore, sentita ASI, potrà valutare un aumento del livello di severità rispetto a quanto già inserito

dall’utente

Si specifica che il sistema oggi in uso potrà cambiare nel corso della fornitura ed è richiesto al Fornitore di adattarsi all’eventuale nuovo strumento che sarà messo a disposizione da CSEA senza alcun onere aggiuntivo a carico della stazione appaltante.

A fronte di ogni richiesta formulata da CSEA e verificata dal Fornitore con ASI, che conterrà:

• la tipologia di intervento;

• la descrizione sintetica dei risultati da raggiungere o delle attività da svolgere;

• l’indicazione dei tempi entro i quali quanto richiesto dovrà essere realizzato, verificato (test, collaudi) e messo in esercizio;

il Fornitore formulerà un piano di intervento, anch’esso soggetto a verifica da parte di ASI, in cui

saranno indicati almeno:

• la stima dei giorni/uomo ritenuti necessari;

• un documento prospettico di esecuzione, inclusivo di un cronoprogramma di massima;

• i nominativi delle risorse che saranno coinvolte, in termini di FTE ed Headcount (vedi relativo paragrafo § 4.2 Headcount ed FTE) con Capacity Planning e sua adeguata contingency;

• eventuali vincoli e dipendenze.

Ulteriori informazioni nel piano di intervento potranno essere richieste da ASI o più in generale da CSEA. Quanto richiesto potrà anche essere redatto in semplice formato testo da inserire su GestioneProgetti.

Ricevuta l’approvazione al piano da parte dei referenti ASI, il Fornitore procederà con l’esecuzione delle attività assegnandole alle risorse individuate.

Una volta completate le attività e a chiusura dell’intervento, il Fornitore dovrà predisporre un verbale di esecuzione, da sottoporre ad ASI, anche in semplice formato testo da inserire su GestioneProgetti, al fine dell’ottenimento del benestare al pagamento.

Il verbale di esecuzione dovrà contenere indicazioni intellegibili e replicabili riguardo l’intervento effettuato e le sue modalità, i test eseguiti, inclusi i test di non regressione, indicazione di quali documenti siano stati aggiornati, dei test eseguiti in collaudo e quanto altro opportuno.

4.5 Modalità di Esecuzione delle Attività

Gestione della Documentazione

Ogni intervento dovrà apportare, oltre alla modifica del sistema, anche un contemporaneo intervento di redazione o modifica della documentazione, andando a chiarire – oltre a quanto implementato – anche il contesto di riferimento sul quale si è operato e le necessità funzionali o tecnologiche soddisfatte. Questo approccio prevede quindi una iterazione ricorsiva per l’aggiornamento della documentazione con successivi incrementi periodici per migliorarne la completezza, leggibilità e fruibilità (c.d. “kaizen” documentale). Rimane solidale con le attività svolte l’attività di scrittura, evoluzione e manutenzione della documentazione, includendo con questa il perimetro delle attività riconosciute.

ASI si riserva di valutare periodicamente l’aggiornamento e la bontà della documentazione prodotta. La mancata approvazione della documentazione redatta verrà considerato come il mancato completamento dell’intervento inerente, con conseguente mancato riconoscimento della consuntivazione delle giornate uomo, oltre ad eventuali penali.

Stima dell’effort in base ai requisiti funzionali

Per ciascuna attività dovrà essere previsto e motivato l’effort in maniera comprensibile; questo sarà

soggetto ad approvazione formale da parte di ASI, prerequisito per poter procedere con l’attività.

La previsione dell’effort dovrà essere riportata su Gestione Progetti o su documentazione di progetto

diversa qualora sia stato così concordato con ASI.

L’esecuzione delle attività senza una approvazione formale da parte di ASI dell’effort preventivato non potrà essere consuntivata, a meno di deroga esplicita e formalizzata per iscritto di ASI per eventuali contesti, aree di intervento et similia.

5 Criteri di valutazione

Il criterio di aggiudicazione della presente selezione è quello dell’offerta economicamente più vantaggiosa e prevede l’assegnazione di un punteggio così suddiviso:

• 70 % valutazione tecnica: l’Offerta Tecnica sarà valutata con criteri qualitativi, corrispondenti ad un punteggio complessivo di 70 (settanta) punti su 100 come riportato nella tabella seguente;

• 30 % valutazione economica: l’Offerta Economica sarà valutata con un punteggio complessivo

di 30 (trenta) punti su 100 sulla base della quotazione offerta.

5.1 Criteri di valutazione dell’offerta tecnica

Il punteggio dell’offerta tecnica è attribuito sulla base dei criteri di valutazione elencati nella

sottostante tabella, con la relativa ripartizione dei punteggi:

Tabella 1 - criteri e punteggi di valutazione tecnica

VALUTAZIONE TECNICA
CRITERIO	SUB-CRITERIO	PUNTEGGIO MASSIMO	TOTALE MASSIMO
1.) Composizione del team	Nessun sub-criterio. Descrizione completa riportata nel relativo paragrafo: §5.1-1.) Composizione del Team	10	10
	2.a) Organizzazione complessiva e per aree di
	progetto in riferimento alle peculiarità di CSEA e
	del contratto; descrizione completa riportata nel
	relativo paragrafo: §5.1-	5
	2.) Modalità Organizzativa per l'erogazione dei
	servizi
2.) Modalità organizzativa per l’erogazione dei servizi			15
2.) Modalità organizzativa per l’erogazione dei servizi	• 2.b) Capacità di gestire adeguatamente la formazione e rotazione di competenze per le risorse del Fornitore, documentando l’approccio che si terrà per headcount, FTE e nuovi ingaggi di personale; descrizione completa riportata nel relativo paragrafo: § 5.1-	10	15
	2.) Modalità Organizzativa per l'erogazione dei
	servizi
3.) Disegno di massima per una architettura ad alta adeguabilità e scalabilità	Nessun sub-criterio. Descrizione completa riportata nel relativo paragrafo: § 5.1-3.) Disegno di massima per una architettura ad alta adeguabilità e scalabilità	10	10
4.) Modalità di	Nessun sub-criterio. Descrizione completa riportata
monitoraggio e controllo	nel relativo paragrafo: §5.1-4.) Modalità di	15	15
della fornitura	monitoraggio e controllo fornitura
5.) Modalità di acquisizione e trasferimento know-how	Nessun sub-criterio. Descrizione completa riportata nel relativo paragrafo: §5.1-5.) Modalità di acquisizione e trasferimento know-how	10	10
6.) Referenze progettuali per attività simili	Nessun sub-criterio. Descrizione completa riportata nel relativo paragrafo: §5.1-6.) Referenze progettuali per attività simili	10	10

Al fine di rendere agevole ed organica la valutazione dell’Offerta Tecnica da parte della Commissione giudicatrice, essa dovrà essere predisposta secondo lo stesso ordine previsto nella tabella del presente paragrafo. L’Offerta dovrà descrivere, in maniera chiara e completa e in separate sezioni, quanto richiesto.

L’offerta tecnica dovrà essere redatta in lingua italiana e contenuta entro 40 pagine formato A4, utilizzando il carattere “Calibri 12”.

L’Offerta dovrà essere firmata digitalmente.

1.) Composizione del Team

Saranno oggetto di valutazione le qualifiche del gruppo di lavoro proposto dal Concorrente.

In particolare, si richiede che nel Team complessivo di progetto siano presenti almeno le seguenti figure professionali, anche in modalità “on demand” e/o in misura inferiore ad 1 FTE laddove opportuno:

• Project Manager capace di interfacciarsi con i livelli più alti dell’organizzazione e di intercettare ed esplicitare le esigenze di CSEA in termini di misurazione dell’efficacia ed efficienza delle stesse. I team/gruppi di lavoro devono essere composti per almeno il 10% da risorse afferenti a tale profilo professionale;

• Analisti programmatori senior Java JEE, con il compito di analizzare, progettare e realizzare interventi ed evoluzioni. I team/gruppi di lavoro di analisti programmatori devono essere composti per almeno il 70% da risorse afferenti a tale profilo professionale;

• Database MariaDB/Mysql Senior Administrator, in grado di gestire tutte le procedure necessarie alla messa in opera e manutenzione del progetto, alla pianificazione e verifica dell’operatività delle basi di dati, compresa la configurazione di sistemi di replica ed ambienti cluster;

• Esperto piattaforma di Middleware, con competenze ESB Mule, in grado di intervenire sulle procedure in essere o di svilupparne di nuove nell’ambito del sistema Enterprise Service Bus Mule ESB e/o di futuri middleware che saranno adottati;

• Esperto di sviluppo di procedure ETL realizzate tramite sistema Hitachi Vantara Pentaho Data Integration (Kettle).

• Test manager con esperienza di redazione di test case, esecuzione di test, monitoring e reporting dei test, creazione ed esecuzione, anche automatizzata, di test book tramite sistemi open source.

• Sistemista con competenze sistemistiche di SAP (queste ultime qui esplicitate in quanto non già rappresentate nell’architettura esposta), Linux, Windows Server, VMWare, VSphere, competenze di rete TCP/IP ed organizzazione, supervisione e manutenzione di sistemi SIEM.

2.) Modalità Organizzativa per l'erogazione dei servizi

Con riferimento al subcriterio 2.a): “Organizzazione complessiva e per aree di progetto in riferimento alle peculiarità di CSEA e del contratto” CSEA valuterà l’approccio proposto per l’organizzazione delle risorse del Concorrente tenendo in considerazione la dinamicità di CSEA ed al contempo la necessità

di presidio di progetti o di aree di attività come indicato nel paragrafo §3.3 Servizi a Consumo: le Aree e le Attività di Progetto.

Con riferimento al subcriterio 2.b): “Capacità di gestire adeguatamente la formazione e rotazione di competenze per le risorse del Fornitore, documentando l’approccio che si terrà per headcount, FTE e nuovi ingaggi di personale” CSEA valuterà l’approccio proposto per garantire la riduzione dei citati rischio persona e ridotta capacità operativa massima, come riportato nel paragrafo §4.2 Headcount ed FTE. In particolare, sarà valutata la strategia per perseguire la massima resa dei sopra citati obiettivi e la conseguente organizzazione che verrà adottata, descrivendo anche le eventuali modalità previste per la rotazione e formazione delle risorse del Concorrente.

3.) Disegno di massima per una architettura ad alta adeguabilità e scalabilità

L‘Offerta Tecnica dovrà riportare un disegno di massima per la nuova architettura di CSEA, prevedendo contemporaneamente:

• L’eventuale attribuzione a livello normativo e regolatorio di nuove attività affidate alla CSEA;

• Un continuo adeguamento normativo, con conseguente necessità di adattamento delle piattaforme già esistenti (es. aggiornamento delle aliquote, regole diverse per l’erogazione, etc.).

L’architettura dovrà quindi essere orientata a principi di rapida adattabilità.

Il disegno di massima dell’architettura dovrà essere orientato verso soluzioni software che abbiano una importante dominance di mercato (open source e non) e, ove possibile, limitino fenomeni di lock- in da parte dei fornitori sia per il software che per i servizi.

Il disegno di massima dell’architettura dovrà inoltre prevedere, possibilmente, l’integrazione dei processi funzionali di CSEA con una o più blockchain – indicando quali di queste sono suggerite – con riferimento alle attività di notarizzazione, tokenizzazione e smart contract.

4.) Modalità di monitoraggio e controllo fornitura

L’Offerta Tecnica sarà oggetto di valutazione da parte di CSEA in termini di organizzazione del Concorrente per la rispondenza a quanto richiesto nel presente Capitolato, con particolare riferimento alle attività di PM e PMO, alla modalità di controllo della fornitura per le parti a canone ed a consumo, per il Capacity Planning e per le attività di collaudo.

5.) Modalità di acquisizione e trasferimento know-how

Il presente criterio sarà oggetto di valutazione da parte di CSEA nei seguenti termini di:

• Modalità e soluzioni per l’acquisizione ed il trasferimento di know-how dell’architettura, delle competenze per lo sviluppo, delle competenze per la gestione dei sistemi; per acquisizione e trasferimento si intende non solo le attività dei Servizi di Presa in Carico e di Passaggio di Consegne come già riportato nel paragrafo § 3.2 Servizi a Canone, ma anche una più amplia strategia di condivisione.

• L’approccio che verrà adottato per la manutenzione documentale, con particolare enfasi sulle procedure adottate per garantire che sia sempre aggiornata e completa, oltre a quanto già

richiesto nel paragrafo § 4.5 Modalità di Esecuzione delle Attività, sottoparagrafo § Gestione della Documentazione.

Le attività documentali sono intese come asse portante, ma non esclusivo, delle modalità per i trasferimenti di know-how.

6.) Referenze progettuali per attività simili

Le referenze progettuali per attività e contesti di mercato simili a quanto richiesto nella fornitura (mercato di riferimento, numerosità dei sistemi JEE) devono essere in numero massimo di 5, che corrispondono alle 5 esperienze più significative ai fini del presente capitolato di gara. Le sezioni da sviluppare sono le seguenti:

• Riferimento del cliente e settore di appartenenza;

• Data di inizio e fine dell’esperienza;

• Indicazione delle variazioni apportate ai sistemi come conseguenza di evoluzioni o di aggiornamenti normativi;

• Descrizione della referenza, in cui dovranno essere indicati gli elementi caratterizzanti, distintivi e univoci del lavoro svolto e dalla quale risulti possibile verificare e valutare l’aderenza rispetto a quanto richiesto nel presente capitolato.

Sono considerate e valutate con maggiore preferenza le referenze di attività IT conseguenti la regolamentazione del Mercato delle Energy & Utilities e la regolazione ambientale Italiana; sarà considerato, inoltre, con maggior preferenza l’utilizzo di un approccio che abbia permesso di organizzare il lavoro in maniera strutturata ma al contempo altamente reattiva e dinamica.

5.2 Metodo di attribuzione del coefficiente per il calcolo del punteggio dell’offerta tecnica Per i criteri e sub-criteri 1, 2.a, 2.b, 3, 4, 5, 6 relativi ad elementi qualitativi di valutazione dell’offerta, la Commissione di gara sulla base del metodo discrezionale attribuirà ciascuna offerta un coefficiente compreso tra 0 e 1, in ragione del giudizio assegnato dagli stessi alle caratteristiche qualitative tra quelli di seguito riportati: ottimo = 1, buono = 0,8; sufficiente = 0,6, insufficiente = 0,3; assenza di proposta = 0.

Per l’offerta i-esima il coefficiente attribuito al j-esimo sub-criterio tecnico (VTi,j) viene calcolato come media dei coefficienti assegnati da ciascun commissario. La Commissione calcolerà il punteggio tecnico (PT𝑖) di ciascuna offerta 𝑖 -esima come somma dei punteggi tecnici afferenti ai singoli sub- criteri di valutazione relativi ad elementi qualitativi, secondo il metodo aggregativo compensatore, con la formulazione di seguito riportata:

𝑗=1

PT𝑖 = ∑𝑛

𝑉𝑇𝑖𝑗 ∗ C𝑗

=VT𝑖,1∗C1+ VT𝑖,2a∗C2a+ VT𝑖,2b∗C2b+VT𝑖,3∗C3+VT𝑖,4∗C4+VT𝑖,5∗C5+VT𝑖,6∗C6

Con 𝑉T𝑖𝑗 = Coefficiente attribuito all’offerta del concorrente 𝑖-esimo per l’elemento di valutazione j- esimo;

C𝑗 = Punteggio massimo attribuito al j-esimo sub-criterio tecnico; j= {1, 2a, 2b, 3, 4, 5, 6} indice del sub-criterio tecnico.

Il punteggio tecnico del Concorrente 𝑖-esimo, PT𝑖, non sarà oggetto di riparametrazione e sarà calcolato con una precisione fino alla quinta cifra decimale inclusa e poi sarà troncato alla seconda cifra decimale (es.: 65,34661 diventa 65,34).

5.3 Criteri di valutazione dell’offerta economica

L’Offerta economica per la fornitura del servizio dovrà, quindi, essere riferita a dette attività, e dovrà essere costituita da due distinte offerte di prezzo unitario rispetto a quelli individuati a base di gara come di seguito esposto:

- Servizi a Canone. Tali servizi saranno riconosciuti secondo un canone mensile a forfait. Il prezzo unitario a base d’asta è pari a 25.000€ oltre IVA mensili; l’erogazione dei Servizi e la corresponsione del relativo canone mensile avranno luogo per i soli mesi in cui i “Servizi a Consumo” abbiano capienza residua, a meno di diversa indicazione da parte di CSEA per il proseguimento dell’attività;

- Servizi a Consumo. Il prezzo unitario a base d’asta è pari a 350€ oltre IVA per giornata uomo. Il Concorrente dovrà indicare, ed utilizzare durante il contratto, una unica tariffa di riferimento per la consuntivazione di tutte le risorse impiegate nella quota parte di progetto “Servizi a Consumo” (tariffa di fte/qiornaliera). Sarà quindi criterio di valutazione dell’offerta la percentuale di ribasso rispetto alla tariffa giornaliera di 350€/gg oltre IVA. La soglia minima di tariffa giornaliera è di 200€/gg oltre IVA, oltre la quale la proposta al ribasso non sarà presa in considerazione.

In caso di esaurimento anticipato del plafond di giornate uomo per i Servizi a Consumo, CSEA si riserva la possibilità di riallocare le risorse economiche residuali secondo le medesime modalità previste nel Capitolato.

Il punteggio dell’offerta economica è attribuito sulla base dei criteri di valutazione riportati nella sottostante tabella, con la relativa ripartizione dei punteggi:

CRITERIO

(Quantitativo)

PUNTEGGIO

MASSIMO

TOTALE

MASSIMO

Ribasso della base d’asta dei Servizi a

Canone

Ribasso della base d’asta sulla tariffa complessiva media giornaliera

I prezzi unitari offerti non potranno essere pari o superiori, pena l’esclusione, ai prezzi unitari posti a

base d’asta.

L’Offerta deve essere firmata digitalmente.

5.4 Metodo di attribuzione del coefficiente per il calcolo del punteggio dell’offerta

economica

Il punteggio economico complessivo PEc,i assegnato al Concorrente i-esimo, sarà determinato sulla base della seguente relazione:

PEC,i = PE1,i + PE2,i

con:

- PE1,i = punteggio economico per i Servizi a Canone;

- PE2,i = punteggio economico per i Servizi a Consumo.

Per la valutazione del punteggio economico complessivo sarà calcolato con una precisione fino alla quinta cifra decimale inclusa e poi sarà troncato alla seconda cifra decimale (es.: 25,34661 diventa 25,34).

A ciascun Concorrente i-esimo, i punteggi economici PE1,i, PE2,i saranno attribuiti secondo la seguente relazione:

PEj,i = VEJ,i* CJ

con:

- J=1,2 indice del criterio economico

- CJ punteggio massimo attribuito al J-esimo criterio economico

- VEJ,i coefficiente relativo al criterio j-esimo ed all’offerta i-esima

Per ciascuna criterio j-esimo, il valore del coefficiente VEJ,i si ricava attraverso le formulazioni di seguito elencate:

𝑉E

j,i

𝑅𝑖

= 0,9 ∗ 𝑅𝑠𝑜𝑔𝑙𝑖𝑎

per R 𝑖

≤ Rsoglia

𝑉E

j,i

𝑅𝑖−𝑅𝑠𝑜𝑔𝑙𝑖𝑎

= 0,9 + (1 − 0,9) ∗ 𝑅𝑚𝑎𝑥−𝑅𝑠𝑜𝑔𝑙𝑖𝑎

per R

𝑖 > R

soglia

con:

R𝑖 = Ribasso relativo all’offerta 𝑖 -esima;

Rsoglia = Valore medio dei ribassi offerti da tutti i Concorrenti;

Rmax = Ribasso massimo tra tutte le offerte presentate.

Il Punteggio Economico complessivo del Concorrente i-esimo PEci non sarà oggetto di riparametrazione.

5.5 Metodo per il calcolo del punteggio complessivo

Il punteggio complessivo di ogni singola Offerta i-esima presentata sarà dato dalla somma dei

punteggi complessivi ottenuti per l’offerta tecnica e per l’offerta economica di cui ai precedenti

paragrafi:

POci = PTi + PEci

e sarà calcolato con una precisione fino alla quinta cifra decimale inclusa e poi sarà troncato alla seconda cifra decimale (es.: 65,34661 diventa 65,34).

6 Fatturazione, SLA e Penali

In relazione alle attività oggetto del servizio si elencano di seguito, in modo specifico, gli SLA attesi e le penalità applicate in caso di mancato raggiungimento dei livelli richiesti.

Le fatturazioni avranno luogo, con cadenza trimestrale, al positivo esito delle seguenti attività che ASI, il RUP ed il Direttore dell’esecuzione effettueranno, anche disgiuntamente, in occasione di ciascun SAL formale:

• Verifica che siano state effettuate le attività, previste o richieste e con la qualità necessaria;

• Validazione delle giornate uomo impiegate per le diverse attività “a consumo”;

• Validazione da parte di CSEA dei deliverable ricevuti.

In caso di esito negativo delle suddette attività di verifica in sede di SAL, dagli importi oggetto di fatturazione saranno decurtate le eventuali penali come di seguito determinate. Si precisa che le stesse saranno calcolate a partire dal giorno dell’accertamento da parte di CSEA.

Oggetto	Unità di misura	Penale	Tolleranza
Servizi di presa in carico oltre le tempistiche riportate nel relativo paragrafo	Xxxxxx lavorativi oltre i due mesi dall’avvio del contratto.	0,8 per mille dell’ammontare netto contrattuale per ciascuna giornata lavorativa	Non applicabile
Servizi di passaggio di consegne verso il Fornitore subentrante	Xxxxxx lavorativi oltre i due mesi dalla richiesta di passaggio di consegne	0,8 per mille dell’ammontare netto contrattuale per ciascuna giornata lavorativa	Non applicabile
Xxxxxxx, mancata consegna o inadeguatezza della richiesta intermedia della documentazione di passaggio di consegne	Xxxxxx lavorativi oltre la richiesta intermedia di passaggio di consegne	100€/gg per le consegne periodiche intermedie; 300€/gg per la consegna al Fornitore subentrante, oltre quanto già riportato nei “Servizi di passaggio di consegne verso il Fornitore subentrante” di cui al punto precedente	10 giorni lavorativi per le consegne periodiche intermedie; non applicabile per la consegna finale.
Non consegna o inadeguatezza dei SAL bisettimanali per ciascuna Attività di Progetto	Giorni lavorativi oltre la scadenza	200€/gg	5 giorni lavorativi;
Non consegna o inadeguatezza dei Vulnerability Assessment	Giorni lavorativi oltre la scadenza	200€/gg	5 giorni lavorativi È escluso dalle penali (grace period) il periodo di presa in carico ed i 180 giorni solari successivi.
Ritardi per le attività di manutenzione (incluso il supporto e le attività sistemistiche)	Giorni lavorativi, con riferimento alla data di consegna concordata con ASI ed inserita su GestioneProgetti. Xxxxxxx non sia inserita su GestioneProgetti nel momento della presa in carico, si intende entro due giorni lavorativi dall’inserimento della richiesta. Eventuali riaperture della segnalazione conteranno come ex-novo a partire dal momento della riapertura.	A seconda della severità: - Low: 100€ ogni 5 giorni lavorativi - High: 50€ ogni giorno lavorativo - Urgent: 200€ ogni giorno lavorativo - Immediate: 500€ ogni giorno lavorativo	Non applicabile. È escluso dalle penali (grace period) il periodo di presa in carico ed i 30 giorni solari successivi.
Ritardi per le richieste di gestione applicativa	Come sopra	A seconda della severità: - Low: 100€ ogni 5 giorni lavorativi - High: 50€ ogni giorno lavorativo - Urgent: 200€ ogni giorno lavorativo - Immediate: 500€ ogni giorno lavorativo	Non applicabile È escluso dalle penali (grace period) il periodo di presa in carico ed i 30 giorni solari successivi.
Mancata allocazione degli headcount rispetto a quanto condiviso	Xxxxxx lavorativi, per ciascun headcount mancante	100€ ogni giorno lavorativo	10 giorni lavorativi È escluso dalle penali (grace period) il periodo di presa in carico ed i 30 giorni solari successivi.
Mancata Continuità Operativa, anche parziale, in ambiente di esercizio	Ore (intesa come unità di 60 minuti) all’interno della fascia oraria 9-18 dei giorni feriali nazionali	250€/h per il primo giorno lavorativo oltre le quattro ore di tolleranza; successivamente, per ciascuna ora, una nona parte dell’1 per mille dell’ammontare netto contrattuale.	Le prime quattro ore di disservizio

Le suddette penali sono state determinate in conformità con quanto previsto dall’art. 113 bis

comma 4 del D.Lgs 50/2016.

7 Modalità di pagamento

Il Fornitore provvederà ad emettere fatture elettroniche, tramite piattaforma SDI, per le prestazioni del servizio dopo l’approvazione del SAL. La liquidazione di ogni singola fattura elettronica, a seguito della verifica della documentazione attestante la regolarità contributiva, sarà effettuata tramite bonifico bancario a 30 (trenta) giorni dalla data di ricezione della stessa. La fattura sarà intestata a:

Cassa per i servizi energetici e ambientali Xxx Xxxxxx Xxxxxxxx, 00

00196 Roma

C.F. – 80198650584

Si applica lo split payment, il codice univoco per la fatturazione è UFVE7Y.

Ai sensi dell’art. 3 della l. n. 136/2010, il Fornitore dovrà indicare in ogni singola fattura il numero di CIG indicato nel Bando di gara, nonché, nel Contratto, il conto corrente dedicato ove far confluire i pagamenti dei corrispettivi di cui alle fatture suddette, con il relativo codice IBAN e le generalità ed il codice fiscale della persona delegata ad operare sul conto corrente medesimo.

8 Garanzia

Preventivamente alla sottoscrizione del Contratto, il Fornitore dovrà presentare una garanzia definitiva, ai sensi dell’art. 103 del d.lgs. 50/2016, tramite cauzione o fidejussione, sottoscritta a favore di CSEA secondo le modalità di cui all’art. 93 commi 2 e 3. La garanzia dovrà essere presentata in originale a CSEA entro 10 giorni di calendario dalla data di comunicazione dell’aggiudicazione definitiva e dovrà essere conforme agli schemi tipo approvati con decreto del Ministro dello Sviluppo Economico di concerto con il Ministro delle Infrastrutture e dei Trasporti e previamente concordato con le banche e le assicurazioni o loro rappresentanze. Si applica l’articolo 93, comma 7 del d.lgs. 50/2016.

La garanzia, prevista con le modalità di cui all'articolo 103 del d.lgs. 50/2016, deve prevedere espressamente la rinuncia al beneficio della preventiva escussione del debitore principale, la rinuncia all’eccezione di cui all’articolo 1957, comma 2, del codice civile, nonché l’operatività della garanzia medesima entro quindici giorni, a semplice richiesta scritta da parte della CSEA.

Il mancato svincolo nei quindici giorni dalla consegna degli stati di avanzamento o della documentazione analoga costituisce inadempimento del garante nei confronti dell'impresa per la quale la garanzia è prestata.

Ai sensi dell’articolo 103, comma 4 del d.lgs. 50/2016, la mancata costituzione della garanzia determina la decadenza dell’affidamento e l’acquisizione della cauzione provvisoria presentata in sede di offerta da parte della CSEA, che aggiudica l’appalto al Concorrente che segue nella graduatoria.

La garanzia copre gli oneri per il mancato o inesatto adempimento e cessa di avere effetto solo alla data di emissione del certificato di regolare esecuzione.

9 Personale

Il Fornitore si impegna a tenere sollevata la CSEA da qualsiasi tipo di responsabilità, assumendo a proprio carico tutti i relativi oneri, nonché le eventuali sanzioni civili e penali previste dalle disposizioni vigenti in materia, restando a carico della CSEA il solo obbligo del pagamento dei servizi eseguiti.

Il Fornitore risponde dell’idoneità del personale ad assicurare lo svolgimento del servizio in maniera perfettamente rispondente alle esigenze della CSEA ed in modo da non ritardare o intralciare lo svolgimento delle attività della CSEA e/o di altro soggetto dalla stessa indicato.

10 Durata del Contratto

Il servizio sarà aggiudicato per la durata massima di 36 mesi dalla sottoscrizione del Contratto, e comunque sino all’esaurimento delle risorse economiche previste, come riportato nel paragrafo §5.3 Criteri di valutazione dell’offerta economica

La durata del contratto in corso di esecuzione potrà essere modificata per il tempo strettamente necessario alla conclusione delle procedure necessarie per l’individuazione del nuovo contraente ai sensi dell’art. 106, comma 11, del Codice. In tal caso, il contraente è tenuto all’esecuzione delle prestazioni oggetto del contratto agli stessi - o più favorevoli - prezzi, patti e condizioni.

11 Riservatezza

Il Fornitore garantisce la riservatezza in merito a dati, informazioni e documenti di cui viene a conoscenza o in possesso nell’esecuzione del servizio, nel rispetto delle disposizioni previste dal D.Lgs. n. 101/2018 e dal Regolamento UE 2016/679.

12 Obblighi del Fornitore relativi alla tracciabilità dei flussi finanziari

Il Fornitore assume tutti gli obblighi di tracciabilità dei flussi finanziari di cui all’art. 3 della legge 13

agosto 2010, n. 136 e successive modifiche e integrazioni.

Document Metadata

Table of Contents

Capitolato Tecnico

Document Metadata