Procedura aperta per l’acquisizione di servizi di manutenzione e di sviluppo per i sistemi informativi a supporto della riscossione, suddivisa in 2 Lotti

(Lotto 1: CIG 6520069326 – Lotto 2: CIG 65200779BE)

Equitalia SpA

Allegato 1A – Capitolato Tecnico Lotto 1

Equitalia SpA

Gara per servizi di manutenzione e di sviluppo per i sistemi informativi a supporto della riscossione suddivisa in due lotti Lotto 1

Capitolato tecnico

CIG: 6520069326

Sommario

Sommario 2

Acronimi 3

1 Introduzione 4

2 Consistenza della fornitura 5

2.1 Attività richieste nella fornitura 5

2.2 Servizio di AMS 5

2.3 Servizio di NSS 7

2.4 Dimensionamento della fornitura 7

2.5 Passaggio di consegne 10

3 Il contesto applicativo 12

3.1 Architettura di massima per le applicazioni in Equitalia 12

3.2 Le applicazioni oggetto dei servizi 13

3.3 Ambienti 33

3.4 Sistemi e tecnologie di rilievo per le attività oggetto di gara 34

4 Ciclo di vita del Software e gestione dei progetti 38

5 Gestione dei picchi di lavoro 40

6 Logistica 41

7 Figure professionali richieste per l’esecuzione dei servizi 42

7.1 Dimensionamento del pool di risorse e composizione media per ciascun servizio 42

7.2 Profili delle figure professionali 44

7.3 Requisiti migliorativi 53

7.4 Verifica requisiti delle risorse professionali 53

8 Governo della fornitura 55

8.1 Modalità di fornitura del servizio di AMS 55

8.2 Modalità di fornitura del servizio di NSS 60

8.3 Garanzia 72

8.4 Modalità di remunerazione 72

8.5 Verifica avanzamento lavori 73

8.6 Gestione delle risorse professionali 74

8.7 Produttività 76

8.8 SLA (Service Level Agreement) 77

8.9 Penali e rilievi 80

8.10 Proposte a supporto del monitoraggio dei servizi di AMS e di NSS 81

9 Allegati 83

Acronimi

• EQ Equitalia

• GG/P Giorni Persona (usato come sinonimo di Full Time Equivalent)

• FP Punti Funzione

• SLA Service Level Agreement

• SW Software

• HW Hardware

• AMS Servizio di Application Management

• NSS Servizio di Nuovi Sviluppi

• MAC Manutenzione Correttiva

• MAA Manutenzione Adeguativa

• MEV Manutenzione Evolutiva

• RDM Richiesta di Manutenzione Evolutiva

• RDA Richiesta di Manutenzione Adeguativa

• RDS Richiesta di Sviluppo Software o di Supporto Specialistico

1 Introduzione

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, Equitalia S.p.A., di seguito “EQ” sta attuando, a partire dal 2008, 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 EQ 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, EQ intende affidare all’aggiudicatario del lotto 1 i servizi informatici di sviluppo, manutenzione e supporto specialistico dettagliatamente indicati nel presente capitolato.

Relativamente a detti 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 Consistenza della fornitura

2.1 Attività richieste nella fornitura

La fornitura oggetto di affidamento è relativa ai seguenti servizi:

− Servizio di Application Management (AMS)

− Servizio di Nuovi Sviluppi (NSS)

Nella tabella seguente sono riepilogate le attività rientranti in ciascuno di detti servizi, descritte in dettaglio nei paragrafi successivi, nonché la modalità di remunerazione di ciascuna attività.

Servizio

Attività

Remunerazione

Servizio di Application Management (AMS)

• Manutenzione Correttiva (MAC)

• Manutenzione Adeguativa (MAA)

Canone mensile

Servizio di Nuovi Sviluppi (NSS)

• Manutenzione Evolutiva (MEV)

• Sviluppo Software

A corpo, misurata in FP

• Supporto Specialistico

A corpo, misurata in

giorni persona

Tabella 1 - elenco dei servizi oggetto della fornitura

L’aggiudicatario del lotto 1, 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 EQ, riportato nell’allegato A, del Sistema Gestione Sicurezza Informazioni (SGSI) di EQ, 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 7.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.

2.2 Servizio di AMS

Il servizio di AMS riguarda un sottoinsieme delle applicazioni di EQ, dettagliatamente indicate nel capitolo 3, e si compone di due attività:

• 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à:

• 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, etc..) 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 dall’esigenza di:

• 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).

2.3 Servizio di NSS

Il servizio di NSS, comprende le attività di realizzazione di software negli ambienti applicativi descritti al capitolo 3, nonché le attività di Supporto Specialistico.

In particolare, 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

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

• Supporto Specialistico

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

Il Supporto Specialistico comprende principalmente le seguenti attività:

− formazione

− redazione di documentazione tecnica

− supporto a redazione di studi

− redazione di presentazioni

2.4 Dimensionamento della fornitura

Il dimensionamento della fornitura è stato calcolato per un periodo di 48 (quarantotto) mesi, fatto salvo 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 2.5. 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 EQ.

La tabella seguente riporta le applicazioni per le quali il Fornitore dovrà prestare il servizio di AMS (MAC e MAA) per tutta la durata contrattuale del servizio pari a 48 mesi, il dimensionamento in FP

ed il prezzo unitario a FP del canone mensile posto a base di gara, non superabile dal Concorrente in sede di offerta.

Applicazioni	Dimensionamento Applicazione (FP)	Prezzo unitario FP mensile (base di gara)
Provvedimenti Web Minuta di Ruolo Web 4.x e Monitoraggio Processi (MOP) Minuta di Ruolo – Controlli in Frontiera (CIF) Minuta di Ruolo – Upload Minute 350 (GFXML) Invio dati: Minute di Ruolo Invio dati: Provvedimenti Download generalizzato Ruoli (back end e batch) Servizi di ricezione dati Applicazioni GIA Web Gestionale Ruoli CICS Cartelle di pagamento (CR60 e Back End) Tabelle ancillari - SIFE Entrate patrimoniali Applicazioni Ruoli e Provvedimenti CICS su Web Piattaforma d’interscambio e relativi verticali Notifica Messo Fascicolo del contribuente Infrastruttura Portale e GEU - CSE Business Process Management (BPM) - Ruoli	455	€ 0,80
	1.350 € 0,80
	901	€ 0,80
	811	€ 0,80
	926	€ 0,80
	516	€ 0,80
	396	€ 0,80
	94	€ 0,80
	927	€ 0,80
	475	€ 0,80
	321	€ 0,80
	1.034 € 0,80
	932	€ 0,80
	536	€ 0,80
	1.187 € 0,80
	1.839	€ 0,80
	1.399 € 0,80
	404	€ 0,80
	1.651	€ 0,80
	1.016 € 0,80

Tabella 2 - servizi MAC e MAA

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 2.5.

EQ, in base alle proprie effettive esigenze, si riserva di ridurre la durata del servizio di AMS previsto per ciascuna applicazione, dandone comunicazione al Fornitore con un preavviso di 20

giorni lavorativi dalla data di effettiva cessazione. In caso di cessazione anticipata del servizio di AMS per una o più applicazioni, il relativo importo residuo incrementerà il sub-corrispettivo massimo per i servizi di NSS, fermo restando l’importo massimo complessivo del contratto.

La tabella seguente riporta per ciascuna tipologia di applicazioni, il numero dei FP che si stima verranno sviluppati nell’esecuzione dei servizi di NSS (attività realizzative) durante tutto il periodo contrattuale ed il prezzo unitario a FP, posto a base di gara, non superabile dal Concorrente in sede di offerta.

Tipologie di Applicazioni

Stima dimensionamento (FP)

Prezzo unitario (base di gara)

Applicazioni J2EE ad alta intensità elaborativa

Applicazioni J2EE ad alta interazione utente

Applicazioni COBOL ad alta intensità elaborativa

11.313

€ 116,96

14.884

€ 116,96

6.840

€ 116,96

Tabella 3 - servizi di NSS

La tabella seguente riporta per ciascuna figura professionale, le giornate persona che si stima verranno prestate per l’attività di Supporto Specialistico, nell’arco temporale di della durata contrattuale, e la relativa tariffa giornaliera, posta a base di gara, non superabile dal Concorrente in sede di offerta.

Figure professionali	Stima gg/p	Tariffa giornaliera (base di gara)
P5 - Capo Progetto	94	€ 460
P4 - Anal. Funz. / Team Leader e/o Analista di Processo	247	€ 368
P3 - Anal. Prog Senior	315	€ 276
P2 - Anal. Prog Junior	677	€ 221
P7 - Business Process Re-engineer	189	€ 552
P6 - Esperto FP	84	€ 414
S2 - Data Base Administrator	103	€ 414
S1 - Sistemista Junior	103	€ 239

Tabella 4 - Attività di Supporto Specialistico

2.5 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 della fornitura, consiste nell’acquisizione delle specifiche conoscenze relative alle peculiarità delle attività e delle applicazioni di EQ ed è totalmente a carico del Fornitore. Tale attività dovrà essere completata entro 20 (venti) giorni lavorativi, a decorrere dalla data di stipula del contratto.

• Attività di passaggio finale delle conoscenze

Nei 20 (venti) giorni lavorativi 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 EQ, con particolare riferimento a quelle maturate nel periodo di erogazione dei servizi oggetto della fornitura, senza alcun ulteriore onere per EQ. Durante il periodo di passaggio finale delle conoscenze, il Fornitore sarà comunque tenuto all’erogazione dei servizi previsti (AMS e NSS) nel rispetto delle obbligazioni contrattualmente assunte.

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:

o Funzionalità applicative e contenuti specifici

o Contesto di utilizzo ed eventuali personalizzazioni software in uso

o Stato delle richieste di manutenzione

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

o Consegna dei riferimenti relativi al patrimonio applicativo realizzato o adeguato

o Consegna della documentazione (sia quella relativa al progetto di implementazione sia quella generata/modificata durante il periodo di manutenzione)

o Consegna di tutto il materiale relativo ai corsi di formazione e addestramento effettuati, alle note di riunione, a documenti specifici redatti durante la fornitura.

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

Al termine di ciascuna sessione di lavoro, il Fornitore segnalerà ad EQ le applicazioni che a suo avviso sono carenti della documentazione tecnica necessaria per garantire la corretta esecuzione del servizio di AMS.

Accertata da parte di EQ l’intervenuta acquisizione delle conoscenze da parte del Fornitore, EQ stessa redigerà il verbale di avvio dell’esecuzione del contratto. Il verbale, tra l’altro, riporterà le applicazioni che ad avviso di EQ saranno oggetto di specifici interventi di Supporto Specialistico finalizzati alla produzione della documentazione tecnica necessaria.

In caso di mancato passaggio delle conoscenze, per fatto imputabile al Fornitore, entro i 20 giorni lavorativi dalla stipula del contratto, EQ avrà facoltà di procedere alla risoluzione del contratto stesso.

3 Il contesto applicativo

3.1 Architettura di massima per le applicazioni in Equitalia

La figura che segue mostra l’organizzazione di massima dei servizi prestati da EQ agli utenti istituzionali.

Nel modello attuale, le funzioni on – line sono ospitate in sistemi dipartimentali (con sistemi operativi AIX e Linux).

In generale le applicazioni on – line acquisiscono informazioni interagendo con dati su Oracle e su DB2 (agganciato tramite DB2 Connect) e le registrano su entrambi questi database (Oracle e DB2 di front – end), anche se il ruolo di Oracle come database completamente dedicato all’on-line sta crescendo (a scapito di quello DB2 front – end).

I dati sono poi processati da vari batch che muovono le informazioni dal DB2 front – end al DB2 back end, tra le 18:00 del giorno prima e le 8:00 del giorno dopo.

Mainframe

Sistema web

Utente

Internet

DB2

Oracle

Front End

DB2

Back End

Le applicazioni on – line esistenti, la cui manutenzione è affidata al Fornitore nell’ambito dei servizi di AMS e di NSS, sono scritte in Java (J2EE) e operano sugli application server JBoss (in minima parte) e IBM WAS (in migrazione a versione superiore).

La lettura e la scrittura dei dati presenti in Oracle è fatta mediante driver JDBC di Oracle. L’interazione con il database DB2 su zOS è mediata da DB2 Connect.

Le applicazioni su mainframe sono sia in ambiente CICS che procedure batch eseguite tramite JCL da uno schedulatore applicativo.

Le applicazioni CICS (Cobol e DB2) leggono e scrivo sui database DB2 di front end.

Le applicazioni batch acquisiscono informazioni dalle tabelle su DB2 del front end e provvedono ad elaborarle per andare poi a consolidarle sul DB2 di back end. In queste operazioni sono prodotti file da scambiare con il mondo esterno

Un’altra modalità che scatena l’esecuzione di programmi batch su mainframe è la ricezione di file dal mondo esterno. I programmi batch processano i file ricevuti e salvano le informazioni sui database DB2.

Completa il modello architetturale di figura il sistema di document composition e di stampa massiva, che non è stato inserito in quanto non rientra nel gruppo di funzioni per le quali si richiedono i servizi descritti nel presente capitolato tecnico.

3.2 Le applicazioni oggetto dei servizi

Nella tabella di seguito riportata sono indicate le applicazioni attualmente in uso presso EQ relativamente alle quali ed alle loro evoluzioni, EQ stessa richiederà al Fornitore i servizi di AMS e NSS.

Utente finale Applicazione Caratteristiche sintetiche Servizi richiesti
Servizi per gli enti	Provvedimenti Web	Java, Linux	J2EE,	Oracle,	DB2,	AMS, NSS
	Minuta di Ruolo Web 4.x e Monitoraggio Processi (MOP)	Java, Linux	J2EE,	Oracle,	DB2,	AMS, NSS
	Minuta di Ruolo – Controlli in Frontiera (CIF)	Java, Linux	J2EE,	Oracle,	DB2,	AMS, NSS
	Minuta di Ruolo – Upload Minute 350 (GFXML)	Java, Linux	J2EE,	Oracle,	DB2,	AMS, NSS
	Invio dati: Minute di Ruolo	Java, Linux	J2EE,	Oracle,	DB2,	AMS, NSS
	Invio dati: Java, J2EE, Oracle, Linux AMS, NSS

	Provvedimenti
	Download	Java, J2EE, Oracle, DB2,	AMS, NSS
	generalizzato	Linux
	Ruoli e Provvedimenti	Cobol, DB2, zOS	AMS, NSS
	CICS su Web
	Servizi di ricezione	Java, J2EE, Oracle, DB2,	AMS, NSS
	dati	Linux
	Applicazioni GIA Web	Java, J2EE, Oracle, DB2, Linux	AMS, NSS
	Gestionale Ruoli CICS, Cobol, DB2, zOS AMS, NSS CICS
	Cartelle di pagamento (CR60 e Back End)	Cobol, DB2, zOS	AMS, NSS
	Tabelle ancillari -	Java, J2EE, Oracle, DB2,	AMS, NSS
	SIFE	Linux
Servizi per gli Agenti della Riscossione	Entrate patrimoniali	Cobol, DB2, zOS	AMS, NSS
Servizi per gli Agenti della Riscossione	Applicazioni Ruoli e Provvedimenti CICS	Java, J2EE, Oracle, DB2, Linux, Cobol, DB2, zOS, IB;	AMS, NSS
	su Web	HATS
	Piattaforma
	d’interscambio e	Java, J2EE, Oracle, Linux	AMS, NSS
	relativi verticali
	Gestione Messo	Java, J2EE, Oracle, Linux	AMS, NSS
	Fascicolo del	Java, J2EE, Oracle, Linux,	AMS, NSS
	contribuente	WSO2
	Infrastruttura Portale e	Java, J2EE, Oracle, DB2,	AMS, NSS
	GEU - CSE	Linux
Servizi Trasversali e di supporto	Business Process Management (BPM) - Ruoli	Java, J2EE, Oracle, Linux, IBM Business Process Manager.	AMS, NSS

Tabella 5 - applicazioni oggetto dei servizi

3.2.1 Provvedimenti Web

Descrizione

Provvedimenti Web è accessibile via web dal portale di EQ e consente ad un ente di inserire e gestire, su apposite form web, dei provvedimenti (sospensione, sgravio, rateazione, le varie revoche, ecc.), tramite le seguenti funzioni:

• creazione guidata di un provvedimento;

• gestione dei soggetti e dei carichi iscritti nei ruoli di competenza

• visibilità sui ruoli pregressi

• descrizione delle motivazioni di un provvedimento

• gestione e personalizzazione delle lettere da inviare ai contribuenti

• visibilità dello stato di avanzamento di un provvedimento.

Il sistema esegue in automatico, prima di prendere in carico il provvedimento, tutti quei controlli necessari (capienza, coesistenza, ecc.) perché il provvedimento possa poi essere correttamente processato nelle fasi successive del processo.

I provvedimenti correttamente registrati e acquisiti dal sistema , sono poi propagati su mainframe per essere processati e resi operativi tramite le loro trasmissione agli AdR.

Architettura

L’autenticazione è gestita dal portale di EQ tramite una procedura di SSO custom denominata EQS_SSO (anch’essa scritta in Java e fondata su un LDAP di IBM).

L’applicazione è sviluppata in Java, usando il paradigma J2EE e il pattern MVC.

Il database è DB2 su mainframe, acceduto tramite DBLink di IBM. L’acceso ai dati è possibile tramite la gestione di pool di connessioni affidate al WAS.

Il processo dei provvedimenti su mainframe è fuori obiettivo di questa fornitura.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: DB2 v 7 acceduto mediante DB Link.

• Sistema operativo Linux Centos.

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.2 Minuta di Ruolo Web 4.x

Descrizione

Il servizio Minuta di Ruolo Web 4.x è accessibile via web dal portale di EQ e consente all’ente di inserire una minuta di ruolo attraverso opportune e guidate interfacce web.

Il servizio è stato pensato per gli enti che non sono già dotati di un proprio sistema informatico con il quale gestiscono la messa a ruolo e quindi hanno la necessità di inserire una minuta attraverso uno strumento di “data entry” assistito per comunicare a EQ la minuta di ruolo.

Le principali funzioni che questo servizio consente sono le seguenti:

• Inserimento della minuta di ruolo attraverso interfacce web guidate

• controllo formale e di consistenza dei dati inseriti mediante opportune regole

• report statistico sui controlli effettuati da EQ

• consultazione delle spedizioni, ovvero la consultazione dello storico delle minute inviate e il loro stato di lavorazione.

Architettura

L’autenticazione è gestita dal portale di EQ tramite una procedura di SSO custom denominata EQS_SSO (anch’essa scritta in Java e fondata su un LDAP di IBM).

L’applicazione è sviluppata in Java, usando il paradigma J2EE e il pattern MVC.

Il database è Oracle 11g RAC. L’acceso ai dati è possibile tramite la gestione di pool di connessioni affidate al WAS.

Il programma esegue una validazione formale e di merito della minuta tramite una seconda applicazione denominata CIF (Controlli in Frontiera), la cui manutenzione è oggetto di questa gara e sarà descritta nel seguito.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g ,

• Sistema operativo Linux Centos,

• Interfaccia con mainframe: SPAZIO Primeur

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.3 Minuta di Ruolo – Monitoraggio Processi

Descrizione

Il servizio Minuta di Ruolo - Monitoraggio Processi è accessibile via web dal portale di EQ e consente all’ente di verificare lo stato di lavorazione di una minuta da questo precedentemente inviata (attraverso un qualunque altro applicativo che gestisce le minute di ruolo).

Il sistema consente di selezionare quali situazioni si intendono analizzare e quindi, sulla base dei filtri impostati, presenta lo stato di lavorazione delle minute che soddisfano gli stati immessi.

L’utente può anche scaricare dal sito eventuali file informativi di dettaglio associati alle lavorazioni sottomesse.

Architettura

L’autenticazione è gestita dal portale di EQ tramite una procedura di SSO custom denominata EQS_SSO (anch’essa scritta in Java e fondata su un LDAP di IBM).

L’applicazione è sviluppata in Java, usando il paradigma J2EE e il pattern MVC.

Il database è Oracle 11g RAC. L’acceso ai dati è possibile tramite la gestione di pool di connessioni affidate al WAS.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g ,

• Sistema operativo Linux Centos.

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.4 Controlli in Frontiera (CIF)

Descrizione

Il sistema rappresenta il canale di validazione delle minute di ruolo inviate dagli Enti ad EQ attraverso i sistemi di inserimento delle forniture (Nuova Minuta di Ruolo, Invio Dati, Upload 350).

I CIF realizzano un insieme di servizi che provvedono alla validazione formale e di merito dei contenuti delle minute di ruolo. Gli esiti della validazione formale vengono resi fruibili agli utenti in modo sincrono sul frontend dei sistemi di invio sopracitati; gli esiti delle validazioni di

merito vengono elaborati in modalità asincrona e resi fruibili agli utenti mediante il sistema di monitoraggio delle minute (MOP).

Architettura

Il sistema è sviluppato sulla piattaforma J2EE ed espone i propri servizi mediante Web Service.

Il database è Oracle 11 g RAC. L'acceso ai dati è possibile tramite la gestione di pool di connessioni affidate al WAS.

Una volta acquisiti i file e verificata la validità degli stessi, il sistema provvede al trasferimento dei file su mainframe tramite SPAZIO di Primeur, per essere processato dalle procedure che producono i ruoli di EQ.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE, XML

• Application Server: IBM WAS

• Database: Oracle RAC 11g

• Sistema operativo: Linux Centos

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.5 Upload 350 (GFXML)

Descrizione

Il sistema rappresenta il canale mediante il quale le ditte di registrazione (DRD), provvedono all’invio ad EQ delle minute di ruolo originariamente in formato cartaceo.

Il sistema consente l’invio delle forniture mediante l’upload di un file in formato XML, la gestione ed il monitoraggio dello stato di avanzamento della lavorazione delle stesse.

Gli utenti sono le ditte di registrazione (DRD) e gli utenti interni a EQ.

Architettura

L'autenticazione è gestita dal portale di EQ tramite una procedura di SSO custom denominata EQS-SSO (anch'essa scritta in Java e fondata su un LDAP di IBM).

L'applicazione è sviluppata sulla piattaforma J2EE ed utilizza il framework AJAX GWT. Il database è Oracle 11 g RAC. L'acceso ai dati è possibile tramite la gestione di pool di connessioni affidate al WAS.

Il programma esegue una validazione formale e di merito della minuta tramite una seconda applicazione denominata CIF (Controlli in Frontiera).

Tecnologia e linguaggi

• Linguaggio: Java, J2EE, XML

• Application Server: IBM WAS

• Database: Oracle RAC 11g

• Sistema operativo: Linux Centos

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.6 Invio dati: Minute di Xxxxx

Descrizione

Il servizio Invio dati (Upload minute di ruolo) è accessibile via web dal portale di EQ e consente all’ente l’invio del file della minuta di ruolo, in uno dei formati standard di EQ

Il servizio è stato pensato per gli enti che sono già dotati di un proprio sistema informatico con il quale gestiscono la messa a ruolo e quindi hanno la necessità di comunicare a EQ il file prodotto finale dalle loro elaborazioni.

Le principali funzioni che questo servizio consente sono le seguenti:

• trasmissione guidata del l’elenco debitori con verifica on – line dell’esito della trasmissione verso EQ

• controllo formale della struttura dei dati

• report statistico sui controlli effettuati da EQ

• consultazione delle spedizioni, ovvero la consultazione dello storico delle minute inviate e il loro stato di lavorazione.

I formati file supportati da EQ in questo servizio sono di due tipi

• Formato R.L. 290

• Formato R.L. 450

• Formato XML 350 (ad uso interno di EQ)

Ne i primi due casi il sistema gestisce file “piatti” dalla lunghezza del singolo record del tracciato pari rispettivamente a 290 e 450 byte, con struttura definita.

Il terzo caso si riferisce ad una applicazione che gestisce upload di file in formato XML.

Architettura

L’autenticazione è gestita dal portale di EQ tramite una procedura di SSO custom denominata EQS_SSO (anch’essa scritta in Java e fondata su un LDAP di IBM).

L’applicazione è sviluppata in Java, usando il paradigma J2EE e il pattern MVC.

Il database è Oracle 11g RAC. L’acceso ai dati è possibile tramite la gestione di pool di connessioni affidate al WAS.

Anche in questo caso il programma esegue una validazione formale e di merito della minuta tramite una seconda applicazione denominata CIF (Controlli in Frontiera).

Una volta acquisito il file e verificato che il formato è corretto, il file è trasferito su mainframe tramite SPAZIO di Primeur, per essere processato dalle procedure che producono i ruoli di EQ.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g ,

• Sistema operativo Linux Centos,

• Interfaccia con mainframe: SPAZIO Primeur

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.7 Invio dati: Provvedimenti

Descrizione

Il servizio Invio dati (Upload Provvedimenti) è accessibile via web dal portale di EQ e consente all’ente l’invio di varie tipologie di file contenenti provvedimenti, utilizzando formati standard di EQ

Anche in questo caso, il servizio è stato pensato per gli enti che sono già dotati di un proprio sistema informatico con il quale gestiscono la messa a ruolo e quindi hanno la necessità di comunicare a EQ il file prodotto finale dalle loro elaborazioni.

Le principali funzioni che questo servizio consente sono le seguenti:

• trasmissione guidata di provvedimenti con verifica on – line dell’esito della trasmissione verso EQ

• controllo formale della struttura dei dati

• report statistico sui controlli effettuati da EQ

• consultazione delle spedizioni, ovvero la consultazione dello storico dei provvedimenti inviati e il loro stato di lavorazione.

I formati file supportati da EQ in questo servizio sono vari.

Architettura

L’autenticazione è gestita dal portale di EQ tramite una procedura di SSO custom denominata EQS_SSO (anch’essa scritta in Java e fondata su un LDAP di IBM).

L’applicazione è sviluppata in Java, usando il paradigma J2EE e il pattern MVC.

Il database è Oracle 11g RAC. L’acceso ai dati è possibile tramite la gestione di pool di connessioni affidate al WAS.

Una volta acquisito il file e verificato che il formato è corretto, il file è trasferito su mainframe tramite SPAZIO di Primeur, per essere processato dalle procedure.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g ,

• Sistema operativo Linux Centos,

• Interfaccia con mainframe: SPAZIO Primeur

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.8 Download generalizzato

Descrizione

Il servizio Ricezione Dati: Download Generalizzato, mette a disposizione dell’ente un sistema unico di download dei file di propria pertinenza. Grazie ad un’interfaccia web, l’utente può ricercare e scaricare un file appartenente ad una delle seguenti tipologie:

• RUOLI

• MINUTA CON DATI CONTABILI E ANAGRAFICI

• STATO DELLA RISCOSSIONE

• COMUNICAZIONI INESIGIBILITA’

• VERSAMENTI ICI.

Architettura

L’autenticazione è gestita tramite il portale EQ con i meccanismi già descritti in precedenza.

La pubblicazione dei file sulle code dell’ente vengono gestite con la nuova versione di Spazio (Primeur). L’archiviazione dei file su cartuccia viene gestito mediante EJB.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS.

• Database: Oracle RAC 11g e DB2 v 7 su zOS.

• Sistema operativo Linux Centos.

• Spazio (Primeur)

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.9 Servizi di ricezione dati

Descrizione

Si tratta di un servizio generale accessibile via web dal portale di EQ e mediante il quale gli utenti possono inviare sul Portale di EQ file di diverso tipo.

Architettura

L’architettura del servizio è centrata su SPAZIO di Primeur.

Una volta che l’utente si è autenticato tramite EQS_SSO, di fatto l’applicazione incapsula servizi di SPAZIO per la ricezione del file.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g e /o DB2 V7 su zOS interfacciato via DBLink di IBM

• Sistema operativo Linux Centos,

• Interfaccia con mainframe: SPAZIO Primeur

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.10 GIA Web

Descrizione

L’applicativo GIA Web per la gestione delle convenzioni è stato migrato su tecnologie compatibili con WAS6 e le funzionalità di profilazione degli utenti sono state spostate da un software dedicato a GPU. Sarà possibile inoltre, a valle di tale migrazione, mantenere ed evolvere il servizio.

Gli utenti sono interni EQ.

Architettura

L’autenticazione è gestita tramite il portale EQ e la profilazione attraverso il servizio GPU.

L’applicazione consiste di un layer di frontend, dedicato all’interfaccia con l’utente, e uno di back end contenente le logiche di business.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS.

• Database: DB2 v 7.

• Sistema operativo Linux Centos,

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.11 Ruoli (Gestionale Ruoli CICS e procedure batch di back end)

Descrizione

In ottemperanza alle disposizioni legislative in materia di riscossione (cfr. D.L. 321/99), EQ ha predisposto una procedura informatica che consente di trasformare una minuta inviata dagli enti non telematici in un ruolo telematico al fine di garantire l’interscambio delle informazioni con gli Agenti della riscossione.

Le minute di ruolo possono essere trasmesse dagli enti non telematici ad EQ nei seguenti modi:

• Documento cartaceo

• Supporto informatico.

EQ riceve le minute dagli enti non telematici (Comuni, Provincie, Consorzi, ecc…) e, attraverso un processo elaborativo, provvede alla formazione/informatizzazione dei ruoli;

i ruoli non telematici così formati vengono trasmessi all’ente per l’apposizione del visto di esecutorietà. I flussi dei ruoli telematici risultanti dalla modalità espresse nel punto precedente, vengono trasmessi agli Agenti della riscossione competenti per territorio.

Nell’ambito del processo di formazione ruoli, l’Agente della riscossione è chiamato a comunicare ad EQ gli aggiornamenti in merito ai rapporti convenzionali con gli enti, ed a fornire i timbri dei ruoli telematici presi in carico nel proprio sistema informativo per la riscossione.

Per la gestione del processo di iscrizione a ruolo è stata realizzata una applicazione c.d. Gestionale Ruoli che consente sia di rilasciare le fasi produttive sia di monitorare l’attraversamento del processo.

Architettura

L’operatività TP per le funzioni del gestionale ruoli avviene attraverso mappe CICS.

Il gestionale ruoli attiva poi delle procedure batch di back end che eseguono controlli e operazioni sui flussi telematici.

La piattaforma software di trasmissione per lo scambio dei flussi informatici su mainframe è basata su IBM Tivoli Netview Ftp.

Le fasi elaborative dei dati avvengono su mainframe utilizzando tabelle DB2.

Tecnologia/Linguaggi

• Piattaforma Hardware: Mainframe IBM Z9

• Sistema operativo Z/OS versione 1.8

• TP: CICS

• Database: DB2 versione 8

• Change Management: Endevor

• Linguaggio di programmazione: Cobol3

Tipologia interventi

Sono previsti interventi di AMS e di NSS.

3.2.12 Cartelle di pagamento

Descrizione

Le Cartelle di Pagamento sono i documenti che gli Agenti della riscossione predispongono e notificano ai contribuenti per invitarli a pagare le somme iscritte a ruolo entro sessanta giorni dalla loro notifica.

Per consentire questo adempimento normativo, EQ ha predisposto una procedura informatica che permette all’Agente della riscossione di gestire l’intero processo di cartellazione: dalla predisposizione delle Cartelle di Pagamento alla stampa e spedizione delle stesse ai contribuenti.

In particolare, la procedura consente di:

1. Effettuare simulazioni sulle attività di cartellazione;

2. Visualizzare, a conclusione delle simulazioni effettuate, i prospetti sintetici ed analitici delle Cartelle da stampare, utili per le attività di pianificazione;

3. Confermare l’esecuzione e dare l’avvio alla fase di cartellazione effettiva. Tale fase genera: la predisposizione di flussi informatici per la riscossione, lo spool di stampa da inviare alle tipografie per la stampa effettiva e la postalizzazione delle Cartelle di Pagamento;

4. Prenotare la ristampa delle Cartelle di Pagamento selezionate.

L’Agente ha a disposizione il servizio “Cartelle” (procedura CICS) con il quale può effettuare le seguenti attività:

• Simulazioni delle cartellazioni, definendo di volta in volta i relativi parametri;

• Validare l’esito della simulazione;

• Ristampare le Cartelle di Pagamento, anche dopo l’elaborazione e la stampa effettuata da EQ.

Architettura

L’operatività TP per le funzioni di richiesta, visualizzazione e conferma delle esecuzioni avviene attraverso mappe CICS.

La piattaforma software di trasmissione dei flussi informatici per la riscossione da mainframe è basata su IBM Tivoli Netview Ftp.

Le fasi elaborative dei dati e di ottenimento degli spool di stampa avviene su mainframe utilizzando tabelle DB2.

Le fasi di elaborazione degli spool di stampa avviene su piattaforma CSF Designer utilizzando l’architettura AFP per l’ottenimento degli spool tipografici (le attività con CSF Designer non sono comunque oggetto di fornitura).

Tecnologia/Linguaggi

• Piattaforma Hardware: Mainframe IBM Z9

• Sistema operativo Z/OS versione 1.8

• TP: Cics

• Database: DB2 versione 8

• Change Management: Endevor

• Linguaggio di programmazione: Cobol3

• Document Composition: CSF Designer, CSF Designer Web

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

EQ si riserva inoltre la possibilità di attivare su questo tema specifico l’attività di studio dei programmi COBOL costituenti la soluzione cartelle di pagamento e la loro eventuale re- ingegnerizzazione in modo da rendere il programma più efficiente e manutenibile.

A fronte di una migrazione di tutto l’ambiente di produzione massiva di documenti per la riscossione da CSF Designer a EMC Documentum, EQ potrà incaricare il Fornitore di migrare la stampa delle cartelle dall’attuale sistema alla nuova piattaforma documentale.

3.2.13 Tabelle ancillari: SIFE - Web

Descrizione

Si tratta di un’applicazione accessibile via web dal portale di EQ che ha come utente personale interno di EQ (in particolare la gestione tabelle), che ha come obiettivo l’efficientemento delle attività di Produzione di EQ.

L’applicazione gestisce le tabelle ancillari necessarie per tutte le elaborazioni di EQ (dai ruoli alla gestione dei provvedimenti).

Si tratta di un’applicazione articolata in varie form per l’acquisizione dei dati da utente, regole con le quali propagare i dati in ingresso su un database Oracle, regole e procedure Java per propagare i dati da Oracle al database DB2 su zOS per rendere disponibili i dati ancillari alle procedure batch Cobol.

Architettura

L’autenticazione è gestita dal portale di EQ tramite una procedura di SSO custom denominata EQS_SSO (anch’essa scritta in Java e fondata su un LDAP di IBM).

L’applicazione è sviluppata in Java, usando AJAX, il paradigma J2EE e il pattern MVC.

Le regole con cui sono validati i dati e con i quali i dati sono estratti e propagati verso il DB2 sono opportunamente codificate su un motore a regole open source.

Le applicazioni usano entrambi i database, ovvero sia DB2 su mainframe, acceduto tramite DBLink di IBM, sia Oracle RAC 11g. L’acceso ai dati è possibile tramite la gestione di pool di connessioni affidate al WAS.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g e/o DB2 V 7 per zOS

• Sistema operativo Linux Centos,

• Sistema di trasporto dati: SPAZIO Primeur

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.14 Entrate patrimoniali

Descrizione

Il servizio prevede l’elaborazione, la stampa tipografica, l’imbustamento e la postalizzazione di Avvisi/Fatture, di Solleciti e di Note di Credito relativi alle Entrate Patrimoniali che l’Agente della riscossione invia ai contribuenti per conto degli enti convenzionati.

Il servizio prevede la predisposizione e l’invio da parte degli Agenti della Riscossione di flussi telematici secondo le caratteristiche tecniche, predisposte per garantire gli aspetti semantici e sintattici delle informazioni trasmesse.

L’erogazione del servizio di Elaborazione e Stampa dei documenti si articola nelle seguenti fasi principali:

1. Ricezione, controllo ed elaborazione dei dati di input;

2. Elaborazione degli spool di stampa e dei Provini di Stampa;

3. Stampa dei documenti e verifica della qualità tipografica;

4. Postalizzazione dei plichi documentali.

Architettura

La piattaforma software di trasmissione dei flussi dati in input su mainframe è basata su IBM Tivoli Netview Ftp.

Le elaborazioni di controllo dei flussi dei dati e di elaborazione degli spool di stampa avvengono su mainframe utilizzando tabelle DB2.

Tecnologia/Linguaggi

• Piattaforma Hardware: Mainframe IBM Z9

• Sistema operativo Z/OS versione 1.8

• TP: CICS

• Database: DB2 versione 8

• Change Management: Endevor

• Linguaggio di programmazione: Cobol3

• Document Composition: CSF Designer , CSF Designer Web

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.15 Xxxxx e Provvedimenti CICS su Web

Descrizione

Alcune transazioni CICS (mainframe), necessarie per l’inserimento di minute di ruolo e provvedimenti, sono state incapsulate con opportune interfacce per essere esposte su web.

Gli utenti sono limitati e tutti interni a EQ, in altri termini questi servizi non sono aperti ad Enti o AdE.

Architettura

L’autenticazione è gestita tramite il portale EQ con i meccanismi già descritti in precedenza.

Le transazioni CICS sono state incapsulate utilizzando la tecnica di “screen screaping” mediante il software HATS di IBM.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS, IBM HATS.

• Database: Oracle RAC 11g e DB2 v 7 su zOS.

• Sistema operativo Linux Centos,

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.16 Piattaforma d’interscambio

Descrizione

La piattaforma d’interscambio (PdI) è un sistema software che consente di scambiare file (ricevere ed inviare) tra diversi soggetti con cui deve interagire EQ più in generale e strutture esterne quali service di stampa e/o postalizzazione, gestione di richieste varie.

In generale la PdI consente di conoscere quando una certa richiesta è stata inoltrata ad un soggetto esterno e quando è stata assolta, consentendo inoltre di verificare se gli SLA sono stati soddisfatti.

Un file di richiesta in realtà contiene n richieste atomiche. La PdI verifica la singola richiesta

atomica e produce lo SLA per ciascuna di queste.

Correda la PdI un insieme di applicazioni detti di “Amministrazione” o “tools” che consento agli amministratori della piattaforma di gestire in modo puntuale eventuali anomalie ed errori dovute ai software che utilizzarono la piattaforma (che possono produrre ad esempio file non corretti e non gestibili da PdI), come anche errori stessi di PdI.

Su PdI sono poi innestate delle applicazioni verticali specializzate nella gestione di determinati scambi di dati. Queste applicazioni al momento sono:

• Rendicontazione Raccomandate con Ricevuta di Ritorno (RAR)

• Rendicontazione ICI (ICI)

• Pagamenti Reti Amiche (PRA)

• Tools di Amministrazione (PDI)

Rendicontazione Raccomandate con Ricevuta di Ritorno è un verticale su PdI che consente di:

1. ricevere dalle tipografie quali documenti sono pronti alla spedizione via raccomandata

2. concentrare le richieste di spedizione di raccomandate in EQ e di inviare la distinta a Poste

3. conoscere l’effettiva spedizione delle raccomandate

4. conoscere l’effettiva consegna della raccomandata da parte di Poste al destinatario

5. misurare lo SLA con cui la consegna è avvenuta

6. segnalare a Poste quali spedizioni hanno superato la soglia dello SLA

7. ricevere da poste le immagini delle relate di notifica (delle raccomandate).

Rendicontazione ICI è un verticale su PdI che consente di:

1. ricevere da Poste i file anacontabili relativi ai versamenti effettuati su ICI

2. verificare questi file e inviare le parti di competenza ai vari AdR ed Enti.

Pagamento Reti Amiche è un verticale su PdI che consente di:

1. acquisire informazioni sui pagamenti eseguiti dai contribuenti sulle reti amiche (come ad esempio on – line via web, ecc.)

2. gestire le rendicontazioni verso gli AdR, di fatto si comporta da smistatore di flussi di dati telematici.

Tools di Amministrazione è un verticale su PdI che consente di:

1. visualizzare e monitorare tutti flussi scambiati dalla piattaforma

2. scaricare e caricare flussi sulla piattaforma

Architettura

PdI è stata realizzata in Java usando il paradigma J2EE.

Gli strumenti di amministrazione hanno una interfaccia utente e utilizzano il pattern MVC. Dal punto di vista architetturale, la PdI è un oggetto composito:

1. le funzioni di trasporto sono assolte da SPAZIO di Primeur;

2. le funzioni di trasformazione dei dati sono al momento fornite da software Java appositamente sviluppato

3. la gestione dei processi è svolta da software dedicato ed appositamente sviluppato

4. tutti i dati sono salvati su Oracle.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g

• Sistema operativo Linux Centos,

• Sistema di trasporto dati: SPAZIO Primeur

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.17 Notifica Messo

Descrizione

Il Servizio di Notifica Messo consente la gestione dello scambio di informazioni (a doppio senso) tra gli AdR e il soggetto preposto alla “notifica via messo” delle comunicazioni esattoriali (ad esempio cartelle, avvisi di fermo, ecc.). Il sistema riceve le informazioni circa le comunicazioni che il soggetto preposto alla notifica via messo dovrà recapitare e registra gli avanzamenti della notifica grazie alle notizie che il soggetto preposto trasmette indietro. Il sistema è stato costruito in modo da poter gestire un gran volume di immagini di documenti relativi alle notifiche via messo e successivamente archiviati otticamente su un sistema EMC Documentum. Il sistema EMC Documentum che gestisce l’archiviazione ottica dei documenti e il loro recupero per essere esposti agli utenti non è oggetto di manutenzione in questa gara.

Il servizio di gestione della Notifica Messo supporta l’Agente della riscossione nel processo di notifica degli atti e dei documenti esattoriali, consentendo di:

• Affidare una commessa al Messo, sia dei documenti elaborati e stampati dalla Divisione Servizi ICT sia di quelli già nella disponibilità dell’Agente della riscossione (commessa manuale) e gestire la Presa in carico dell’Affido da parte del Fornitore;

• Richiedere l’interruzione del processo di notifica per uno o più documenti affidati;

• Gestire le richieste di supporto provenienti dal Messo volte al reperimento di certificazioni delle anagrafiche;

• Gestire la rendicontazione (parziale e finale) delle attività di notifica;

• Gestire le immagini provenienti dalle attività di notifica;

Sul tema della notifica si innestano delle applicazioni verticali specializzate:

• Portale Immagini (PWP)

• Portale Gestione Messo (GME)

Portale Immagini è un verticale che consente di:

1. ricercare, visualizzare e scaricare le immagini delle relate di notifica tramite Raccomandata AR;

2. effettuare una richiesta del cartaceo originale delle relate della notifica con Raccomandata AR presso il Centro di Gestione Documentale dell’Agenzia delle Entrate;

3. ricercare, visualizzare e scaricare tutte le immagini dell’attività di notifica tramite Messo.

Portale Gestione Messo è un verticale che consente di:

1. caricare i file sulla piattaforma di scambio flussi;

2. ricercare, visualizzare e scaricare i flussi caricati e/o ricevuti sulla piattaforma;

3. perfezionare l’Affido al Messo notificatore;

4. monitorare lo scambio flussi e visualizzare eventuali errori;

5. effettuare riepiloghi ed export delle attività.

Architettura

Il Servizio è stato realizzato in Java usando il paradigma J2EE.

Dal punto di vista architetturale, è un oggetto composito:

1. le funzioni di trasporto sono assolte da SPAZIO di Primeur;

2. le funzioni di gestione dei documenti sono svolte da Documentum

3. le funzioni di trasformazione dei dati sono al momento fornite da software Java appositamente sviluppato

4. la gestione dei processi è svolta da software dedicato ed appositamente sviluppato

5. tutti i dati sono salvati su Oracle.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g

• Sistema operativo Linux Centos,

• Sistema di trasporto dati: SPAZIO Primeur

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.18 Fascicolo del contribuente

Descrizione

Si tratta di un’applicazione accessibile via web dal portale di Equitalia che ha come utente personale interno di Equitalia (in particolare gli operatori del secondo livello del Customer Service), che ha come obiettivo l’efficientamento delle attività di risposta alle istanze dei contribuenti facilitando la raccolta dei dati relativi alla “storia” esattoriale del contribuente stesso.

L’applicazione si basa sull’infrastruttura SOA di Equitalia ed interagisce con alcuni dei sistemi legacy (mainframe e dipartimentali) per raccogliere i dati del contribuente. Tali dati

sono memorizzati in un “fascicolo” documentale che, alla chiusura del “case” del contribuente, viene storicizzato.

L’applicazione può essere invocata sia dal sistema di CRM (Siebel) tramite web service, che dalla Intranet Equitalia tramite interfaccia web.

Architettura

L’autenticazione è gestita dal portale di Equitalia tramite una procedura di SSO custom denominata EAI (anch’essa scritta in Java e fondata su un LDAP di IBM).

L’applicazione è sviluppata in Java, usando AJAX, il paradigma J2EE, ed è puramente di “presentation”. Tutta la logica è sviluppata sotto forma di processi sul BPS dell’infrastruttura SOA che sono invocati tramite web-services. Tali processi interagiscono con i servizi esposti dalle applicazioni di back-end per la raccolta dei dati.

La storicizzazione del “fascicolo documentale” avviene sul sistema documentale di Equitalia basato su Documentum.

L’acceso ai dati è possibile tramite la gestione di pool di connessioni affidate al WAS.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Infrastruttura SOA: WSO2

• Application Server: IBM WAS

• Database: Oracle RAC 11g e/o DB2 V 7 per zOS

• Sistema operativo Linux Centos,

• Sistema di trasporto dati: SPAZIO Primeur

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.19 Infrastruttura Portale e GEU CSE

Descrizione

L’infrastruttura Portale e GEU – CSE identifica un gruppo di funzionalità di servizio per la gestione del sito e degli accessi. Tra queste, quella più rilevante è la funzione GEU – CSE.

La funzione GEU – CSE consente a EQ, agli AdR e agli Enti di gestire gli accessi e le autenticazioni a tutte le altre funzioni del portale.

La funzione implementa il seguente processo:

1. L’AdR inizializza funzioni fruibili via portale (coma ad esempio i servizi di invio dati);

2. L’Ente completa la registrazione tramite funzioni dedicate

3. EQ provvede a rendere le inizializzazioni dell’AdR e le registrazioni dell’Ente operative tramite l’esecuzione di procedure batch java e PL – SQL che di fatto propagano le informazioni in tutti i sistemi di EQ.

4. L’Ente, una volta operativo, può gestire in autonomia ulteriori username sui servizi su cui è abilitato.

Architettura

Il sistema si compone di varie form fruibili via web, implementate usando J2EE (JSP e servlet), con programmi batch eseguiti su richiesta da parte dell’operatore o schedulati.

I programmi batch sono in generale in Java e PL – SQL.

Il database è Oracle RAC 11 g per quanto riguarda la gestione del front end, i dati (come nel caso dei provvedimenti) sono scritti anche sul DB2 del mainframe, acceduto tramite DBLink di IBM. L’acceso ai dati è possibile tramite la gestione di pool di connessioni affidate al WAS.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g e DB2 v 7 su zOS.

• Sistema operativo Linux Centos,

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.20 Business Process Management (BPM) - Ruoli

Descrizione

L’attività di composizione dei ruoli, descritta nel paragrafo precedente, è stata oggetto di un’operazione di efficientamento che si è tradotta nella realizzazione del processo di produzione dei ruoli, dalla minuta all’invio del ruolo all’AdR e chiusura del processo stesso per ricezione del timbro dell’AdR.

Tutto il processo è stato creato e sviluppato utilizzando la suite Web Sphere BPM di IBM.

Alcune porzioni di attività sono state automatizzate, costruendo opportuni adattatori verso le interfacce CICS tramite HATS, come anche la realizzazione di query sul DB2 che impostano i valori nel processo, adattatori in grado di applicare regole e quindi di stabilire se il processo sta fluendo regolarmente o proporre eventuali gestioni straordinarie di situazioni specifiche.

Il sistema così realizzato è in grado di monitorare i tempi di attraversamento della lavorazione e attivare allarmi in caso di superamento delle soglie prefissate (SLA del processo).

Architettura

Il processo BPM di fatto guida tutte le operazioni sui Ruoli, interfacciando le funzioni originarie del “Gestionale Ruoli – CICS” in ambiente mainframe mediante HATS o IBM CTG.

Il processo BPM inoltre accede a informazioni sui database (Oracle su ambiente open e DB2 su mainframe) mediante opportune query.

Dove è necessario, il processo accede anche a sysout (opportunamente trasferiti su file) applicando parser del testo e quindi regole per dedurre la correttezza e il completamento di determinate fasi.

Tutte le chiamate del processo a elementi esterni sono effettuate attraverso l’invocazione di Web Service. A titolo di esempio, l’interfaccia HATS verso una transazione CICS di fatto è un web service invocabile dal processo stesso.

Tecnologia/Linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS, IBM HATS

• BPM: Websphere BPM IBM

• Database: Oracle RAC 11g e DB2 su mainframe

• Sistema operativo Linux Centos

• Interfaccia con mainframe: IBM CTG, CICS

Tipologia interventi

Sono previsti interventi di AMS e di NSS.

3.3 Ambienti

EQ si è dotata di vari ambienti software che sono via via coinvolti nelle fasi del ciclo di vita del software.

3.3.1 Ambiente di sviluppo

L’ambiente di sviluppo è utilizzato solo per gli sviluppi svolti presso EQ. È composto da vari moduli software che sono elencati nel successivo capitolo 3.4.

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

3.3.2 Ambiente di test

L’ambiente di test è quello sul quale il Fornitore dovrà effettuare il primo rilascio e sul quale EQ effettuerà le verifiche di corrispondenza tra il software oggetto di rilascio e quanto richiesto.

Le verifiche di funzionalità potranno richiedere l’utilizzo di dati nei vari DB che dovranno essere preventivamente identificati dal Fornitore e quindi caricati nei DB da parte di EQ.

Sull’ambiente di test è in genere eseguita la prima 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 test deve essere comprensivo di tutti i sorgenti e di tutte le istruzioni necessarie per compilare e installare in quest’ ambiente il software oggetto di rilascio.

3.3.3 Ambiente di collaudo

Una volta completati con esito positivo i test, il software realizzato è installato da personale EQ nell’ambiente di collaudo.

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

Per la descrizione dell’ambiente di collaudo e delle relative procedure, si faccia riferimento alla documentazione del lotto 2 del presente bando di gara.

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

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.

3.3.4 Ambiente di esercizio

I software che hanno superato il collaudo sono messi in esercizio a cura di EQ con l’eventuale supporto del fornitore (su richiesta di EQ).

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.

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

3.4.1 Ambiente mainframe

I processi core di EQ sono eseguiti su ambiente zOS installato fisicamente da un outsourcer e gestito da EQ in sinergia con l’outsourcer.

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

Ambiente	Prodotto	Versione	Compatibilità	Vs. Versione
Monitor BMC	MAINVIEW	9.01.00	x DB2	9.01.00
	MAINVIEW	5.0.05	x CICS	5.0.05
	MAINVIEW	5.0.05	x ZOS	5.0.05

	MAINVIEW	4.03.01	x MQ	4.03.01
COMPUWARE	FILE - AID	9.2.0	MVS	9.2.0
	FILE - AID	6.1	DB2	6.1
	FILE - AID	4.7.1	RDX	4.7.1
	FILE - AID	4.3.0	DA	4.3.0
	XPED/XCHANGE	3.05		3.05
	XPED/CICS	7.06		7.06
	XPED/CODE COVER	3.0		3.0
	XPED/TSO	9.0		9.0
COMPUTER ASSOCIATES	CA	CA	COMMON	SERVICES
	CA	OPS		MVS 11.5
	CA	XCOM		3.01
	CA	7		11
	CA	DYNAM	TLMS	RMM
	CA	VIEW		11.5
PRIMEUR	SPAZIO	2.03.01		2.03.01
ORACLE	Oracle Transparent Gateway	9.2.0.1
MACRO4	VTAMPRINT	4R9M1
IBM	ZOS	1.04		1.6/1.10
	JES2	1.04		1.5
	RACF	1.04		7.70.9
	TSO	3.03.00		3.6.0
	DFSMS	1.03.00		1.06.0
	DSF	1.17.00		1.17.0
	VTAM	6.01		6.01
	ISPF	5.02.00		5.6.0
	DB2	7.01		8.1
	MQ	6.00		6.0
	QMF	3.03		8.1
	JES328X	3.R2.M0		3.R2.M0
	CICS	2.02		2.02
	ACF NCP	7.06		7.06
	ACF SSP	V4		V4
	PSF	3.03.00		3.04.00
	NETVIEW	1.R4		1.6
	HSM	1.05.09		1.05.09
	NETVIEW/FTP	2R2M1		2R2M1
	NVAS	2.R1.M1		2.R1.M1
	GDDM	V3.R2M0		V3.R2M0
	COBOL FOR OS/390	V2/3		3.3.0
	PPFA 370

IBM OGL/370
SDF2	1.R4.M0	4.0
Tivoli Performance Reporter	V1.05.01	V1.05.01
ZOS	1.04	1.6/1.10
JES2	1.04	1.5

Tabella 6 - prodotti ambiente mainframe

3.4.2 Ambiente Web

L’ambiente web di EQ è basato su hardware e software “open” ed è installato fisicamente in EQ. La tabella seguente fornisce un quadro di massima di quanto è impiegato.

Oggetto	Prodotto e versione
Sistema operativo
	Linux Centos 5
	Linux RedHat 5
	SUSE Linux Enterprise Server 11 SP1
	Oracle Linux 5
	Microsoft Windows Server 2003 / 2008 / 2008 R2
	Vmware VSphere 5
Web Server
	Apache HTTPD Server 2.x
	IBM HTTP Server 6.1.0.x
	Microsoft IIS Server 6
	Microsoft IIS Server 7
ESB e BPM
	IBM BPM – Lombardi Edition
	WSO2
	JBPM
Application Server
	IBM WebSphere Application Server Network Deployment 6.1.0.x
	JBoss Application Server 4.2.x / 5.1.x
Database
	Oracle RAC 11g su Oracle Linux
Sistemi d’interfacciamento
	IBM DB2 Connect 9.5
	CICS Transaction Gateway 7.2.x

Sicurezza
	IBM Tivoli Access Manager 6.1 (Webseal 6.1)
	IBM Tivoli Directory Server 6.1
Managed File Transfer
	Primeur Spazio MFTS 2.3.4 / 2.5.0
Sistemi di backup
	IBM Tivoli Storage Manager
Sistemi di archiviazione documentale
	Alfresco 3.0.0
	CODIS 2.5
	EMC Documentum
	Columbus Macro 4
Content Management
	Open CMS
	• Microsoft Project Server 2013 e Sharepoint 2013

Tabella 7 - prodotti ambiente web

EQ sta rivolgendo particolare attenzione alla tematica di integrazione SOA. A tal proposito nel tempo ha predisposto un’infrastruttura SOA, basata sulla suite WSO2, con l’obiettivo di estendere tale paradigma dove possibile. Allo stato attuale le applicazioni che la utilizzano sono di tipo informativo che dispositivo. L’approccio architetturale nella realizzazione di queste nuove funzioni su SOA consiste nell’incapsulare funzioni del back end (nel caso del mainframe si sta utilizzando il paradigma CTG), ottenere dei servizi atomici, che poi sono aggregati secondo le logiche di business in modo da realizzare i macro servizi richiesti.

Non tutti i moduli della suite WSO2 sono attualmente utilizzati nell’infrastruttura Equitalia, in particolare alla data odierna vengono impiegati i seguenti moduli: ESB, Governance Registry, Buiness Process Server, Business Activity Monitor. Sono stati realizzati circa 12 processi BPS e sono gestiti circa 20 web services. E’ intenzione di Equitalia, nel tempo, introdurre l’utilizzo di altri moduli della suite quali, ad esempio (non esaustivo) il BRMS, l’Identity Server, i moduli di Security, etc.

4 Ciclo di vita del Software e gestione dei progetti

Per lo sviluppo del software, EQ 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 EQ, è 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 di Microfocus Caliber e 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” è rilasciato utilizzando dei templates che prevedono un documento Word e degli allegati in formato fisso quando l’attività di collaudo sarà svolta con Microfocus QADirector, ed in altri formati (MS Word/Excel) quando QADirector non è applicabile.

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” rapportando, tramite opportune tabelle, il numero di Linee di Codice (LOC) sviluppate. 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 SVN).

Il numero di LOC 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).

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à essere effettuato utilizzando alcuni strumenti quali Microfocus QADirector, Microfocus TestPartner, Microfocus QA Loader, strumenti per test di Vulnerabilità applicativa, etc.

Alcuni degli strumenti forniscono automaticamente della reportistica sugli avanzamenti, qualora nel caso specifico non fosse possibile ottenere i report automaticamente 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 Microfocus, dovranno essere già in possesso del Fornitore.

5 Gestione dei picchi di lavoro

Fermo restando quanto previsto dal successivo capitolo 8 “Governo della fornitura”, 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 EQ, che determinano eccezionali carichi di lavoro.

In caso di eventi eccezionali e non pianificabili, il Fornitore, nel rispetto di quanto previsto dal successivo paragrafo 8.6.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.

6 Logistica

Il Fornitore svolgerà le attività oggetto del presente capitolato tecnico presso la propria sede o presso la sede di EQ di Xxxx, Xxx Xxxxxxxxx Xxxxx x.000 o, qualora se ne rendesse necessario, presso altra sede di EQ nel territorio di Roma Capitale o presso le sedi delle società del Gruppo Equitalia, nel territorio italiano, nel rispetto di quanto di seguito indicato.

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

EQ, 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, ha un’occorrenza marginale.

Le risorse del Fornitore presenti presso le suddette sedi di lavoro di EQ che debbono connettersi alla rete aziendale EQ dovranno disporre di apparecchiature (notebook o similari), con caratteristiche adeguate per la connessione, opportunamente dimensionate, in termini di hardware e software, in funzione dell’attività da svolgere e rispondenti ai requisiti di sicurezza definiti da EQ (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 EQ 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 EQ; in nessun caso l’apparecchiatura collegata alla rete aziendale EQ potrà essere collegata contemporaneamente ad una rete esterna.

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

7 Figure professionali richieste per l’esecuzione dei servizi

Nel presente capitolo sono indicate le figure professionali previste per lo svolgimento dei servizi oggetto della fornitura, il numero minimo di risorse, per ciascuna figura professionale, di cui il Fornitore dovrà avere a disposizione, i profili (requisiti minimi) di ciascuna figura professionale nonché i requisiti migliorativi che potranno essere oggetto di offerta.

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

Il Fornitore dovrà eseguire i servizi di AMS e di NSS, oggetto del presente capitolato, impiegando risorse professionali corrispondenti alle figure professionali indicate nel successivo paragrafo 7.2.

Il numero delle risorse professionali (pool di risorse) che 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
P6	Account manager	1
P5	Capo Progetto	2
P4	Anal. Funzionale o Processo / Team Leader	4
P3a	Anal. Prog. Senior Cobol	2
P3b	Anal. Prog. Senior	2
P3c	Anal. Prog. Senior Java - BPM	3
P2a	Anal. Prog. Junior Cobol	2
P2b	Anal. Prog. Junior	3
P7	Business Process Re-engineer	2
P6	Esperto Function Point	1
S4a	DBA DB2 (mainframe)	1
S4b	DBA Oracle	1
S3a	Sistemista mainframe	1
S3b	Sistemista dipartimentale	1

Tabella 8 - Figure professionali richieste

In sede di offerta il Concorrente potrà indicare nella Relazione tecnica (paragrafo 9) 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 nella Relazione tecnica 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 in modo da garantire gli SLA richiesti o, ove previsto, quelli migliorativi dallo stesso offerti (numero di GG/P medi adeguato); di seguito si riporta la composizione del team di lavoro e la percentuale di impiego stimata, per ciascuna figura professionale.

Figura	Percentuale d’impiego
P5 – Capo progetto	5%
P4 – Anal. Funz. / Team Leader e/o Analista di Processo	15%
P3 - Anal. Prog Senior	20%
P2 - Anal. Prog Junior	45%
P7 – Business Process re-engineer	0%
P6 – Esperto Function Point	0%
S4 - DBA	0%
S3 - Sistemista	5%
Totale	100%

Tabella 9 - dimensionamento medio 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 e la percentuale di impiego stimata, per ciascuna figura professionale, in ragione del grado di complessità dell’intervento richiesto.

Figure Professionali	Complessità
Figure Professionali	Bassa	Media	Alta
P5 – Capo progetto	4%	6%	8%
P4 – Anal. Funz. / Team Leader e/o Analista di Processo	10%	10%	10%
P3 - Anal. Prog Senior	12%	14%	20%
P2 - Anal. Prog Junior	63%	50%	35%
P7 – Business Process re-engineer	5%	10%	15%
P6 – Esperto Function Point	2%	2%	2%
S4 - DBA	2%	4%	5%

S3 - Sistemista	2%	4%	5%
Totale	100%	100%	100%

Tabella 10 - Dimensionamento medio NSS

Ovviamente la figura P1 – Architetto Datawarehouse deve intendersi presente quando l’intervento prevede relazioni con la tecnologia o tematiche datawarehouse.

La complessità dell’intervento ed il relativo mix di risorse, è definito secondo quanto di seguito riportato:

Complessità bassa

• Tale mix si applica per quelle attività di effort complessivo inferiore ai 70 FP.

Complessità media

• Tale mix si applica per quelle attività di effort complessivo compreso tra 70 e 150 FP

Complessità alta

• Tale mix si applica per quelle attività di effort complessivo superiore ai 150 FP.

Per gli interventi relativi al Supporto Specialistico, non è stata definita una stima della composizione media del team di lavoro, atteso che la stessa verrà definita in modo puntuale sul singolo intervento.

7.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”, oppure la “buona 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%) mentre la “buona conoscenza” corrisponde ad un utilizzo o ad un’operatività su quello specifico item superiore a 6 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.

7.2.1 P6 – Account manager

La figura di account manager non è imputabile nei costi di progetto, ma costituisce l’interfaccia del Fornitore per quanto riguarda la gestione del contratto.

Requisiti

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

• Estrazione tecnica;

• Orientamento al problem solving

Responsabilità

• È l’unico referente del contratto

• Supporta il management di EQ nella gestione della fornitura

• Costituisce il punto di escalation per la risoluzione dei problemi della fornitura (tecnici, economici, gestionali, ecc.).

7.2.2 P5 – Capo Progetto

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;

• controllo realizzazione procedure, stima di risorse per realizzazione di progetto, stima di tempi e pianificazione attività;

• 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.

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. Il Capo Progetto 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 .

7.2.3 P4 – Analista Funzionale e/o di Processo / Team Leader

Requisiti minimi

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

• almeno 6 anni di esperienza lavorativa in società di ICT, di cui almeno 3 anni nel ruolo;

• aver definito, realizzato, collaudato e documentato, in totale autonomia o per tramite del team da lui diretto, le soluzioni tecniche, anche per le problematiche più complesse;

• aver applicato le principali tecniche e strumenti di project management (Gantt, CPM, livellamento risorse);

• conoscenza della metodologia UML e/o linguaggi di modellizzazione di processo;

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

7.2.4 P3a – Analista Programmatore Senior mainframe

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 8 e versioni seguenti per zOS;

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

• aver definito / scritto in autonomia documentazione tecnica e manuali utente;

7.2.5 P3b – Analista Programmatore Senior dipartimentale

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 Visio;

• 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;

• aver definito / scritto in autonomia documentazione tecnica e manuali utente;

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

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

− IBM WAS

− JBoss

− DBLINK

− WSO2

− WebSphere Host Access Transformation Service (HATS)

7.2.6 P3c – Analista Programmatore Senior dipartimentale 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 Visio;

• 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;

• aver definito / scritto in autonomia documentazione tecnica e manuali utente;

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

− IBM WAS

− JBoss

− DBLINK

− conoscenza di soluzioni di middleware (ESB) come ad esempio WSO2 o IBM IIB.

7.2.7 P2a – Analista Programmatore Junior mainframe

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 Visio;

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

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

• aver definito / scritto in autonomia documentazione tecnica e manuali utente.

7.2.8 P2b – Analista Programmatore Junior dipartimentale

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;

• aver definito / scritto in autonomia documentazione tecnica e manuali utente;

• buona 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 JBoss ESB

− 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à.

7.2.9 P7 - Business Process Re-engineer

Requisiti minimi

• almeno 6 anni di esperienza consulenziale, di cui 4 anni con specifico riferimento a progetti significativi di BPR preferibilmente della Pubblica Amministrazione ;

• laurea in discipline economico-gestionali o cultura equivalente;

• conoscenza delle tecniche e metodologie di analisi organizzativa, di disegno dei processi e gestione del cambiamento organizzativo;

• conoscenza delle metodologie di analisi dati;

• esperienza su tematiche di re-engineering, definizione modelli di competenze, sistemi di valutazione, determinazione dei dimensionamenti delle strutture, formazione e comunicazione;

• conoscenza di Change Management e implementazione di nuove strutture organizzative;

• conoscenza delle Tecniche di Problem Solving e di Risk management.

7.2.10 P6 – Esperto Function Point

Requisiti minimi

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

• laurea in discipline tecniche o cultura equivalente;

• capacità nella stima di tempi;

• conoscenza di metodologie di stima e misura progetti;

• buona conoscenza delle regole IFPUG di conteggio;

• aver partecipato nel ruolo ad almeno 10 progetti diversi con diverse architetture (web, Client Server ecc…);

• aver eseguito l’analisi dei Function Point applicata a diverse tipologie di progetti (dipartimentali e non);

• conoscenze ed uso di prodotti SW per la stima dei progetti;

• conoscenza di metodologie di analisi dei processi;

• conoscenza di metodologie di analisi e disegno di prodotti SW;

• conoscenza di metodologie di analisi e disegno dati;

• conoscenze tecniche di controllo qualità.

7.2.11 S4a – DBA DB2

Requisiti minimi

• Almeno 6 anni di esperienza lavorativa;

• almeno 4 anni di esperienza lavorativa nell’ambito di gruppi di progetto, con ruolo di DB Administrator;

• Aver operato su ambienti DB2 v 7 (e superiori) su mainframe (zOS) per almeno 4 progetti (della durata non inferiore a 4 mesi).

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

• Aver definito e/o scrittura documentazione tecnica e di progetto.

• Conoscenza lingua italiana

Altri requisiti

• Possesso di certificazioni relative al ruolo

• Partecipazione a di progetti di grande complessità;

• capacità di comunicazione ed interazione sugli aspetti tecnici nei confronti dei clienti

• conoscenza della lingua inglese.

Responsabilità

• offre assistenza al team di Equitalia per quanto riguarda la configurazione e set up del DB2 per le componenti applicative richiesta (derivante da MAC, MAA, RDM o RDS)

• supporta il team di Equitalia nell’operare tutti i cambiamenti di configurazione che si rendono necessari con l’evoluzione dei requisiti applicativi configurando opportunamente le dimensioni di memoria utilizzate sia per il DB che per i processi utente in fase di collaudo e sviluppo;

• per le attività di messa in esercizio, fornisce assistenza al team di Equitalia nella configurazione e performance tuning dei sistemi rilasciati.

7.2.12 S4b – DBA Oracle

Requisiti minimi

• Almeno 6 anni di esperienza lavorativa;

• almeno 4 anni di esperienza lavorativa 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 minore di 4 mesi.

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

• Aver scritto o definito documentazione tecnica e di progetto;

• Conoscenza lingua italiana

Altri requisiti

• Possesso di certificazioni Oracle database 11g relative al ruolo.

• conoscenza di progetti di grande complessità;

• capacità di comunicazione ed interazione sugli aspetti tecnici nei confronti dei clienti

• conoscenza della lingua inglese.

Responsabilità

• supporta il team Equitalia nell’installazione e configurazione di tutti i server che si renderanno necessari sia in ambiente di sviluppo che di collaudo offrendo assistenza alle corrispondenti attività di esercizio, relativamente alla componente applicativa richiesta (derivante da MAC, MAA, RDM o RDS)

• per le attività di messa in esercizio, fornisce assistenza al team di Equitalia nella configurazione e performance tuning dei sistemi rilasciati.

7.2.13 S3a – Sistemista mainframe

Requisiti minimi

• Almeno 5 anni di esperienza lavorativa;

• almeno 3 anni di esperienza lavorativa nell’ambito di gruppi di progetto, con ruolo di Sistemista;

• Aver operato in modo sistemistico su zOS v 1.6 e seguenti, in modo comprovato su almeno progetti 3 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 definito / scritto in autonomia documentazione tecnica e manuali utente

• Conoscenza lingua italiana

Altri requisiti

• possesso delle certificazioni del ruolo

• Partecipazione a progetti di grande complessità

• capacità di problem solving applicativo-sistemistica;

• conoscenza di protocolli di rete.

• Conoscenza lingua inglese

Responsabilità

• assiste le problematiche applicative relative all’utilizzo dei database (monitoraggio, riorganizzazione, tuning applicativo) e relativo alle applicazioni stesse;

• supporta l’esecuzione di collaudi tecnici;

• supporta la progettazione dei casi di test.

7.2.14 S3b – Sistemista dipartimentale

Requisiti minimi

• Almeno 5 anni di esperienza lavorativa;

• almeno 3 anni di esperienza lavorativa 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, nei quali abbia effettivamente lavorato sugli ambienti richiesti;

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

• aver operato su protocolli di rete;

• approfondita aver operato su componenti dei Personal Computer e delle LAN.

• Aver definito / scritto in autonomia documentazione tecnica e manuali utente

• Conoscenza lingua italiana

Altri requisiti

• possesso delle certificazioni del ruolo

• Partecipazione a progetti di grande complessità

• capacità di comunicazione ed interazione sugli aspetti tecnici nei confronti dei clienti

• capacità di problem solving applicativo-sistemistica;

• Conoscenza lingua inglese

Responsabilità

• assiste le problematiche applicative relative all’utilizzo dei database (monitoraggio, riorganizzazione, tuning applicativo) e relativo alle applicazioni stesse;

• supporta l’esecuzione di collaudi tecnici;

• supporta la progettazione dei casi di test.

7.3 Requisiti migliorativi

Fermo restando quanto sopra, il Concorrente, nel rispetto di quanto previsto nell’ “Allegato 3 – Schema Offerta tecnica lotto 1”, in sede di offerta potrà indicare il possesso dei seguenti requisiti migliorativi da parte delle risorse professionali che, in caso di aggiudicazione, verranno impiegate nell’esecuzione dei servizi di AMS e di NSS:

• Per le risorse P5 e P4 le seguenti certificazioni:

− PMI-PMP

− Prince 2 Foundation

• Per le risorse P3c - Anal. Prog. Senior Java - BPM le seguenti certificazioni:

− IBM Certified BPM Developer – WebSphere Lombardi Edition

− IBM Certified Associated BPM Developer – WebSphere Lombardi Edition

− IBM Certified BPM Program Manager - WebSphere Lombardi Edition

• Sempre per le risorse P3c – Analista Programmatore Senior dipartimentale BPM:

− IBM Integration Bus V9 Application Development o certificazione per versione di IBM BPM superiore.

− WSO2 ESB for Developers – Advanced.

Ai requisiti migliorativi sarà attribuito un punteggio secondo quanto espresso nel disciplinare di gara

Si evidenzia che ai fini del punteggio sarà considerata una sola certificazione per ciascuna risorsa, indipendentemente dal numero di certificazioni possedute dalla risorsa stessa.

7.4 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 delle risorse professionali P5, P4 e P3c, di cui al precedente paragrafo 7.3.

A tal fine, entro 10 (dieci) giorni dalla richiesta di EQ, il Concorrente risultato aggiudicatario dovrà produrre:

1. dichiarazione attestante l’elenco nominativo delle risorse professionali di cui si avvarrà per l’esecuzione dei servizi e la natura del rapporto di lavoro in essere con ciascuna di dette risorse. Si evidenzia che il numero delle risorse riportato nell’elenco dovrà essere pari al

numero minimo previsto dal precedente paragrafo 7.1 o nel maggior numero indicato nella Relazione Tecnica (paragrafo 9);

2. il curriculum vitae di ciascuna di dette risorse professionali, sottoscritto dalla risorsa stessa. Al curriculum vitae dovrà essere allegata copia fotostatica del documento di identità del sottoscrittore.

Si precisa che 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” o “buona 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. Sul punto si rinvia a quanto previsto dal precedente paragrafo 7.2

EQ si riserva comunque di richiedere chiarimenti e/o integrazioni alla documentazione prodotta, in particolare con riferimento alla dimostrazione dei requisiti minimi o di quelli migliorativi, se dichiarati in sede di offerta.

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

8 Governo della fornitura

La fornitura oggetto della gara si svolgerà 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 della fornitura.

Il Fornitore, entro 10 (dieci) giorni lavorativi dalla data di sottoscrizione del contratto, dovrà consegnare il Piano della Qualità Generale ad EQ per la sua approvazione. Nel caso in cui EQ rilievi 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.

8.1 Modalità di fornitura del servizio di AMS

Il servizio di AMS dovrà essere erogato a decorrere dalla data del verbale di avvio dell’esecuzione del contratto, di cui al precedente paragrafo 2.5, per il periodo previsto, per ciascuna applicazione, nella tabella “Tabella 2 - servizi MAC e MAA” riportata al paragrafo 2.4.

Come anticipato nel paragrafo 2.4, EQ, in base alle proprie effettive esigenze, si riserva 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.

Le attività di AMS 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 EQ e fruibili mediante un browser web. 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à di tali sistemi, saranno utilizzati la e-mail o il fax; il Fornitore sarà pertanto tenuto a mettere a disposizione una casella e-mail ed un numero di fax dedicati al servizio. In caso di utilizzo della e-mail o del fax, sarà compito del Fornitore tracciare l’attività su OTRS o Bugzilla, a seconda dei casi.

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 previsti dal presente capitolato tecnico o, ove previsto, in quelli migliorativi previsti dall’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 tempestiva comunicazione ad EQ, utilizzando i sistemi suddetti. Nella comunicazione dovranno essere dettagliatamente indicate le circostanze che possono determinare l’inadempimento.

8.1.1 Manutenzione correttiva (MAC)

8.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

La priorità dell’intervento sarà assegnata da EQ ed 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

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

* EQ può richiedere la presenza presso le proprie sedi per specifiche attività che coinvolgano proprie risorse, risorse delle società clienti di EQ o 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 ed EQ che dovrà dare

approvazione scritta. In assenza di tali accordi, tali giornate si intendono come lavorative a tutti gli effetti.

Tabella 11 - Definizione priorità dell’intervento

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 8.8.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 8.8.2. Qualora per ragioni oggettive l’anomalia non possa essere risolta nei termini, il Fornitore ed EQ definiranno di comune accordo le modalità e la tempistica per la risoluzione del malfunzionamento e l’intervento si intenderà “chiuso con difetto”.

8.1.1.2 Rendicontazione dell’attività di MAC

• 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)

• 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 EQ, a suo insindacabile giudizio.

8.1.2 Manutenzione adeguativa (MAA)

8.1.2.1 Modalità operative di attivazione ed erogazione

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

Sede delle attività	Sede Fornitore * e sede EQ
Mezzi di comunicazione	OTRS o 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

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

1. EQ trasmetterà al Fornitore una Richiesta di Manutenzione Adeguativa (RDA). Nella RDA saranno indicate:

− 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 ad EQ entro i 5 (cinque) giorni lavorativi successivi alla data della RDA.

3. EQ, 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

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

** Qualora ricorrano particolare esigenze EQ 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.

dovrà trasmettere ad EQ 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 EQ.

5. EQ 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, Equitalia 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 di lavoro, di cui al precedente punto 2, e si procederà come sopra descritto.

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

• 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 EQ;

• 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 risulteranno da apposito verbale.

8.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 EQ (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

8.2 Modalità di fornitura del servizio di NSS

8.2.1 Modalità operative di erogazione

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

Sede delle attività	Sede Fornitore* e sede EQ
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

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

In caso di indisponibilità di tale sistema, sarà utilizzata la e-mail; il Fornitore sarà pertanto tenuto a mettere a disposizione una casella e-mail dedicata al servizio.

In caso di utilizzo della e-mail, sarà compito del Fornitore tracciare la comunicazione su 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.

* È da prevedere una presenza frequente delle risorse del Fornitore presso la sede EQ per le attività di analisi che coinvolgano risorse EQ e di altri fornitori. Tale presenza è considerata, inoltre, funzionale alle necessità di coordinamento con il referente EQ. La presenza di altre 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 EQ. È possibile, sempre previo accordo scritto tra il Fornitore e EQ, che venga richiesta la presenza di risorse del Fornitore presso le sedi delle società del Gruppo Equitalia, 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 EQ; comunque all’occorrenza EQ 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.

8.2.2 Attività realizzative di software

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

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 EQ, 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

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

• Garanzia da erogare dopo l’accettazione dello sviluppo.

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

• Definizione tipologia di intervento:

− Manutenzione Evolutiva

− Sviluppo software;

• Modalità di affidamento

• Accettazione dell’intervento

• Determinazione del valore economico dell’intervento

8.2.2.1 Definizione tipologia di intervento

Ciascun intervento (Manutenzione Evolutiva e Sviluppo Software) costituisce un progetto di sviluppo software.

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

• la prima fase di Preparazione del Progetto ed Analisi;

• la seconda fase di Realizzazione, Preparazione all’avvio in esercizio ed Avvio in esercizio, nonché le eventuali attività di assistenza per il rilascio in esercizio.

EQ, 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, allo scopo di definire la tipologia dell’intervento, ai soli fini della gestione contrattuale, 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 è stimato in misura superiore ai 21 (ventuno) FP (ma comunque inferiore ai 210 FP).

• Sviluppo software

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

EQ 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.

8.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 8.8.3.

Qualora EQ intenda avviare un progetto, invierà al Fornitore una richiesta di intervento e segnatamente 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).

EQ, anche in considerazione della complessità e/o 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, entro i 5 (cinque) giorni lavorativi successivi alla data della RDM o entro i 15 (quindici) giorni lavorativi successivi alla data della RDS, trasmetterà EQ 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, 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 Caper 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 EQ, sarà pertanto determinato applicando le seguenti formule:

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

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

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

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)

• Su richiesta di EQ, nominativi delle risorse impegnate nell’intervento

Si evidenzia che il dettaglio dei deliverable e delle fasi di progetto, da prevedere nel piano di progetto e nel relativo cronoprogramma, sono specificatamente riportati 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é da quanto previsto dal Piano della Qualità Generale del Fornitore.

EQ, a seguito delle proprie valutazioni, potrà accettare la proposta d’intervento o richiede modifiche alla stessa e segnatamente al piano delle attività, al cronoprogramma, 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 ad EQ la proposta d’intervento aggiornata entro i successivi 3 (tre) giorni lavorativi.

EQ 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, XX 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 EQ intenda invece affidare le 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.

EQ, 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.

EQ 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, EQ ad affidare al Fornitore l’intero progetto (prima fase e seconda fase) né una delle due fasi del ciclo di vita del progetto. EQ si riserva, infatti, sulla base delle proprie valutazioni, la facoltà di affidare a terzi l’esecuzione dell’intero progetto o l’esecuzione della prima o della seconda fase.

Qualora EQ, 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

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

Fornitore

Trasmissione proposta di intervento (comprensiva di elenco delle attività, stima in FP e/o GG/P), cronoprogramma

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.

Esecuzione I fase

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

Fornitore

Rilascio dei prodotti di fornitura di fine analisi. Consegna del documento di analisi di dettaglio e delle specifiche funzionali.

Rilascio della documentazione riepilogativa e di dettaglio della fornitura

Riscontro dei prodotti consegnati in termini di quantità e correttezza

Approvazione dell’analisi (verbale di accettazione).

Affidamento II fase (eventuale)	EQ	Trasmissione del modulo di affidamento della seconda fase.
Esecuzione II fase	Fornitore	Rilascio dei prodotti di fornitura finali (codice sorgente e documentazione tecnica) Documentazione dei casi di test eseguiti Documentazione attestante i FP effettivamente sviluppati e misurazione dell’indice di produttività
Esecuzione II fase	EQ	Riscontro dei prodotti consegnati in termini di quantità (verbale di consegna)
Accettazione	EQ	Validazione dei prodotti finali di fornitura, previo collaudo e verifica (verbale di accettazione)

Tabella 12 – Processo di affidamento ed esecuzione attività realizzative

8.2.2.3 Accettazione dell’intervento

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

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

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

Ai fini dell’accettazione dell’intervento EQ 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 EQ, secondo quanto previsto della metodologia di cui all’allegato A.

Ciascun intervento sarà accettato quando:

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

• il software realizzato supera con esito positivo il collaudo di accettazione di EQ. L’esito delle suddette attività di collaudo e verifica risulteranno da apposito verbale.

8.2.2.4 Determinazione del valore economico dell’intervento

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

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

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

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

• 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 EQ nel corso di esecuzione dell’intervento.

Di seguito si riportano le attività che EQ svolgerà ai fini della determinazione del valore economico dell’intervento.

Ai fini della determinazione del numero totale di FP realizzati dal Fornitore alla conclusione dell’intervento, EQ procederà al calcolo del numero complessivo di LOC presenti nel codice sorgente.

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 13 - 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 EQ o del Fornitore e in particolare se è maggiore del 25% lo scarto tra FP dichiarati dal Fornitore stesso e quelli misurarti con il suddetto metodo.

Al fine di determinare il valore economico dell’intervento nei casi di:

• affidamento delle sole attività di Preparazione del Progetto ed Analisi o esecuzione della sola prima fase a seguito di interruzione dell’intervento, decisa da EQ;

• affidamento delle sole attività di Realizzazione, Preparazione all’avvio in esercizio ed Avvio in esercizio;

EQ 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 seconda fase), dichiarati dal Fornitore, in sede di offerta, nella tabella riportata nell’ “Allegato 3 – Schema Offerta tecnica”, 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)	Rapporto IP % (a/b)
3	4	75%

Tabella 14 - indice di produttività FP

Il “Rapporto percentuale” verrà quindi applicato nelle suddette ipotesi, con la modalità riportata di seguito. Si evidenzia che nel caso in cui al Fornitore, che ha già realizzato la prima fase (Preparazione del Progetto ed Analisi), sia affidata anche la seconda fase (Preparazione all’avvio in esercizio ed Avvio in esercizio), il valore economico del progetto avverrà determinato secondo quanto di seguito previsto per l’affidamento del ciclo di vita completo.

EQ, determinerà quindi la misura dei FP dell’intervento per le attività realizzative, come di seguito riportato. Per “FP stimati” (FPs) s’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 EQ; per “FP misurati” (FPm) s’intendono i FP realizzati dal Fornitore alla conclusione dell’intervento, come sopra calcolati.

Caso A) Affidamento ciclo di vita completo (fase 1 e fase 2) oppure affidamento realizzazione, preparazione all’avvio in esercizio ed eventuale avvio in esercizio (solo 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 sia inferiore di meno del 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 EQ 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 EQ, 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).

EQ, infine, procederà a convertire in FP il numero di GG/P delle attività di assistenza, moltiplicando i GG/P per l’indice di produttività (IP) del ciclo di vita completo, dichiarato dal Fornitore, in sede di offerta, nella tabella riportata nell’“Allegato 3 – Schema Offerta tecnica”, per l’ambiente tecnologico relativo al progetto. Tale valore sarà sommato al numero dei FP ottenuto dalla procedura appena descritta, ottenendo la misura complessiva in FP dell’intervento.

Determinata la misura complessiva in FP dell’intervento, il valore economico dello stesso sarà determinato moltiplicando il numero di FP per il prezzo unitario a FP, per l’ambiente tecnologico relativo al progetto, indicato dal Fornitore nell’offerta economica.

8.2.3 Supporto Specialistico

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

• Modalità di affidamento

• Accettazione dell’intervento

• Determinazione del valore economico dell’intervento

8.2.3.1 Modalità di affidamento

Le richieste relative alle attività di Supporto Specialistico saranno attivate attraverso apposita richiesta di intervento (“RDS”), 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;

• Figure professionali richieste

Il Fornitore, entro i 15 (quindici) giorni lavorativi successivi alla data della RDS, trasmetterà EQ 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.

EQ, a seguito delle proprie valutazioni, potrà accettare la proposta d’intervento o richiede modifiche alla stessa e segnatamente al piano delle attività, alla composizione del team di lavoro, alla stima dell’impegno delle risorse professionali. In caso di richiesta di modifiche, il Fornitore dovrà trasmettere ad EQ la proposta d’intervento aggiornata entro i successivi 3 (tre) giorni lavorativi.

In caso di accettazione, EQ 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, EQ ad affidare al Fornitore l’intervento. EQ si riserva, infatti, sulla base delle proprie valutazioni, la facoltà di affidare a terzi l’esecuzione delle attività di Supporto Specialistico.

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

8.2.3.2 Accettazione dell’intervento

Alla conclusione dell’intervento o, nel caso siano previsti più rilasci, a ciascun rilascio, EQ procederà a verificare la conformità tra quanto realizzato in esecuzione dell’intervento e quanto previsto dal piano delle attività accettato da EQ 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.

8.2.3.3 Determinazione del valore economico dell’intervento

Il valore economico relativo a ciascun intervento viene determinato forfettariamente sulla base della stima dell’impegno previsto per ciascuna figura professionale impiegata nell’esecuzione dello stesso, come risultante dalla proposta d’intervento approvata da EQ, e dalla relativa tariffa giornaliera offerta dal Fornitore in sede di gara.

8.2.4 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

• 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

− Giornate uomo per figura professionale, 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 EQ (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

8.2.5 Monitoraggio e verifica SLA

Tutti gli interventi di NSS sono monitorati con più strumenti interni:

• Le richieste (RDM e RDS) sono tracciate mediante OTRS e/o ; i tempi di presentazione della proposta d’intervento, sono misurati considerando le date che avrà registrato OTRS.

• L’inizio dell’attività di realizzazione sarà tracciata mediante uno strumento denominato Masterplan.

• La verifica tra le date pianificate e quelle effettive di consegna dei rilasci previsti sarà condotta mediante lo strumento Masterplan

• Il numero di ricicli sulla documentazione di analisi sarà misurato sulla base delle comunicazioni di rigetto tracciate su OTRS e su Masterplan.

• Il numero di ricicli sul collaudo sarà misurato sulla base delle comunicazioni di “pronti al collaudo” inviati dal Fornitore tracciati su OTRS e su Masterplan.

Relativamente agli interventi di Manutenzione Evolutiva, Sviluppo Software, ogni fine settimana, tutto il software sviluppato, comprensivo di tutto quanto necessario alla compilazione del codice stesso, dovrà essere rilasciato in forma di sorgente ad EQ 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, EQ, a campione, procederà ad ispezionare il codice sorgente rilasciato, sia con strumenti manuali che automatici, per verificare che (la lista non è esaustiva):

• sia stato correttamente commentato;

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

• 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 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 EQ per tutta la durata contrattuale.

A valle dell’ispezione del codice sorgente EQ rilascerà apposito verbale che dettaglierà l’esito della verifica effettuata.

Sulla base del report prodotto dal Fornitore, di cui al precedente paragrafo 8.2.4 nonché sulla base dei dati estratti da OTRS e Masterplan e dai verbali di collaudo e verifica positiva, EQ 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.

8.3 Garanzia

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

La garanzia decorre dalla data di accettazione del software realizzato (comprovata dal verbale di accettazione) e dovrà essere prestata dal Fornitore:

• fino alla scadenza del contratto per tutto il software realizzato ei primi tre anni di contratto;

• per 12 mesi, per tutto il software realizzato nel quarto anno.

8.4 Modalità di remunerazione

Per l’esecuzione del servizio AMS verrà riconosciuto un canone mensile posticipato per ciascuna applicazione che nel corso del mese di riferimento è stata oggetto del servizio. Per ciascuna applicazione l’importo del canone mensile sarà determinato sulla base del numero di FP dell’applicazione, riportato nel precedente paragrafo 2.4, nella Tabella 2 - servizi MAC e MAA, ed il prezzo unitario mensile a FP offerto dal Fornitore in sede di gara.

Considerando che quanto realizzato nel corso della fornitura in esecuzione degli interventi di NSS nonché di MAA è da considerare 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 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 che prevede la fatturazione (collaudo, rilascio in esercizio, ecc.). L’importo del corrispettivo sarà determinato pertanto dalla sommatoria degli importi di ciascun intervento valorizzato forfettariamente secondo quanto previsto nei precedenti paragrafi 8.2.2.4 e 8.2.3.3.

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

8.5 Verifica avanzamento lavori

EQ ed il Fornitore, con apposite riunioni periodiche, verificheranno lo stato della fornitura relativamente ai servizi di AMS e di NSS.

Nelle riunioni sarà verificato, in primo luogo, il rispetto degli SLA previsti per ciascun servizio (AMS e NSS) dal capitolato tecnico o quelli migliorativi, ove previsto, indicati dal Fornitore nell’offerta tecnica. La verifica del rispetto degli SLA sarà eseguita sulla base dei dati estratti dai sistemi OTRS, Bugzilla, Masterplan, nonché, sulla base dei verbali di collaudo e verifica positiva, tenuto conto altresì di quanto riportato nei report periodici prodotti dal Fornitore. Il mancato rispetto degli SLA comporterà l’applicazione dei rilievi e/o penali previsti dagli indicatori di qualità, riportati nell’allegato C.

Si procederà poi ad una verifica puntuale circa lo stato di esecuzione dei singoli interventi di Manutenzione Evolutiva, Sviluppo Software, Manutenzione Adeguativa non completati nel periodo di riferimento, allo scopo di accertare:

• rispetto degli standard di EQ per i vari rilasci;

• completezza e qualità dei contenuti dei rilasci;

• il rispetto delle milestone pianificate;

• le eventuali inadempienze del Fornitore e le relative cause.

Saranno inoltre verificate anche particolari criticità emerse nel corso del periodo in esame circa i servizi richiesti al Fornitore. Le verifiche potranno concludersi con un piano di azioni per il Fornitore che si impegna a effettuare nei tempi e nei modi stabiliti durante l’incontro stesso.

Si precisa che l’attività di MAC sarà verificata (monitorata) attraverso la misurazione dei corrispondenti indicatori di qualità previsti nel capitolo 4 dell’allegato C.

Per le attività di MAC, nel corso delle riunioni, verranno verificate le segnalazioni rifiutate dal Fornitore al fine di accertare l’effettiva imputabilità del malfunzionamento “ a terzi fattori”. Se viene accertato che il malfunzionamento oggetto della segnalazione rifiutata da parte del Fornitore non dipenda dal terzi fattori, EQ applicherà la penale prevista dall’indicatore di qualità IQ2.04 riportato nell’allegato C.

La periodicità degli incontri sarà settimanale nei primi 2 mesi della fornitura, per diventare successivamente mensile. EQ si riserva in ogni momento la facoltà di convocare riunioni per verifiche aggiuntive.

E’ importante sottolineare che tali verifiche sono da considerarsi in aggiunta al SAL periodico (report) che il Fornitore è tenuto comunque a produrre.

8.6 Gestione delle risorse professionali

8.6.1 Il pool di risorse per EQ

Le figure professionali, di cui al capitolo 7, 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 X.

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 EQ.

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

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

8.6.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 paragrafo7.4;

• Entro 10 giorni solari EQ 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 7.3, 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, EQ dovrà sempre autorizzare per iscritto la sostituzione di risorse del pool.

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 EQ.

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

In nessun caso:

• il pool delle risorse potrà scendere sotto il numero minimo previsto nel precedente paragrafo 7;

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

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 ad EQ l’autorizzazione al subappalto, nel rispetto di quanto previsto dalla legge, si evidenzia che dovranno essere presentati i CV delle risorse del subappaltatore che svolgeranno le attività che s’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 EQ, fermo restando l’obbligo del Fornitore di assicurare la prosecuzione e continuità delle prestazioni contrattuali nel rispetto degli SLA previsti dal presente capitolato tecnico.

EQ 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 sul/sui quale/quali a cui è assegnata.

Il Fornitore provvederà alla sostituzione della risorsa professionale con altra appartenente al pool entro 3 (tre) giorni dalla ricezione della richiesta motivata di EQ.

Qualora le risorse professionali del pool risultino tutte impegnate nell’esecuzione degli interventi, ai fini della sostituzione richiesta da EQ, 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.

8.6.3 Integrazione del pool di risorse

Nell’ipotesi in cui, per impreviste specifiche esigenze, EQ non possa ridefinire la priorità degli interventi affidati e, quindi, si rendesse necessario eseguire più interventi contemporaneamente (picco di lavoro), EQ stessa ne darà comunicazione al Fornitore.

Nella suddetta comunicazione verrà indicato, 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 7.2.

Il Fornitore renderà effettivamente disponibile la risorsa proposta entro 5 (cinque) giorni dall’approvazione da parte di EQ 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.

8.6.4 Aggiornamento professionale

Qualora EQ decidesse di utilizzare nuove release dei prodotti facenti parte degli ambienti di riferimento, di cui ai precedenti paragrafi 3.3 e 3.4, 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.

8.7 Produttività

La tabella che segue presenta i valori di produttività minimi richiesti da EQ e che l’Aggiudicatario della gara si impegna a garantire.

Ambiente Tecnologico

Indice di produttività FP per ciclo di vita completo affidamento totale (analisi +

realizzazione)

Indice di produttività FP per ciclo di vita ridotto affidamento sola

realizzazione.

Applicazioni J2EE o

MS ad alta intensità elaborativa

3,5

Applicazioni J2EE o MS ad alta interazione

utente

Applicazioni Cobol ad alta intensità

elaborativa

Tabella 15: Indici di Produttività richiesti da EQ.

Il Concorrente potrà proporre valori di produttività migliorativi secondo le modalità e i valori massimi espressi nel disciplinare di gara.

Gli indici di produttività richiesti da EQ, ovvero quelli migliorativi proposti dall’Aggiudicatario della gara saranno oggetto di verifica e monitoraggio.

8.8 SLA (Service Level Agreement)

Nel presente paragrafo sono riportati tutti gli SLA che il Fornitore dovrà rispettare nell’esecuzione della fornitura

In particolare nelle tabelle riportate nei successivi paragrafi sono indicati gli SLA relativi alla qualità generale della fornitura, gli SLA relativi alla qualità del servizio di AMS e gli SLA relativi alla qualità del servizio di NSS 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.

8.8.1 Indicatori qualità generale della fornitura

Indicatori di qualità

SLA

(valore limite)

Miglio

rabile

Consegna del Piano della

Qualità Generale

IQ1.01

• 10 giorni lavorativi dalla stipula del contratto

		• 5 giorni lavorativi dalla richiesta di modifica
Sostituzione del personale su richiesta EQ	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
Integrazione del pool di risorse	IQ1.05	5 giorni lavorativi	No
Sostituzioni di risorse su richiesta del Fornitore	IQ1.06	3 risorse anno	No
Numero di verifiche EQ per subentro e/o sostituzione di una risorsa	IQ1.07	1 verifica	No
Rilievi sulla qualità generale della fornitura	IQ1.08	2 rilievi a trimestre	No

8.8.2 Indicatori qualità del servizio di AMS

Si evidenzia che anche con riferimento a quelle applicazioni per le quali, ai sensi di quanto previsto dal precedente paragrafo 2.5, nel verbale di avvio dell’esecuzione del contratto sono previsti interventi di Supporto Specialistico finalizzati alla produzione della documentazione tecnica necessaria, il Fornitore dovrà prestare il servizio di AMS a decorrere dalla data del suddetto verbale.

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

Per ciascuna di dette applicazioni e sino alla produzione della relativa documentazione tecnica, in caso di mancato rispetto di uno degli SLA EQ accerterà, in contraddittorio con il Fornitore, se detto inadempimento è oggettivamente imputabile ad una carenza documentale. In caso affermativo non troveranno applicazione le penali/rilievi previsti in caso di mancato rispetto dello SLA di cui il Fornitore si è reso inadempiente.

Indicatore di qualità

SLA

(valore limite)

Miglio- rabile

Tempi di presa in carico (accettazione/rifiuto)

IQ2.01

Tempi di risoluzione (chiusura o chiusura con difetto)	IQ2.02		Si
Casi recidivi	IQ2.03	1 caso al mese	No
Ticket rifiutato in modo errato	IQ2.04	0 (zero) ticket	No
Consegna piano attività MAA	IQ2.05		No
Ritardo per approvazione software di MAA	IQ2.06	0 (zero) giorni lavorativi	No
Rilievi sul servizio di AMS	IQ2.07	2 rilievi mese	No

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

Consegna in risposta a

RDA

5 giorni lavorativi

Consegna in caso di

richiesta di modifica

3 giorni lavorativi

8.8.3 Indicatori qualità dei servizi di NSS

Indicatori di qualità

SLA

(valore limite)

Miglio

-rabile

Consegna proposta d’intervento di Manutenzione Evolutiva	IQ3.01		No
Consegna proposta d’intervento di Sviluppo Software o di Supporto Specialistico.	IQ3.02		No
Rispetto della pianificazione dell’intervento	IQ3.03	0 (zero) giorni lavorativi di ritardo	No
Ritardo per approvazione documento di analisi o del software	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
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

Consegna in risposta a

RDM

5 giorni lavorativi

Consegna in caso di

richiesta di modifica

3 giorni lavorativi

Consegna in risposta a

RDS

15 giorni lavorativi

Consegna in caso di

richiesta di modifica

3 giorni lavorativi

8.9 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 della fornitura. 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.

EQ 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 dei SLA (valore limite), siano essi legati ad indicatori di qualità generale della fornitura 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.

8.10 Proposte a supporto del monitoraggio dei servizi di AMS e di NSS

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

Il Concorrente, nel rispetto delle modalità previste nell’ “Allegato 3 – Schema Offerta tecnica”, può comunque proporre delle soluzioni software integrative e/o alternative per la misurazione degli SLA. La proposizione di dette soluzioni non determinerà l’attribuzione di un punteggio.

8.10.1 Condizioni per l’adozione delle soluzioni proposte

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

• Essere installata in EQ, non sono considerate percorribili soluzioni applicative fisicamente installate presso il Fornitore e accessibili da EQ 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 EQ (no costi di licenze, di manutenzione, ne di supporto all’installazione e quant’altro).

• Essere compatibile con il sistema hardware e software di EQ, in particolare di poter essere gestito su macchine virtuali.

• Essere già stato impiegato dal Fornitore in altri contesti.

• Le informazioni in esso contenute dovranno essere migrate su eventuale altro sistema target a cura del fornitore a fine contratto.

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 EQ non è in alcun modo obbligata ad adottare o mantenere nel corso del contratto la soluzione software proposta dal Fornitore.

9 Allegati

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

• Allegato A: Metodologia gestione progetti-servizi

• Allegato B: Templates

• Allegato C: Indicatori di Qualità e Penali

Document Metadata

Table of Contents

Procedura aperta per l’acquisizione di servizi di manutenzione e di sviluppo per i sistemi informativi a supporto della riscossione, suddivisa in 2 Lotti

Document Metadata