Capitolato tecnico

L’Ente è stato istituito ai sensi dell'art. 1 del D.L. n. 193/2016, convertito con modificazioni dalla Legge n. 225/2016, ed è subentrato, a titolo universale, nei rapporti giuridici attivi e passivi, anche processuali, delle società del Gruppo Equitalia, sciolte a decorrere dal 1° luglio 2017 (a eccezione di Equitalia Giustizia), e di Riscossione Sicilia S.p.A., a decorrere dal 1° ottobre 2021, ai sensi dell'art. 76 del

D.L. n. 73/2021, convertito con modificazioni dalla Legge n. 106/2021.

AdeR svolge le funzioni relative alla riscossione nazionale dei tributi, la cui titolarità è attribuita all’Agenzia delle Entrate ai sensi dell’art. 3 comma 1 del D.L. 203/2005 (convertito con modificazioni dalla Legge 2 dicembre 2005 n. 248) e assume la qualifica di Agente della riscossione.

Con decorrenza dal 1° ottobre 2021, AdeR svolge anche le funzioni affidate all’Agenzia delle Entrate di cui all’art. 2 comma 2 della Legge Regionale del 22 dicembre 2005 n. 19 della Regione Siciliana, anche relativamente alle entrate non spettanti a quest’ultima.

AdeR svolge tutte le funzioni e compiti attribuiti dalle previsioni normative vigenti, in particolare:

a) effettua l’attività di riscossione mediante ruolo, secondo le disposizioni di cui al titolo I, capo II, e al titolo II del D.P.R. 29 settembre 1973 n. 602 e successive modificazioni e integrazioni;

b) può effettuale le attività di riscossione delle entrate, tributarie o patrimoniali, delle amministrazioni locali (individuate dall’ISTAT ai sensi dell’art. 1 comma 3 della Legge n. 196/2009, con esclusione delle società di riscossione) e delle società da esse partecipate, fermo restando quanto previsto dall’art. 17, commi 3-bis e 3-ter, del D.Lgs. n. 46/1999;

c) altre attività, strumentali e accessorie alla riscossione e alle attività di Agenzia delle Entrate, già svolte dalle società del Gruppo Equitalia alla data del 30 giugno 2017 nonché da Riscossione Sicilia S.p.A. alla data del 30 settembre 2021, nel rispetto delle previsioni normative vigenti.

A titolo di riferimento si riportano gli estremi della normativa che riguarda la riscossione e l’operato di AdeR, della quale il Fornitore dovrà avere competenza, laddove richiesto:

• Art. 10-quinquies, comma 2, del Decreto-legge 27 gennaio 2022, n. 4, convertito, con modificazioni, dalla Legge 28 marzo 2022, n. 25

• Art. 4-sexies del Decreto-legge 1° aprile 2021, n. 44, convertito, con modificazioni, dalla Legge 2 8 maggio 2021, n. 76

• Artt. 30-ter, 30-quater, 30-quinquies, 30-sexies, del Decreto-legge 6 novembre 2021, n. 152, convertito, con modificazioni, dalla Legge 29 dicembre 2021, n. 233

• Art. 1, commi 14, 15, 16, 17, 18, 19, 21, 22, 23, 572, 577 e 913, della Legge 30

dicembre 2021, n. 234

• Artt. 2, 3, commi 2 e 3 e art. 5-octies del Decreto-legge 21 ottobre 2021, n. 146, convertito, con modificazioni, dalla Legge 17 dicembre 2021, n. 215

• Art. 9, comma 2 e art. 76, del Decreto-legge 25 maggio 2021, n. 73, convertito, con modificazioni, dalla Legge 23 luglio 2021, n. 106

• Art. 1, comma 17-bis, art. 4, commi da 3 a 10, e art. 5, commi 8 e 9, del Decreto-legge 22 marzo 2021, n. 41, convertito, con modificazioni, dalla Legge 21 maggio 2021, n. 69

• Art. 22-bis, comma 4, del Decreto-legge 31 dicembre 2020, n. 183, convertito, con modificazioni, dalla Legge 26 febbraio 2021, n. 21

• Art. 1, comma 1090, della Legge 30 dicembre 2020, n. 178

• Art. 13-decies, commi da 1 a 5, del Decreto-legge 28 ottobre 2020, n. 137, convertito, con modificazioni, dalla Legge 18 dicembre 2020, n. 176

• Artt. 152, 153 e 157, comma 3, del Decreto-legge 19 maggio 2020, n. 34, convertito, con modificazioni, dalla Legge 17 luglio 2020, n. 77

• Art. 68, del Decreto-legge 17 marzo 2020, n. 18, convertito, con modificazioni, dalla Legge 24 aprile 2020, n. 27

• Art. 1, commi 785 e 792, della Legge 27 dicembre 2019, n. 160

• Art. 37 del Decreto-legge 24 ottobre 2019, n. 124, convertito, con modificazioni, dalla Legge 19 dicembre 2019, n. 157

• Artt. 4-novies e 16-bis del Decreto-legge 30 aprile 2019, n. 34, convertito, con modificazioni, dalla Legge 28 giugno 2019, n.58

• Artt. 15, 63, 68, 76, 88, 269 e 389 del Decreto legislativo 12 gennaio 2019, n. 14

• Art. 1, commi da 184 a 198, 326, 327, 328, 991, lett. a) e 994, della Legge 30 dicembre 2018, n. 145

• Artt. 3, 4 e 5, del Decreto-legge 23 ottobre 2018, n. 119, convertito, con modificazioni, dalla Legge 17 dicembre 2018, n. 136

• Art. 3, comma 5 e 35, del Decreto-legge 28 settembre 2018, n. 109, convertito, con modificazioni, dalla Legge 16 novembre 2018, n. 130

• Art. 12-bis del Decreto-legge 12 luglio 2018, n. 87, convertito, con modificazioni, dalla Legge 9 agosto 2018, n. 96

• Artt. 1 e 2 del Decreto-legge 16 ottobre 2017, n. 148, convertito, con modificazioni, dalla Legge 4 dicembre 2017, n. 172

• Art. 238-bis del Decreto Presidente della Repubblica 30 maggio 2002, n. 115

• Art. 000-xxx xxx Xxxxxxx legislativo 18 agosto 2000, n. 267

• Art. 11 del Decreto-legge 9 febbraio 2017 n. 8, convertito, con modificazioni, dalla Legge 7 aprile 2017, n. 45

• Artt. 1, 2, 3, 6, 7-quater del Decreto-legge 22 ottobre 2016, n. 193, convertito, con modificazioni, dalla Legge 1° dicembre 2016, n. 225

• Art. 48 del Decreto-legge 17 ottobre 2016 n. 189, convertito, con modificazioni, dalla Legge 15 dicembre 2016, n. 229

• Artt. 4, 6, 9 e 12 del Decreto legislativo 24 settembre 2015, n. 159

• Art. 1, commi 684 e seguenti, della Legge 23 dicembre 2014, n. 190

• Art. 1, commi 537 e seguenti, della Legge 24 dicembre 2012, n. 228

• Art. 9, commi 3-bis, 3-ter, 3-quater, 3-quinquies e 3-sexies, del Decreto-legge 2 marzo 2012, n. 16, convertito, con modificazioni, dalla Legge 26 aprile 2012, n. 44

• Ministero dell'economia e delle finanze, Decreto 6 novembre 2013

• Artt. 29 e 30 del Decreto-legge 31 maggio 2010, n. 78, convertito, con modificazioni, dalla Legge 30 luglio 2010, n. 122

• Ministero Delle Finanze, Decreto 3 settembre 1999, n. 321

• Decreto legislativo 13 aprile 1999, n. 112

• Decreto legislativo 26 febbraio 1999, n. 46

• Xxxxxxx xxx Xxxxxxxxxx xxxxx Xxxxxxxxxx 00 settembre 1973, n. 602

1.2 Obiettivi

Obiettivo dell’Ente è quello di migliorare l'efficacia della riscossione nazionale mediante un approccio che garantisca economicità della gestione, soddisfazione dei contribuenti per i servizi prestati e aumento dei volumi di incasso, anche mediante azioni di prevenzione e contrasto dell'evasione ed elusione fiscale.

Nel quadro della generale tendenza al rinnovamento delle attività di riscossione, e in particolare in seguito al riordino della disciplina relativa alle attività di riscossione mediante ruolo, Agenzia delle entrate-Riscossione (di seguito anche AdeR) sta attuando un complesso piano industriale che persegue il miglioramento dell’efficacia e dell’efficienza del modello di produzione, allo scopo di migliorare i livelli di servizio ottimizzando al contempo la struttura dei costi operativi.

All’interno di questo percorso, sono state lanciate diverse iniziative riconducibili

complessivamente a tre precise direttrici sostanziali:

• Innovazione e sviluppo dell’informatizzazione, rimarcando sempre di più il ruolo primario svolto da AdeR nella realizzazione, promozione e diffusione di soluzioni informatiche innovative come strumenti abilitanti del processo di riscossione;

• Massimizzazione dell’efficienza complessiva del modello operativo;

• Miglioramento della trasparenza delle attività svolte verso il mercato di riferimento, attraverso la definizione di chiari standard qualitativi e il potenziamento della capacità di gestione dei clienti.

Nell’ambito di questo quadro di trasformazione, AdeR intende affidare all’aggiudicatario della gara i servizi informatici di sviluppo, manutenzione, supporto specialistico e di supporto agli utenti dettagliatamente indicati nel presente capitolato relativi al sistema della riscossione di AdeR denominato SET (Sistema Esazione Tributi).

La necessità di acquisire i servizi in parola nasce sia dal profondo e continuo cambiamento del quadro normativo di riferimento, che introduce sistematicamente nuove “regole” inerenti all’attività di riscossione, sia dal contesto socioeconomico nel quale AdeR opera, che determina l’esigenza di rivedere il modello relazionale con cittadini, imprese contribuenti ed enti impositori.

Tutto ciò implica la necessità di un’evoluzione delle componenti applicative, per

assicurare:

• un livello di compliance più aderente al modello istituzionale di impresa;

• il controllo organico dei fenomeni della riscossione;

• l’evoluzione dei servizi offerti al contribuente.

Relativamente a predetti servizi il presente capitolato definisce la stima delle quantità, la qualità ed i livelli di servizio richiesti, da considerarsi requisiti minimi, nonché i requisiti migliorabili dal Concorrente in sede di offerta.

2 Il Sistema Esazione Tributi (SET)

Il Sistema della Riscossione (SET) oggetto di gara si può considerare suddiviso nelle seguenti aree funzionali:

− Anagrafica Ruoli e cartellazione

− Coattivo

− Contabilità

− Conto Fiscale

− Esatto

− Funzioni di servizio

− Inesigibilità

− Java Web Services

− JCL SET

− Notifica

− Procedure Cautelari ed Esecutive

− Provvedimenti

− Rendicontazione e Versamento

− Riscossione

− Servizi

− Stato della Riscossione

− Versamenti diretti e Servizi di cassa

− Servizi REST

− Servizio AVCP

Da un punto di vista tecnologico, SET è in massima parte costituito da applicazioni mainframe (CICS, COBOL, DB2) e in minima parte da implementazioni su sistemi dipartimentali che interagiscono tra di loro.

Le componenti applicative si possono considerare divise in due categorie tecnologiche:

• Applicazioni J2EE/MS ad alta intensità elaborativa e/o alta interazione utente che rappresentano i sistemi dipartimentali che elaborano grandi quantitativi di dati o che hanno una maggior interazione utente;

• Applicazioni COBOL ad alta intensità elaborativa e/o alta interazione utente che rappresentano i sistemi mainframe, che elaborano molte informazioni o che hanno una maggior interazione utente.

Tutte le componenti applicative sopra citate sono state stimate in Function Point (FP), il cui numero definisce il fabbisogno di manutenzione evolutiva e correttiva su di esse.

Nella tabella seguente si riporta il parco applicativo con le informazioni tecnologiche:

Area Funzionale	TECHNOLOGIES
Anagrafica Ruoli e Cartellazione	CICS, Cobol, JCL, SQL
Coattivo	ASP, C++, HTML5, SQL, Visual Basic
Contabilità	CICS, Cobol, JCL, SQL
Conto Fiscale	CICS, Cobol, JCL, SQL
Esatto	CICS, Cobol, SQL
Funzioni Di Servizio	CICS, Cobol, JCL, SQL
Inesigibilità	CICS, Cobol, JCL, SQL
Java Web services	JEE
JCL Set	CICS, Cobol, JCL, SQL
Notifica	CICS, Cobol, JCL, SQL
Procedure Cautelari ed Esecutive	CICS, Cobol, JCL, SQL
Provvedimenti	CICS, Cobol, JCL, SQL
Rendicontazione e Versamento	CICS, Cobol, JCL, SQL
Riscossione	CICS, Cobol, JCL, SQL
Servizi	CICS, Cobol, SQL
Stato della Riscossione	CICS, Cobol, JCL, SQL
Versamenti Diretti e Servizi di Cassa	CICS, Cobol, JCL, SQL
Servizi REST	HTML5, JEE, SQL
Servizio AVCP	CICS, Cobol, JCL, SQL, JEE

Tabella 1: Lista delle componenti software di SET oggetto dei servizi descritti in questo capitolato

Si rimanda agli allegati tecnici “F” e “G” circa i dettagli sull’organizzazione e

sull’architettura dei moduli elencati in tabella.

3 Consistenza dei servizi

3.1 Attività richieste nell’appalto

I Servizi oggetto di affidamento sono i seguenti:

• Onboarding Application Portfolio Management (APM);

• Servizio di Application Management (AMS);

• Servizio di Nuovi Sviluppi (NSS);

• Servizio di Assistenza Specialistica (AS);

• Servizio di Supporto agli utenti e Richiesta Informazioni (RI).

Nella tabella seguente sono indicate le metriche di contabilizzazione per le attività rientranti in ciascuno di detti servizi, descritte in dettaglio nei paragrafi successivi.

Servizio	Metriche di contabilizzazione
Onboarding APM	corrispettivo a misura in base al numero delle GG/P effettivamente erogate
Servizio di Application Management (AMS)	canone mensile fisso posticipato calcolato in funzione del numero complessivo di FP
Servizio di Nuovi Sviluppi (NSS)	corrispettivo a misura in base al numero delle GG/P effettivamente erogate
Servizio di Assistenza Specialistica (AS)	corrispettivo a misura in base al numero delle GG/P effettivamente erogate
Servizio di Supporto agli utenti e Richiesta Informazioni (RI)	corrispettivo a misura in base al numero delle GG/P effettivamente erogate

Tabella 2 – Metriche di contabilizzazione dei servizi oggetto dell’appalto

L’aggiudicatario, di seguito “Fornitore”, sarà obbligato all’esecuzione dei suddetti servizi, nel rispetto di quanto previsto, per ciascuna attività, dal sistema di qualità aziendale (SGQ) di AdeR (cfr. allegato “D”) e del Sistema Gestione Sicurezza Informazioni (SGSI) di AdeR (cfr. allegato “E”), nonché nel rispetto delle condizioni e dei livelli di servizio previsti dal presente capitolato tecnico o migliorati, ove previsto, dal Fornitore in sede di offerta, mediante l’impiego di risorse professionali in possesso dei requisiti minimi previsti dal successivo paragrafo 8.2 o di quelli migliorativi indicati

in sede di offerta e, comunque, nel rispetto di quanto previsto dal contratto, il cui schema fa parte integrante della documentazione di gara.

3.2 Onboarding Application Portfolio Management (APM)

Il Fornitore dovrà predisporre una piattaforma di Application Portfolio Management (APM) ed effettuare il caricamento e l’analisi iniziale per costituire la “baseline” del software preso in carico.

La piattaforma che sarà fornita dall’aggiudicatario deve permettere diverse tipologie di analisi sia dal punto di vista dimensionale, in termini di Linee di Codice (LOC) e di Punti Funzione (FP), sia dal punto di vista della qualità del software, attraverso un insieme di specifici indicatori.

A titolo di riferimento, AdeR ha utilizzato una piattaforma basata sulla soluzione

software CAST, fornita dall’aggiudicatario del contratto in corso di vigenza.

La seguente tabella rappresenta il dimensionamento del sistema SET in Linee di Codice (LOC) e Function Point (FP) come risultante dal sistema CAST di analisi del software alla data del 31 dicembre 2021:

	Snapshot al 31/12/2021
Area Funzionale	Linee di codice	Function Point
Anagrafica Ruoli e Cartellazione	3.560.584	9.151
Coattivo	1.005.688	4.061
Contabilità	3.694.530	5.756
Conto Fiscale	2.190.212	3.352
Esatto	3.568.518	6.860
Funzioni Di Servizio	3.134.018	8.016
Inesigibilità	2.152.423	3.001
Java Web services	84.790	2.402
JCL Set	5.423.280	0
Notifica	2.476.143	4.261
Procedure Cautelari ed Esecutive	3.388.876	9.217
Provvedimenti	3.064.098	8.320
Rendicontazione e Versamento	3.384.062	9.927
Riscossione	3.835.565	11.213
Servizi	3.013.687	6.546
Stato della Riscossione	2.376.994	5.879
Versamenti Diretti e Servizi di Cassa	2.559.577	4.766
Servizi REST	19.651	148
Servizio AVCP	8.154	16
Totale	48.940.850	102.892

Tabella 3: Dimensionamento di SET in LOC e FP al 31/12/2021

Nell’allegato “F” sono riportati maggiori dettagli sulla dimensione attuale del software SET e sugli indicatori richiesti per la piattaforma APM, per dare la possibilità al concorrente di valutare correttamente questa attività.

Il Fornitore dovrà mantenere la piattaforma aggiornata durante tutto lo svolgimento del contratto in base ai diversi rilasci software che saranno effettuati.

3.3 Servizio di AMS

Il servizio di AMS è dettagliatamente descritto nel capitolo 4 e si compone delle due attività di Manutenzione Correttiva (MAC) e Manutenzione Adeguativa (MAA) indicate di seguito:

Manutenzione Correttiva (MAC)

La Manutenzione Correttiva è volta alla diagnosi ed alla rimozione delle cause e degli effetti, sia sulle interfacce utente che sulle basi dati, dei malfunzionamenti delle procedure e dei programmi in esercizio ed in genere di tutti i componenti dell’applicazione. Si precisa che l’intervento di manutenzione correttiva potrà riguardare anche il disallineamento della documentazione utente.

Rientrano nella Manutenzione Correttiva le seguenti attività (la lista non è esaustiva):

− diagnosi del malfunzionamento;

− rimozione degli errori/difetti e dei relativi effetti che gli stessi hanno provocato;

− contributi di competenza specialistica di prodotto necessari alla corretta soluzione del malfunzionamento;

− test in ambiente di collaudo della soluzione realizzata;

− allineamento della documentazione;

− allineamento degli eventuali script automatici;

− supporto all’installazione in ambiente di esercizio;

− segnalazione delle correttive effettuate per allineamento del software in corso di sviluppo/modifica/collaudo;

− supporto all’attività diagnostica sulla causa del malfunzionamento le cui cause non sono imputabili a errori/difetti presenti nel software applicativo.

Manutenzione Adeguativa (MAA)

La Manutenzione Adeguativa comprende tutte le attività (analisi d’impatto, piccole implementazioni e/o modifiche del software, programmi di conversione, ecc.) volte ad assicurare la costante aderenza delle procedure e dei programmi all’evoluzione dell’ambiente tecnologico del sistema informativo ed al cambiamento dei requisiti (organizzativi e d’ambiente).

Normalmente viene innescata da una delle seguenti esigenze (la lista non è esaustiva):

− adeguamenti dovuti a cambiamenti di condizioni al contorno (ad esempio per variazioni al numero utenti, per migliorie di performance, per aumento delle dimensioni delle basi dati, ecc.);

− adeguamenti necessari a seguito dell’introduzione di nuove disposizioni

di legge;

− adeguamenti necessari a seguito di innalzamento di versioni del software di base;

− adeguamenti volti all’introduzione di nuovi prodotti o modalità di gestione delle applicazioni;

− migrazioni di piattaforma;

− modifiche, anche massive, non a carattere funzionale, alle applicazioni (ad esempio cambiamento di titoli sulle maschere, ecc.).

Come sarà meglio specificato nel seguito, rientrano nell’ambito della Manutenzione Adeguativa interventi evolutivi che richiedono un impegno in GG/P fino a 7 GG/P.

3.4 Servizio di NSS

Il servizio di NSS comprende le attività di realizzazione di software nell’ambito delle componenti applicative riportate in Tabella 1 Errore. L'origine riferimento non è stata trovata.come dettagliate negli allegati tecnici “F“ e “G”.

Rientrano nel servizio NSS le seguenti attività:

Manutenzione Evolutiva (MEV)

Attività realizzative volte ad arricchire le applicazioni esistenti modificando e/o integrando le funzionalità già disponibili.

Sviluppo Software (NS)

Attività realizzative che hanno come obiettivo lo sviluppo di nuove funzionalità su applicazioni esistenti o la realizzazione di nuove applicazioni.

3.5 Assistenza Specialistica (AS)

Comprende un insieme integrato di attività che garantisce supporto per tutte le necessità afferenti alle esigenze specifiche di AdeR, come ad esempio gli studi su specifici argomenti, analisi e ricerche, realizzazione quadri di sintesi.

Comprende inoltre le attività di ripristino del sistema SET Finale a fronte di errori di manovra di operatori o utenti.

Il Supporto Specialistico comprende principalmente le seguenti attività (elenco non esaustivo):

− formazione;

− redazione di documentazione tecnica;

− supporto a redazione di studi;

− redazione di presentazioni;

− supporto alla messa in esercizio di nuove applicazioni o a seguito di importanti interventi funzionali su applicazioni esistenti;

− ripristino del sistema SET Finale da stati incongruenti a seguito di errori operatore attraverso lo sviluppo di opportuni strumenti software (query, programmi, ecc.).

3.6 Supporto agli Utenti o Richiesta Informazioni (RI)

È un servizio di supporto agli utenti finali del sistema SET tramite il quale questi possano avere dal Fornitore notizie e chiarimenti sul corretto uso e funzionamento del sistema SET stesso.

Il sistema SET implementa tutte le normative vigenti in materia di riscossione e applicabili al contesto di AdeR. Eventuali casi o sottocasi della normativa possono essere particolarmente complessi e di conseguenza è necessario contattare direttamente il Fornitore su come le suddette situazioni sono gestite, ovvero codificate, in SET.

Va precisato che il supporto agli utenti richiesto è assimilabile a un servizio di help desk di 3° livello. In altri termini, le richieste di informazione sono intercettate da un primo livello garantito dalla struttura di Esercizio ICT di AdeR, esaminate da un

secondo livello di analisti funzionali ICT di AdeR e, quindi, solo quelle non risolte al primo o al secondo livello saranno gestite attraverso il servizio RI.

3.7 Durata dell’appalto e dimensionamento dei servizi

La durata dell’Appalto, pari a un massimo di 54 mesi, è così determinata:

• massimo n. 6 (sei) mesi (ovvero nei tempi migliorativi non inferiori a 3 (tre) mesi solari indicati dal concorrente in sede di offerta tecnica) per le attività relative al passaggio di consegne (come disciplinato al paragrafo 3.8 del Capitolato Tecnico);

• n. 48 (quarantotto) mesi per lo svolgimento dei restanti servizi oggetto

dell’appalto (Onboarding APM, AMS, NSS, AS e RI).

AdeR si riserva l’opzione di rinnovo di ulteriori 12 (dodici) mesi, per i soli servizi di AMS, NSS, AS e RI, ai medesimi prezzi patti e condizioni.

Il dimensionamento dei servizi è stato calcolato per un periodo di 48 (quarantotto) mesi, fatti salvi gli adempimenti ulteriori previsti dal presente capitolato tecnico e/o dal contratto per la garanzia di quanto realizzato nell’esecuzione dei servizi.

Tale periodo decorrerà dalla data del verbale di avvio dell’esecuzione del contratto che verrà redatto a seguito del completamento delle attività per il passaggio iniziale delle conoscenze, di cui al successivo paragrafo 3.8. Nelle seguenti tabelle sono riportati gli elementi, conosciuti o stimati, di dimensionamento di ciascun servizio. Le stime, relative all’intera durata dell’esecuzione dei servizi (48 mesi), sono da ritenersi indicative, formulate al meglio delle attuali conoscenze e assolutamente non vincolanti per AdeR.

Per quanto riguarda l’attività di Onboarding sul sistema di Application Portfolio Management si è preso in considerazione il dimensionamento del sistema SET che risulterà da prendere in carico all’avvio del contratto:

dimensione asset in LOC = 54.301.100 LOC dimensione asset in FP = 114.330 FP

Per la stima del dimensionamento si è tenuto conto dell’asset risultante al 31/12/2021, dell’incremento per le attività già svolte fino alla redazione di questo Capitolato e della stima per attività di sviluppo che si concluderanno entro il 31/12/2022.

Stimando che il prodotto APM sia in grado di elaborare circa 165.000 LOC al giorno,

si ottiene che per il caricamento di tutto il parco applicativo nella piattaforma APM

saranno necessari circa 329 giorni di elaborazione, che possono essere assimilati, in termini di fabbisogno, in altrettanti GG/P.

A questi sarà necessario aggiungere circa 20 GG/P per l’organizzazione dei risultati

sotto forma di documentazione.

Il fabbisogno per l’attività di Onboarding APM è quindi pari a circa 349 GG/P.

Come già ricordato in precedenza, sia la descrizione APM, sia la baseline dovranno poi essere aggiornate a carico del Fornitore ad ogni rilascio a seguito di affidi di nuovi sviluppi (NSS), che saranno ricompresi nelle attività del servizio NSS.

Il servizio AMS è dimensionato in base al numero totale di FP costituenti il sistema SET. Secondo le considerazioni precedenti, l’asset che si stima risulterà alla data di avvio del contratto comprende 114.330 FP.

Il servizio di AMS dovrà essere prestato per tutte le applicazioni a decorrere dalla data del verbale di avvio dell’esecuzione del contratto, di cui al successivo paragrafo 3.8.

Per calcolare il fabbisogno relativo alla Manutenzione Evolutiva (MEV) si è applicata la legge di Xxxxxx al valore dell’asset che si stima risulterà alla data di avvio del contratto, secondo le considerazioni precedenti. A tale valore è stata aggiunta una stima del fabbisogno per Nuovi Sviluppi pari a 30.000 FP per tutta la durata contrattuale. Si è così ottenuto il seguente fabbisogno in termini di FP:

FP manutenzione Evolutiva = (114.330 FP * 80%) + 30.000 = 121.464 FP

Il fabbisogno in termini di GG/P del servizio NSS si è ottenuto considerando una produttività media di 3 FP/giorno:

Fabbisogno in GG/P servizio NSS = 121.464 (FP) / 3 (FP/gg) = 40.488 GG/P

Le attività del servizio NSS vengono classificate, dal Fornitore in contraddittorio con AdeR, secondo quanto specificato al successivo paragrafo 9.2, nelle seguenti categorie: bassa, media e alta.

Il totale del fabbisogno in GG/P è quindi suddiviso nelle 3 categorie per le quali, sulla base dei consuntivi del servizio NSS dell’attuale contratto G9, è stimato, per il periodo di 48 mesi del contratto, un numero di GG/P riportato di seguito.

Fabbisogno in GG/P servizio NSS complessità bassa = 8.790 GG/P Fabbisogno in GG/P servizio NSS complessità media = 15.183 GG/P Fabbisogno in GG/P servizio NSS complessità alta = 16.515 GG/P

Per quanto riguarda il servizio di Assistenza Specialistica, riferito ad un team organizzato come nella tabella 10 riportata al paragrafo 8.1, il massimale dei GG/P richiesti è pari a 6.903 GG/P.

Per quanto riguarda il servizio di Supporto Utenti (RI), riferito ad un team organizzato come nella tabella 11 riportata la paragrafo 8.1, il massimale dei GG/P richiesti è pari a 624 GG/P.

La seguente tabella riassume le stime fin qui presentate del fabbisogno dei servizi oggetto del presente Capitolato per la durata di 48 mesi di contratto.

Servizio	Fabbisogno	Unità di misura
AMS (FP/mese)	114.330	FP
NSS bassa	8.790	GG/P
NSS media	15.183	GG/P
NSS alta	16.515	GG/P
AS	6.903	GG/P
RI	624	GG/P
Onboarding APM	349	GG/P

Tabella 4: Quadro riassuntivo del Fabbisogno

3.8 Passaggio di consegne

Al Fornitore sono richieste attività relativamente alle fasi di passaggio iniziale (ricezione) e finale (trasmissione) delle conoscenze, per le quali valgono le seguenti considerazioni generali:

• Attività di passaggio iniziale delle conoscenze

L’attività, propedeutica all’erogazione dei servizi oggetto dell’appalto, consiste nell’acquisizione delle specifiche conoscenze relative alle peculiarità delle attività e delle applicazioni di AdeR ed è totalmente a carico del Fornitore. Tale attività dovrà essere completata entro 6 (sei) mesi solari, a decorrere dalla data di stipula del contratto.

• Attività di passaggio finale delle conoscenze

Nei 6 (sei) mesi solari prima della scadenza del contratto il Fornitore dovrà garantire la massima disponibilità alle attività di passaggio ad altro/i fornitore/i delle conoscenze relative alle peculiarità delle attività e applicazioni, con particolare riferimento a quelle maturate nel periodo di erogazione dei servizi oggetto dell’appalto, senza alcun ulteriore onere per AdeR. Durante il periodo di passaggio finale delle conoscenze, il Fornitore sarà comunque tenuto all’erogazione dei servizi previsti (AMS, NSS, AS e RI) nel rispetto delle

obbligazioni contrattualmente assunte, in linea con il progetto espresso

nell’offerta tecnica.

Le attività di passaggio delle conoscenze consistono:

• nell’affiancamento per il trasferimento delle competenze relative alla manutenzione dei sistemi e alle applicazioni realizzate, che si esplicherà attraverso la descrizione al personale del fornitore entrante di:

− funzionalità applicative e contenuti specifici;

− contesto di utilizzo ed eventuali personalizzazioni software in uso;

− termini, modalità e tecniche per la consegna dei rilasci software SET/Ancillari, per la parte riguardante le attività di Change Management;

− standard e tecniche di realizzazione delle procedure di lancio (JCL) con specifiche regole di naming convention; al momento attuale sono predisposte per essere eseguite in modo automatico mediante l’utilizzo del prodotto IBM Tivoli Workload Scheduler (TWS); AdeR si riserva la possibilità di cambiare schedulatore automatico;

− stato delle richieste di manutenzione.

• nell’espletamento delle operazioni di consegna della documentazione, che si esplicherà nelle seguenti attività:

− consegna dei riferimenti relativi al patrimonio applicativo realizzato o adeguato;

− consegna della documentazione (sia quella relativa al progetto di implementazione sia quella generata/modificata durante il periodo di manutenzione);

− consegna di tutto il materiale relativo ai corsi di formazione e addestramento effettuati, alle note di riunione, a documenti specifici redatti durante la durata del contratto;

− la baseline e APM aggiornati e tutti gli strumenti a supporto indicati in offerta tecnica.

Le attività di trasferimento saranno svolte mediante opportune sessioni di lavoro organizzate da AdeR in modo da rispettare i termini relativi al passaggio di consegne.

Le attività di trasferimento saranno svolte presso le sedi AdeR e/o in riunioni “virtuali”

alla presenza di AdeR.

Al termine di ciascuna sessione di lavoro, il Fornitore segnalerà a AdeR i moduli di SET che a suo avviso sono carenti della documentazione tecnica necessaria per garantire la corretta esecuzione del servizio di AMS.

Nel caso in cui fossero identificati moduli di SET con documentazione carente, il Fornitore (che si ricorda deve eseguire anche l’attività di Analisi del software SET già dettagliata nel paragrafo 3.2) dovrà presentare il piano con il quale riuscirà a colmare il divario informativo, identificando il coinvolgimento del Fornitore uscente.

Accertata da parte di AdeR la completa acquisizione delle conoscenze da parte del Fornitore, AdeR stessa redigerà il verbale di avvio dell’esecuzione del contratto. Tale verbale, tra l’altro, riporterà i moduli che ad avviso di AdeR saranno oggetto di specifici interventi, ricompresi nelle attività di Analisi del sistema SET già citate, che saranno indirizzati anche con il supporto del Fornitore uscente, qualora richiesto.

In caso di mancato passaggio delle conoscenze, per fatto imputabile al Fornitore, entro 6 (sei) mesi solari dalla stipula del contratto, ovvero nei tempi migliorativi indicati dal fornitore in sede di offerta tecnica, AdeR avrà facoltà di procedere alla risoluzione del contratto stesso.

3.9 Cronoprogramma di massima per l’avvio dei servizi

A scopo esemplificativo si indica il cronoprogramma di massima che il Fornitore dovrà seguire per svolgere tutte le attività dall’avvio del contratto fino all’effettivo avvio dei servizi di AMS, NSS, AS e RI.

Sono elencate tutte le attività richieste e i tempi massimi per la loro esecuzione. Il Concorrente può aggiungere altre attività, se lo ritiene opportuno, da eseguirsi comunque nei tempi massimi sotto riportati ovvero in quelli migliorativi indicati in sede di offerta tecnica.

	Mese 1	Mese 2	…	Mese 6
Avvio dei contratto
Redazione piano di qualità	20 gg
Attività di passaggio iniziale delle conoscenze		180	gg
Analisi del software costituente SET		180	gg
Set up dell'ambiente di sviluppo del Fornitore		180	gg
Chiusura passaggio di consegne

Figura 1: GANTT di massima per l’avvio dei servizi oggetto dell’appalto

La data d’inizio è l’inizio del “mese 1” del contratto, le altre attività sono le seguenti:

• Entro 20 GG solari dall’avvio del contratto il Fornitore dovrà presentare il piano

della qualità generale;

• Contestualmente all’avvio del contratto, inizieranno anche le attività di passaggio iniziale delle conoscenze, l’analisi del sistema SET e il caricamento del codice nel sistema APM, come proposto dal Fornitore nella relazione tecnica. Le attività non potranno durare meno di 3 né più di 6 mesi solari;

• Dovrà anche essere preparato e popolato l’ambiente di sviluppo a cura del Fornitore;

• Alla conclusione delle attività di cui al punto precedente, sarà redatto il verbale di passaggio di consegne avvenuto e il Fornitore subentrerà nell’erogazione dei servizi oggetto di questo capitolato.

Si ricorda che AdeR verificherà, con opportuni colloqui, prove e test, l’avvenuto passaggio di conoscenze dal Fornitore uscente a quello subentrante. Solo nel caso in cui tutte le verifiche diano esito positivo sarà redatto il verbale di avvio della esecuzione del contratto di cui al paragrafo precedente.

4 Il contesto applicativo

4.1 Architettura di massima del sistema SET

I moduli funzionali che costituiscono SET sono i seguenti.

• Tabelle DB2

• Programmi

o Mappe BMS Transazioni

o Programmi batch DB2/Cobol

o Programmi TP DB2/Cobol

o Routine Assembler

o Programmi utilità

• Moduli

o Copy Assembler

o Copy per accesso ai dati

o Copy di sistema

• Servizi (componente/routine per svolgere tramite metodi delle specifiche operazioni)

• Insieme di microservizi a supporto di applicativi esterni che interagiscono con SET

• Procedure

o Procedure di lancio (JCL)

Il software SET interagisce con circa 770 tabelle DB2 per ogni DB (DB a livello di regione più un DB specifico per le grandi realtà come Roma, Milano, Napoli e Torino).

Per quanto riguarda il sistema ancillare Co@ttivo il software interagisce con circa 190 tabelle DB2.

Riguardo le procedure JCL, si precisa che sono standardizzate con specifiche regole di “naming convention” e sono predisposte per essere eseguite in automatico mediante l’utilizzo del prodotto IBM Tivoli Workload Scheduler (TWS).

Il sistema SET è stato sviluppato rispettando rigide regole nella programmazione relativamente a:

• Nome file

• Nomi variabili

• Nomi moduli (copy, sottoprogrammi, ecc.)

I servizi opportunamente compilati sono lo strumento con cui viene interrogata la Base Dati (DB2) dagli applicativi sviluppati in dipartimentale su Web Service, vedi

Cassetto Fiscale utilizzato dall’Agenzia delle Entrate sul proprio portale Internet, come anche il Web Service alla base dell’applicativo Estratto Conto.

I programmi online (o TP) sono quei programmi che in esecuzione permettono una continua interazione tra programma stesso e utente. Tutte le funzioni/transazioni di una procedura sono organizzate in sessioni di lavoro in modo da avere più transazioni in esecuzione contemporanea su sessioni diverse.

Il Fornitore è libero di proporre (descrivendone le caratteristiche in fase di offerta tecnica nell’ambito dell’elemento di valutazione V3.1) un proprio sistema per la gestione e lo sviluppo del software che non dovrà determinare maggior onere per AdeR, che dovrà avere in uso gratuito lo stesso software, sia durante che dopo la chiusura del contratto.

4.2 Ambienti e procedura di promozione del software

AdeR si è dotata di vari ambienti software che sono xxx xxx xxxxxxxxx xxxxx xxxx del ciclo di vita del software. Quanto segue si applica sia per le applicazioni “mainframe” sia per quelle “dipartimentali”. Tutti gli ambienti mainframe sono ospitati presso SOGEI, tutti quelli dipartimentali sono attualmente situati presso le sedi di AdeR, ma è in xxxxx xx xxxx xxxxxxxxxx xxxxxx XXXXX.

Xx tutti gli ambienti non di produzione sono disponibili in base dati i dati di 8 ambiti (province), sui quali effettuare le prove e i collaudi.

I database negli ambienti non di produzione saranno aggiornati periodicamente, previo accordo tra AdeR e Fornitore.

4.2.1 Ambiente di sviluppo

L’ambiente di sviluppo è utilizzato solo per gli sviluppi svolti presso AdeR. È composto da vari moduli software che sono elencati nel successivo paragrafo 4.3. Questo ambiente è a uso esclusivo del personale di AdeR.

In generale il Fornitore non avrà accesso a questo ambiente, salvo diverso accordo scritto.

Tutte le attività di sviluppo, compilazione, test unitario, ecc., necessarie ai fini dell’espletamento delle attività descritte in questo capitolato, dovranno essere eseguite dal fornitore su un proprio ambiente di sviluppo presso la propria sede.

4.2.2 Ambiente di test – S1

L’ambiente di test (denominato S1) è quello sul quale il Fornitore dovrà effettuare il primo rilascio e sul quale il Fornitore stesso effettuerà le verifiche di corrispondenza tra il software oggetto di rilascio e quanto richiesto. In altri termini è l’ambiente “AdeR” sul quale il Fornitore dovrà:

1. Compilare il software oggetto di rilascio secondo le caratteristiche degli ambienti AdeR;

2. Costruire o adeguare i JCL necessari all’utilizzo dei moduli (quando

applicabile);

3. Eseguire i propri unit test e integration test;

4. Eseguire gli acceptance test;

5. Dare evidenza a AdeR di tutti i test eseguiti.

Per alcuni rilasci, allo scopo di accelerare il processo di test e collaudo, la fase di acceptance test potrà essere eseguita in contradittorio con una struttura tecnica di AdeR. Queste situazioni saranno ben identificate e la procedura di acceptance test in ambiente S1 sarà concordata preventivamente tra AdeR e Fornitore.

Le verifiche di funzionalità potranno richiedere l’utilizzo di dati nei vari DB. Come già detto in precedenza, i DB di S1 conterranno dati di 8 province. Eventuali ulteriori dati da mettere nei DB dovranno essere preventivamente identificati dal Fornitore e comunicati a AdeR in modo che AdeR li possa caricare nei DB.

In questo ambiente i dati anagrafici sono pseudonimizzati nella fase di aggiornamento della base dati, attraverso un apposito tool di AdeR.

4.2.3 Ambiente di certificazione – S2

I software collaudati dal Fornitore su S1, saranno trasferiti su S2 solo dopo che le strutture tecniche di AdeR abbiano verificato la corretta esecuzione dei test di accettazione (punto 4 del paragrafo precedente).

Su S2, salvo diverso accordo scritto, il rilascio deve essere comprensivo di tutti i sorgenti e di tutte le istruzioni necessarie per compilare e installare in questo ambiente il software oggetto di rilascio.

L’installazione del software in ambiente S2 è effettuata da tecnici di AdeR, ma potrà essere richiesto il supporto tecnico del Fornitore.

Nell’ambiente S2 la struttura tecnica preposta di AdeR esegue a sua volta i test di accettazione e certifica la corretta corrispondenza tra i requisiti utente e la condotta del software oggetto di rilascio.

Anche in questo caso potrà essere richiesto da AdeR il supporto tecnico del

Fornitore per l’esecuzione in contraddittorio dei test di accettazione.

Su questo ambiente è in genere eseguita la prima prova di vulnerabilità del software (quando applicabile e comunque su tutte le applicazioni con interfaccia su Internet).

Gli elementi software che hanno superato le verifiche della struttura tecnica di AdeR saranno predisposti per essere trasferiti sull’ambiente di collaudo.

4.2.4 Ambiente di collaudo – SF

Una volta completati con esito positivo i test, il software realizzato è installato da personale AdeR nell’ambiente di collaudo. In particolare, tutto il software installato in SF diventa il rilascio candidato (Candidate Release) all’esercizio con le seguenti caratteristiche:

o insieme di tutti gli oggetti software (mainframe e distribuiti collegati a MEV/NSS/MAA) che AdeR intende certificare nei propri ambienti prima del passaggio in produzione;

o natura di un oggetto autoconsistente nel quale tutti i vincoli di “innesto logico” all’interno della configurazione software dell’ambiente di collaudo (S2/SF) e di produzione (S4) si intendono sempre risolti al momento del suo collazionamento. Per la realizzazione di tale attività si ritiene fondamentale il contributo del fornitore;

o nel caso in cui la “candidate release” installata negli ambienti SF manifestasse malfunzioni e/o errori e/o difformità dalle RDA/RDM/RDS non imputabili a AdeR, il fornitore provvederà a fornire le istruzioni per la rimozione degli stessi e/o a riprodurre nuovamente la “candidate release”.

Il contenuto della Candidate Release sarà concordato tra AdeR e il Fornitore nel momento in cui il software MEV/NSS/MAA avrà superato i test nell’ambiente S1 e potrà essere parziale rispetto a quanto presente sull’ambiente S2 e con un ordine di installazione diverso rispetto al rilasciato. Va da sé quindi che sarà cura del Fornitore provvedere a adeguare il software in passaggio rispetto alla release del rilascio candidato.

L’ambiente di collaudo è strutturato come quello di esercizio, ma il dimensionamento degli apparati è più ridotto. In questo ambiente gli utenti finali di

AdeR eseguiranno nuovamente i test di accettazione in contraddittorio con la struttura tecnica di AdeR preposta. Ciò nondimeno, anche il Fornitore potrà essere coinvolto a supporto del contraddittorio, nel collaudo di rilasci di particolare complessità o rilevanza.

Sull’ambiente di collaudo sarà eseguita la prova di vulnerabilità del software (quando applicabile e comunque su tutte le applicazioni con interfaccia su Internet).

Una volta conclusi i collaudi (di norma una volta al mese), tutti i programmi software che hanno superato il collaudo sono promossi in produzione S4, tutti quelli che non hanno superato il collaudo sono regrediti in S2 o S1. L’ambiente SF è completamente svuotato e predisposto all’installazione della successiva Candidate Release.

Anche sull’ambiente di collaudo, salvo diverso accordo scritto, il rilascio deve essere comprensivo di tutti i sorgenti e di tutte le istruzioni necessarie per compilare e installare in questo ambiente il software oggetto di rilascio.

4.2.5 Ambiente di pre-esercizio – S3

L’ambiente di pre-esercizio S3 è strutturato come quello di esercizio, ma il dimensionamento degli apparati è più ridotto. In questo ambiente sono rilasciate dal Fornitore le MAC e MAA e la struttura tecnica di AdeR verifica che le anomalie o le adeguative siano state definitivamente risolte. Il Fornitore potrà essere coinvolto a supporto del contraddittorio, nel collaudo di rilasci di particolare complessità o rilevanza.

Anche su S3 sarà eseguita la prova di vulnerabilità del software (quando applicabile e comunque su tutte le applicazioni con interfaccia su Internet).

Una volta conclusi i collaudi delle MAC e delle MAA queste sono spostate in esercizio.

Resta inteso che su S3, salvo diverso accordo scritto, il rilascio deve essere comprensivo di tutti i sorgenti e di tutte le istruzioni necessarie per compilare e installare in questo ambiente il software oggetto di rilascio.

4.2.6 Ambiente di esercizio – S4

I software che hanno superato il collaudo sono messi in esercizio a cura di AdeR con

l’eventuale supporto del fornitore (su richiesta di AdeR).

Sull’ambiente di esercizio è ripetuta la prova di vulnerabilità del software (quando

applicabile e comunque su tutte le applicazioni con interfaccia su Internet).

Salvo diverso accordo scritto, il rilascio in ambiente di esercizio deve essere comprensivo di tutti i sorgenti e di tutte le istruzioni necessarie per compilare e installare in questo ambiente il software oggetto di rilascio.

4.2.7 Gestione della configurazione del software e rilasci

Il sistema utilizzato da AdeR per il controllo della configurazione del software è Endevor per quanto riguarda le applicazioni “mainframe” e DevOps-Azure per le applicazioni “dipartimentali”.

La seguente figura presenta in modo indicativo il modus operandi adottato in proposito.

Figura 2: Gestione del controllo di configurazione del codice

I sorgenti COBOL sono installati a cura del Fornitore sull’ambiente S1 e sottoposti a quanto indicato nel paragrafo 4.2.2. Una volta superati tutti i controlli previsti, il software è posto sotto controllo di configurazione in Endevor e spostato in S2.

Una volta superato quanto previsto nel paragrafo 4.2.3, il software è spostato in SF e aggiornato lo stato su Endevor.

Infine, superato quanto previsto nel paragrafo 4.2.4, il sistema Endevor è aggiornato e il software spostato in produzione.

Nel caso di MAC, il software è rilasciato in S3 e, una volta superato quanto previsto nel paragrafo 4.2.5, si procede ad aggiornare Endevor e a spostare il software in esercizio su S4.

Per quanto riguarda i rilasci da S2 in poi, si procede per insiemi di funzioni (gruppi di MEV o NS) concordate, in modo da costruire un unico “protocollo” oggetto di rilascio costituito da tutti i suoi moduli componenti. I rilasci hanno generalmente una cadenza di uno al mese / ogni tre settimane.

Può tuttavia accadere, in determinati rilasci, che non tutte le MEV o NS oggetto del rilascio in corso superino il collaudo utente, ma che sia necessario procedere comunque con la messa in produzione di quelle MEV o NS che hanno superato il collaudo. In questo caso sarà necessario il supporto del Fornitore per identificare le dipendenze tra i moduli e quindi identificare quali oggetti combinare insieme per effettuare un rilascio autoconsistenze in esercizio.

Il rilascio software avrà le seguenti caratteristiche:

• comprenderà i codici sorgenti e gli eseguibili/DLL degli oggetti rilasciati, unitamente a un’informazione che indicherà il tipo di oggetto:

o COPY COPY COBOL E DCLGEN

o ASMBMS MAPPE CICS ASSEMBLER

o DDL DEFINIZIONI DDL DB2

o PARAM PARAMETRI JCL

o JCL SCHEDE JCL

o CBLNBL PGM COBOL BATCH NON DB2

o CBLDBL PGM COBOL BATCH DB2

o CBLNCL PGM COBOL CICS NON DB2

o CBLDCL PGM COBOL CICS DB2

o ASMNBL PGM ASSEMBLER BATCH NON DB2

• tutti i sorgenti cobol/zOS/CICS/DB2 costituenti la “candidate release” saranno

contenuti in file sequenziali compressi;

• il file compresso conterrà anche un file .txt contenente le istruzioni operative per l’installazione dei singoli moduli e l’indicazione complessiva degli eventuali vincoli/esigenze/interconnessioni tra moduli di diversa natura (es. SET on-line e Xxx@xxx o xxxx@xxx o xxxx@xxx);

• in ogni caso i documenti di rilascio, a qualunque titolo, saranno unici;

• i documenti di rilascio avranno una nomenclatura che deve consentire l’immediata identificazione della tipologia del rilascio stesso (MEV/NSS/MAA/MAC) e dell’ambiente dove deve avvenire.

Per quanto riguarda le procedure di lancio JCL, il Fornitore dovrà gestire i moduli presenti nelle librerie di produzione di AdeR, recependone gli standard di scrittura (naming convention dei singoli oggetti referenziati nel JCL stesso) e le modalità di schedulazione automatica mediante IBM TWS.

Per le applicazioni “dipartimentali” il percorso di collaudo è analogo a quanto già presentato per i moduli mainframe, dove il sistema di gestione della configurazione del software è DevOps (invece di Endevor).

Il rilascio comprende almeno quanto segue:

• i codici sorgente;

• eventuali makefile o equivalenti;

• script per il database (Oracle o MS SQL Server);

• documentazione per l’installazione e la gestione operatore;

• quanto altro sarà ritenuto necessario per quel particolare modulo software.

4.3 Sistemi e tecnologie di rilievo per le attività oggetto di gara

4.3.1 Ambiente mainframe

I processi core di AdeR sono eseguiti su ambiente zOS installato fisicamente in SOGEI e gestito da AdeR in sinergia con SOGEI.

La seguente tabella riporta per ciascun ambiente mainframe i prodotti installati e le relative versioni.

Ambiente	Prodotto	Versione	Compatibilità	note
Monitor BMC	MAINVIEW	V12.2.00	x DB2
	MAINVIEW	V7.2.00	x CICS
	MAINVIEW	V6.3.00	x ZOS	3 componenti Zos Unix Sysprog
	MAINVIEW AUTOPER.	V8.3.00	X ZOS
	MAINVIEW	V5.6.00	x MQ
	BMC CATALOG MANAGER for Db2	V12.01.00
COMPUWARE	FILE – AID	V17.2	MVS

Ambiente	Prodotto	Versione	Compatibilità	note
	FILE – AID	V17.2	DB2
	FILE – AID	V17.2	RDX
	FILE – AID	V17.2	DA
	XPED/XCHANGE	V17.2
	XPED/CICS	V17.2
	XPED/CODE COVER	V17.2
	XPED/TSO	V17.2
COMPUTER ASSOCIATES	CA	CA	COMMON	SERVICES 14.1
	CA VIEW	V14.0		Next 12.1
	ENDEVOR	V18.0
PRIMEUR	SPAZIO	V2.R3.M1
MACRO4	VTAMPRINT	Columbus Z 5.305
IBM	ZOS	V 02.03.00
	JES2	V 2.3
	RACF	V 7.79.1
	TSO	V 4.3.0
	TIVOLI WORKLOAD SCHEDULER (TWS)	V 9.5.0
	DFSMS	V 2.03.0
	DSF	V 1.17.0
	VTAM	V 6.2
	ISPF	V 7.3.0
	DB2	V12R1M500
	MQ	V9.1.0
	QMF	V12 R1
	JES328X	3.R2.M0
	CICS	V5.3.0 (produzione) V5.6.0 (test)
	APPTUNE	11.2
	PSF	4.03.00
	TIVOLI NETVIEW	5.1.0
	HSM	V 1.5.9

Ambiente	Prodotto	Versione	Compatibilità	note
	ENTER. COBOL Z/OS	COBOL for z/OS 6.2.0
	XXXX	X0.X0X0
	DFRMM	V 1.12
	SDF2	1.R4.M0
Chicago-Soft	QuickReference	8.6
SEA INC	$AVRS	7.02051
SEA INC	DMS

Tabella 5 - prodotti ambiente mainframe

4.3.2 Ambiente Web

L’ambiente web di AdeR è basato su hardware e software “open” ed è attualmente installato fisicamente in AdeR, ma è in corso la sua migrazione presso il Data Center di Sogei.

La tabella seguente fornisce un quadro di massima di quanto è impiegato.

Oggetto	Prodotto e versione
Sistema operativo	Linux Centos 5/6/7/8
	Linux RedHat 5/6/7/8
	SUSE Linux Enterprise Server 11 SP1
	Oracle Linux 6/7
	Microsoft Windows Server 2012 / 2016 / 2019
	Vmware VSphere 6.7
Web Server	Apache HTTPD Server 2.x
	IBM HTTP Server 6.1.0.x
	Microsoft IIS Server 6
	Microsoft IIS Server 7
Application Server	IBM WebSphere Application Server Network Deployment 8.5.5.x
Application Server	RedHat JBoss EAP 6

Oggetto	Prodotto e versione
	WildFly Application Server 16.x (Open-jdk 1.13)
Database	Microsoft SQL Server 2014 / 2016 / 2017 / 2019
	Oracle MySQL Server 5.7 / 8.0
	Oracle 19c su Oracle Linux
	Oracle RAC 11g su Oracle Linux
	MongoDB Enterprise 3
	Ceph
Sistemi d’interfacciamento	IBM DB2 Connect
Sistemi d’interfacciamento	CICS Transaction Gateway
Sistemi di integrazione	WSO2 Enterprise Integrator 6
Sistemi di integrazione	WSO2 Api Manager 2
Sistemi di monitoraggio	OpenDistro
Sistemi di monitoraggio	Microsoft SCOM
Sicurezza	IBM Tivoli Directory Server 6.4
	IBM Security Access Manager 9.0.7
	WSO2 Identity Server 5
Managed File Transfer	Primeur Spazio MFTS 2.5.0
Sistemi di backup	DELL Avamar
Sistemi di backup	IBM Tivoli Storage Manager
Sistemi di archiviazione documentale	TImeArchive
	OpenText Documentum
	OpenText xPression 4.6
	Columbus Macro 4
Content Management	Microsoft Project Server e Sharepoint

Oggetto	Prodotto e versione
Tecnologie usate su Cloud Azure	Containers: kubernetes v. 1.19 o succ. - Azure Kubernetes Service (AKS)
	Code: RabbitMQ ver. 3.xx
	Networking: Azure vNet e Azure Network Policy (NPM)
	ApiManager: Azure
	Access and Identity Management: Azure AD
	Container Manager: Azure (ACM)
	Key Manager: Azure Key Vault (AKV)
	Log management: Azure AppInsight

Tabella 6 - prodotti ambiente web

4.4 Evoluzione del sistema SET

4.4.1 Architettura di massima di SET

Negli allegati tecnici “F” e “G” (a cui si rimanda per i dettagli) è descritta l’architettura funzionale e logica del sistema SET. La figura seguente riprende in modo sintetico l’architettura funzionale del sistema.

Figura 3: Architettura funzionale di massima del sistema SET

Il sottosistema “Ancillari Co@ttivo” estrae i dati dal database di SET, li trasferisce e li trasforma per poi scriverli su un database MS SQL e da qui sono accedibili tramite altri applicativi di tipo dipartimentale.

Per maggior precisione il sottosistema “Ancillari Co@ttivo” accede alla base dati DB2 su mainframe tramite un componente applicativo “XAS”, che utilizza la tecnica di comunicazione via CICS Transaction Gateway (CTG).

Per completezza, in figura 3 è riportato anche il sottosistema “Antiriciclaggio” la cui manutenzione non è oggetto di gara.

Il sottosistema “Interfacce Web” (la cui manutenzione è oggetto di questo capitolato) accede a dati del DB2 esponendoli poi ad altri applicativi dipartimentali come “Estratto Conto” e “Lampo AdR” (la cui manutenzione non è oggetto di questo capitolato).

Gli altri sottosistemi sono in Cobol, accedono al DB2 e comprendono sia funzioni TP che batch.

La figura successiva mostra l’architettura logica di massima del sistema SET.

Figura 4: architettura logica di massima del sistema SET

L’aspetto d’interesse è l’organizzazione attuale del sistema SET. Tutti i sottosistemi della precedente figura 3 sono collocati nella scatola blu di Figura 3. Si utilizzano servizi comuni (nella scatola arancione in basso) in particolare per accedere al DB.

Tutta la logica di processo e di calcolo è all’interno delle funzioni Cobol. Una qualunque modifica al processo dovuta ad esempio ad un cambio normativo o di organizzazione di AdeR, determina interventi di MAA, MEV o NS sul sottosistema SET interessato.

In altre situazioni, determinate funzioni sono realizzate tramite l’esecuzione di programmi batch in cascata. A questo scopo sono stati prodotti da AdeR, nel corso del tempo, dei JCL che eseguono un batch, dopo che questo si è concluso correttamente si riordinano i dati estratti dal primo, quindi si attiva un secondo batch e così via fino a completare tutte le operazioni necessarie. In questi casi la logica e il processo si trova distribuita tra i programmi invocati e nell’organizzazione del JCL.

A titolo di esempio, conseguente ad una riscossione di un dato tributo, questo va spacchettato nelle varie componenti fino ad arrivare al riversamento all’Ente impositore da una parte e al recupero spese di AdeR dall’altra, I moduli di “Riscossione” e “Versamento” indicati in Figura 3 contengono tutta la logica necessaria allo scopo e colloquiano con il database attraverso i servizi di accesso DB/DC.

Qualora intervenisse un cambio normativo che cambi le regole per quanto riguarda il riversamento del tributo a fronte di azioni di Ader, sarebbe necessario un

intervento di manutenzione del software del sottosistema “Versamento” e/o

“Riscossione”.

4.4.2 Evoluzione SOA del sistema SET

AdeR ha avviato l’implementazione dell’architettura di SET, mostrata nelle due figure precedenti, puntando alla realizzazione di un sistema più aperto e cooperante con programmi di tipo dipartimentale, allo scopo di creare nuovi servizi che possano interagire non soltanto con operatori di AdeR, ma anche Enti e Contribuenti.

A questo scopo, già da qualche tempo AdeR sta costruendo, a partire dai programmi di SET, servizi SOA da esporre su un ESB per poi integrarli verso i sistemi dipartimentali in modo da realizzare i servizi richiesti tramite l’istanziazione di processi su soluzioni di tipo BPM. I nuovi servizi così realizzati sono fruibili da più canali (Intranet, Internet, sportello, CRM, ecc.) senza dover cambiare il software.

Un esempio di adozione dell’approccio SOA per la costruzione di nuovi servizi d’informazione è mostrato nella figura (a puro titolo d’esempio).

Figura 5: Esempio di architettura SOA per il servizio di Informazioni.

I servizi applicativi esistenti sono stati interfacciati opportunamente tramite un approccio basato su WS / Microservizi. Tutti i servizi sono stati esposti su un sistema EAI (basato sul software Enterprise Service Bus Open Source WSO2) e quindi raccordati tramite il BPS di WSO2 per costruire il servizio “Fascicolo del Contribuente”, come anche gli altri mostrati in figura. Alcuni dei servizi sono in corso di migrazione verso il cloud basato su Kubernetes.

È nelle intenzioni di AdeR continuare ad aprire il sistema SET in modo analogo a quanto mostrato in Figura , incrociando i servizi di SET con quelli di altri applicativi di AdeR, in modo da realizzare servizi sempre più integrati e cooperanti.

Allo stesso modo AdeR intende, nel corso del contratto oggetto di questo capitolato, riorganizzare l’architettura di SET in modalità SOA laddove possibile. In altri termini nuove funzionalità SET o più in generale nuovi sviluppi su SET potranno essere condotti con un approccio SOA piuttosto che “Cobol tradizionale”, con l’obiettivo di portare sul BPM tutta la logica di processo dei nuovi sviluppi.

4.4.3 Passi propedeutici per l’evoluzione di SET in modalità SOA

Per raggiungere questo scopo, il Fornitore dovrà avere (la lista non è completa):

• una mappa dettagliata delle applicazioni e programmi che costituiscono

SET, comprensiva di tutti le “copy” e quanto altro necessario allo scopo;

• xxxxxx e dettagliata conoscenza dei database sottostanti SET;

• dettagliata conoscenza dei JCL utilizzati da AdeR;

• conoscenza di come i vari moduli e programmi software accedono al database (lettura, scrittura, ecc.) e su quali dati.

Le attività di analisi dell’APM associato a SET attraverso un sistema di “application mining” hanno come obiettivo anche quello di riconoscere tutte le funzioni presenti in SET, la loro organizzazione in servizi e moduli e quindi la possibilità di portare le logiche di processo fuori da SET (e fuori dai JCL) per poi rimontarli con architettura SOA, utilizzando BPM e BPS su WSO2.

Ne consegue che il Fornitore dovrà avere ottima conoscenza dell’architettura SOA, preferibilmente realizzata su WSO2, nonché proporre il metodo corretto per la descrizione del sistema SET, come richiesto in apertura del paragrafo 3.2 (Analisi del software costituente SET).

5 Ciclo di vita del Software e gestione dei progetti

Per lo sviluppo del software, AdeR utilizza i consueti concetti di “Ingegneria del Software” dividendo l’attività in fasi: identificazione di una necessità, raccolta di requisiti, progettazione tecnica, realizzazione, test, collaudo, roll out (assistenza all’avvio in esercizio), nonché manutenzione correttiva dell’applicativo in esercizio. I singoli interventi relativi ai servizi di NSS sono organizzati in progetti al fine di garantire la corretta pianificazione ed il relativo monitoraggio.

Tale approccio, personalizzato sulle specifiche esigenze di AdeR, è descritto nei documenti riportati nell’Allegato “A” – “Metodologia gestione progetti-servizi”, al quale si rimanda per i dettagli.

Di seguito si descriveranno i vincoli ed i principali strumenti utilizzati nelle diverse fasi del progetto.

• Fase di “Requisiti”

L’obiettivo della fase è la raccolta e la definizione dei requisiti del progetto; tale attività verrà svolta principalmente tramite interviste agli attori coinvolti e producendo i documenti richiesti, redatti secondo i template riportati nell’allegato “B”.

Tali attività richiedono l’utilizzo dei consueti strumenti di Microsoft Office (Word/Excel/Powerpoint).

Il documento dovrà essere versionato, come anche i requisiti contenuti dovranno essere versionati in modo da poter sempre riconoscere le Change Request intervenute nel corso del progetto.

• Fase di “Analisi”

Per la “pianificazione” si utilizza Microsoft Project, il piano di progetto dovrà essere mantenuto aggiornato su base settimanale e gestendo delle baseline mensili.

I documenti di “analisi” (cfr. procedure allegate) sono sviluppati utilizzando i consueti strumenti di Microsoft Office (Word/Excel/Powerpoint) e diagrammi UML per quanto riguarda gli “activity diagram”, “class diagram”, ecc., utilizzando i template riportati nell’allegato “B”.

Il “piano di collaudo” e i restanti deliverables della fase sono sviluppati con i consueti strumenti di Microsoft Office (Word/Excel/Powerpoint) secondo i template riportati nell’allegato “B”.

• Fase di “Sviluppo e Test”

Lo sviluppo del software viene “misurato” utilizzando la tecnica dei “Function point” attraverso il sistema di Application Portfolio Management.

Allo scopo di misurare l’avanzamento dello sviluppo del software, dovrà essere effettuato un rilascio settimanale (entro le 18.00 del venerdì) indipendentemente dallo stato in cui si trova. A seconda dei progetti/servizi si potranno utilizzare dei sistemi di Configuration management del codice (ad esempio Endevor; SVN, ecc.).

Il numero di FP ottenuto ogni settimana verrà utilizzato per monitorare l’avanzamento e, nella fase di test per misurare la difettosità del rilascio e l’effettiva possibilità di rilasciare al collaudo il software.

La gestione dei “difetti” (Bug tracking) viene svolta prevalentemente tramite l’applicazione Bugzilla.

I documenti di reportistica e gestione dei rischi sono prodotti utilizzando i consueti strumenti di Microsoft Office (Word/Excel/Powerpoint).

Particolare importanza nella fase di sviluppo deve essere data al rispetto dei criteri di esercibilità dell’applicazione sviluppata.

• Fase di “Collaudo”

La pianificazione della fase di Collaudo viene effettuata utilizzando

Microsoft Project ed integrando tale attività nel “piano di progetto”.

A seconda dei casi e dei relativi requisiti, il collaudo potrà includere test di performance, utilizzando strumenti quali Microfocus Silk performer, e test di Vulnerabilità applicativa (quando applicabile e comunque su tutte le applicazioni con interfaccia su Internet).

Per la reportistica sugli avanzamenti si dovrà provvedere alla loro redazione tramite i consueti strumenti di Microsoft Office (Word/Excel/Powerpoint).

La gestione dei difetti (Bug tracking) viene svolta prevalentemente

tramite l’applicazione Bugzilla.

• Fasi successive (roll out, ecc.)

La pianificazione delle fasi successive viene sempre effettuata utilizzando Microsoft Project ed integrando tali attività nel “piano di progetto”.

I documenti sono redatti tramite i consueti strumenti di Microsoft Office (Word/Excel/Powerpoint).

Le procedure ed i template sono riportati rispettivamente negli allegati “A” e “B”.

Resta inteso che tutti i suddetti prodotti software, con l’unica eccezione della suite utilizzata per le fasi di collaudo (ad es. Microfocus Silk performer), e del sistema di Bug tracking (ad es. Bugzilla) dovranno essere già in possesso del Fornitore.

5.1 Sistema di gestione per la protezione dei dati personali

In ottemperanza alle disposizioni contenute nel Regolamento Europeo 679/2016 General Data Protection Regulation – GDPR, AdeR ha definito il proprio Sistema di Gestione per la Protezione dei Dati personali (SGPD).

Il Sistema di Gestione per la Protezione dei Dati Personali è un insieme di regole, ruoli, processi, procedure specifiche e controlli in materia protezione dei dati personali delle persone fisiche, attraverso il quale AdeR, in qualità di Titolare del trattamento dei dati, pianifica, realizza, monitora e migliora le modalità, le garanzie e i limiti ai trattamenti dei dati personali che effettua per il conseguimento delle finalità istituzionali della riscossione nazionale, che le sono affidate dalla normativa di settore.

Gli elementi alla base del SGDP sono:

• la metodologia di gestione dei rischi e valutazione d’impatto sulla protezione dati delle attività di trattamento espresse dall’Ente nel Registro dei trattamenti. La metodologia è specificatamente progettata per la gestione dei rischi connessi ai trattamenti di AdeR;

• Le analisi di rischio per i trattamenti anche in ragione di quanto emerso nelle fasi di realizzazione del registro dei trattamenti (analisi e presidio degli strumenti utilizzati come ad esempio applicazioni informatiche/data base locali).

La metodologia di valutazione del rischio contempla tutte le componenti del trattamento (categorie dati: comuni, sensibili, giudiziari, sensibili, ipersensibili ecc.) e consente di esprimere una valutazione complessiva del rischio residuo (per l’organizzazione e gli interessati) da sottoporre alla valutazione del titolare (struttura owner del trattamento).

Il fornitore è chiamato, nelle fasi di analisi, progettazione ed implementazione, a seguire specifiche regole di sicurezza definite da AdeR, riportate in allegato al presente capitolato nella “Tabella di misure minime di sicurezza da utilizzare nello

sviluppo del software” riportata nel documento

“AdeR_Tabella_misure_software_V03” dell’allegato A.

Inoltre, il fornitore dovrà contribuire all’analisi del rischio del servizio ICT identificando quali sono le misure che devono essere applicate nei vari interventi di manutenzione che gli vengono affidati, al fine di minimizzare il rischio stesso.

Si ricorda inoltre che il fornitore, che sarà nominato come responsabile esterno per il trattamento dei dati gestiti dagli applicativi oggetto della presente gara, è chiamato a seguire e rispondere alle regole “Technical and organisational measures” (TOM) riportate in allegato all’Atto di nomina del Responsabile esterno, facente parte della documentazione di gara.

6 Gestione dei picchi di lavoro

Fermo restando quanto previsto dal successivo capitolo 9 “Governo dei servizi oggetto dell’appalto”, in ordine alle modalità di richiesta di ciascun servizio e durata dello stesso, nel corso di durata contrattuale potranno verificarsi situazioni speciali, legate al contesto operativo di AdeR, che determinano eccezionali carichi di lavoro.

In caso di eventi eccezionali e non pianificabili, il Fornitore, nel rispetto di quanto previsto dal successivo paragrafo 9.8.3, dovrà essere in grado di integrare il pool di risorse, nei termini indicati nell’indicatore di qualità IQ1.05, di cui all’allegato “C” “Indicatori di qualità e penali”.

Resta inteso che per nessun motivo il Fornitore potrà derogare dagli SLA contrattuali anche in presenza di picchi di lavoro.

7 Logistica

Il Fornitore svolgerà le attività oggetto del presente capitolato tecnico presso la propria sede.

La presenza presso la sede di AdeR di Roma, Via Xxxxxxxx Xxxxxx 14 o presso altra sede di AdeR nel territorio di Roma Capitale e nel territorio italiano, sarà contenuta solo a casi di assoluta necessità nel rispetto strettissimo di quanto di seguito indicato.

Si precisa che le risorse che saranno impiegate dal Fornitore non avranno alcun vincolo o rapporto di subordinazione con AdeR ma saranno gestite direttamente dal Fornitore tramite il proprio responsabile di contratto, il quale provvederà ad impartire a dette risorse le istruzioni necessarie per attuare gli interventi richiesti da AdeR.

Per le attività presso la propria sede il Fornitore dovrà dotarsi di una linea di comunicazione dati connessa alla rete aziendale di AdeR (i relativi dettagli tecnici verranno comunicati al Fornitore), di capacità adeguata al traffico previsto alle attività stesse.

AdeR, prima dell’accesso nelle proprie sedi di lavoro, fornirà al personale del Fornitore dettagliate informazioni sui rischi specifici esistenti e sulle misure di prevenzione e di emergenza adottate.

L’accesso e la permanenza del personale del Fornitore nelle suddette sedi di lavoro sono subordinati all’assoluto rispetto delle procedure di sicurezza in vigore.

Le trasferte del personale del Fornitore sono a carico del Fornitore stesso. Va osservato che la possibilità di trasferte al di fuori territorio di Roma Capitale e comunque in Italia, avrà un’occorrenza marginale.

Le risorse del Fornitore presenti presso le suddette sedi di lavoro di AdeR che debbono connettersi alla rete aziendale di AdeR dovranno disporre di apparecchiature (notebook o similari), con caratteristiche adeguate alla connessione, opportunamente dimensionate, in termini di hardware e software, in funzione dell’attività da svolgere e rispondenti ai requisiti di sicurezza definiti da AdeR (che saranno consegnati in corso di esecuzione del contratto). In particolare, tutte le postazioni di lavoro che, seppure in modo minimale, si connetteranno alla rete aziendale AdeR dovranno essere dotate di un programma antivirus mantenuto e aggiornato, almeno mensilmente, a cura e spese del Fornitore.

La connessione da parte delle risorse del Fornitore alla rete aziendale deve essere preventivamente autorizzata da AdeR; in nessun caso l’apparecchiatura collegata

alla rete aziendale di AdeR potrà essere collegata contemporaneamente ad una rete esterna.

Nel corso della durata contrattuale AdeR si riserva di verificare il rispetto, da parte del Fornitore, di quanto sopra previsto; qualora venisse accertato un inadempimento da parte del Fornitore, troverà applicazione la relativa penale prevista al paragrafo 6 dell’allegato “C”.

8 Figure professionali richieste per l’esecuzione dei servizi

Nel presente capitolo sono indicate le figure professionali previste per lo svolgimento dei servizi oggetto dell’appalto, il numero minimo di risorse, per ciascuna figura professionale, che il Fornitore dovrà avere a disposizione e i profili (requisiti minimi) di ciascuna figura professionale.

8.1 Dimensionamento del pool di risorse e composizione media per ciascun servizio

Il Fornitore dovrà eseguire i servizi di richiesti (AMS, NSS, AS e RI) oggetto del presente capitolato, impiegando risorse professionali corrispondenti alle figure professionali indicate nel successivo paragrafo 8.2.

Il numero delle risorse professionali (pool di risorse) di cui il Fornitore dovrà disporre per l’esecuzione dei servizi non dovrà essere inferiore, in relazione a ciascuna figura professionale, a quanto di seguito indicato:

RIF	Figura professionale	N. minimo
P7	Responsabile del contratto	1
P6	Specialista di tematica, specialista analista funzionale (riscossione)	4
P5	Capo progetto / Team Leader / PMO	4
P4	Tecnico di collaudo ed integrazione	2
P3a	Analista Programmatore Senior Cobol	6
P3bJ	Analista Programmatore Senior Java	2
P3bM	Analista Programmatore Senior Microsoft	2
P3c	Analista Programmatore Senior Java–BPM	1
P2a	Analista Programmatore Junior Cobol	6
P2bJ	Analista Programmatore Junior Java	2
P2bM	Analista Programmatore Junior Microsoft	2
P1	Business Process Re - engineer	2
S4a	DBA DB2 (mainframe)	1
S4b	DBA Oracle 11g RAC	1
S3a	Sistemista mainframe	1
S3b	Sistemista dipartimentale	1

Tabella 7 - Figure professionali richieste

In sede di offerta il Concorrente potrà indicare un numero superiore di risorse professionali di cui si avvarrà per l’esecuzione dei servizi di AMS e di NSS. Tutte le risorse professionali dovranno comunque essere in possesso dei requisiti minimi previsti per la corrispondente figura professionale.

La previsione nell’offerta di un numero superiore di risorse professionali non determinerà, comunque, l’attribuzione di un punteggio.

Per quanto riguarda il servizio di AMS (attività di MAC e MAA), il team di risorse dedicato a queste attività, dovrà essere correttamente dimensionato dal Fornitore (numero di GG/P medi adeguato) in modo da garantire gli SLA richiesti oppure, ove previsto, quelli migliorativi dallo stesso offerti; di seguito si riporta la composizione del team di lavoro e la percentuale di impiego stimata per ciascuna figura professionale.

Figura Professionale	Percentuale d’impiego
P6 – Specialista di tematica, specialista analista funzionale (riscossione)	10%
P5 – Capo Progetto / Team Leader / PMO	5%
X0x, X0x – DBA DB2 (mainframe) o DBA Oracle 11g RAC (a seconda dell’ambiente)	10%
P1 – Business Process Re - engineer	10%
X0x, X0xX, X0xX – Analista Programmatore Senior (a seconda della tecnologia)	40%
X0x, X0xX, X0xX – Analista Programmatore Junior (a seconda della tecnologia)	25%
Totale	100%

Tabella 8 - dimensionamento medio per il servizio AMS

I singoli interventi relativi ai servizi di NSS, ad eccezione delle attività di Supporto Specialistico, dovranno essere svolti da un mix di risorse professionali del Fornitore (skill mix), adeguato in ragione delle specifiche attività previste dall’intervento stesso. Di seguito si riporta la composizione del team di lavoro che di massima verrà impiegato negli interventi di Manutenzione Evolutiva, Sviluppo Software o Implementazione dei sistemi e la percentuale di impiego stimata, per ciascuna figura professionale, in ragione del grado di complessità dell’intervento richiesto.

Figura Professionale

Complessità

Bassa

Media

Alta

P1 – Business Process Re – engineer

10%

15%

Figura Professionale	Complessità
Figura Professionale	Bassa	Media	Alta
P6 – Specialista di tematica, specialista analista funzionale (riscossione)	5%	15%	20%
P5 – Capo Progetto / Team Leader / PMO	5%	10%	10%
X0xX, X0x – Analista Programmatore Senior Microsoft o Java- BPM (a seconda della tecnologia)	5%	10%	10%
X0x, X0xX – Analista Programmatore Senior Cobol o Java (a seconda della tecnologia)	40%	30%	30%
X0x, X0xX, X0xX – Analista Programmatore Junior (a seconda della tecnologia)	40%	25%	15%
Totale	100%	100%	100%

Tabella 9 - Dimensionamento medio per il servizio NSS

La complessità dell’intervento (bassa, media, alta) è definita in contraddittorio tra il

Fornitore e AdeR secondo quanto disciplinato dal successivo paragrafo 9.2.

Per gli interventi relativi all’Assistenza Specialistica (servizio di AS), il team di risorse dedicato a queste attività, dovrà essere correttamente dimensionato dal Fornitore in modo da garantire gli SLA richiesti o, ove previsto, quelli migliorativi dallo stesso offerti; di seguito si riporta la composizione del team di lavoro e la percentuale di impiego stimata, per ciascuna figura professionale.

Figura Professionale	Percentuale d’impiego
P1 – Business Process Re – engineer	7%
P6 – Specialista di tematica, specialista analista funzionale (riscossione)	25%
P5 – Capo Progetto / Team Leader / PMO	5%
0S4a, S4b –DBA DB2 (mainframe) o DBA Oracle 11g RAC (a seconda dell’ambiente)	15%
X0x, X0x – Sistemista mainframe o Sistemista dipartimentale (a seconda dell’ambiente)	8%
P4 – Tecnico di collaudo ed integrazione	5%
X0x, X0xX, X0xX – Analista Programmatore Senior (a seconda della tecnologia)	20%
X0x, X0xX, X0xX – Analista Programmatore Junior (a seconda della tecnologia)	15%
Totale	100%

Tabella 10 - Dimensionamento medio per il servizio AS

Per gli interventi relativi al Supporto Utenti o anche Richiesta Informazioni (servizio di RI) il team di risorse dedicato a queste attività, dovrà essere correttamente dimensionato dal Fornitore in modo da garantire gli SLA richiesti o, ove previsto,

quelli migliorativi dallo stesso offerti; di seguito si riporta la composizione del team di lavoro e la percentuale di impiego stimata, per ciascuna figura professionale.

Figura Professionale	Percentuale d’impiego
P1 – Business Process Re - engineer	2%
P6 – Specialista di tematica, specialista analista funzionale (riscossione)	3%
P4 – Tecnico di collaudo ed integrazione	15%
X0x, X0xX, X0xX – Analista Programmatore Senior (a seconda della tecnologia)	80%
Totale	100%

Tabella 11 - Dimensionamento medio per il servizio RI

8.2 Profili delle figure professionali

Le figure professionali, oltre ad essere in possesso dei requisiti minimi di seguito riportati, dovranno avere una buona conoscenza della lingua italiana nonché conoscere la lingua inglese di livello adeguato alla comprensione della documentazione tecnica che potrà essere scritta in tale lingua.

Per alcune figure professionali è richiesta la “conoscenza”, la “buona conoscenza” oppure la “ottima conoscenza”. La “conoscenza” di un item richiesto (linguaggio di programmazione, architettura di riferimento, ecc.) sarà valutata sulla base dell’esperienza maturata sull’argomento in considerazione del tempo in cui la risorsa è stata impegnata in corsi (in termini di numero di corsi sostenuti) sullo specifico item o progetti che prevedono l’utilizzo dello stesso.

La “conoscenza” corrisponde ad un utilizzo o ad un’operatività su quello specifico item per almeno 6 mesi continuativi a tempo pieno (100%), la “buona conoscenza“ corrisponde ad un utilizzo o ad un’operatività su quello specifico item per almeno 12 mesi continuativi a tempo pieno, mentre l’”ottima conoscenza” corrisponde ad un utilizzo o ad un’operatività su quello specifico item superiore a 12 mesi continuativi a tempo pieno.

Si precisa che per “cultura equivalente” si considerano generalmente 4 anni aggiuntivi di esperienza professionale nell’ambito dei servizi applicativi di cui almeno 2 aggiuntivi nel ruolo specifico.

Per laurea si intende la laurea magistrale, mentre in caso di laurea triennale, occorre considerare almeno 2 anni aggiuntivi di esperienza lavorativa.

8.2.1 P7 – Responsabile del contratto

La figura del Responsabile del contratto costituisce l’interfaccia del Fornitore per quanto riguarda la gestione del contratto.

Requisiti minimi

• laurea in discipline tecniche o cultura equivalente

• almeno 15 anni di esperienza lavorativa nel settore ICT, di cui almeno 8 anni nel ruolo.

• .

Responsabilità

• è l’unico referente del contratto;

• supporta il management di AdeR nella gestione dei servizi oggetto dell’appalto;

• costituisce il punto di escalation per la risoluzione di problemi nella esecuzione dei servizi (tecnici, economici, gestionali, ecc.).

8.2.2 P6 – Specialista di tematica, specialista analista funzionale (riscossione) Lo Specialista / Analista Funzionale, gestisce e/o esegue le attività di analisi funzionale per tutti i servizi oggetto di questo capitolato (AMS, NSS, AS e RI). Ha una

forte competenza in materia di riscossione.

È incaricato di analizzare le richieste provenienti da AdeR, valutarle e indirizzare i gruppi di lavoro del Fornitore, sulla base dell’ottima conoscenza dei temi relativi alla riscossione.

Requisiti minimi

• almeno 5 anni di esperienza lavorativa in società di I.T., di cui almeno 2 nel ruolo e partecipazione continuativa per tutta la durata di almeno un progetto di riferimento per cui è indicata la risorsa. La durata della partecipazione agli eventuali altri progetti riportati non dovrà essere inferiore ai quattro mesi per ciascun progetto elencato;

• conoscenza del processo di riscossione coattiva e spontanea secondo quanto indicato nel paragrafo 1.1;

• conoscenza lingua italiana.

Responsabilità

• gestisce le attività di analisi funzionale in supporto al Capo Progetto dello stesso Gruppo di lavoro definito sia per la gestione delle MEV sia per quella dei NSS;

• supporta il Gruppo nella verifica dei casi in cui sia necessario valutare gli impatti di interventi (MEV, NSS) sui sistemi elencati al capitolo 2;

• definisce e predispone tutta la documentazione per l’analisi funzionale della soluzione associata all’intervento richiesto da AdeR;

• fornisce supporto alla struttura tecnica negli interventi di MAC e AS;

• verifica la validità dell’intervento in fase di collaudo e test di non regressione;

• verifica o definisce il piano funzionale di test dei sistemi realizzati e provvede alla stesura della documentazione utente (manuali operativi – funzionali);

• effettua e gestisce i corsi di formazione rivolti agli utenti delle procedure fornite di cui al capitolo 2.

8.2.3 P5 – Capo progetto / Team Leader /PMO

Requisiti minimi

• laurea in ingegneria vecchio ordinamento o specialistica in materie scientifiche / informatiche o cultura equivalente;

• almeno 10 anni di esperienza lavorativa in società di Information and Communication Technology (ICT), di cui almeno 5 anni nel ruolo;

• conoscenza delle principali tecniche e strumenti di project management (Gantt, Pert, CPM, livellamento risorse, earned value);

• responsabilità su gruppi di progetto;

• conoscenze ed uso di tecniche e prodotti software per project management e risk management;

• aver definito e/o applicato processi di gestione della qualità nella realizzazione di soluzioni informatiche;

• aver utilizzato strumenti quali Requisite Pro, Rational Rose, MS Xxxxx;

• conoscenza delle tematiche di legge e normative relative alla riscossione;

• conoscenza della lingua italiana.

Responsabilità

• per gli interventi (progetti) di propria competenza, è responsabile:

− della definizione del team di lavoro per l’esecuzione dell’intervento

richiesto;

− della realizzazione di tutte le funzionalità previste in fase progettuale;

− del rispetto dei tempi di consegna previsti dalla pianificazione

dell’intervento;

− del rispetto degli standard qualitativi, documentativi e tecnici definiti da EQ.

• la figura indicata dovrà pertanto:

− fornire al team di lavoro gli indirizzi generali al fine di ottenere il risultato desiderato in termini di soluzione ed impegni sottoscritti;

− predisporre i piani generali di progetto sulla base dei piani tecnici di dettaglio, verificandone la coerenza e l'aggiornamento per la durata dell'intero progetto;

− controllare l'andamento del progetto mediante il monitoraggio di risorse e scadenze; fornire report sullo stato di avanzamento del progetto, evidenziando eventuali deviazioni dal piano;

− individuare iniziative per risolvere carenze e/o deviazioni;

− adempiere alle attività previste in ambito aziendale per garantire la disponibilità dei servizi interni e delle risorse necessari per la realizzazione del progetto;

− risolvere eventuali problematiche che emergessero in corso d'opera e porre in essere azioni di escalation qualora ciò si rendesse necessario per la risoluzione del problema;

− coordinare e gestire le risorse per lo svolgimento delle attività previste;

− verificare i contenuti dei deliverable di progetto;

− garantire la completezza e la coerenza della documentazione di progetto;

− predisporre tool per la gestione della documentazione di progetto;

− gestire i report concernenti issue, change request e reclami, monitorando lo stato di avanzamento.

8.2.4 P4 – Tecnico di collaudo ed integrazione

È responsabile, per conto del Fornitore, della corretta integrazione dei sistemi e dei componenti software con i sistemi preesistenti e della loro rispondenza ai requisiti funzionali e non.

Analizza, raccomanda e seleziona piattaforme software e/o pacchetti/soluzioni conformi e adeguati agli standard di interconnessione ed ai requisiti di integrazione.

Raccomanda strategie di implementazione delle applicazioni di integrazione dei sistemi selezionando tecnologie di componenti e piattaforme adeguate e verifica le capacità e l’operatività dei sistemi integrati rispetto alle esigenze espresse da AdeR.

Può partecipare e/o supportare il collaudo di certificazione e di accettazione della soluzione software su richiesta della struttura ICT di AdeR, in contradditorio con i key user interni di AdeR stessa.

Requisiti minimi

• almeno 5 anni di esperienza lavorativa in società di I.T., di cui almeno 2 nel ruolo e partecipazione continuativa per tutta la durata di almeno un progetto

di riferimento per cui è indicata la risorsa. La durata della partecipazione agli eventuali altri progetti riportati non dovrà essere inferiore ai quattro mesi per ciascun progetto elencato;

• conoscenza delle metodologie di integrazione e del collaudo del software.

• conoscenza lingua italiana.

Responsabilità

• supporta il Gruppo degli analisti e programmatori del Fornitore nella definizione dei test case e dei piani di test.

• definisce e predispone tutta la documentazione di test relativamente all’analisi funzionale della soluzione associata all’intervento richiesto da AdeR;

• fornisce supporto alla struttura tecnica negli interventi di MAC e AS;

• verifica la validità dell’intervento in fase di collaudo e test di non regressione;

8.2.5 P3a – Analista Programmatore Senior Cobol

Requisiti minimi

• almeno 6 anni di esperienza lavorativa nel settore ICT di cui almeno 2 anni nel ruolo;

• aver applicato la metodologia UML;

• buona conoscenza dell’architettura specifica dell’attività lavorativa cui è

preposto;

• aver sviluppato applicazioni su DB2 v 12 e versioni seguenti per zOS;

• aver utilizzato i linguaggi Cobol e SQL in progetti per almeno un totale di 3 anni.

• conoscenza lingua italiana.

8.2.6 P3bJ – Analista Programmatore Senior Java

Requisiti minimi

• almeno 6 anni di esperienza lavorativa nel settore ICT di cui almeno 2 anni nel ruolo;

• aver applicato la metodologia UML;

• aver utilizzato strumenti quali Requisite Pro, Rational Rose, MS Xxxxx;

• aver utilizzato il paradigma architetturale SOA e Web Service in almeno 4 progetti;

• aver programmato moduli software utilizzando J2EE (Servlet, JSP, EJB, ecc.);

• aver sviluppato utilizzando i linguaggi Java e SQL nei vari progetti per almeno 3 anni;

• aver sviluppato utilizzando il DBMS Oracle RAC 11g;

• buona conoscenza dell’architettura specifica dell’attività lavorativa cui è

preposto;

• buona conoscenza dei software di base in utilizzo presso AdeR, tra i quali si ricordano:

− IBM WAS

− JBoss

− DBLINK

− Soluzioni di middleware (ESB) come ad esempio WSO2

− WebSphere Host Access Transformation Service (HATS);

• conoscenza della lingua italiana.

8.2.7 P3bM – Analista Programmatore Senior Microsoft

Requisiti minimi

• almeno 6 anni di esperienza lavorativa nel settore ICT di cui almeno 2 anni nel ruolo;

• aver applicato la metodologia UML;

• aver utilizzato strumenti quali Requisite Pro, Rational Rose, MS Xxxxx;

• aver utilizzato il paradigma architetturale SOA e Web Service in almeno 4 progetti;

• aver programmato moduli software utilizzando .NET Frameworks 2.0 o superiori;

• aver sviluppato utilizzando i linguaggi Microsoft e SQL nei vari progetti per almeno 3 anni;

• aver sviluppato utilizzando il DBMS Oracle RAC 11g e/o Microsoft SQL Server 2000 o superiori;

• conoscenza della lingua italiana.

8.2.8 P3c – Analista Programmatore Senior Java- BPM

Requisiti minimi

• almeno 6 anni di esperienza lavorativa nel settore ICT nelle attività nella analisi, progettazione e realizzazione di software, di cui almeno 2 anni nel ruolo;

• laurea in discipline tecniche o cultura equivalente;

• aver applicato la metodologia UML;

• aver utilizzato strumenti quali Requisite Pro, Rational Rose, MS Xxxxx;

• aver utilizzato il paradigma architetturale SOA e Web Service in almeno 4 progetti;

• aver programmato moduli software utilizzando J2EE (Servlet, JSP, EJB, ecc.);

• aver realizzato soluzioni software mediante IBM – BPM e in particolare il

modulo definito “Lombardi”;

• aver utilizzato IBM Blueworks per la definizione dei processi;

• aver descritto i processi mediante BPMN (Business Process Modeling Notation), averli eseguiti su motore BPEL (Business Process Execution Language);

• aver sviluppato utilizzando i linguaggi Java e SQL in vari progetti per almeno 3 anni;

• aver sviluppato utilizzando il DBMS Oracle RAC 11g;

• conoscenza dei software di base in utilizzo presso EQ, tra i quali si ricordano:

− IBM WAS

− JBoss

− DBLINK

− Soluzioni di middleware (ESB) come ad esempio WSO2

− WebSphere Host Access Transformation Service (HATS);

• conoscenza della lingua italiana

8.2.9 P2a – Analista Programmatore Junior Cobol

Requisiti minimi

• almeno 3 anni di esperienza lavorativa nel settore ICT nelle attività nella analisi, progettazione e realizzazione di software, di cui almeno 2 anni nel ruolo;

• aver utilizzato la metodologia UML;

• aver utilizzato strumenti quali Requisite Pro, Rational Rose, MS Xxxxx;

• aver utilizzato DB2 v 12 e versioni seguenti su zOS;

• aver sviluppato utilizzando dei linguaggi Cobol e SQL in progetti per almeno 1,5 anni;

• conoscenza della lingua italiana

8.2.10 P2bJ – Analista Programmatore Junior Java

Requisiti minimi

• almeno 3 anni di esperienza lavorativa nel settore ICT nelle attività nella analisi, progettazione e realizzazione di software, di cui almeno 2 anni nel ruolo;

• aver utilizzato la metodologia UML;

• aver utilizzato strumenti quali Requisite Pro, Rational Rose, MS Xxxxx;.

• aver utilizzato il paradigma architetturale SOA e Web Service in almeno 2 progetti;

• aver programmato moduli software utilizzando J2EE (Servlet, JSP, EJB, ecc.);

• aver sviluppato utilizzando il DBMS Oracle RAC 11g;

• conoscenza dell’architettura specifica dell’attività lavorativa cui è preposto;

• conoscenza ed esperienza di utilizzo del DBMS Oracle RAC 11g;

• buona conoscenza dei software di base in utilizzo presso AdeR, tra i quali si ricordano:

− IBM WAS

− JBoss

− DBLINK

− Soluzioni di middleware (ESB) come ad esempio WSO2

− Websphere Host Access Transformation (HATS)

− IBM – BPM, già noto come “WebSphere Lombardi Edition”

− IBM Blueworks

• buona conoscenza applicativa (funzionale) del sistema sul quale è chiamato a svolgere la propria attività.

• conoscenza della lingua italiana.

8.2.11 P2bM – Analista Programmatore Junior Microsoft

Requisiti minimi

• almeno 3 anni di esperienza lavorativa nel settore ICT nelle attività nella analisi, progettazione e realizzazione di software, di cui almeno 2 anni nel ruolo;

• aver utilizzato la metodologia UML;

• aver utilizzato strumenti quali Requisite Pro, Rational Rose, MS Xxxxx;

• aver utilizzato il paradigma architetturale SOA e Web Service in almeno 2 progetti;

• aver programmato moduli software utilizzando .NET Frameworks 2.0 o superiori;

• aver sviluppato utilizzando il DBMS Oracle RAC 11g e/o Microsoft SQL Server 2000 o superiori;

• buona conoscenza ed esperienza di utilizzo del DBMS Oracle RAC 11g;

• conoscenza della lingua italiana

8.2.12 S4a – DBA DB2 (mainframe)

Requisiti minimi

• almeno 6 anni di esperienza lavorativa nel settore ICT, di cui almeno 4 anni

nell’ambito di gruppi di progetto, con ruolo di DB Administrator;

• aver operato su ambienti DB2 v 12 (e superiori) su mainframe (zOS) per almeno 4 progetti ciascuno della durata non inferiore a 4 mesi;

• aver applicato i tool sistemistici e di analisi dell’ambiente DB2;

• conoscenza della lingua italiana.

8.2.13 S4b – DBA Oracle 11g RAC

Requisiti minimi

• almeno 6 anni di esperienza lavorativa nel settore ICT, di cui almeno 4 anni

nell’ambito di gruppi di progetto, con ruolo di DB Administrator;

• aver operato su ambienti Oracle di grandi dimensioni (Very Large DataBase), su Oracle RAC11g in almeno 4 progetti ciascuno della durata non inferiore a 4 mesi;

• aver applicato tool sistemistici e di analisi dell’ambiente Oracle;

• conoscenza della lingua italiana

8.2.14 S3a – Sistemista mainframe

Requisiti minimi

• almeno 5 anni di esperienza lavorativa nel settore ICT, di cui almeno 3 anni

nell’ambito di gruppi di progetto, con ruolo di Sistemista;

• aver operato in modo sistemistico, su zOS v 2.0 e seguenti, su almeno 3 progetti, ciascuno della durata non inferiore a 4 mesi;

• aver operato su problematiche di configurazione ed installazione hardware e software e delle infrastrutture di comunicazione;

• conoscenza della lingua italiana.

8.2.15 S3b – Sistemista dipartimentale

Requisiti minimi

• almeno 5 anni di esperienza lavorativa nel settore ICT, di cui almeno 3 anni

nell’ambito di gruppi di progetto, con ruolo di Sistemista;

• aver operato in modo sistemistico su Windows Server, Linux Centos o Red Hat, IBM WAS per Linux e Jboss, con evidenza di almeno progetti 4, ciascuno della durata non inferiore a 4 mesi;

• aver operato su problematiche di configurazione ed installazione hardware e software e delle infrastrutture di comunicazione;

• aver operato su protocolli di rete;

• aver operato su componenti dei Personal Computer e delle LAN;

• conoscenza della lingua italiana.

8.2.16 P1 – Business Process Re – engineer

È coinvolto nelle attività che hanno come obiettivo l’analisi di organizzazioni e di processi di riscossione allo scopo di identificare e determinare la migliore organizzazione dei processi e/o identificare miglioramenti rispetto a quelli correnti.

Collabora con il team di analisi di AdeR e del Fornitore per indentificare gli aspetti di processo che devono essere rivisti conseguentemente alla realizzazione dei NSS e quindi indirizzarli opportunamente.

In caso di rilasci particolarmente complessi, provvede ad elaborare il processo di deploy e messa in esercizio della soluzione.

Requisiti minimi

• almeno 6 anni di esperienza lavorativa in società di I.T. o analoga, di cui almeno 4 nel ruolo e partecipazione continuativa per tutta la durata ad almeno un progetto individuabile;

• conoscenze ed uso di tecniche di project management e risk management in progetti complessi;

• ottima conoscenza di metodologie di disegno e implementazione organizzativa, Business Process Reengineering e change management;

• approfondita esperienza nella gestione di progetti organizzativi e IT complessi;

• realizzazione di progetti in ambito Riscossione;

• conoscenza della lingua italiana.

8.3 Verifica requisiti delle risorse professionali

Come meglio previsto nel disciplinare di gara, il Concorrente risultato aggiudicatario, ai fini dell’efficacia dell’aggiudicazione stessa dovrà dimostrare, tra l’altro, il possesso da parte delle proprie risorse professionali, dei requisiti minimi previsti per ciascuna figura professionale dai precedenti paragrafi nonché, se dichiarati in sede di offerta, il possesso dei requisiti migliorativi.

A tal fine, nei termini indicati dal Disciplinare di Gara, il Concorrente risultato aggiudicatario dovrà produrre l’elenco nominativo delle risorse professionali nel numero minimo previsto o nel maggior numero indicato nella Relazione Tecnica di cui si avvarrà per l’esecuzione dei servizi, con l’indicazione della natura del rapporto di lavoro in essere, nonché il curriculum vitae di ciascuna di dette risorse professionali dal quale dovrà risultare il possesso degli specifici requisiti minimi richiesti.

I CV dovranno essere redatti utilizzando il formato Europass secondo le specifiche esposte su xxxx://xxxxxxxx.xxxxxxx.xxxxxx.xx. Nel CV, a dimostrazione del grado di “conoscenza”, “buona conoscenza” o “ottima conoscenza” dell’item richiesto, dovrà essere indicato il numero di corsi eseguiti o la durata dei progetti che hanno previsto un impegno a tempo pieno.

Per le conseguenze in caso di produzione di documentazione non corretta, incompleta o altro, si rinvia a quanto previsto dal disciplinare di gara.

9 Governo dei servizi oggetto dell’appalto

Il servizio di Onboarding APM sarà erogato a partire dalla data di avvio del contratto con le modalità indicate nel precedente paragrafo 3.2 e secondo il cronoprogramma di cui al precedente paragrafo 3.9.

I servizi di AMS, NSS, AS e RI dovranno essere erogati a decorrere dalla data del verbale di avvio dell’esecuzione del contratto, di cui al precedente paragrafo 3.7, per il periodo previsto di 48 mesi. Nel caso in cui AdeR eserciti l’opzione di rinnovo per ulteriori 12 mesi di cui al precedente paragrafo 3.7, gli stessi servizi dovranno essere erogati per gli ulteriori 12 mesi.

I servizi oggetto della gara si svolgeranno secondo il processo descritto nei paragrafi seguenti.

Il Fornitore, sulla base di quanto previsto nell’Allegato “A” – “Metodologie e procedure” ed in linea con quanto indicato nell’offerta tecnica, dovrà predisporre il proprio Piano della Qualità Generale nel quale dovrà essere riportato, in modo dettagliato, il modello di gestione dei servizi.

Il Fornitore, entro 20 (venti) giorni lavorativi dalla data di sottoscrizione del contratto, dovrà consegnare il Piano della Qualità Generale a AdeR per la sua approvazione. Nel caso in cui AdeR rilevi non conformità e/o incongruenze con le metodologie e procedure riportate nell’allegato “A” e/o con quanto riportato nell’offerta tecnica, il Fornitore sarà tenuto a consegnare il Piano della Qualità Generale aggiornato entro 5 (cinque) giorni lavorativi dalla formalizzazione dei suddetti rilievi.

Su questa attività è legato l’indicatore di qualità IQ1.01 riportato nell’allegato “C” –

Indicatori di qualità e penali.

Come si vedrà nei paragrafi che seguono, tutte le attività di AMS, NSS, AS e RI saranno commissionate da AdeR al Fornitore mediante uno strumento che permetta di (la lista non è indicativa):

1. accedere a tutte le informazioni via web;

2. trasmettere la richiesta da AdeR al Fornitore in modo non ripudiabile;

3. consentire un colloquio tracciato tra AdeR e il Fornitore circa l’ingaggio;

4. supportare la gestione degli stati della richiesta;

5. consentire di misurare gli SLA richiesti da AdeR o proposti dal Fornitore;

6. trasferire tutti i dati delle richieste (storiche e in corso) su altro sistema su richiesta di AdeR.

Ader allo scopo utilizza il sistema Bugzilla, per le fasi di collaudo e OTRS per la gestione delle comunicazioni. Sono a carico del Fornitore tutte le operazioni di configurazione e/o l’installazione di detti sistemi sulle proprie postazioni adibite all’erogazione del servizio e di quanto necessario per accedere da remoto agli stessi.

In caso di indisponibilità del sistema, sarà utilizzata la posta elettronica; il Fornitore sarà pertanto tenuto a mettere a disposizione una casella e-mail dedicata al servizio. In caso di utilizzo della posta elettronica, sarà compito del Fornitore tracciare l’attività su Bugzilla e/o OTRS non appena ripristinata l’operatività del sistema.

Il Fornitore potrà proporre una sua soluzione, che sarà impiegata in aggiunta a quelle di AdeR, nel caso in cui fosse giudicata valida da AdeR stessa e senza maggior onere per AdeR, come meglio indicato al successivo paragrafo 9.11.

Nel resto del documento, ovunque si scriva di trasmissione delle richieste, sono citati gli strumenti di AdeR, fermo restando questa possibile sostituzione con mezzi del Fornitore.

9.1 Modalità di esecuzione del servizio di AMS

AdeR, in base alle proprie effettive esigenze, si riserva la facoltà di ridurre la durata del servizio di AMS previsto per ciascuna applicazione, dandone comunicazione al Fornitore con un preavviso di 20 (venti) giorni lavorativi dalla data di effettiva cessazione. In questo caso il canone mensile del servizio AMS sarà ridotto del valore corrispondente alla dimensione in FP della applicazione dismessa, quale risultante dall’asset preso in carico all’avvio del contratto, moltiplicato il prezzo unitario offerto in sede di gara.

Le attività di AMS saranno tracciate tramite il sistema Bugzilla messo a disposizione da AdeR e fruibile mediante un browser web.

La chiusura di un ticket dovrà essere corredata dalla documentazione tecnica dell’intervento, da cui risultino i difetti/errori riscontrati ed il dettaglio degli interventi effettuati (traccia di tutte le richieste di manutenzione, del loro dimensionamento – effort, delle date di rilascio, della documentazione a supporto, ecc.), nonché dalla documentazione tecnica dell’applicazione aggiornata.

Il Servizio di AMS (MAC e MAA) dovrà essere eseguito dal Fornitore nel rispetto degli SLA indicati nel presente capitolato tecnico oppure, ove previsto, in quelli migliorativi riportati nell’offerta tecnica presentata dal Fornitore stesso in sede di gara. Qualora, a giudizio del Fornitore, per fatti a lui non imputabili (ad es. descrizione insufficiente, indisponibilità di sistemi, ecc.) si possa determinare il mancato rispetto degli SLA, come sopra definiti, il Fornitore stesso dovrà darne comunicazione a AdeR entro gli stessi tempi definiti per la presa in carico dall’indicatore di qualità IQ2.01 o in quelli migliorativi eventualmente indicati dal Fornitore nell’offerta tecnica. Nella comunicazione dovranno essere dettagliatamente indicate le circostanze che possono determinare l’inadempimento.

9.1.1 Manutenzione correttiva (MAC)

9.1.1.1 Modalità operative di attivazione ed erogazione

Per le attività di manutenzione correttiva, rientranti nel servizio di AMS, sono previste le seguenti modalità di erogazione:

Sede delle attività	Sede Fornitore*
Mezzi di comunicazione	OTRS o Bugzilla
Lingua	Italiano
Giorni di servizio**	Giorni lavorativi: i giorni dal lunedì al venerdì, ad esclusione delle festività nazionali. Reperibilità il sabato mattina
Orario di servizio**	8.30 – 17.30

Tabella 12 – Modalità di erogazione del servizio di MAC

La priorità dell’intervento sarà assegnata da AdeR e indicata nella segnalazione trasmessa al Fornitore in ragione della gravità del malfunzionamento riscontrato, come di seguito riportato:

Priorità

dell’intervento

Gravità

malfunzionamento

Situazione

0 - Emergenza

Alta

Errore bloccante che compromette

l’operatività delle principali funzionalità dell’applicazione

* AdeR può richiedere la presenza presso le proprie sedi per specifiche attività che coinvolgano proprie risorse o risorse di altro fornitore.

** Eventuali riduzioni del livello di assistenza in periodi ritenuti scarichi (per esempio, giorni feriali durante le festività natalizie, mese di agosto, ecc.) dovranno essere concordati tra il Fornitore e AdeR che dovrà dare approvazione scritta. In assenza di tali accordi, tali giornate si intendono come lavorative a tutti gli effetti.

1 – Grave

Media

Errore grave che comporta l’indisponibilità di una funzionalità o una funzionalità degradata

dell’applicazione

2 – Normale

Bassa

Errore che comporta l’indisponibilità

di funzionalità non critiche

dell’applicazione

Tabella 13 - Definizione priorità dell’intervento di MAC

Il processo di gestione dell’intervento di MAC, come previsto nella procedura CRZ

04, riportata nell’allegato “A”, prevede due fasi:

1. presa in carico: il Fornitore dovrà ricercare le ragioni del malfunzionamento e comunicare l’accettazione della segnalazione nel rispetto dello SLA, di cui al successivo paragrafo 9.9.2. Il Fornitore nel caso di anomalie bloccanti o gravi dovrà comunque fornire eventuali soluzioni di bypass per ripristinare almeno in parte l’operatività del sistema o della funzionalità. Qualora il malfunzionamento non dipenda dall’applicazione il Fornitore comunicherà che la segnalazione è stata “rifiutata” e fornirà indicazioni sulle ragioni del malfunzionamento;

2. risoluzione: il Fornitore dovrà rimuovere l’anomalia fornendo la modifica al software, la documentazione tecnica dell’intervento nonché la documentazione tecnica dell’applicazione aggiornata, nel rispetto dello SLA, di cui al successivo paragrafo 9.9.2. Qualora per ragioni oggettive l’anomalia non possa essere risolta nei termini, il Fornitore e AdeR definiranno di comune accordo le modalità e la tempistica per la risoluzione del malfunzionamento e l’intervento si intenderà “chiuso con difetto”.

9.1.1.2 Rendicontazione dell’attività di MAC

Il Fornitore dovrà produrre un report di rendicontazione dell’attività di MAC che

comprenda i seguenti elementi:

• tipo attività (PR=Probelm Report/Ticket, DIF=DIFetto, MA=Manutenzione Adattativa);

• codice (del ticket o del difetto);

• priorità del problem report o del difetto (A=Alta, M=Media, B=Bassa);

• identificazione se MAC o altro tipo di intervento (secondo quanto indicato nel paragrafo 3.3);

• breve descrizione;

• richiedente (nome e cognome);

• assegnatario (nome e cognome);

• stato attuale;

• data e ora di apertura;

• data e ora di chiusura;

• giorni di attività per la soluzione;

• note eventuali.

Nell’intestazione del report devono sempre essere riportati:

• Nome del Fornitore

• Data di redazione

• Periodo a cui si riferiscono i dati

La periodicità di produzione dei report sarà settimanale in una fase iniziale (primi 4 mesi dalla data di avvio dell’esecuzione del contratto), per poi diventare mensile.

La periodicità potrà essere rivista in ogni momento da AdeR, a suo insindacabile giudizio.

9.1.2 Manutenzione adeguativa (MAA)

9.1.2.1 Modalità operative di attivazione ed erogazione

Per le attività di manutenzione adeguativa (MAA), rientranti nel servizio di AMS, sono previste le seguenti modalità di erogazione:

Sede delle attività	Sede Fornitore o sede AdeR
Mezzi di comunicazione	Bugzilla
Lingua	Italiano
Giorni di servizio**	Giorni lavorativi: i giorni dal lunedì al venerdì, ad esclusione delle festività nazionali
Orario di servizio**	8.30 – 17.30

Tabella 14 – Modalità di erogazione del servizio di MAA

Le attività di MAA dovranno essere eseguite nel rispetto della procedura CRZ04 riportata nell’allegato “A”. In particolare:

1. AdeR trasmetterà al Fornitore una Richiesta di Manutenzione Adeguativa (RDA) nella quale saranno indicati:

** Qualora ricorrano particolari esigenze AdeR potrà richiedere al Fornitore prestazioni da effettuare al di fuori dell’orario di servizio o in giorni festivi; in tali casi non verrà riconosciuto al Fornitore alcun compenso aggiuntivo. Non è possibile quantificare preventivamente frequenza e durata di tali evenienze, da considerarsi comunque come straordinarie.

− nome dell’applicazione;

− specifiche tecniche dell’intervento;

− milestone e relativi rilasci attesi.

La RDA riporterà la codifica assegnata alla richiesta secondo il criterio nome_applicazione-Maa-Modulo-nnnn, dove:

− nome_applicazione = applicazione interessata all’intervento;

− aa = anno;

− nnnn = progressivo.

2. Il Fornitore provvederà, sulla base delle informazioni indicate nella RDA, a predisporre un dettagliato piano delle attività da svolgere, in termini di rilasci ed obiettivi; il piano delle attività dovrà essere trasmesso a AdeR entro i 5 (cinque) giorni lavorativi successivi alla data della RDA.

3. AdeR, a seguito delle proprie valutazioni, accetterà il piano delle attività o ne richiederà delle modifiche, dandone comunicazione al Fornitore. In caso di richiesta di modifiche, il Fornitore dovrà trasmettere a AdeR il piano delle attività aggiornato entro i successivi 3 (tre) giorni lavorativi.

4. Il Fornitore, completate le attività di manutenzione adeguativa, comunicherà

il “pronti al collaudo” a AdeR.

5. AdeR effettuerà il collaudo delle modifiche apportate al software e la verifica del corretto aggiornamento della documentazione tecnica. In caso di esito positivo delle suddette attività di collaudo e verifica, AdeR comunicherà al Fornitore la chiusura della RDA; in caso di esito negativo la RDA non s’intenderà chiusa ed il Fornitore dovrà procedere alla definizione di un nuovo piano delle attività, secondo quanto riportato al precedente punto 2, e si procederà come sopra descritto nei successivi punti, fino alla chiusura della RDA.

Si evidenzia che il Fornitore, contestualmente alla comunicazione di “pronto al collaudo”, di cui al precedente punto 4, dovrà fornire a AdeR:

− le modifiche apportate al software (codice sorgente);

− la documentazione tecnica dell’intervento;

− la documentazione tecnica dell’applicativo aggiornata.

Con riferimento al collaudo ed alla verifica di cui al precedente punto 5, si evidenzia che le stesse avranno esito positivo quando:

− le modifiche apportate al software superano il collaudo di accettazione di AdeR;

− le modifiche sono corredate da documenti di analisi funzionale e tecnica redatti nel rispetto della metodologia di cui all’allegato “A”;

− la documentazione tecnica dell’applicativo è redatta nel rispetto della metodologia di cui all’allegato “A”.

L’esito delle suddette attività di collaudo e verifica sarà riportato in un apposito verbale.

Sulle modifiche del software apportate nell’ambito di un intervento di MAA il Fornitore erogherà la garanzia, secondo i termini previsti nel successivo paragrafo 9.5, a partire dalla data del verbale di collaudo positivo.

9.1.2.2 Rendicontazione dell’attività di MAA

Per le attività di MAA, il Fornitore dovrà produrre un report che elenca tutte le RDA aperte e/o chiuse nel mese di riferimento, con almeno le seguenti informazioni per ciascuna RDA:

• nome dell’applicativo;

• codice RDA;

• breve descrizione;

• richiedente (struttura, nome e cognome);

• assegnatario (nome e cognome);

• data di apertura;

• data prevista di consegna al collaudo;

• data effettiva di consegna al collaudo;

• data del collaudo e della verifica della documentazione ed esito delle stesse;

• referente di AdeR (nome e cognome) per il collaudo e la verifica della documentazione;

• note eventuali.

Nell’intestazione del report devono sempre essere riportati:

• nome del Fornitore;

• data di redazione;

• periodo a cui si riferiscono i dati.

9.2 Modalità di esecuzione del servizio di NSS

9.2.1 Modalità operative di erogazione

Il servizio di NSS prevede le seguenti modalità di erogazione:

Sede delle attività	Sede Fornitore* e sede AdeR
Mezzi di comunicazione	Sistema OTRS o e-mail
Giorni di servizio**	Giorni lavorativi: i giorni dal lunedì al venerdì, ad esclusione delle festività nazionali
Orario di servizio**	8.30 – 17.30

Tabella 15 – Modalità di erogazione del servizio di NSS

Come indicato in tabella, per lo scambio di comunicazioni tra AdeR ed il Fornitore (ad es. richiesta intervento, consegna proposta d’intervento, consegna dei deliverable, ecc.) verrà utilizzato il sistema OTRS.

Di seguito, le singole attività rientrati nel servizio di NSS vengono distinte tra attività realizzative di software, da un lato, e quelle di supporto, dall’altro lato, al fine di evidenziare le differenti modalità di affidamento del singolo intervento, di accettazione delle attività prestate e di determinazione del valore dell’intervento.

9.2.2 Attività realizzative di software

Nell’ambito del servizio di NSS, costituiscono attività realizzative di software gli interventi di Manutenzione Evolutiva, Sviluppo Software ed Implementazione dei sistemi.

Nell’ambito delle attività realizzative il Fornitore sarà tenuto a svolgere, a seconda dei casi e con le modalità, termini e condizioni previste dalla proposta d’intervento accettata da AdeR, di cui appresso, le seguenti attività:

• supporto alla definizione dei requisiti utente;

• preventivazione e fattibilità interventi di sviluppo;

• analisi funzionale e specifiche tecniche dell’applicazione;

• analisi della soluzione architetturale;

• analisi strutture dati;

• analisi tecnica e sviluppo;

• definizione del piano di test e stesura dei casi di test;

• aggiornamento della APM;

* È da prevedere una presenza frequente delle risorse del Fornitore presso la sede di Roma di AdeR per le attività di analisi che coinvolgano risorse di AdeR e di altri fornitori. Tale presenza è considerata, inoltre, funzionale alle necessità di coordinamento con il referente di AdeR. La presenza di risorse del Fornitore è da prevedersi in forma saltuaria o in forma continuativa per specifiche attività, secondo gli accordi scritti che verranno presi tra il Fornitore e AdeR. È possibile, sempre previo accordo scritto tra il Fornitore e AdeR, che venga richiesta la presenza di risorse del Fornitore presso le sedi periferiche di AdeR, per specifiche necessità di analisi di fattibilità e/o collaudi e/o supporto on site.

** Applicabile solo nel caso in cui sia prevista l’erogazione dell’attività presso una sede di AdeR; comunque, all’occorrenza, AdeR potrà richiedere al Fornitore prestazioni da effettuare al di fuori dell’orario di servizio o in giorni festivi. Anche in questo caso, non è possibile quantificare preventivamente frequenza e durata di tali evenienze, che saranno di volta in volta specificate al Fornitore.

• aggiornamento della baseline ed evidenza dei FP effettivamente sviluppati;

• supporto alle attività di dry test, collaudo ed alla messa in esercizio;

• garanzia da erogare dopo l’accettazione dello sviluppo, secondo quanto indicato nel successivo paragrafo 9.5.

Di seguito si riportano le principali fasi/attività che caratterizzano la gestione delle attività realizzative:

• Definizione tipologia di intervento:

− Manutenzione Evolutiva;

− Sviluppo software;

− Implementazione dei sistemi.

• Modalità di affidamento;

• Accettazione dell’intervento;

• Determinazione del tipo di complessità (bassa, media, alta) e del valore

economico dell’intervento.

9.2.2.1 Definizione tipologia di intervento

Ciascun intervento (Manutenzione Evolutiva, Sviluppo Software, Implementazione dei sistemi) costituisce un progetto di sviluppo software.

Il ciclo di vita di un progetto prevede due principali fasi:

• Fase 1: Preparazione del Progetto e Analisi;

• Fase 2: Realizzazione, Preparazione all’avvio in esercizio e Avvio in esercizio, nonché le eventuali attività di assistenza per il rilascio in esercizio.

AdeR, a seguito della definizione del proprio fabbisogno di attività realizzative, definisce la stima di massima dell’impegno richiesto per la realizzazione del progetto, in termini di FP, al solo scopo di definire la tipologia dell’intervento (MEV o NS), secondo quanto di seguito riportato:

Manutenzione Evolutiva (MEV)

Rientrano in questa tipologia di intervento, le attività realizzative che prevedono un impegno complessivo non superiore ai 210 (duecentodieci) FP. Convenzionalmente vi rientra anche la Manutenzione Adeguativa il cui effort sia stimato in misura superiore ai 21 (ventuno) FP, ma comunque inferiore ai 210 FP.

Sviluppo software (NS)

Rientrano in questa tipologia di intervento, le attività realizzative il cui effort sia stimato in misura maggiore a 210 (duecentodieci) FP.

Si precisa che qualora l’impegno dell’attività di NSS sia stato espresso in GG/P, ovunque possibile (quindi esclusi i casi di adeguamento parametrico di software), la conversione tra FP e GG/P sarà eseguita sulla base della formula:

FP = GG/P * Prd

dove Prd è la Produttività espressa dal Fornitore nell’offerta tecnica, applicabile al contesto (ciclo di sviluppo e tecnologia).

AdeR si riserva di richiedere al Fornitore, anche nel corso di esecuzione dell’intervento, attività di assistenza per il rilascio in esercizio, la formazione utenti e l’assistenza agli utenti post-rilascio.

9.2.2.2 Modalità di affidamento

Tutte le attività realizzative previste nel servizio di NSS saranno gestite, a seconda della tipologia di intervento, nel rispetto della procedura CRZ 03 o quella CRZ 08, riportate nell’allegato “A” e soggette ai livelli di servizio di cui al successivo paragrafo 9.9.3.

Qualora AdeR intenda avviare un progetto, invierà al Fornitore una richiesta di intervento, in particolare: una “RDM” in caso di intervento di MEV o una “RDS” in caso di interventi di Sviluppo Software.

Nella richiesta d’intervento saranno riportate le seguenti informazioni:

• descrizione dell’attività;

• data prevista per l’avvio delle attività;

• documentazione necessaria alla valutazione delle attività richieste;

• ambiente tecnologico di riferimento;

• milestone e relativi rilasci, ponendo particolare attenzione ai seguenti aspetti:

− perimetro tecnologico (strumenti di gestione dei servizi, strumenti di sviluppo, architettura di riferimento, interfacce, ecc.);

− perimetro utente (casi d’uso, funzionalità da definire e relative modalità

di utilizzo, ecc.);

− perimetro temporale (elapsed rilasci).

• eventuali attività di assistenza (rilascio in esercizio, formazione utenti e assistenza agli utenti post-rilascio).

AdeR, anche in considerazione della criticità dell’attività realizzativa che intende affidare, si riserva di convocare degli incontri preventivi con il Fornitore al fine di meglio rappresentare l’attività realizzativa che sarà oggetto di richiesta d’intervento.

Il Fornitore, in contradditorio con AdeR, assegnerà al singolo intervento un tipo di complessità (bassa, media, alta) in funzione della combinazione dei seguenti fattori:

• numero delle funzionalità previste;

• caratteristiche delle funzionalità previste;

• dimensione del sistema da realizzare in termini di requisiti funzionali.

Il Fornitore, entro i 5 (cinque) giorni lavorativi successivi alla data della RDM o entro i 15 (quindici) giorni lavorativi successivi alla data della RDS, trasmetterà a AdeR una proposta di intervento predisposta sulla base di quanto riportato nella richiesta d’intervento. Nella proposta d’intervento dovrà essere riportato un dettagliato piano delle attività (in termini di rilasci ed obiettivi), la stima dei FP che verranno realizzati, il tipo di complessità dell’intervento (bassa, media, alta), la composizione del team di lavoro, con indicazione nominativa delle risorse professionali, nonché, nel caso di richiesta di attività di assistenza, le figure professionali coinvolte e l’impegno previsto.

Si precisa che il numero di GG/P necessari per l’esecuzione delle attività di assistenza dovrà essere determinato, in coerenza con quanto riportato in letteratura sull’argomento (rif. “Applied Software Measurement – Assuring Productivity and Quality” di Xxxxx Xxxxx), con le modalità di seguito riportate:

• l’impegno stimato per le attività di rilascio in esercizio di un progetto di

sviluppo è pari a 0,02 GG/P per ogni FP;

• l’impegno stimato per le attività di formazione utenti da erogare per un

progetto rilasciato in esercizio è pari a 0,02 GG/P per ogni FP;

• l’impegno stimato per le attività di assistenza utenti post-rilascio da erogare per un progetto rilasciato in esercizio è pari a 0,08 GG/P per ogni FP.

L’impegno in GG/P per le eventuali attività di assistenza richieste da AdeR sarà pertanto determinato applicando le seguenti formule:

𝑅𝑖𝑙𝑎𝑠𝑐𝑖𝑜 𝑖𝑛 𝑒𝑠𝑒𝑟𝑐𝑖𝑧𝑖𝑜 𝑁° 𝑔𝑔/𝑝 = 0,02 𝑔𝑔/𝑝 ∗ 𝐹𝑃𝑝𝑟𝑗

𝐹𝑜𝑟𝑚𝑎𝑧𝑖𝑜𝑛𝑒 𝑢𝑡𝑒𝑛𝑡𝑖 𝑁° 𝑔𝑔/𝑝 = 0,02 𝑔𝑔/𝑝 ∗ 𝐹𝑃𝑝𝑟𝑗

𝐴𝑠𝑠𝑖𝑠𝑡𝑒𝑛𝑧𝑎 𝑝𝑜𝑠𝑡 − 𝑎𝑣𝑣𝑖𝑜 𝑁° 𝑔𝑔/𝑝 = 0,08 𝑔𝑔/𝑝 ∗ 𝐹𝑃𝑝𝑟𝑗

dove FPprj rappresenta il numero di FP del progetto di sviluppo o manutenzione evolutiva da rilasciare in esercizio.

Il piano delle attività, riportato nella proposta d’intervento, dovrà essere corredato da un cronoprogramma che contenga, rispetto alla data di inizio attività, i tempi per i rilasci (parziali e/o finali) previsti da ciascuna fase di esecuzione dell’intervento.

In particolare, il cronoprogramma dovrà prevedere almeno le seguenti milestone:

• avvio del progetto;

• consegna dei requisiti utente;

• consegna dell’analisi tecnica di dettaglio e del piano di test;

• avvio dello sviluppo;

• conclusione delle implementazioni;

• consegna della documentazione tecnica (manuale operatore, manuale utente, manuale installazione, ecc.);

• supporto nel setup dell’ambiente di collaudo;

• rilascio software per il collaudo (pronti al collaudo);

• avvio della messa in esercizio;

• apertura all’esercizio e inizio dell’attività in modo supervisionato;

• avvio all’esercizio “ordinario”;

• eventuale assistenza post avvio (se richiesto);

• eventuale data di inizio formazione (se richiesta);

• eventuale data di fine della formazione (se richiesta);

• nominativi delle risorse impegnate nell’intervento;

• aggiornamento dell’APM;

• aggiornamento della baseline.

Si evidenzia che il dettaglio dei rilasci e delle fasi di progetto, da prevedere nel piano di progetto e nel relativo cronoprogramma, è specificatamente riportato nelle procedure CRZ 03 e CRZ 08, di cui all’allegato “A”. L’elenco dei rilasci attesi dovrà pertanto corrispondere a quanto previsto dalle suddette procedure nonché a quanto previsto dal Piano della Qualità Generale del Fornitore.

AdeR, a seguito delle proprie valutazioni, potrà accettare la proposta d’intervento o richiedere modifiche alla stessa relativamente al piano delle attività, al cronoprogramma, al tipo di complessità (bassa, media, alta), alla composizione del team di lavoro, alla stima dei FP o dell’impegno delle risorse professionali per le attività di assistenza. In caso di richiesta di modifiche, il Fornitore dovrà trasmettere a AdeR la proposta d’intervento aggiornata entro i successivi 3 (tre) giorni lavorativi.

AdeR si riserva di affidare al Fornitore entrambe le fasi o di affidare solo una delle due fasi cioè affidare l’esecuzione della sola prima fase (Preparazione del Progetto ed Analisi) o della sola seconda fase (Realizzazione, Preparazione all’avvio in esercizio ed Avvio in esercizio, ed eventuale attività di assistenza).

In caso di accettazione della proposta d’intervento, AdeR trasmetterà al Fornitore, il modulo di affidamento nel quale verrà, tra l’altro, indicato se l’affidamento riguarda l’intero progetto (prima fase e seconda fase del ciclo di vita del progetto) o solo le attività di Preparazione del Progetto ed Analisi (prima fase), nonché la data

di avvio delle attività. Qualora AdeR intenda invece affidare le sole attività di Realizzazione, Preparazione all’avvio in esercizio ed Avvio in esercizio, nonché le eventuali attività di assistenza (seconda fase), la stessa ne darà comunicazione al Fornitore a seguito dell’accettazione della proposta d’intervento; l’affidamento della seconda fase verrà formalizzato mediante l’invio del modulo di affidamento.

AdeR, in caso di affidamento della sola prima fase del progetto, si riserva di affidare al Fornitore, sulla base della proposta d’intervento presentata, le attività di Realizzazione, di Preparazione all’avvio in esercizio e di Avvio in esercizio (seconda fase), mediante trasmissione del modulo di affidamento nel quale verrà, tra l’altro, indicata la data di avvio delle attività, preventivamente concordata con il Fornitore.

AdeR si riserva, comunque, la facoltà di interrompere in qualsiasi momento l’esecuzione dell’intervento, riconoscendo al Fornitore il corrispettivo delle sole attività effettivamente prestate.

La presentazione della proposta d’intervento non impegna, in nessun caso, AdeR ad affidare al Fornitore l’intero progetto (prima fase e seconda fase) né una delle due fasi del ciclo di vita del progetto.

Qualora AdeR, a seguito della presentazione della proposta d’intervento, ancorché aggiornata su sua richiesta, non intenda affidare l’intervento, ne darà comunicazione al Fornitore.

A seguito della ricezione del modulo di affidamento, il Fornitore dovrà avviare le attività entro la data in esso riportata ed eseguire l’intervento nel rispetto di quanto previsto dal piano di lavoro e dal relativo cronoprogramma.

La tabella seguente riepiloga sinteticamente il processo di affidamento ed esecuzione dell’intervento previsto nelle procedure CRZ 03 o quella CRZ 08, di cui all’allegato “A”.

Milestone

Attore

Descrizione

Attivazione

AdeR

Invio della richiesta di intervento che riporta:

• Descrizione della richiesta;

• Ambiente di riferimento;

• Documentazione tecnica a corredo;

• Data prevista per l’avvio delle attività;

• Eventuali attività di assistenza richieste.

Affidamento

Esecuzione I fase

Fornitore

AdeR

Fornitore

AdeR

Trasmissione proposta di intervento (comprensiva della stima di massima del valore dell’intervento stesso, espresso in GG/P o FP, e del tipo di complessità).

Approvazione della proposta d’intervento (anche a seguito di richiesta di modifica della stessa) e trasmissione del modulo di affidamento (solo prima fase o intero progetto);

Rifiuto motivato della proposta d’intervento.

Organizzazione e presidio degli incontri tra AdeR ed il Fornitore per la raccolta e la formalizzazione delle esigenze rilevate.

Rilascio dei prodotti di fine analisi dell’intervento.

Consegna del documento di analisi di dettaglio e delle specifiche funzionali;

Rilascio della documentazione riepilogativa e di dettaglio dell’intervento.

Riscontro dei prodotti consegnati in termini di quantità e correttezza;

Approvazione dell’analisi (verbale di

accettazione).

Affidamento II fase (eventuale)

AdeR Trasmissione del modulo di affidamento della seconda fase.

Rilascio dei prodotti finali dell’intervento (codice sorgente e documentazione tecnica);

Esecuzione II fase

Fornitore

Documentazione dei casi di test eseguiti; Aggiornamento della descrizione APM;

Dimensionamento del lavoro effettivamente eseguito in FP e aggiornamento della baseline.

AdeR Riscontro dei prodotti consegnati in termini di quantità (verbale di consegna).

Validazione dei prodotti finali dell’intervento,

Accettazione AdeR

previo collaudo e verifica (verbale di accettazione).

Tabella 16 – Processo di affidamento ed esecuzione attività realizzative

9.2.2.3 Accettazione dell’intervento

Un progetto di sviluppo (attività realizzative) prevede i seguenti rilasci (intermedi e finali) oggetto di accettazione:

• documentazione tecnica dell’intervento, nonché, per gli interventi di MEV, la documentazione tecnica dell’applicativo aggiornata;

• software realizzato (codice sorgente, script database, file di configurazione, ecc.).

Ai fini dell’accettazione dell’intervento AdeR effettuerà, al termine dello stesso, il collaudo del software realizzato e la verifica della documentazione tecnica prodotta. I rilasci intermedi saranno oggetto di collaudo/verifica da parte di AdeR, secondo quanto previsto dalla metodologia di cui all’allegato “A”.

Ciascun intervento sarà accettato quando:

• il software sarà corredato da documenti di analisi funzionale e tecnica, redatti nel rispetto della metodologia di cui all’allegato “A”;

• il software realizzato avrà superato con esito positivo il collaudo di accettazione di AdeR.

L’esito delle suddette attività di collaudo e verifica risulterà da apposito verbale.

9.2.2.4 Determinazione del valore economico dell’intervento

A seguito del collaudo positivo di quanto realizzato in esecuzione dell’intervento, AdeR procederà alla consuntivazione dei dati di progetto.

Sulla base dei dati consuntivati AdeR determinerà il valore complessivo dell’intervento tenendo conto:

• del tipo di complessità (bassa, media, alta);

• del numero di FP necessari per la realizzazione del progetto stimato dal Fornitore nella proposta d’intervento approvata da AdeR;

• del numero totale di FP realizzati, comprese quindi le eventuali variazioni (Change Request – CR) richieste o approvate da AdeR;

• se l’intervento è stato eseguito per l’intero ciclo di vita del progetto o solo per

la prima fase;

• del numero di GG/P per l’esecuzione delle attività di assistenza eventualmente previste nella richiesta d’intervento e/o richieste da AdeR nel corso dell’esecuzione dell’intervento.

Ai fini della determinazione del numero totale di FP realizzati dal Fornitore alla conclusione dell’intervento, il Fornitore dovrà dare evidenza dei FP effettivamente sviluppati secondo quanto previsto dalla metodologia IPFUG 4.3.

AdeR procederà alla determinazione dei FP effettivamente rilasciati o esaminando il codice sorgente, applicando la metodologia IPFUG 4.3 partendo dalla documentazione di progetto consegnata dal Fornitore, o consultando i report ottenuti dal sistema di Application Portfolio Management.

Nel caso in cui AdeR intenda stimare il numero dei FP effettivamente rilasciati dal Fornitore a partire dal codice sorgente, sarà eseguito il calcolo del numero complessivo di LOC presenti nel codice sorgente stesso.

Le LOC saranno poi convertite in FP secondo la seguente tabella.

Linguaggio	LOC per FP
Cobol e Cobol III	107
Java	53
.NET	57
SQL	13

Tabella 17 - Conversione LOC in FP

Va precisato che la misura dei FP tramite LOC è da ritenersi indicativa. La misura esatta dei FP tramite IFPUG 4.3 potrà essere effettuata in ogni momento su richiesta di AdeR o del Fornitore e in particolare se è maggiore del 25% lo scarto tra FP dichiarati dal Fornitore stesso e quelli misurati con il suddetto metodo.

Al fine di determinare il valore economico dell’intervento nei casi di affidamento della sola prima fase (Preparazione del Progetto e Analisi), AdeR calcolerà il rapporto percentuale tra i due indici di produttività (IP), per ciclo di vita completo (prima e seconda fase) e ciclo di vita ridotto (solo prima fase), dichiarati dal Fornitore, in sede di offerta, per l’ambiente tecnologico relativo al progetto.

Il rapporto percentuale sarà calcolato con la seguente formula:

Rapporto percentuale IP = IP FP per ciclo completo / IP FP per ciclo ridotto

Esempio:

Indice di produttività FP

Rapporto IP % (a/b)

ciclo di vita completo

(a)

ciclo di vita ridotto

(b)

75%

Tabella 18 - indice di produttività FP

AdeR, determinerà la misura dei FP dell’intervento per le attività realizzative, come di seguito riportato, dove per “FP stimati” (FPs) si intende la stima iniziale indicata dal Fornitore nella proposta d’intervento compresa la stima dei FP delle eventuali variazioni (Change Request – CR) richieste o approvate da AdeR e per “FP misurati” (FPm) si intendono i FP realizzati dal Fornitore alla conclusione dell’intervento.

Caso A) Affidamento ciclo di vita completo (fase 1 e fase 2)

Qualora il numero dei FP misurati risulti inferiore di oltre il 15% del numero dei FP stimati (FPm < FPs - 15%) la misura dei FP dell’intervento sarà pari ai FP misurati;

Qualora il numero di FP misurati sia uguale al numero di FP stimati o lo scostamento, in più o in meno, sia uguale o inferiore al 15% (FPs -15% ≤ FPm ≤ FPs + 15%), la misura dei FP dell’intervento sarà pari al numero totale di FP stimati;

Qualora i FP misurati siano superiori di oltre il 15% del numero di FP stimati (FPm

> FPs +15%) la misura dei FP dell’intervento sarà pari al numero totale di FP stimati incrementati del 15%.

Lo scopo è quello di evitare che vengano effettuate stime iniziali forzatamente ed esageratamente basse, per ottenere l’affidamento della realizzazione del progetto.

Caso B) Affidamento solo prima fase (Preparazione del progetto ed Analisi)

Qualora AdeR decida di affidare al Fornitore la sola prima fase, ovvero, in caso di esecuzione della sola prima fase a seguito di interruzione dell’intervento, decisa da AdeR, la misura dei FP dell’intervento sarà calcolata partendo dal numero di FP stimati, ridotta secondo il Rapporto percentuale tra gli indici di produttività (ciclo completo e ciclo ridotto).

Si evidenzia che nel caso in cui il Fornitore abbia già realizzato la prima fase (Preparazione del Progetto ed Analisi) e sia a lui affidata successivamente anche la seconda fase (Preparazione all’avvio in esercizio ed Avvio in esercizio), il valore economico del progetto sarà determinato secondo quanto previsto per l’affidamento del ciclo di vita completo.

AdeR, infine, procederà a convertire il numero totale dei FP dell’intervento, determinato nel modo fin qui descritto, nel numero di GG/P, ottenuto dividendo i FP per l’indice di produttività (IP) del ciclo di vita completo, dichiarato dal Fornitore, in sede di offerta, nella tabella riportata nello “Schema Offerta tecnica”, per l’ambiente tecnologico relativo al progetto. Tale valore sarà sommato al numero dei GG/P per le attività di assistenza (rilascio in esercizio, formazione e assistenza post-avvio), ottenendo la misura complessiva in GG/P dell’intervento.

Il valore economico complessivo dell’intervento sarà ottenuto moltiplicando il numero complessivo dei GG/P, come precedentemente determinati, per la tariffa giornaliera offerta dal Fornitore in sede di gara per il servizio NSS relativo al tipo di complessità (bassa, media, alta) assegnata all’intervento.

9.2.2.5 Rendicontazione del servizio di NSS

Il Fornitore mensilmente dovrà produrre un report che elenca le RDM/RDS aperte e/o chiuse, con almeno le seguenti informazioni (per ciascun intervento):

• codifica interna dell’attività;

• codice RDM/RDS;

• tipo di complessità (bassa, media, alta)

• breve descrizione;

• richiedente (struttura, nome e cognome);

• assegnatario (nome e cognome);

• stato attuale;

• data di apertura;

• data consegna piano di lavoro;

• effort, strutturato in:

− Function Point e/o giornate uomo;

− giornate uomo, per gli interventi di Supporto Specialistico;

• data prevista di consegna del collaudo;

• data effettiva di consegna del collaudo;

• numero di sedute di collaudo effettuate;

• data effettiva di accettazione;

• riferimento del responsabile AdeR (nome e cognome) per il collaudo;

• note eventuali.

Nell’intestazione del report devono sempre essere riportati:

• nome del Fornitore;

• data di redazione;

• mese a cui si riferiscono i dati.

9.2.2.6 Monitoraggio e verifica SLA

Tutti gli interventi di NSS sono monitorati attraverso lo strumento OTRS. In particolare:

• tutte le richieste (RDM e RDS) sono tracciate mediante OTRS e i tempi di presentazione delle proposte d’intervento sono misurati considerando le date che saranno registrate su OTRS;

• l’inizio dell’attività di realizzazione sarà tracciato mediante lo strumento OTRS;

• la verifica tra le date pianificate e quelle effettive di consegna sarà condotta confrontando le date dell’ultima pianificazione approvata da AdeR e la data di effettivo rilascio rilevabile da OTRS;

• il numero di ricicli sulla documentazione di analisi sarà misurato sulla base delle comunicazioni di rigetto tracciate su OTRS;

• il numero di ricicli sul collaudo sarà misurato sulla base delle comunicazioni di

“pronti al collaudo” inviati dal Fornitore e tracciati su OTRS.

Relativamente agli interventi di Manutenzione Evolutiva, Sviluppo Software ed Implementazione dei sistemi, ogni fine settimana, tutto il software sviluppato, comprensivo di tutto quanto necessario alla compilazione del codice stesso, dovrà essere rilasciato in forma di sorgente a AdeR per consentire alla stessa di verificare l’avanzamento del progetto mediante la misura automatica di LOC (con l’esclusione di quanto aggiunto in automatico dall’uso di eventuali sistemi IDE).

Rispetto a tutti i rilasci effettuati ogni fine settimana, AdeR procederà ad ispezionare a campione il codice sorgente rilasciato, sia con strumenti manuali che automatici, per verificare (la lista non è esaustiva):

• che il codice sia stato correttamente commentato;

• che il codice sia tutto necessario (verifica di codice inerte);

• che il codice sia nel complesso comprensibile (correttamente innestato, ecc.);

• il numero di LOC fino a quel momento sviluppate.

Per il dettaglio delle modalità di calcolo di ciascuno di questi aspetti, si rimanda ai relativi indicatori di qualità riportati nel documento allegato “C” – Indicatori di qualità e penali.

Si sottolinea che il Fornitore dovrà dotarsi di strumenti per la misurazione di questi valori; gli stessi saranno utilizzati ad ogni rilascio del software e produrranno la documentazione a corredo dell’obiettivo. Tali strumenti dovranno essere messi a disposizione di AdeR per tutta la durata contrattuale.

A valle dell’ispezione del codice sorgente AdeR rilascerà apposito verbale che

dettaglierà l’esito della verifica effettuata.

Sulla base del report prodotto dal Fornitore, di cui al precedente paragrafo 9.2.2.5, nonché sulla base dei dati estratti da OTRS e dai verbali di collaudo e verifica positiva, AdeR verificherà il rispetto degli SLA di ciascun intervento. Il mancato rispetto degli SLA comporterà l’applicazione dei rilievi e/o penali previsti dagli indicatori di qualità riportati nel capitolo 5 dell’allegato “C”.

9.3 Modalità di esecuzione del servizio di Assistenza Specialistica

9.3.1 Modalità operative di erogazione

Il servizio di AS prevede le seguenti modalità di erogazione:

Sede delle attività	Sede Fornitore* e sede AdeR
Mezzi di comunicazione	OTRS o e-mail
Giorni di servizio**	Giorni lavorativi: i giorni dal lunedì al venerdì, ad esclusione delle festività nazionali.
Orario di servizio**	8.30 – 17.30

Tabella 19 – Modalità di erogazione del servizio di AS

Di seguito si riportano le principali fasi/attività che caratterizzano la gestione degli interventi di Assistenza Specialistica:

• modalità di affidamento;

• accettazione dell’intervento;

• determinazione del valore economico dell’intervento.

9.3.2 Modalità di affidamento

Le richieste relative alle attività di Assistenza Specialistica saranno attivate attraverso apposita richiesta di intervento di Assistenza Specialistica (“RAS”), nella quale saranno riportate, a titolo indicativo, le seguenti informazioni:

• descrizione dell’attività;

• data prevista per l’avvio delle attività;

• documentazione necessaria alla valutazione delle attività richieste;

• ambiente tecnologico di riferimento;

• milestone e relativi rilasci, ponendo particolare attenzione ai seguenti aspetti:

− perimetro tecnologico (strumenti di gestione dei servizi, architettura di riferimento, interfacce, ecc.);

− perimetro utente;

− perimetro temporale (elapsed rilascio/i);

• dimensionamento in giorni uomo e durata temporale.

* È da prevedere una presenza frequente delle risorse del Fornitore presso la sede di Roma di AdeR per le attività di analisi che coinvolgano risorse di AdeR e di altri fornitori. Tale presenza è considerata, inoltre, funzionale alle necessità di coordinamento con il referente AdeR. La presenza di risorse del Fornitore è da prevedersi in forma saltuaria o in forma continuativa per specifiche attività, secondo gli accordi scritti che verranno presi tra il Fornitore e AdeR. È possibile, sempre previo accordo scritto tra il Fornitore e AdeR, che venga richiesta la presenza di risorse del Fornitore presso le sedi periferiche di AdeR, per specifiche necessità di analisi di fattibilità e/o collaudi e/o supporto on site.

** Applicabile solo nel caso in cui è prevista l’erogazione dell’attività presso AdeR; comunque, all’occorrenza, AdeR potrà richiedere al Fornitore prestazioni da effettuare al di fuori dell’orario di servizio o in giorni festivi. Anche in questo caso, non è possibile quantificare preventivamente frequenza e durata di tali evenienze, che saranno di volta in volta specificate al Fornitore.

Secondo la tipologia di RAS, sarà definito nella richiesta che tipo di rilascio è atteso, le caratteristiche della documentazione che il Fornitore dovrà presentare e se applicabile o meno il collaudo o una semplice accettazione.

Il Fornitore, entro i tempi previsti dall’indicatore di qualità IQ4.01, o in quelli migliorativi eventualmente indicati dal Fornitore nell’offerta tecnica, trasmetterà a AdeR una proposta di intervento predisposta sulla base di quanto riportato nella richiesta d’intervento. Nella proposta d’intervento dovrà essere riportato un piano delle attività (in termini di rilasci ed obiettivi), la composizione del team di lavoro, con indicazione nominativa di ciascuna risorsa professionale ed il relativo impegno previsto.

AdeR, a seguito delle proprie valutazioni, potrà accettare la proposta d’intervento o richiedere modifiche alla stessa relativamente al piano delle attività, alla composizione del team di lavoro o alla stima dell’impegno delle risorse professionali. In caso di richiesta di modifiche, il Fornitore dovrà trasmettere a AdeR la proposta d’intervento aggiornata entro i tempi previsti in questo caso dall’indicatore di qualità IQ4.01, o in quelli migliorativi eventualmente indicati dal Fornitore nell’offerta tecnica.

In caso di accettazione, AdeR trasmetterà al Fornitore, il modulo di affidamento nel quale verrà, tra l’altro indicata, la data di avvio delle attività.

La presentazione della proposta d’intervento non impegna, in nessun caso, AdeR

ad affidare al Fornitore l’intervento.

AdeR si riserva, comunque, la facoltà di interrompere in qualsiasi momento l’esecuzione dell’intervento, riconoscendo al Fornitore il corrispettivo delle sole attività effettivamente prestate.

9.3.3 Accettazione dell’intervento

Alla conclusione dell’intervento o, nel caso siano previsti più rilasci, a ciascun rilascio, AdeR procederà a verificare la conformità tra quanto realizzato in esecuzione dell’intervento e quanto previsto dal piano delle attività accettato da AdeR nonché a verificare gli effettivi risultati ottenuti (ad es. grado di comprensione ed apprendimento dei corsi di formazione, accuratezza e completezza della documentazione prodotta, ecc.).

L’intervento s’intenderà accettato a seguito dell’esito positivo della suddetta

verifica.

L’esito dell’attività di verifica risulterà da apposito verbale.

9.3.4 Determinazione del valore economico dell’intervento

Il valore economico relativo a ciascun intervento viene determinato sulla base della stima dell’impegno previsto (misurato in GG/P) come risultante dalla proposta d’intervento approvata da AdeR, e dalla relativa tariffa giornaliera offerta dal Fornitore in sede di gara.

9.3.5 Rendicontazione del servizio di AS

Il Fornitore mensilmente dovrà produrre un report che elenca le RAS aperte e/o chiuse, con almeno le seguenti informazioni (per ciascun intervento):

• codifica interna dell’attività;

• codice RAS;

• breve descrizione;

• richiedente (struttura, nome e cognome);

• assegnatario (nome e cognome);

• stato attuale;

• data di apertura;

• data consegna piano di lavoro;

• effort espresso in GG/P;

• data prevista di consegna dell’intervento;

• data effettiva di consegna dell’intervento;

• data effettiva di accettazione;

• riferimento del responsabile AdeR (nome e cognome) per l’accettazione;

• note eventuali.

Nell’intestazione del report devono sempre essere riportati:

• nome del Fornitore;

• data di redazione;

• mese a cui si riferiscono i dati.

9.3.6 Monitoraggio e verifica SLA

Tutti gli interventi di RAS sono monitorati attraverso lo strumento OTRS. In particolare:

• le richieste RAS sono tracciate mediante OTRS e i tempi di presentazione della proposta d’intervento sono misurati considerando le date che saranno registrate in OTRS;

• l’inizio dell’attività di realizzazione sarà tracciato su OTRS;

• la verifica tra le date pianificate e quelle effettive di consegna dei rilasci previsti sarà condotta su OTRS;

• il numero di ricicli sulla documentazione di analisi (se applicabile) sarà misurato sulla base delle comunicazioni di rigetto tracciate su OTRS;

• il numero di ricicli sul collaudo (se applicabile) sarà misurato sulla base delle

comunicazioni di “pronti al collaudo” inviati dal Fornitore tracciati su OTRS.

Sulla base del report prodotto dal Fornitore, di cui al precedente paragrafo 9.3.5, nonché sulla base dei dati estratti da OTRS e dai verbali di collaudo e verifica positiva, AdeR verificherà il rispetto degli SLA di ciascun intervento. Il mancato rispetto degli SLA comporterà l’applicazione dei rilievi e/o penali previsti dagli indicatori di qualità riportati nel capitolo 5 dell’allegato “C”.

9.4 Modalità di esecuzione del servizio di Supporto Utenti (RI)

Le attività di RI saranno tracciate tramite i sistemi OTRS o Bugzilla, a seconda che per l’applicazione oggetto dell’intervento sia utilizzato l’uno o l’altro sistema, messi a disposizione da AdeR e fruibili mediante un browser web.

La chiusura di un ticket dovrà recare una sintesi del tipo di supporto fornito all’utente in modo da poter alimentare un sistema di Knowledge Management (a disposizione dell’utente stesso).

Il Servizio di RI dovrà essere eseguito dal Fornitore nel rispetto degli SLA previsti dal presente capitolato tecnico o, ove previsto, in quelli migliorativi indicati nell’offerta tecnica presentata dal Fornitore stesso in sede di gara. Qualora, ad avviso del Fornitore, per fatti a lui non imputabili (ad es. descrizione insufficiente, indisponibilità di sistemi, ecc.) si possa determinare il mancato rispetto degli SLA, come sopra definiti, il Fornitore stesso dovrà darne comunicazione a AdeR entro i tempi di presa in carico definiti dall’indicatore di qualità IQ5.01 o in quelli migliorativi eventualmente indicati dal Fornitore nell’offerta tecnica, utilizzando i sistemi suddetti. Nella comunicazione dovranno essere dettagliatamente indicate le circostanze che possono determinare l’inadempimento.

9.4.1 Modalità operative di attivazione ed erogazione

Per le attività di RI sono previste le seguenti modalità di erogazione:

Sede delle attività	Sede Fornitore*
Mezzi di comunicazione	OTRS o Bugzilla
Lingua	Italiano

* AdeR può richiedere la presenza presso le proprie sedi per specifiche attività che coinvolgano proprie risorse, risorse di Enti per i quali AdeR svolge attività istituzionali o risorse di altro fornitore.

Giorni di servizio**

Giorni lavorativi: i giorni dal lunedì al venerdì, ad esclusione delle festività nazionali.

Reperibilità il sabato mattina

Orario di servizio**

8.30 – 17.30

Tabella 20 – Modalità di erogazione del servizio di RI

La priorità dell’intervento sarà assegnata da AdeR e indicata nella segnalazione trasmessa al Fornitore in ragione della gravità del malfunzionamento riscontrato, come di seguito riportato:

Priorità

dell’intervento

Rilevanza

Informazione

Situazione

0 - Emergenza

Alta

L’utente del servizio non è in grado di lavorare su un tema di particolare rilevanza che richiede urgente

soluzione

1 – Grave

Media

L’utente del servizio non è in grado di lavorare su un tema di particolare

rilevanza che richiede soluzione

2 – Normale

Bassa

L’utente del servizio non è in grado di lavorare su un tema la cui soluzione non

è particolarmente urgente

Tabella 21 - Definizione priorità dell’intervento

Il processo di gestione dell’intervento di RI è organizzato come segue:

1. presa in carico: il Fornitore acquisisce la richiesta di informazioni e

l’assegna ad una propria risorsa;

2. risoluzione: il Fornitore fornisce la risposta attesa all’operatore AdeR.

9.4.2 Determinazione del valore economico dell’intervento

9.4.3 Rendicontazione dell’attività di RI

Il Fornitore dovrà produrre un report che elenca le richieste d’intervento aperte e/o chiuse, con almeno le seguenti informazioni (per ciascun intervento):

• codice del ticket;

• priorità del RI (A=Alta, M=Media, B=Bassa);

• breve descrizione;

• richiedente (nome e cognome);

• assegnatario (nome e cognome);

• stato attuale;

• data e ora di apertura;

• data e ora di chiusura;

• giorni di attività per la soluzione;

• note eventuali.

Nell’intestazione del report devono sempre essere riportati:

• nome del Fornitore;

• data di redazione;

• periodo a cui si riferiscono i dati.

La periodicità di produzione dei report sarà settimanale in una fase iniziale (primi 4 mesi dalla data di avvio dell’esecuzione del contratto), per poi diventare mensile. Tale periodicità potrà essere rivista in ogni momento da AdeR, a suo insindacabile giudizio.

9.5 Garanzia

Quanto realizzato (software e documentazione tecnica) in esecuzione degli interventi di Manutenzione Adeguativa, Manutenzione Evolutiva, Sviluppo Software ed Implementazione dei sistemi, entra in garanzia. Il Fornitore, relativamente a quanto realizzato, dovrà pertanto prestare i servizi di AMS di cui al precedente paragrafo 9.1.

La garanzia decorre dalla data di accettazione del software realizzato nell’ambito dei servizi di AMS e NSS (comprovata dal verbale di accettazione) e dovrà essere prestata dal Fornitore:

• fino alla scadenza del contratto per tutto il software realizzato nel primo, secondo e terzo anno;

• per 12 mesi decorrenti dalla scadenza del contratto, per tutto il software realizzato nel quarto anno.

Nel caso in cui AdeR eserciti l’opzione di rinnovo per ulteriori 12 mesi di cui al precedente paragrafo 3.7, la garanzia di cui sopra viene estesa a tutto il periodo di rinnovo e inoltre dovrà essere prestata dal Fornitore per 12 mesi decorrenti dalla scadenza per periodo di rinnovo, per tutto il software realizzato nel periodo di rinnovo.

9.6 Modalità di remunerazione

Per l’esecuzione del servizio di Onboarding APM sarà riconosciuto un corrispettivo determinato dal numero dei GG/P equivalenti all’attività effettivamente svolte dal Fornitore per l’analisi di SET e il caricamento del codice sul sistema APM, come risultanti a conclusione del verbale positivo accettato da AdeR, moltiplicato il prezzo unitario del singolo GG/P per tale servizio, offerto dal Fornitore in sede di gara.

Per l’esecuzione del servizio AMS verrà riconosciuto, a decorrere dalla conclusione del passaggio di consegne e per un periodo di 48 mesi, un canone mensile posticipato. L’importo del canone mensile sarà determinato sulla base del prezzo unitario offerto dal Fornitore in sede di gara per singolo FP, moltiplicato per 114.330 (valore della dimensione dell’asset da prendere in carico come indicato nel precedente paragrafo 3.7), fatto salvo quanto indicato al precedente paragrafo

9.1 riguardo l’eventuale riduzione del canone.

Considerando che quanto realizzato nel corso dell’appalto in esecuzione degli interventi di NSS nonché di MAA è da ritenersi in garanzia per tutta la durata contrattuale, l’incremento dei FP di ciascuna applicazione in conseguenza di detti interventi non concorrerà a determinare il canone mensile dovuto per l’esecuzione del Servizio di AMS.

Per l’esecuzione del servizio NSS verrà riconosciuto un corrispettivo mensile determinato sulla base degli interventi che, nel corso del mese di riferimento, hanno raggiunto una milestone progettuale secondo quanto riportato di seguito:

- il 30% del corrispettivo dell’intervento, all’avvio del primo ciclo di collaudo

risultante dallo stato avanzamento attività validato da AdeR;

- il 60% del corrispettivo effettivo dell’intervento, all’avvio in esercizio dell’intervento stesso risultante dallo stato avanzamento attività validato da AdeR;

- il saldo, trascorsi 30 giorni dalla data di avvio in esercizio.

L’importo del corrispettivo sarà determinato pertanto dalla sommatoria degli importi di ciascun intervento valorizzato secondo quanto previsto nel precedente paragrafo 9.2.2.4.

Per l’esecuzione del servizio AS verrà riconosciuto un corrispettivo mensile determinato sulla base degli interventi che, nel corso del mese di riferimento, sono stati conclusi con successo. L’importo del corrispettivo sarà determinato pertanto dalla sommatoria degli importi di ciascun intervento valorizzato secondo quanto previsto nel precedente paragrafo 9.3.4.

Per l’esecuzione del servizio RI verrà riconosciuto un corrispettivo mensile determinato sulla base degli interventi che, nel corso del mese di riferimento, sono stati conclusi con successo, moltiplicato per il prezzo offerto dal Fornitore per il servizio di RI.

Le condizioni, modalità e termini di pagamento dei corrispettivi sono riportate nel contratto, il cui schema fa parte integrante della documentazione di gara.

9.7 Verifica dell’esecuzione del contratto

AdeR, ai sensi dell’art. 102 e 111 del D.lgs. 50/2016, procederà ad effettuare le verifiche e i controlli occorrenti ad accertare la regolare esecuzione del contratto.

Il Direttore dell’Esecuzione di AdeR, in conformità a quanto previsto dall’art 18 del

D.M. n. 49/2018, verificherà la corretta esecuzione dei servizi affidati. In relazione alla specifica tipologia di servizio oggetto di contratto, le attività di controllo del DEC sono indirizzate alla valutazione:

• del rispetto degli standard di AdeR per i vari rilasci;

• della completezza e qualità dei contenuti dei rilasci;

• del rispetto delle milestone pianificate;

• del rispetto degli indicatori di qualità;

• delle eventuali inadempienze del Fornitore.

Il Direttore dell’Esecuzione di AdeR, anche avvalendosi di assistenti e di strutture di supporto, effettuerà le verifiche, sottese alle predette valutazioni, tra il primo giorno solare ed entro il decimo solare del mese successivo al periodo di riferimento del singolo indicatore di qualità e comunque prima dell’emissione delle fatture.

Le predette verifiche verranno effettuate servendosi delle evidenze raccolte dal DEC mediante gli strumenti resi disponibili da AdeR per il monitoraggio ed il controllo, lettere, verbali, e-mail, PEC, Contratto e di ogni altro elemento ritenuto dalla stessa utile per gli opportuni riscontri. Verrà sempre redatto un verbale in contraddittorio con il Fornitore.

AdeR, tra il primo giorno solare ed entro il decimo giorno solare del mese successivo al periodo di riferimento precedente alla rilevazione, comunica al Fornitore - a mezzo e-mail - le risultanze delle verifiche effettuate. In tale sede può richiedere chiarimenti e/o documentazione integrativa e/o revisione del documento stesso assegnando al Fornitore 5 giorni lavorativi per i necessari riscontri e l’invio del rendiconto definitivo.

Il Fornitore, nel tempo massimo di 5 giorni lavorativi successivi, potrà presentare i propri giustificativi in forma scritta, evidenziando ogni circostanza e documentazione utile a supporto.

Il DEC, qualora sia riscontrata una mancata, ritardata o non conforme esecuzione rispetto alle prescrizioni tecniche impartite nel presente Capitolato e nei relativi allegati, segnala al RUP le inadempienze riscontrate, anche al fine dell’applicazione delle penali stabilite di cui al successivo paragrafo “Penali” del presente Capitolato, ovvero della risoluzione dello stesso per inadempimento.

Il RUP provvede, quindi, a formulare le relative contestazioni al Fornitore a mezzo PEC all’indirizzo indicato nel contratto, assegnando a quest’ultimo un termine per la presentazione delle proprie controdeduzioni e per rimuovere gli inadempimenti riscontrati non inferiore a 15 giorni naturali e consecutivi, salvo i casi d’urgenza in cui il predetto termine non potrà essere inferiore a 10 giorni naturali e consecutivi.

Ad ogni modo, nei termini definiti dal RUP e indicati nella segnalazione, il Fornitore dovrà trasmettere a AdeR le proprie eventuali controdeduzioni; trascorso tale termine, la stazione appaltante adotterà i provvedimenti conseguenti.

AdeR, conclusi i controlli positivamente, in assenza di contestazioni o, comunque, all’esito del contraddittorio sopradescritto - comunica il numero di Regolare Esecuzione che il Fornitore dovrà riportare nella fattura elettronica.

9.7.1 Riserve

Alla conclusione delle predette attività il Fornitore avrà la facoltà di presentare le proprie eventuali contestazioni, procedendo alla formulazione delle relative riserve. Qualora l'esplicitazione e la quantificazione delle riserve non sia possibile al momento della formulazione delle stesse, il Fornitore avrà l’onere di esplicitare per iscritto e via PEC, a pena di decadenza, nel termine di 15 (quindici) giorni naturali e consecutivi, dall’emissione di detto certificato, le cifre di compenso cui crede di aver diritto e le ragioni di ciascuna domanda. Il DEC, nei successivi quindici giorni, comunicherà al Fornitore le sue motivate deduzioni.

Nel caso in cui il Fornitore non abbia esplicitato le proprie eventuali riserve nel modo e nel termine sopra indicati, i controlli tecnico contabili effettuati dal DEC s’intendono definitivamente accertati e il Fornitore decade dal diritto di far valere, in qualunque termine e modo, le riserve o le domande che ad essi si riferiscono.

Le riserve non espressamente confermate sul certificato di ultimazione delle prestazioni (Regolare Esecuzione Finale) si intendono abbandonate.

9.8 Gestione delle risorse professionali

9.8.1 Il pool di risorse per AdeR

Le figure professionali, di cui al paragrafo 8, determinano di fatto un pool di risorse

dedicato all’esecuzione dei servizi oggetto del presente capitolato.

Il Fornitore dovrà garantire la stabilità del pool di risorse professionali proposte evitando, nel corso della durata del contratto, l’allocazione delle suddette risorse ad altre attività/commesse.

Il rispetto di detto obbligo verrà misurato con l’indicatore di qualità IQ1.06, riportato nell’allegato “C”.

Nell’ambito delle risorse professionali costituenti il pool, il Fornitore definirà il team di lavoro impiegato nell’esecuzione dei servizi AMS nonché il team di lavoro relativo al singolo intervento di NSS che verrà, di volta in volta, affidato al Fornitore stesso, sulla base delle effettive esigenze di AdeR.

Il Fornitore dovrà garantire, salvi i casi di sostituzione autorizzati, che ciascuna risorsa professionale del team di lavoro sia impegnata sino al completamento del/degli intervento/i al/ai quale/quali la stessa sia stata assegnata.

Il Fornitore s’impegna comunque ad integrare, nel rispetto di quanto previsto dal successivo paragrafo 9.8.3, il numero di risorse professionali del pool qualora ciò sia determinato da impreviste specifiche esigenze di AdeR (picchi di lavoro).

9.8.2 Sostituzione risorsa professionale del pool

Qualora il Fornitore si trovi nella necessità di sostituire nell’esecuzione di uno o più interventi una risorsa professionale del pool con una nuova risorsa, lo stesso dovrà procedere come segue:

• con preavviso di almeno 20 giorni solari (salvo eccezioni connesse alla sostituzione per cause di forza maggiore o giustificato motivo) il Fornitore dovrà inviare una richiesta scritta, dalla quale dovrà risultare:

a) il nominativo della risorsa da sostituire e l’intervento o gli interventi a

cui la stessa è assegnata;

b) la motivazione della sostituzione;

c) il CV della risorsa subentrante, redatto nel rispetto di quanto previsto dal paragrafo 7.4;

• entro 10 giorni solari AdeR valuterà la richiesta di sostituzione e, qualora i CV siano sostanzialmente paragonabili, procederà ad autorizzare la sostituzione tramite comunicazione scritta.

In caso di sostituzione di una risorsa professionale in possesso di requisiti migliorativi, di cui al precedente paragrafo Errore. L'origine riferimento non è stata trovata., la nuova risorsa professionale dovrà essere in possesso dei medesimi requisiti migliorativi della risorsa che sostituisce o comunque il Fornitore dovrà garantire che nel pool di risorse, come ricostituito a seguito della sostituzione, siano presenti i medesimi requisiti migliorativi offerti in sede di gara.

Non è previsto in alcun caso il silenzio assenso, la sostituzione potrà considerarsi autorizzata solo nel caso di riscontro per iscritto di AdeR.

Resta inteso che il Fornitore dovrà garantire il passaggio delle conoscenze tra la risorsa uscente e quella entrante per un tempo adeguato e senza maggior onere per AdeR.

AdeR potrà richiedere eventuali colloqui di approfondimento tecnico con la risorsa subentrante, nei quali esaminare, tra le altre cose, l’avvenuto passaggio di consegne.

In nessun caso:

• il pool delle risorse potrà scendere al di sotto del numero minimo previsto nel precedente paragrafo 8 o al di sotto del numero superiore di risorse professionali eventualmente offerto dal Fornitore in fase di gara;

• il Fornitore potrà utilizzare risorse diverse da quelle del pool, eventualmente integrato ai sensi del paragrafo 9.8.3.

Si evidenzia che, qualora il Fornitore, nel corso di esecuzione del contratto, volesse subappaltare delle attività (sempre che si sia riservato la facoltà in fase di presentazione dell’offerta), nel richiedere a AdeR l’autorizzazione al subappalto, nel rispetto di quanto previsto dalla legge, dovranno essere presentati i CV delle risorse del subappaltatore che dovranno essere in possesso dei requisiti minimi previsti al precedente paragrafo 8.2, ovvero quelli migliorativi eventualmente offerti in sede di gara, per il relativo profilo professionale, per svolgere le attività che si intende subappaltare.

L’esecuzione delle attività da parte delle risorse del subappaltatore potrà avere inizio solo a seguito dell’autorizzazione al subappalto da parte di AdeR, fermo restando l’obbligo del Fornitore di assicurare la prosecuzione e continuità delle prestazioni contrattuali nel rispetto degli SLA previsti dal presente capitolato tecnico.

AdeR potrà in ogni momento chiedere la sostituzione di una risorsa professionale del team di lavoro qualora la stessa sia ritenuta non adeguata alla perfetta esecuzione del/degli intervento/i al/ai quale/quali è assegnata.

In questo caso il Fornitore provvederà alla sostituzione della risorsa professionale con altra appartenente al pool entro 3 (tre) giorni dalla ricezione della richiesta motivata di AdeR.

Qualora le risorse professionali del pool risultino tutte impegnate nell’esecuzione degli interventi, ai fini della sostituzione richiesta da AdeR, il Fornitore sarà comunque obbligato a far subentrare nel team di lavoro una nuova risorsa nel rispetto di quanto previsto dal paragrafo successivo.

Il rispetto dei tempi previsti e la qualità delle risorse proposte, è misurata attraverso gli indicatori di qualità IQ1.02, IQ1.03, IQ1.06 e IQ1.07 riportati nell’allegato “C”.

9.8.3 Integrazione del pool di risorse

Nell’ipotesi in cui tutte le risorse del team di lavoro siano impegnate nello svolgimento di attività a loro affidate e, per impreviste specifiche esigenze, AdeR abbia necessità di eseguire ulteriori interventi senza poter ridefinire la priorità di quelli già affidati (picco di lavoro), AdeR stessa ne darà comunicazione al Fornitore.

Nella suddetta comunicazione verrà indicata, per ciascuna figura professionale, la stima del numero di risorse professionali necessarie e del relativo tempo stimato in cui le stesse verranno impiegate nell’esecuzione degli interventi.

Entro i successivi 5 (cinque) giorni dalla suddetta comunicazione, il Fornitore dovrà provvedere a trasmettere i curricula vitae delle risorse professionali dallo stesso ritenute necessarie all’esecuzione dei servizi con attestazione del rapporto intrattenuto con le stesse.

Le risorse professionali proposte dovranno essere almeno in possesso dei requisiti minimi previsti, per il relativo profilo professionale, dal precedente paragrafo 8.2.

Il Fornitore renderà effettivamente disponibile la risorsa proposta entro 5 (cinque)

giorni dall’approvazione da parte di AdeR del relativo CV.

Per l’integrazione delle nuove risorse professionali nel pool, troverà applicazione quanto previsto dal precedente paragrafo 8.6.2.

Il rispetto dei tempi previsti e la qualità delle risorse proposte, è misurata attraverso

l’indicatore di qualità IQ1.05 e IQ1.07, riportati nell’allegato “C”.

9.8.4 Aggiornamento professionale

Qualora AdeR decidesse di utilizzare nuove release dei prodotti facenti parte degli ambienti di riferimento, di cui al precedente paragrafo 4.3, o decidesse di adottare nuovi sistemi a supporto dell’esecuzione dei servizi oggetto del presente capitolato, ne darà comunicazione preventiva al Fornitore che dovrà provvedere tempestivamente, a propria cura e spese, all’aggiornamento professionale delle proprie risorse, al fine di garantire il corretto svolgimento dei servizi stessi.

Fermo restando quanto sopra, il Fornitore sarà tenuto a garantire l’aggiornamento delle risorse professionali impiegate nell’esecuzione dei servizi, che comunque si rendesse necessario, ai fini dell’esecuzione degli stessi nel rispetto della migliore pratica di mercato.

9.9 SLA (Service Level Agreement)

Nel presente paragrafo sono riportati tutti gli SLA che il Fornitore dovrà rispettare

nell’esecuzione dei servizi oggetto dell’appalto.

In particolare, nelle tabelle riportate nei successivi paragrafi sono indicati gli SLA relativi alla qualità generale dell’appalto e gli SLA relativi alla qualità dei diversi servizi (AMS, NSS, AS e RI), nonché, per ciascuno di essi, l’indicazione dei relativi “Indicatori di qualità” di cui all’allegato “C”.

Nelle tabelle sono, altresì, indicati quali SLA il Concorrente potrà migliorare in sede di offerta.

9.9.1 Indicatori di qualità generale dell’appalto

Indicatori di qualità		SLA (valore limite)	Miglio rabile
Consegna del Piano della Qualità Generale	IQ1.01	• 20 giorni lavorativi dalla stipula del contratto • 5 giorni lavorativi dalla richiesta di modifica	No
Sostituzione del personale su richiesta di AdeR	IQ1.02	3 giorni lavorativi	No
Professionalità delle risorse del pool	IQ1.03	0 (zero) sostituzioni	No
Utilizzo risorse non autorizzato	IQ1.04	0 (zero) risorse	No

Indicatori di qualità		SLA (valore limite)	Miglio rabile
Integrazione del pool di risorse	IQ1.05	5 giorni lavorativi per la presentazione del CV e 5 giorni lavorativi per l’effettiva disponibilità della risorsa	No
Sostituzioni di risorse su richiesta del Fornitore	IQ1.06	3 risorse anno	No
Numero di verifiche AdeR per subentro e/o sostituzione di una risorsa	IQ1.07	1 verifica	No
Rilievi sulla qualità generale dell’appalto	IQ1.08	2 rilievi a trimestre	No

Tabella 22: Indicatori qualità generale dell’appalto

0 - Emergenza	4 ore lavorative
1 - Grave	8 ore lavorative
2 - Normale	16 ore lavorative

0 - Emergenza	8 ore lavorative
1 - Grave	16 ore lavorative
2 - Normale	32 ore lavorative

9.9.2 Indicatori di qualità del servizio AMS

Indicatore di qualità		SLA (valore limite)			Miglio rabile
Tempi di presa in carico segnalazioni di MAC (accettazione/rifiuto)	IQ2.01				Sì
Tempi di risoluzione segnalazioni di MAC (chiusura o chiusura con difetto o chiusura senza necessità di correzione del software)	IQ2.02				Sì
Casi recidivi	IQ2.03	1 caso al mese			No
Ticket rifiutato in modo errato	IQ2.04	0 (zero) ticket			No
Consegna piano attività su richiesta MAA	IQ2.05				No
			Consegna in risposta a RDA	5 giorni lavorativi
			Consegna in caso di richiesta di modifica	3 giorni lavorativi
Tempi di consegna su ricicli	IQ2.06	0 (zero) giorni lavorativi			No
Rilievi sul servizio di AMS	IQ2.07	2 rilievi mese			No

Tabella 23: Indicatori qualità del servizio AMS

Si ricorda che, come già specificato nel paragrafo 3.3, gli interventi di MAC potranno determinare rilasci di fix correttive oppure risolversi con delle spiegazioni o altre tipologie di soluzione. L’indicatore IQ2.02 si applica anche ai casi in cui è stata aperta una MAC ma non è necessario un rilascio software per sanarla.

9.9.3 Indicatori di qualità del servizio NSS

Indicatori di qualità		SLA (valore limite)			Miglio rabile
Consegna proposta d’intervento di Manutenzione Evolutiva	IQ3.01
			Consegna in risposta a RDM	5 giorni lavorativi		No
			Consegna in caso di richiesta di modifica	3 giorni lavorativi

Consegna proposta d’intervento di Sviluppo Software, di Implementazione dei sistemi o di Supporto Specialistico	IQ3.02
			Consegna in risposta a RDS	15 giorni lavorativi		No
			Consegna in caso di richiesta di modifica	3 giorni lavorativi

Rispetto della pianificazione dell’intervento	IQ3.03	0 (zero) giorni lavorativi di ritardo			No
Tempi di consegna su ricicli	IQ3.04	0 (zero) giorni lavorativi di ritardo			No
Casi di test negativi in collaudo	IQ3.05	0 (zero) casi di test negativi			No
Rispetto degli standard documentali	IQ3.06	0 (zero) documenti fuori standard			No
Densità dei commenti del software sviluppato	IQ3.07	≥ 5% per linguaggio Java "Applicazioni web Java" (J2EE) /.NET ≥ 25% per i linguaggi Cobol/ Visual basic/C/C++			No
Linee di codice inerte	IQ3.08	0 (zero) linee di codice inerte			No
Essential Complexity	IQ3.09	complessità essenziale del singolo modulo ≤ 3			No
Violazioni dell'Incapsulamento da parte di una Classe	IQ3.10	0 (zero) violazioni			No
Dipendenza di una Classe dai suoi Child	IQ3.11	nessuna dipendenza			No
Metodi implementati in una Classe	IQ3.12	≤ 14 metodi			No

Indicatori di qualità		SLA (valore limite)	Miglio rabile
Complessità Ciclomatica di una Classe	IQ3.13	≤ 70	No
Grado di Coesione dei Metodi di una Classe	IQ3.14	≥ 75%	No
Complessità Ciclomatica (sviluppi non object oriented)	IQ3.15	≤ 5	No
Rilievi sull’intervento	IQ3.16	2 rilievi per intervento	No
Qualità generale del servizio NSS	IQ3.17	97%	No

Tabella 24: Indicatori qualità del servizio NSS

9.9.4 Indicatori di qualità del servizio AS

Indicatori di qualità		SLA (valore limite)			Miglio rabile
Consegna proposta di intervento di AS	IQ4.01
			Consegna in risposta a RAS	5 giorni lavorativi		Sì
			Consegna in caso di richiesta di modifica	3 giorni lavorativi

Rispetto della pianificazione dell’intervento	IQ4.02	0 (zero) giorni lavorativi di ritardo			No
Tempi di consegna su ricicli	IQ4.03	0 (zero) giorni lavorativi di ritardo			No
Casi di test negativi in collaudo	IQ4.04	0 (zero) casi di test negativi (quando applicabile)			No
Rispetto degli standard documentali	IQ4.05	0 (zero) documenti fuori standard			No
Rilievi sull’intervento	IQ4.06	2 rilievi per intervento			No
Qualità generale del servizio AS	IQ4.07	97%			No

Tabella 25: Indicatori qualità del servizio AS

0 - Emergenza	8 ore lavorative
1 - Grave	16 ore lavorative
2 - Normale	32 ore lavorative

9.9.5 Indicatori di qualità del servizio RI

Indicatore di qualità		SLA (valore limite)			Miglio rabile
Tempi di presa in carico richiesta RI (accettazione/rifiuto)	IQ5.01				Sì
			0 - Emergenza	4 ore lavorative
			1 - Grave	8 ore lavorative
			2 - Normale	16 ore lavorative
Tempi di risoluzione di richiesta RI	IQ5.02				Sì
Casi recidivi	IQ5.03	1 caso al mese			No
Ticket rifiutati in modo errato	IQ5.04	0 (zero) ticket			No
Rilievi sull’intervento	IQ5.05	2 rilievi per intervento			No
Qualità generale del servizio RI	IQ5.06	97%			No

Tabella 26: Indicatori qualità del servizio RI

9.10 Penali e rilievi

Si rimanda all’allegato “C” – “Indicatori di qualità e penali” per l’individuazione degli indici il cui mancato rispetto determina l’applicazione di una penale, e la quantificazione della stessa, e quelli che danno luogo ad uno o più rilievi.

Si precisa che i rilievi consistono in comunicazioni formali al Fornitore che non prevedono di per sé l’applicazione di penali, ma costituiscono avvertimento sugli aspetti critici nello svolgimento dei servizi. La sommatoria di rilievi in un arco di tempo determina l’applicazione di una penale, secondo quanto previsto da ciascun indicatore di qualità associati al limite dei rilievi, di cui all’allegato ”C”.

AdeR formalizzerà il rilievo attraverso una nota di rilievo; mediante una nota di rilievo potranno essere notificati al Fornitore uno o più rilievi anche relativi a diversi indicatori di qualità.

Nel caso in cui il Fornitore in sede di offerta proponga, ove previsto, miglioramenti degli SLA (valore limite), siano essi legati ad indicatori di qualità generale dell’appalto che di qualità degli interventi resi, tali nuovi valori saranno assunti come nuovo profilo della qualità. L’applicazione della penale non esonera il Fornitore

dall’esecuzione dell’attività che ha dato origine alla penale e/o alla rimozione dell’inadempimento.

Si rinvia allo schema di contratto per la relativa disciplina.

9.11 Proposte a supporto del monitoraggio dei servizi (AMS, NSS, AS e RI)

Per i servizi di AMS, NSS, AS e RI la misurazione degli SLA sarà effettuata, come detto, sulla base dei dati estratti dal database dei sistemi OTRS, Bugzilla, dal software che verrà adottato per il conteggio delle LOC, conteggio dei FP, nonché, sulla base dei verbali di collaudo e verifica.

Il Concorrente può comunque proporre delle soluzioni software integrative per la misurazione degli SLA. La proposizione di dette soluzioni non determinerà l’attribuzione di un punteggio.

AdeR intende, da una parte garantire l’aspetto di gestione formale delle segnalazioni tracciando le informazioni sui propri sistemi (OTRS e Bugzilla), ma contestualmente richiede al concorrente di proporre i propri strumenti di gestione e monitoraggio che si affiancheranno a quelli messi a disposizione da AdeR.

Perché la soluzione software possa essere adottata da AdeR dovrà soddisfare le seguenti condizioni minime:

• essere installata presso AdeR, non sono considerate percorribili soluzioni applicative fisicamente installate presso il Fornitore e accessibili da AdeR via web;

• il database deve essere ben documentato e consentire di estrarre facilmente i dati per eventuale migrazione su altro sistema;

• non determinare alcun maggior onere per AdeR (costi di licenze, di manutenzione, di supporto all’installazione e quant’altro);

• essere compatibile con il sistema hardware e software di AdeR, in particolare di poter essere gestito su macchine virtuali;

• essere già stato impiegato dal Fornitore in altri contesti. Sono preferite soluzioni basate su open source.

Il Fornitore dovrà provvedere, a propria cura e spese, all’installazione e configurazione della soluzione software proposta, fornire il necessario supporto all’avvio nonché garantirne la manutenzione per tutta la durata contrattuale.

Resta inteso che AdeR non è in alcun modo obbligata ad adottare o mantenere nel corso del contratto la soluzione software proposta dal Fornitore.

10 Allegati

Sono allegati al presente Capitolato Tecnico i seguenti documenti che ne costituiscono parte integrante e sostanziale.

Allegato A - Metodologia gestione progetti-servizi (che comprende n. 7 documenti) Allegato B - Templates (che comprende n. 12 documenti)

Allegato C - Indicatori di Qualità e Penali

Allegato D - SGQ Sistema della qualità aziendale (che comprende n. 5 documenti)

Allegato E - SGSI Sistema Gestione Sicurezza Informazioni (che comprende n. 5 documenti)

Allegato F - Descrizione del sistema SET (che comprende n. 25 documenti)

Allegato G - n. 93 Manuali utente suddivisi in 8 file (da “Allegato G1” a “Allegato G8”)

Document Metadata

Table of Contents

Capitolato tecnico

Document Metadata