Allegato 1B – Capitolato Tecnico Lotto 2

Equitalia SpA

Allegato 1B – Capitolato Tecnico Lotto 2

Equitalia SpA

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

Capitolato tecnico

CIG: 65200779BE

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 38

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

4 Ciclo di vita del Software e gestione dei progetti 44

5 Gestione dei picchi di lavoro 46

6 Logistica 47

7 Figure professionali richieste per l’esecuzione dei servizi 48

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

7.2 Profili delle figure professionali 50

7.3 Requisiti migliorativi 58

7.4 Verifica requisiti delle risorse professionali 58

8 Governo della fornitura 60

8.1 Modalità di fornitura del servizio di AMS 60

8.2 Modalità di fornitura del servizio di NSS 65

8.3 Garanzia 77

8.4 Modalità di remunerazione 77

8.5 Verifica avanzamento lavori 78

8.6 Gestione delle risorse professionali 79

8.7 Produttività 81

8.8 SLA (Service Level Agreement) 82

8.9 Xxxxxx e rilievi 85

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

9 Allegati 87

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
Servizio di Nuovi Sviluppi (NSS)	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, il 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à:

o formazione

o redazione di documentazione tecnica

o supporto a redazione di studi

o 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)
Frontespizio digitale Servizi di cooperazione applicativa - Minute di ruolo e Provvedimenti (SPC) Servizi di cooperazione applicativa - integrazione Giudici di Pace (SPC) Sospensione mandati di pagamento (48 bis) Applicativi a supporto Siebel on Demand Conto di gestione Cartelle via PEC Infrastruttura PEC Provvedimenti back end e procedure batch Stato riscossione – Gestione flusso AdR ed Enti Documenti procedure esecutive Lampo AdR GEDO CIN Gestione plico telematico Firma digitale per FUG Compensazione rimborsi (28 ter) Gestionale Stampe Portale statistico e datawarehouse	1.630	€ 0,80
	456	€ 0,80
	311	€ 0,80
	1.340 € 0,80
	266	€ 0,80
	592	€ 0,80
	1.802	€ 0,80
	1057	€ 0,80
	947	€ 0,80
	633	€ 0,80
	831	€ 0,80
	2.189 € 0,80
	422	€ 0,80
	250	€ 0,80
	581	€ 0,80
	372	€ 0,80
	1135	€ 0,80
	1002	€ 0,80
	1.092 € 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.306	€ 116,96
	15.167	€ 116,96
	6.060	€ 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	84	€ 460
P4 - Anal. Funz. / Team Leader e/o Analista di Processo	203	€ 368
P3 - Anal. Prog Senior	253	€ 276
P2 - Anal. Prog Junior	669	€ 221
P8 - Progettista Data Warehouse	132	€ 442
P7 - Business Process Re-engineer	153	€ 552
P6 - Esperto FP	88	€ 414
S2 - Data Base Administrator	101	€ 414

S1 - Sistemista Junior

101 € 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
	Frontespizio digitale	Java, J2EE, Oracle, Linux	AMS, NSS
	Servizi di
	cooperazione applicativa - Minute di	Java, J2EE, Oracle, DB2, Linux	AMS, NSS
	ruolo e Provvedimenti
	(SPC)
	Servizi di
Servizi per gli enti	cooperazione applicativa –	Xxxx, X0XX, Xxxxxx, XX0, Linux	AMS, NSS
	integrazione Giudici di
	Pace (SPC)
	Sospensione mandati	Xxxx, X0XX, Xxxxxx, XX0,	AMS, NSS
	di pagamento (48 bis)	Linux
	Applicativi a supporto	Xxxx, X0XX, Xxxxxx, XX0,	AMS, NSS
	Siebel on Demand	Linux, Siebel on Demand

Conto		di	Gestione	Java, J2EE, Oracle, DB2, Linux, Siebel on Demand				AMS, NSS
Servizi per gli AdR	Cartelle via PEC			Java, J2EE, Oracle, Linux				AMS, NSS
	Provvedimenti back end e procedure batch			Cobol, DB2, zOS				AMS, NSS
	Stato riscossione – Gestione flusso AdR ed Enti			Cobol, DB2, zOS				AMS, NSS
	Documenti procedure esecutive			Cobol, DB2, zOS, Java, J2EE, Oracle, Linux			DB2,	AMS, NSS
	Lampo AdR			Java, Linux	J2EE,	Oracle,	DB2,	AMS, NSS
	GEDO			Java, Linux	J2EE,	Oracle,	DB2,	AMS, NSS
	CIN			Java, Linux	J2EE,	Oracle,	DB2,	AMS, NSS
	Gestione telematico		plico	Java, Linux	J2EE,	Oracle,	DB2,	AMS, NSS
	Firma FUG	digitale	per	Java, Linux	J2EE,	Oracle,	DB2,	AMS, NSS
Servizi trasversali	Compensazione rimborsi (28 ter)			Java, Linux	J2EE,	Oracle,	DB2,	AMS, NSS
	Gestionale Stampe			Java, Linux	J2EE,	Oracle,	DB2,	AMS, NSS
	Portale statistico e datawarehouse			Java, J2EE, Oracle, Oracle BI, DB2, Linux				AMS, NSS

Tabella 5 - applicazioni oggetto dei servizi

3.2.1 Frontespizio digitale

Descrizione

Il servizio di Firma Digitale è accessibile via web dal portale di EQ ed è dedicato agli Enti e consente di firmare in modo digitale i frontespizi. In altri termini, consente agli enti servizio di firmare i frontespizi via web sul sito di EQ.

Il Frontespizio elettronico avrà pieno valore legale attraverso l’apposizione della firma digitale. Tramite l’apposizione della firma digitale sul documento Frontespizio e l’utilizzo della posta elettronica certificata, EQ garantisce l’integrità e l’autenticità del documento Frontespizio, attribuisce una data certa, certifica l’invio e l’avvenuta ricezione del documento stesso da parte dell’Ente nei tempi e nei modi previsti dalla normativa vigente (Decreto Ministeriale 321/99).

Per consentire all’ente di firmare digitalmente i documenti, EQ distribuisce le firme digitali e caselle di posta certificata (PEC).

Il servizio mette a disposizione dell’ente un sistema gestionale tramite il quale è possibile consultare le forniture nei diversi stati di lavorazione:

• Da vistare;

• In lavorazione;

• Vistate;

Effettuati gli opportuni riscontri, il firmatario dell’ente può procedere all’apposizione del visto digitale dei frontespizi inserendo il PIN di firma.

L’apposizione della firma sui frontespizi digitali, rende esecutivi i ruoli e darà automaticamente l’impulso alle fasi successive del processo, con l’invio agli AdR dei flussi dati dei ruoli.

I frontespizi firmati digitalmente rimarranno in linea per un breve periodo di tempo (fino a sei mesi o un anno), dopodiché saranno inseriti un sistema di conservazione digitale a norma di legge. I frontespizi archiviati, se richiesto, potranno essere estratti dal sistema.

Architettura

L’architettura di Frontespizio digitale contiene vari componenti.

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.

Frontespizio digitale utilizza un sistema HSM (Hardware Security Module) per conservare le firme digitali e renderle disponibili agli utenti, quando ne hanno necessità (ovvero nel momento di firma di un documento digitale). Le firme digitali sono gestite tramite un accordo con una CA (certification authority).

I documenti sono salvati su un sistema di archiviazione elettronica sostitutiva a norma, denominato CODIS (COnservazione DIgitale e Sostitutiva) di Agorà Telematica.

Frontespizio Digitale è interfacciato via CTG (Common Transaction Gateway) con procedure CICS su mainframe per attivare le procedure successive di produzione dei ruoli.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g ,

• Sistema operativo Linux Centos

• Archiviazione documentale: CODIS

• Interfaccia con mainframe: IBM CTG.

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.2 Servizi di cooperazione applicativa - Minute di Xxxxx e Provvedimenti

Descrizione

I servizi di cooperazione applicativa sul Sistema di Pubblica Connettività (SPC) consentono agli Enti dotati di porta di dominio (PDD) di:

• attivare la procedura di riscossione a mezzo ruolo tramite l’invio di minute di ruolo con il formato 450;

• esaminare l’avanzamento della lavorazione delle minute inviate;

• ricevere la minuta arricchita con il dettaglio delle posizioni messe a ruolo;

• inviare i provvedimenti su posizioni messe a ruolo;

• ricevere lo stato delle riscossione;

• altri servizi che consentono di conoscere gli stati delle varie richieste.

La figura seguente mostra i servizi esposti su PDD.

Web Services - EAR

FormazioneRuoloWS LavorazioneRuoloWS

ProvvedimentiWS

File

Protocollo

Provvedimento

InvioMinuta

RiepilogoRuoliVistati

SgravioDiscarico

Esito invio

File

Esito

Nome file

Protocollo

Provvedimento

ProtocolloMinuta

Ente

Sospensione

ListaStatoRiscossione

Esito

Lista nomi file

Protocollo

Stato

Provvedimento

StatoMinuta

Nome file

RevocaSospensione

StatoRiscossione

Esito

File

Protocollo

Provvedimento

MaggiorRateazione

EsitoMinuta

File

Esito

Provvedimento

Periodo

RevocaMaggiorRateazione

RiepilogoMinuteInviate

Lista nomi file

Esito

Provvedimento

Protocollo

AnnullaCoobbligato

MinutaArricchita

File

Esito

Identificativo

Protocollo

StatoProvvedimento

ListaRuoliPDF

Lista nomi file

Stato

Identificativo

Nome file

AnnullaProvvedimento

RuoliPDF

Esito

File

Richiesta Esito richiesta

AnnullaMinuta

File

EsitoMinutaArricchita

Esito invio

EqS

Ente

EqS

Ente

EqS

Ente

I servizi, mostrati in modo sintetico nella figura seguente, consentono:

• di conoscere se esistono dei procedimenti e ricorsi in carico al Giudice di Xxxx su cartelle emesse da EQ o verbali (di vigili urbani) associati a ruoli (del Comune);

• di conoscere le sentenze relative ai ricorsi;

• attivare quanto previsto nella sentenza o disposizione (in generale provvedimenti)

I servizi SPC relativi ai provvedimenti sono stati specializzati per consentire agli Enti di inviare sospensioni, discarichi e le relative revoche in modo massivo, piuttosto che in modo puntuale.

Altri attori stanno per entrare tra gli Enti autorizzati ad utilizzare questi servizi SPC, ma non sono previsti ulteriori modifiche mirate e dedicate al software.

Architettura

È previsto che le amministrazioni che intendono utilizzare i servizi SPC dichiarino le username dei soggetti incaricati e che questi siano registrati in un segmento LDAP dedicato.

I servizi, sono strutturati come WS e sono stati sviluppati in Java, usando il paradigma J2EE.

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.

Il sistema fa uso di code (di WAS) per gestire l’accesso controllato al database DB2.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g, DB2 v 7 acceduto mediante DB Link.

• Sistema operativo Linux Centos.

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.3 Servizi di cooperazione applicativa - Integrazione Giudici di Pace

Descrizione

Il servizio di cooperazione applicativa – Integrazione Giudici di Pace supporta la gestione degli atti emessi dall’Autorità Giudiziaria a seguito dei ricorsi presentati dal Contribuente contro i verbali di violazione alle norme del Codice della Strada.

L’obiettivo del sistema è quello di accorciare i tempi tra l’espressione (sospensioni e sentenze) del Giudice di Xxxx e la recezione delle stesse in EQ, per quanto riguarda provvedimenti di sospensione o di sgravio, in materia di violazione del codice della strada.

Il servizio prevede che si proceda come segue:

• Alla sospensione dei provvedimenti di esecuzione (in ottemperanza ex. Art. 22 Legge 689/81, Art. 615 e 617 c.p.c.) nel caso in cui l’Autorità Giudiziaria ne disponga la preventiva sospensione dell’esecutività prima dell’emissione della sentenza.

• Alla sospensione definitiva, totale o parziale, delle azioni esecutive intraprese in funzione dell’esito della sentenza emessa dall’Autorità Giudiziaria.

Inoltre il servizio supporta il processo di gestione dei provvedimenti emessi dall’ente (Comune) per effetto dei ricorsi presentati dai contribuenti contro i Verbali di violazione alle norme del Codice della Strada.

Il sistema prevede la cooperazione applicativa tra applicazioni di vari enti. I servizi di cooperazione applicativa sono esposti tramite Porta di Dominio.

I servizi di cooperazione applicativa che consentono il funzionamento del processo sono le seguenti:

1. EQ richiede al sistema del Giudice di Xxxx (nel seguito brevemente indicato come SIGP) l’elenco e dati dei ricorsi aggiornati, EQ utilizza un WS esposto dal SIGP.

2. EQ comunica a SIGP eventuali posizioni non comprese (scart), EQ utilizza un WS esposto da SIGP.

3. Il Comune richiede a EQ i dati relativi ad eventuali cartelle (associate a verbali di violazione del codice della strada) già emesse sulle quali sono stati rilevati ricorsi sul sistema SIGP; il Comune utilizza un WS esposto da EQ.

4. Il Comune invia provvedimenti di sospensione, sgravio o revoca della sospensione sui ruoli (cartelle), già emessi da EQ e sui quali il Giudice di Pace si è espresso; il Comune utilizza un WS esposto da EQ.

5. EQ comunica al Comune l’esito del processamento dei provvedimenti sottomessi; EQ utilizza un WS esposto dal Comune.

6. EQ consulta il database delle ordinanze e sentenze del Giudice di Xxxx (relativamente a quanto espressamente riguardante il gruppo Equitalia); l’operazione è possibile grazie al WS esposto dal sistema SIGP.

7. EQ consulta l’agenda delle udienze (a proposito di quanto espressamente riguardante il gruppo Equitalia); l’operazione è possibile grazie al WS esposto dal sistema SIGP.

Architettura

È previsto che le amministrazioni che intendono utilizzare i servizi SPC dichiarino le username dei soggetti incaricati e che questi siano registrati in un segmento LDAP dedicato.

I servizi, sono strutturati come WS e sono stati sviluppati in Java, usando il paradigma J2EE.

Il sistema fa uso di code (di WAS) per gestire l’accesso controllato al database DB2.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g, DB2 v 7 acceduto mediante DB Link.

• Sistema operativo Linux Centos.

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.4 Sospensione mandati di Pagamento (48 bis)

Descrizione

Il servizio Sospensione Mandati di Pagamento consente alle Pubbliche Amministrazioni di ottemperare all’obbligo stabilito dall’art. 48-bis D.P.R. n.602/73 di verificare, prima di effettuare il pagamento, se il beneficiario è inadempiente all'obbligo di versamento derivante dalla notifica di una o più Cartelle di Pagamento e, in caso affermativo, di segnalare la circostanza all'Agente della riscossione competente per territorio, ai fini dell'esercizio dell'attività di riscossione delle somme iscritte a ruolo.

Le fasi operative, finalizzate al completo svolgimento del servizio, sono le seguenti:

Trasmissione agli Agenti della riscossione del flusso contenente le richieste da sottoporre a verifica di persistente morosità;

Ricezione dell’eventuale intenzione a procedere con il recupero del credito da parte degli Agenti della riscossione;

Ricezione delle comunicazioni di riduzione delle morosità da parte degli Agenti della riscossione;

Allineamento ed elaborazione dei dati e conseguente comunicazione/autorizzazione agli Agenti della riscossione della presenza dei prerequisiti necessari per attuare le procedure esecutive;

Visualizzazione e notifica dello stato di lavorazione sulle singole richieste effettuate (tale funzione viene fruita dalle Pubbliche Amministrazioni tramite l’interfaccia Web messa a loro disposizione).

Architettura

L’architettura contiene sia componenti per l’interscambio di flussi con gli Agenti della Riscossione sia per il servizio WEB rivolto alle Pubbliche Amministrazioni.

La piattaforma software di trasmissione per lo scambio dei flussi informatici su mainframe è basata su IBM Tivoli Netview Ftp. Le relative fasi elaborative dei dati avvengono su mainframe utilizzando tabelle DB2

L’accesso ai servizi online da parte delle Pubbliche Amministrazioni è consentito tramite il Portale xxx.xxxxxxxxxxxxxxx.xx, al quale sono demandate le procedure di registrazione.

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 / Linguaggi

• Piattaforma Hardware: Mainframe IBM Z9

• Sistema operativo Z/OS versione 1.8

• Database: DB2 versione 8

• Change Management: Endevor

• Linguaggio di programmazione: Cobol3

• 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.5 Applicazioni di supporto al CRM

Descrizione

Nel contesto del contact center, al fine di efficientare la gestione delle richieste degli utenti finali dei servizi di EQ, sono stati sviluppati degli applicativi a supporto che sono utilizzati direttamente dagli operatori telefonici.

Questi applicativi sono:

• Leggimail: crea ticket automaticamente, importando i contenuti delle email e dei fax pervenuti agli indirizzi istituzionali;

• Creaticket: crea ticket in modalità semi-automatica a partire dall’anagrafica Cliente (Ente/ADR) ed eliminare automaticamente i ticket incompleti non salvati;

• InviaMail: permetter di inviare email con parti di testo preformattato e possibilità di inserire allegati, per l’invio della soluzione al cliente o per richiedere informazioni aggiuntive o per semplice inoltro di corrispondenza;

• AssegnazioneMassiva: cambiare o revocare il proprietario di uno o piu’ ticket, per far fronte all’assenza imprevista di un operatore.

Architettura

Gli applicativi Java utilizzano dei WebService messi a disposizione della piattaforma Siebel per istruire le operazioni di lettura dei dati e l’esecuzione di comandi come ad esempio la creazione de ticket.

L’autenticazione degli applicativi su Siebel è realizzata attraverso la verifica delle credenziali USR/PWD riportate nei file di properties degli applicativi.

Le chiamate dagli applicativi verso siebel on demad avvengono via Web Service, mentre i link dalla piattaforma siebel on demad verso gli applicativi è diretta con configurazione di apposite URL.

Gli applicativi sono inoltre collegati con il server di posta elettronica aziendale, i parametri per l’autenticazione sono configurati in appositi file di properties.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• WebService: Axis 1.4

• Application Server: IBM WAS.

• Database: Interno Siebel / Oracle

• Sistema operativo : Linux Centos,

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.6 Conto di Gestione

Descrizione

Il servizio Conto di gestione è accessibile via web dal portale di EQ e consente all’AdR di gestire la produzione e l’invio dei conti di gestione annuali, che sono una rendicontazione all’Ente delle attività della riscossione.

Il sistema permette di inserire una richiesta di produzione di conti di gestione multi ambito multi ente, verificare i documenti prodotti, certificarne il contenuto, firmarli digitalmente e consegnare i documenti agli enti con pubblicazione su servizio Ricezione dati e spedizione su PEC.

Il servizio è stato pensato per gli agenti della riscossione per semplificare il processo di gestione del documento Conto di gestione, consentendo agli utenti di interagire con il sistema attraverso un’applicazione web che fornisce tutte le funzioni necessarie allo svolgimento delle attività in carico alle competenti strutture aziendali.

Le principali funzioni che questo servizio consente sono le seguenti:

• Front end - Inserimento richieste di produzione dei conti di gestione

• Back end - Invio delle richieste tramite Spazio al sistema istituzionale CAD

• Back end - Presa in carico tramite Spazio dell’output dell’elaborazione lato CAD

• Front end - Verifica e certificazione contenuto dei conti di gestione prodotti

• Back end - Generazione conto di gestione aggregato per AdR

• Front end - Firma digitale dei conti di gestione

• Back end - Consegna all’ente del conto di gestione : pubblicazione su servizio Ricezione dati e spedizione via PEC.

Architettura

L’autenticazione è gestita dal portale di Equitalia 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, architettura multi-tier.

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

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.7 Cartelle via PEC

Descrizione

Il servizio consente di inviare cartelle e altre comunicazioni, attualmente inoltrate mediante raccomandata con ricevuta di ritorno, via posta elettronica certificata ai contribuenti che ne hanno fatto richiesta o che hanno una PEC (come ad esempio gli iscritti alle CCIAA).

L’applicazione sviluppata al momento in cui si scrive (giugno 2012) è costituita da una piattaforma che provvede alle seguenti funzioni di massima:

1. Gestione delle caselle di PEC

2. Gestione dei testi per ciascuna tipologia di comunicazione (ad esempio per i Fermi Amministrativi, Cartelle, ecc.)

3. Gestione della spedizione della comunicazione con gli allegati sul canale PEC

4. Gestione delle notifiche e comunicazione delle stesse secondo quanto rpevisto dai processi di riscossione.

Gli sviluppi futuri prevedono di interfacciare l’infrastruttura con i canali che producono gli allegati da trasmettere come ad esempio i Fermi Amministrativi, le cartelle e così via.

Architettura

Il sistema si compone di un database in Oracle dove sono registrati gli utenti, i loro indirizzi PEC e i processi per i quali hanno chiesto la notifica via PEC della comunicazione (come appunto la cartella).

Gli altri applicativi che implementano i vari processi verificano la presenza di un dato contribuente nel repository e in questo caso provvedono a inviare la comunicazione via PEC invece che con gli altri canali.

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.8 Provvedimenti back end e procedure batch

Descrizione

Si tratta di un insieme di programmi batch che gestiscono i provvedimenti acquisiti e li inoltrano agli AdR, per poi registrare l’esito di processamento degli stessi da parte dell’AdR.

I provvedimenti possono entrare nel sistema di EQ attraverso varie modalità:

1. Inseriti dagli enti via web mediante il servizio Provvedimenti Web

2. Inviati dagli Enti non telematici a mezzo file tramite Upload Provvedimenti

3. Inviati dagli Enti telematici (Agenzia delle Entrate, INPS e INAIL) mediante file txt contenente vari tipi record.

Nel primo caso le informazioni sono registrate dai sistemi citati su un database mainframe (DB2 V8) detto RUW.

Nel secondo caso, il file è verificato da un programma batch e registrato sul database mainframe (DB2 V8) detto PNT.

Nel terzo caso i provvedimenti sono verificati da un programma batch mainframe e quindi registrati su un database DB2 detto RUO.

Le procedure batch, nel caso di provvedimenti da enti non telematici, eseguono le seguenti operazioni:

1. Estrazione dei provvedimenti dal database RUW (solo quelli registrati mediante Provvedimenti Web)

2. Costruzione di un file intermedio

3. Registrazione del file intermedio su un database detto PNT

4. Estrazione dei provvedimenti dal database PNT (comprensivi sia di quelli pervenuti via Provvedimenti Web, sia di quelli da file)

5. Costruzione di un file intermedio

6. Registrazione del file intermedio sul database RUO.

Una volta che tutti i provvedimenti sono stati riportati nel database RUO, un nuovo batch provvede ad estrarre i provvedimenti (in questo caso sono tutti, quelli da ente non telematico e da ente telematico) e crea nuovi file intermedi, uno per ogni ambito AdR e per tipo di provvedimento. Tutti i vari file sono poi composti in file fisici (103 file, uno per ambito) e trasmessi all’AdR.

Una volta ricevuta la risposta dall’AdR, su un file fisico che raggruppa gli esiti delle elaborazioni dell’AdR stesso relativamente ai provvedimenti precedentemente trasmessi da EQ, altri programmi batch provvedono a:

1. Aggiornare lo stato del provvedimento nel database RUO (provvedimento acquisito o scartato dall’AdR)

2. Riportare l’informazione anche sul database PNT e RUW.

Architettura

Il sistema è rappresentato da un insieme di procedure mainframe (circa 10 programmi per tipo provvedimento, oltre a vari controlli) scritte in Cobol che leggono e scrivono sui vari database DB2 V8.

Tecnologia / Linguaggi

• Piattaforma Hardware: Mainframe IBM Z9

• Sistema operativo Z/OS versione 1.8

• Database: DB2 versione 8

• Change Management: Endevor

• Linguaggio di programmazione: Cobol3

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.9 Stato della Riscossione – Gestione flusso AdR ed Enti

Descrizione

Su base periodica, EQ deve informare gli Enti circa gli eventi della riscossione accaduti.

Per eventi della riscossione si intendono tutti quegli avvenimenti che interessano la riscossione, come ad esempio la formazione del ruolo, notifica della cartella, pagamenti, provvedimenti sul carico, procedure esecutive, ecc.

Poiché EQ non si occupa di riscossione, queste informazioni sono trasmesse dagli AdR a EQ tramite file txt mainframe strutturati a tipo record diversi.

Il processo di rendicontazione agli Enti comincia con la ricezione dei file di stato della riscossione dai vari AdR. In generale ogni ambito trasmette un file con tutti gli eventi registrati per ciascun Ente.

Una sequenza di processi batch mainframe elabora i file dagli AdR come segue:

1. Analisi dei file inviati dagli AdR e controllo di consistenza dello stesso secondo quanto previsto nei documenti tecnici.

2. Qualora il file sia consistente si procede a smontare lo stesso e a raggruppare le informazioni per Ente.

3. Tutte le informazioni per un dato Ente, provenienti da tutti gli ambiti, sono montate in un unico file.

4. I file per ente così ottenuti sono recapitati ad Agenzia delle Entrate

5. Acquisizione da Agenzia dell’Entrate dell’esito di validità del file prodotto per ciascun Ente

6. Trasmissione a ciascun ente del file di stato della riscossione validato anche da Agenzia delle Entrate.

Qualora nel processo di elaborazione dei dati degli AdR e di loro composizione in un file di Stato della Riscossione per Ente si abbia un qualsiasi tipo di scarto, l’AdR dovrà provvedere alla trasmissione di un correttivo.

I file di stato della riscossione per gli Enti sono pubblicati su web e resi accessibili agli Enti tramite il servizio di Download Generalizzato.

File di stato della riscossione particolarmente rilevanti possono essere masterizzati su CD – Rom e inviati all’Ente per posta.

Architettura

Lo spostamento dei file da AdR a EQ e da EQ ad Agenzia delle Entrate, avviene tramite Netview – FTP.

La pubblicazione dello stato della riscossione su web avviene grazie a SPAZIO.

Per il resto il processamento dei dati e la produzione dello stato della riscossione è possibile mediante un insieme di programmi batch scritti in Cobol e concatenati tra di loro.

Tecnologia / Linguaggi

• Piattaforma Hardware: Mainframe IBM Z9

• Sistema operativo Z/OS versione 1.8

• Database: DB2 versione 8

• Change Management: Endevor

• Linguaggio di programmazione: Cobol3

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.10 Documenti procedure esecutive - CSE

Descrizione

Si tratta di un insieme di processi batch sia mainframe che dipartimentale che hanno come obiettivo l’acquisizione di ordini di stampa inviati dagli AdR e quindi il loro processamento fino alla stampa.

Sebbene EQ ha avviato un progetto che ha come obiettivo la sostituzione di questa attuale soluzione con un nuovo sistema informatico (denominato Piattaforma Centralizzazione Stampe - PCS, non oggetto di questa fornitura), considerato che i vari tipi di documento saranno portati su PCS nel corso del tempo, potrà essere necessario affidare attività di manutenzione e nuovi sviluppi anche sul sistema CSE all’aggiudicatario di questa gara.

Il sistema CSE esegue la stampa dei documenti procedure esecutive o più in generale esattoriali, attraverso le seguenti operazioni:

1. Acquisizione dell’ordine di stampa dall’AdR, tipicamente un file txt formattato mainframe contenente tipi record multipli.

2. Un programma Cobol su mainframe esegue un controllo del file e determina se la lavorazione può proseguire o se deve essere scartato.

3. Nel caso in cui la lavorazione può proseguire, il sistema procede a produrre informazioni intermedie che saranno poi impiegate per il processo di stampa.

La stampa massiva dei documenti in CSE avviene grazie a CSF Classic (su ambiente mainframe) o CSF Designer in ambiente dipartimentale.

Una volta prodotti i file intermedi per la stampa su mainframe o su dipartimentale si procede con la pubblicazione di provini di stampa e di file di statistiche di controllo.

Architettura

Il sistema è principalmente operante su mainframe, dove procedure batch Cobol eseguono analisi del file inviato e operano trasformazioni dei dati utili per i successivi processi di stampa.

Nel caso la stampa sia operata con CSF Classic, l’operazione prosegue su mainframe: Quando la stampa è eseguita con CSF Designer, un file intermedio è spostato su dipartimentale (tramite SPAZIO) e quindi processato.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

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

• Sistema operativo Linux Centos,

• Sistema di trasporto dati: SPAZIO Primeur

• 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.11 Lampo AdR

Descrizione

Lampo AdR è un servizio transazionale web erogato tramite il portale di EQ, a favore degli AdR.

Il servizio consente la gestione dei provvedimenti di dilazione di pagamento per gli enti telematici (Agenzia entrate, Inps ed Inail) e per gli altri enti che non dichiarino espressamente di voler continuare ad emettere in autonomia i suddetti provvedimenti.

Le principali funzioni sono:

• Protocollazione: selezione delle cartelle e dei tributi per codice fiscale, assegnazione protocollo univoco, invio provvedimenti di sospensione al sistema dell’agente, invio telematico dell’informazione agli enti che ne hanno fatto richiesta (le sospensioni al momento non vengono inviate);

• Analisi della posizione: verifica completezza e correttezza della documentazione presentata dal contribuente, verifica situazione di temporanea difficoltà, stampa del preavviso di rigetto o del rigetto, annullamento del protocollo per motivi di ufficio;

• Acquisizione della dilazione: selezione delle cartelle e dei tributi, calcolo importi del piano di dilazione (capitale residuo, aggio, mora, spese) tramite i dati forniti dai servizi degli AdR, impostazione dei dati per il calcolo del piano (numero rate, scadenza prima rata, , stampa del modulo di accoglimento parziale/totale;

• Approvazione della dilazione: verifica congruenza dati, invio provvedimenti di dilazione e revoca della sospensione sul sistema dell’agente, invio dell’informazione agli enti che ne hanno fatto richiesta;

• Gestione revoca dilazione: invio provvedimenti di revoca della dilazione sul sistema dell’agente, invio dell’informazione agli enti che ne hanno fatto richiesta.

Altre funzioni disponibili agli utenti sono:

• Stampa dei RAV allo sportello

• Stampa massiva dei RAV per successiva spedizione ai contribuenti

• Funzione di verifica e supporto alla correzione degli indirizzi dei contribuenti a cui spedire i RAV.

• Funzioni di abilitazione e disabilitazione delle funzioni di stampa su singolo protocollo.

• Stampa massiva dei piani di rateazione.

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.

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.

Fanno parte di Lampo AdR alcuni batch Java che provvedono all’estrazione dei dati su file e il loro invio al mainframe tramite SPAZIO di Primeur.

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 su zOS interfacciato con 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.12 GEDO

Descrizione

Il …..

Architettura

………

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.13 CIN

Descrizione

Il …..

Architettura

………

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.14 Firma digitale per Plico telematico

Descrizione

Il Plico telematico è un servizio di back end di firma digitale che consenta agli agenti della riscossione di firmare digitalmente il documento “plico telematico” ed i documenti in esso contenuti, accedendo in sicurezza agli HSM dell’infrastruttura di firma digitale Equitalia. Il documento Plico telematico è prodotto dal Servizio chiamante Gestore procedure immobiliari.

Le principali funzioni che questo servizio consente sono le seguenti:

• Gestione della chiamata da parte del sistema Gestore procedure immobiliari e presa in carico degli hash dei documenti da firmare;

• Presentazione su front end del form per l’inserimento del PIN di firma da parte dell’utente;

• Firma digitale degli hash dei documenti ricevuti;

• Restituzione degli hash firmati al Gestore procedure immobiliari;

Architettura

L’autenticazione dell’utente avviene alla chiamata HTTPS del sistema Gestore procedure immobiliari tramite Datapower. L’applicazione è sviluppata in Java, usando il paradigma J2EE e il pattern MVC, architettura multi-tier.

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

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,

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.15 Firma digitale per FUG

Descrizione

Il servizio di firma digitale per FUG consente alle strutture organizzative di Equitalia giustizia di firmare digitalmente i documenti relativi alle “disposizioni di restituzione” emesse dalla stessa società. Il servizio prende in carico i documenti da firmare prodotti dal sistema Fondo unico giustizia, consente l’apposizione della firma digitale agli stessi documenti e consente la loro ripresa in carico all’interno del sistema Fondo unico giustizia tramite funzione di download.

Per le attività di back-end, che vedono coinvolti i sistemi Equitalia e Sogei, sono previsti i seguenti servizi:

1. acquisizione documenti da firmare;

2. aggiornamento dei documenti da firmare;

3. verifica stato della pratica;

4. modifica stato della pratica;

5. annullamento richiesta apposizione firma (annullamento documento);

6. download del documento firmato.

Il sistema contempla anche le seguenti funzioni di amministrazione : Profilo Amministratore:

• Funzionalità “Posta Elettronica Certificata”

• Funzionalità “Gestione attivazione firma”

• Funzionalità “Profilazione Utente”

• Funzionalità di attivazione di certificati già presenti

• Funzionalità di ricerca documenti

• Funzionalità di Visualizzazione e download dei documenti (firmati o da firmare)

Profilo Utente:

• Funzionalità “Posta Elettronica Certificata”

• Funzionalità “Gestione attivazione firma”

• Funzionalità di ricerca documenti

• Funzionalità di apposizione di firma singola/multipla

• Funzionalità di Visualizzazione e download dei documenti (firmati o da firmare)

Architettura

L’architettura di riferimento per il progetto “Fondo Unico EqG” è progettata in base ai paradigmi SOA e prevede alcuni moduli di back-end, necessari per le comunicazioni tra Equitalia e Sogei e per le operazioni asincrone di firma, e un modulo di front-end.

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.16 Stampa Proposte di Compensazione (ex art. 28-ter)

Descrizione

Il servizio prevede l’elaborazione, la stampa tipografica e la postalizzazione delle Proposte di Compensazione (ex. art. 28 ter) che consentono all’Agente della riscossione di “proporre” al contribuente il pagamento di debiti iscritti a ruolo utilizzando crediti d’imposta di cui lo stesso contribuente risulta beneficiario.

Il servizio consente, inoltre, di allegare alle Proposte di Compensazione (ex. art. 28 ter) un volantino personalizzato nel quale sono riportate le comunicazioni che l’Agente della riscossione intende recapitare al contribuente.

Il rapporto con le tipografie che effettuano le stampe è gestito direttamente da EQ, che ne controlla i processi operativi interni e cura le fasi di imbustamento e spedizione, allo scopo di assicurare la qualità delle Proposte di Compensazione stampate.

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.

Le fasi di elaborazione degli spool di stampa avviene su piattaforma CSF Designer utilizzando l’architettura AFP per l’ottenimento degli spool tipografici

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.17 Gestionale Stampe

Descrizione

Il servizio di cooperazione applicativa – Gestionale Stampe supporta l’ufficio Gestione Stampe di EQ nella gestione dei processi di elaborazione e stampa a partire dalla richiesta da parte degli AdR fino alle fasi di spedizione dei documenti e fatturazione attiva e passiva.

Il macroprocesso quindi può essere visto come segue:

• Il Gestionale Stampe colleziona dati da diverse fonti alimentanti durante varie fasi del processo elaborativo della stampa. Tali dati vengono memorizzati in un DB e resi fruibili tramite opportune viste create dagli utenti stessi per il monitoraggio del processo.

• Il Gestionale Stampe per tutta la durata del processo di elaborazione e stampe, riceve aggiornamenti di stato legati alle varie fasi del processo in modo da tenere traccia dello stato avanzamento lavori delle richieste di stampa.

• Il Gestionale Stampe fornisce agli utenti, oltre alle funzionalità di consultazione e monitoraggio, anche la possibilità di eseguire operazioni “attive”, quali l’invio in tipografia, la generazione delle distinte cartacee, il censimento dei controlli tipografici, la generazione delle bolle per la fatturazione sia verso i service di stampa che verso gli AdR.

• Il Gestionale Stampe fornisce agli utenti il monitoraggio di SLA e Alert con l’obiettivo di monitorare eventuali ritardi e/o anomalie nella gestione di una richiesta di stampa.

Di seguito due sequence diagram che descrivono il processo di stampa monitorato e gestito dal servizio Gestionale Stampe:

Figura 1 - Macroprocesso: Aggiornamento dati

Figura 2 - Macroprocesso: Gestione Tipografia

Architettura

Il sistema Gestionale Stampe è composta da:

- Application Server – L’insieme dei servizi e delle applicazioni Web che costituiscono la componente applicativa del sistema.

- Database Server – La base dati del sistema.

Applicazioni Enterprise:

Configurazione
GestioneStampeEar.ear	Applicazione Web per la gestione della attività di stampa dei prodotti in arrivo dalle AdR.
GestioneStampeWSEar.ear	Contiene i servizi esposti dal Gestionale Stampe per ricevere le nuove lavorazioni, gestire i benestare e ricevere i ritorni dalle tipografie

I servizi interessati dal progetto Gestionale Stampe sono i seguenti:

- Servizio di Acquisizione Lavorazione: Servizio esposto dall’applicazione GestioneStampeWSEar per l’acquisizione di nuove lavorazioni in arrivo dagli AdR.

- Servizio di Benestare Provini: Servizio esposto dall’applicazione GestioneStampeWSEar per la gestione dei benestare dei provini da parte di EQ e AdR

- Servizio di Scarto Provini: Servizio esposto dall’applicazione GestioneStampeWSEar per la gestione degli scarti dei provini da parte di EQ e AdR

- Servizio Ritorno flusso da tipografia: Servizio esposto dall’applicazione GestioneStampeWSEar per la ricezione dei flussi xml di ritorno dalla tipografia

- Servizio Chiusura Ticket OTRS: Servizio esposto dall’applicazione GestioneStampeWSEar per la ricezione della comunicazione di chiusura dei ticket da parte del sistema OTRS

- Servizio Caricamento Cartelle: Servizio esposto dall’applicazione GestioneStampeWSEar per il caricamento giornaliero delle nuove cartelle arrivate sulla tabella di DB2 RICH_ESTRAZ

- Servizio Previsione settimanale: Servizio esposto dall’applicazione GestioneStampeWSEar per il calcolo e l’invio delle previsioni di stampa settimanali

- Servizio Previsione mensile: Servizio esposto dall’applicazione GestioneStampeWSEar per il calcolo e l’invio delle previsioni di stampa mensili

- Servizio Report del giorno dopo: Servizio esposto dall’applicazione GestioneStampeWSEar per la produzione e l’invio del report del giorno dopo (documento pdf da inviare alle singole tipografie)

- Servizio Esito invio file AFP tramite cruscotto: Servizio esposto dall’applicazione GestioneStampeWSEar per la ricezione dell’esito dell’invio (dei soli prodotti inviati tramite cruscotto) da parte dell’applicazione Cruscotto.

Il gestionale stampe produce un resoconto giornaliero per ogni tipografia creando un report pdf, che viene inviato alle singole tipografie. Nel report vengono riportate tutte le comunicazioni intercorse durante la giornata precedente tra EQ e le tipografie (invii di lavorazioni da equitalia, stato delle lavorazioni dalle tipografie). Gli indirizzi email vengono letti dalla tabella dedicata alle tipografie presente in Oracle.

Tecnologia e linguaggi

• Linguaggio: Java, J2EE;

• Application Server: IBM WAS

• Database: Oracle RAC 11g, DB2 v 8 acceduto mediante DB Link.

• Sistema operativo Linux Centos.

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.18 Portale Statistico

Descrizione

Il servizio “Portale Statistico” è accessibile via web dal portale di EQ ed è composto da aree di analisi, report e cruscotti.

Le aree di analisi utilizzano i dati dei sistemi operazionali a cui afferiscono. In particolare il servizio consente di:

Visualizzare tutte le pagine ed i report a cui l’utente ha accesso e scaricarli nei seguenti formati:

o HTML

o PDF

o Excel

o Powerpoint

o Excel2000

o Dati (estensione .csv)

o Web (MHTML)

o Word (.rdf)

Gestire il data entry per dati proprietari

Architettura

L’applicazione è sviluppata utilizzando le componenti di Oracle Business Intelligence Enterprise Edition Plus 10g, 11g.

Il database è Oracle 10g e Oracle 11g RAC ed è alimentato, tramite processi ETL, da fonti dati sorgenti eterogenee.

Tecnologia e linguaggi

• Linguaggio: SQL, PL/SQL, Shell

• Application Server: IBM WAS

• Database: Oracle 10g, 11g RAC

• Middleware: Oracle Business Intelligence Enterprise Edition Plus 10g, 11g

• Oracle BI Server

• Oracle Bi Answers

• Oracle BI Interactive Dashboard

• Oracle BI Delivers

• Oracle BI Publisher

• Sistema operativo Linux Centos, AIX Version 5.3

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.2.19 Datawarehouse

Descrizione

Il servizio è accessibile via web dal portale di EQ ed è composto dalle seguenti applicazioni di reporting:

• Programmazione Operativa

• Monitoraggio Processi

• Monitoraggio Produzione

• Monitoraggio Flussi

• Riassunti alla provincia

Architettura

L’applicazione è sviluppata in java e Oracle*Report Builder (componente di Oracle*Developer Suite)

Il database è Oracle 10g e Oracle 11g RAC ed è alimentato, tramite processi ETL da file.

Tecnologia e linguaggi

• Linguaggio: SQL, PL/SQL, Shell, java

• Database: Oracle 10g, 11g RAC

• Middleware: Oracle Developer Suite - Oracle Report Builder

• Sistema operativo Linux Centos, AIX Version 5.3

Tipologia di interventi

Sono previsti interventi di AMS e di NSS.

3.3 Ambienti

EQ si è dotata di vari ambienti software che sono xxx xxx xxxxxxxxx xxxxx xxxx 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
XXXX	X0.X0X0	X0.X0X0
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
Application Server
	IBM WebSphere Application Server Network Deployment 6.1.0.x
	JBoss Application Server 4.2.x / 5.1.x

ESB e BPM
	IBM BPM – Lombardi Edition
	WSO2
	JBPM
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 Roma, Via Xxxxxxxxx Xxxxx n.124 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
P2a	Anal. Prog. Junior Cobol	2
P2b	Anal. Prog. Junior	3
P8	Progettista Datawarehouse	2
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	43%
P8 – Progettista datawarehouse	2%
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	61%	48%	31%
P8 – Progettista datawarehouse	2%	2%	3%
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:

o della definizione del team di lavoro per l’esecuzione dell’intervento richiesto;

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

o del rispetto dei tempi di consegna previsti dalla pianificazione dell’intervento;

o 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 Xxxxx;

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

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

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

• aver sviluppato utilizzando il DBMS Oracle RAC 11g;

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

o IBM WAS

o JBoss

o DBLINK

o WSO2

o 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 Xxxxx;

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

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

• aver realizzato soluzioni software mediante IBM – BPM e in particolare il modulo definito “Lombardi”;

• aver utilizzato IBM Blueworks per la definizione dei processi;

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

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

• aver sviluppato utilizzando il DBMS Oracle RAC 11g;

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

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

o IBM WAS

o JBoss

o DBLINK

o 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 Xxxxx;

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

o IBM WAS

o JBoss

o DBLINK

o Soluzioni di middleware (ESB) come ad esempio JBoss ESB

o Websphere Host Access Transformation (HATS)

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

o IBM Blueworks

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

7.2.9 P8 – Progettista datawarehouse

Si tratta della figura che si occuperà delle attività relative al portale statistico e datawarehouse

Requisiti minimi

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

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

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

• conoscenza della soluzione Oracle BI maturata in almeno 3 anni di esperienza su questo prodotto specifico.

• aver definito e costruito architetture e soluzioni di ETL e architetture dati finalizzate a datawarehouse e business intelligence, avendo partecipato a vari progetti per un tempo minimo di 2 anni.

• conoscenza approfondita di applicazioni informatiche con architetture tecniche ed aspetti funzionali analoghe a quelle descritte nella presente specifica, maturata attraverso varie esperienze di progetto, con capacità di soluzione di problematiche complesse;

7.2.10 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.11 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.12 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.

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

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

7.2.14 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

7.2.15 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

7.3 Requisiti migliorativi

Fermo restando quanto sopra, il Concorrente, nel rispetto di quanto previsto nell’ “Allegato 3 – Schema Offerta tecnica lotto 2”, 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 proposte, 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:

o Nome dell’applicazione

o Specifiche tecniche dell’intervento;

o Milestone e relativi rilasci attesi.

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

o nome_applicazione = applicazione interessata all’intervento

o aa = anno

o 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à

* È 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.

di affidamento del singolo intervento, di accettazione delle attività prestate e di determinazione del valore dell’intervento.

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:

o 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, 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 Xxxxx Xxxxx), con le modalità di seguito riportate:

o l’impegno stimato per le attività di rilascio in esercizio di un progetto di sviluppo è pari a 0,02 gg/p per ogni FP;

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

o 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:

o Avvio del progetto

o Consegna dei requisiti utente

o Consegna dell’analisi tecnica di dettaglio e del piano di test

o Avvio dello sviluppo

o Conclusione delle implementazioni

o Consegna della documentazione tecnica (manuale operatore, manuale utente, manuale installazione, ecc.)

o Supporto nel setup dell’ambiente di collaudo

o Rilascio software per il collaudo (pronti al collaudo)

o Avvio della messa in esercizio

o Apertura all’esercizio e inizio dell’attività in modo supervisionato

o Avvio all’esercizio “ordinario”

o Eventuale assistenza post avvio (se richiesto)

o Eventuale data di inizio formazione (se richiesta)

o Eventuale data di fine della formazione (se richiesta)

o 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

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

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

o 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:

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

o il software realizzato supera con esito positivo il collaudo di accettazione di EQ.

o 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:

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

o del numero totale di FP realizzati, comprese quindi le eventuali variazioni (Change Request

– CR) richieste o approvate da EQ;

o se l’intervento è stato eseguito per l’intero ciclo di vita del progetto o solo per la prima fase;

o 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:

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

o 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 A – Schema Offerta tecnica lotto 1”, per l’ambiente tecnologico relativo al progetto.

Il rapporto percentuale sarà calcolato con la seguente formula:

Esempio

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

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)

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

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

o 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 A – Schema Offerta tecnica lotto 1”, 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:

o Descrizione dell’attività

o Data prevista per l’avvio delle attività;

o Documentazione necessaria alla valutazione delle attività richieste;

o Ambiente tecnologico di riferimento;

o Milestone e relativi rilasci, ponendo particolare attenzione ai seguenti aspetti:

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

o perimetro utente;

o 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):

o Codifica interna dell’attività

o Codice RDM/RDS

o Breve descrizione

o Richiedente (struttura, nome e cognome)

o Assegnatario (nome e cognome)

o Stato attuale

o Data di apertura

o Data consegna piano di lavoro

o Effort, strutturato in:

o Function Point

o Giornate uomo per figura professionale, per gli interventi di Supporto Specialistico.

o Data prevista di consegna del collaudo

o Data effettiva di consegna del collaudo

o Numero di sedute di collaudo effettuate

o Data effettiva di accettazione

o Riferimento del responsabile EQ (nome e cognome) per il collaudo

o Note eventuali

o Nell’intestazione del report devono sempre essere riportati:

o Nome del Fornitore

o Data di redazione

o 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:

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

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

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

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

o 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):

o sia stato correttamente commentato;

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

o sia nel complesso comprensibile (correttamente innestato, ecc.);

o 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, 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 nei 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:

o rispetto degli standard di EQ per i vari rilasci;

o completezza e qualità dei contenuti dei rilasci;

o il rispetto delle milestone pianificate;

o 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 C.

Nell’ambito delle risorse professionali costituenti il pool, il Fornitore definirà il team di lavoro impiegato nell’esecuzione dei servizi AMS nonché il team di lavoro relativo al singolo intervento di NSS che verrà, di volta in volta, affidato al Fornitore stesso, sulla base delle effettive esigenze di 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

Indice di produttività

FP per ciclo

completo affidamento totale (analisi +

realizzazione)

di vita ridotto affidamento sola

realizzazione.

Applicazioni J2EE o

MS ad alta intensità elaborativa

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 dal Fornitore 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

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

0 - Emergenza	8 ore lavorative
1 - Grave	16 ore lavorative
2 - Normale	32 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

Casi recidivi

IQ2.03

1 caso al mese

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

Consegna in risposta a

RDA

5 giorni lavorativi

Consegna in caso di

richiesta di modifica

3 giorni lavorativi

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

Consegna proposta d’intervento di Sviluppo Software, o di Supporto Specialistico.

IQ3.02

Rispetto della pianificazione

dell’intervento

IQ3.03

0 (zero) giorni lavorativi di ritardo

Ritardo per approvazione documento di analisi o del

software

IQ3.04

0 (zero) giorni lavorativi di ritardo

Casi di test negativi in collaudo

IQ3.05

0 (zero) casi di test negativi

Rispetto degli standard

documentali

IQ3.06

0 (zero) documenti fuori standard

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++

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

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 A – Schema Offerta tecnica lotto 1”, 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:

o Essere installata in EQ, non sono considerate percorribili soluzioni applicative fisicamente installate presso il Fornitore e accessibili da EQ via web.

o Il database deve essere ben documentato e consentire di estrarre facilmente i dati per eventuale migrazione su altro sistema.

o Non determinare alcun maggior onere per EQ (no costi di licenze, di manutenzione, ne di supporto all’installazione e quant’altro).

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

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

o 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

Allegato 1B – Capitolato Tecnico Lotto 2

Document Metadata