Il presente documento è conforme all'originale contenuto ... · PDF fileOTMA Open...

Il presente documento è conforme all'originale contenuto negli archivi della Banca d'Italia

Firmato digitalmente da

Sede legale Via Nazionale, 91 - Casella Postale 2484 - 00100 Roma - Capitale versato Euro 156.000,00 Tel. 06/47921 - telex 630045 BANKIT - Partita IVA 00950501007 - www.bancaditalia.it

http://www.bancaditalia.it/�

G858 - 009/12 – Pag. 1 di 97

Allegato 1

CAPITOLATO TECNICO

Procedura aperta per l’Evoluzione di Servizi Applicativi Generalizzati (ESAG)

per lo scambio di flussi informativi

G858 - 009/12

G858 - 009/12 – Pag. 3 di 97

AVVERTENZE

La pubblicità degli atti di gara è preordinata in via esclusiva a esigenze di imparzialità e trasparenza dell’attività amministrativa. È vietato, e sarà perseguito ai sensi di legge, qualsiasi utilizzo, totale o parziale, del materiale pubblicato, che sia difforme da tale finalità. La pubblicazione dei documenti avviene nel rispetto della normativa in materia di protezione dei dati personali e dei diritti di privativa. In nessun modo la pubblicazione, infatti, intende costituire violazione dei diritti di privativa da cui sono coperti i prodotti citati negli atti pubblicati, come creazioni intellettuali o invenzioni industriali in uso presso la Banca. Allo stesso modo è vietato, e sarà perseguito ai sensi di legge, qualsiasi utilizzo, totale o parziale, da parte di terzi, del materiale pubblicato, che miri a costituire un vantaggio indiretto o pubblicità ingannevole nei confronti del pubblico ovvero ad appropriarsi della proprietà intellettuale altrui.

G858 - 009/12 – Pag. 4 di 97

INDICE

GLOSSARIO 7

INTRODUZIONE 9

1 SEZIONE PRIMA - SITUAZIONE ATTUALE 10

1.1 LA GESTIONE DEI FLUSSI DI DATI 10 1.2 LA GESTIONE DEI TABULATI 12

2 SEZIONE SECONDA - SOLUZIONE RICHIESTA 17

2.1 ARCHITETTURA DI RIFERIMENTO 17 2.2 ESAG SUITE 18 2.2.1 GESTIONE ACCESSO 18 2.2.2 GESTIONE FLUSSI 19 2.2.3 SERVIZI FLUSSI 21 2.2.4 GESTIONE BASE DATI FLUSSI 23 2.2.5 GESTIONE TABULATI 24 2.2.6 SERVIZI TABULATI 26 2.2.7 GESTIONE BASE DATI TABULATI 29 2.2.8 SERVIZI SUPPORTI FISICI 31 2.3 ESAG U2A 33 2.3.1 INTERFACCIA UTENTE FLUSSI 33 2.3.2 INTERFACCIA UTENTE TABULATI 36 2.4 ESAG A2A 40 2.4.1 INTERFACCIA ASF 40 2.4.2 INTERFACCIA GARI 41 2.4.3 INTERFACCIA TWS 42 2.4.4 INTERFACCIA NETVIEW FTP 42 2.4.5 INTERFACCIA FAGDD 43 2.4.6 INTERFACCIA APMAIN 44 2.4.7 INTERFACCIA IC 45 2.4.8 INTERFACCIA LPTAB 46 2.5 REQUISITI NON FUNZIONALI 48 2.5.1 REQUISITI TECNOLOGICI E D’INTEGRAZIONE 48 2.5.2 REQUISITI DI SICUREZZA 49 2.5.3 REQUISITI PRESTAZIONALI 50

3 SEZIONE TERZA - OGGETTO DELLA FORNITURA 53

3.1 LICENZE D’USO DEL SOFTWARE 53 3.2 SERVIZI DI MANUTENZIONE DEL SOFTWARE 54 3.3 SERVIZI PROFESSIONALI NELLA FASE DI PROGETTO 54 3.3.1 PIANIFICAZIONE E PROGETTAZIONE 57 3.3.2 REALIZZAZIONE 58 3.3.3 COLLAUDO 59

G858 - 009/12 – Pag. 5 di 97

3.3.4 MIGRAZIONE DEI FLUSSI E DEI TABULATI 60 3.3.5 ASSISTENZA ALL’AVVIO 60 3.4 SERVIZI PROFESSIONALI NELLA FASE DI STABILIZZAZIONE 61 3.4.1 SERVIZIO DI PRESIDIO E REPERIBILITÀ 62 3.5 SERVIZI PROFESSIONALI NELLA FASE DI ESERCIZIO 63 3.5.1 SERVIZI DI ASSISTENZA SISTEMISTICA DI TIPO ”EVOLUTIVO” 63 3.5.2 SERVIZI DI ASSISTENZA SISTEMISTICA DI TIPO ”CORRENTE” 64

4 SEZIONE QUARTA – CONDIZIONI DI EROGAZIONE DELLA FORNITURA 65

4.1 MODALITÀ DI PAGAMENTO 65 4.2 LIVELLI DI SERVIZIO (SLA) 67 4.3 PENALI 68

ALLEGATO A. LE APPLICAZIONI INGE/PEGASO/GESPED 70

ALLEGATO B. L’APPLICAZIONE FAGDD 81

ALLEGATO C. FIGURE PROFESSIONALI DEL FORNITORE 88

ALLEGATO D. DOCUMENTAZIONE RICHIESTA 91

FIGURE Figura 1 - Attuale architettura per lo scambio dei dati tramite INGE, PEGASO e GESPED ......11 Figura 2 - Attuale architettura per la distribuzione dei tabulati ....................................................13 Figura 3 - Componenti Logici di ESAG .......................................................................................17 Figura 4 - Progetto ESAG .............................................................................................................56 Figura 5 - Piano di massima del progetto......................................................................................58 Figura 6 - Elementi di notazione ArchiMate.................................................................................70 Figura 7 - INGE Global View .......................................................................................................71 Figura 8 - INGE Consegna e Ricezione ........................................................................................73 Figura 9 - INGE Acquisizione ......................................................................................................75 Figura 10 - PEGASO Global View ...............................................................................................77 Figura 11 - PEGASO Produzione Flusso Dati ..............................................................................78 Figura 12 - GESPED Produzione Flusso Supporti Magneto-ottici...............................................80

TABELLE Tabella 1 – ESAG Suite - Requisiti “Gestione Accessi” ..............................................................19 Tabella 2 – ESAG Suite - Requisiti “Gestione Flussi” .................................................................21 Tabella 3 – ESAG Suite - Requisiti “Servizi Flussi” ....................................................................23 Tabella 4 – ESAG Suite - Requisiti “Gestione Basi Dati Flussi” .................................................24 Tabella 5 – ESAG Suite - Requisiti “Gestione Tabulati” .............................................................26 Tabella 6 – ESAG Suite - Requisiti “Servizi Tabulati” ................................................................28 Tabella 7 – ESAG Suite - Requisiti “Gestione Base Dati Tabulati”.............................................31 Tabella 8 – ESAG Suite - Requisiti “Servizi Supporti Fisici”......................................................32 Tabella 9 – ESAG U2A - Requisiti “Interfaccia Utente Flussi" ..................................................36 Tabella 10 – ESAG U2A - Requisiti Interfaccia Visualizzazione Tabulati" ...............................38 Tabella 11 – ESAG U2A - Requisiti Interfaccia Stampa Tabulati ..............................................39

G858 - 009/12 – Pag. 6 di 97

Tabella 12 – ESAG U2A - Requisiti Interfaccia Disegno Tabulati ..............................................39 Tabella 13 – ESAG A2A - Requisiti "Interfaccia ASF" ...............................................................40 Tabella 14 – ESAG A2A - Requisiti “Interfaccia GARI” ............................................................41 Tabella 15 – ESAG A2A - Requisiti “Interfaccia TWS”..............................................................42 Tabella 16 – ESAG A2A - Requisiti "Interfaccia Netview FTP" .................................................43 Tabella 17 – ESAG A2A - Requisiti Interfaccia FAGDD............................................................44 Tabella 18 – ESAG A2A - Requisiti Interfaccia APMAIN ..........................................................45 Tabella 19 – ESAG A2A - Requisiti Interfaccia IC......................................................................46 Tabella 20 – ESAG A2A - Requisiti Interfaccia LPTAB .............................................................47 Tabella 21 – ESAG Requisiti Architetturali e di Integrazione......................................................49 Tabella 22 – ESAG Requisiti Sicurezza .......................................................................................49 Tabella 23 – ESAG Requisiti Prestazionali Flussi........................................................................50 Tabella 24 – ESAG Requisiti Prestazionali Tabulati ....................................................................52 Tabella 25 – Tipologie di pagamento............................................................................................65 Tabella 26 - Documenti di chiusura macro-fasi ............................................................................66 Tabella 27 – Modalità di pagamento.............................................................................................66 Tabella 28 – Tempi massimi di intervento...................................................................................67 Tabella 29 – Tempi massimi di ripristino .....................................................................................67 Tabella 30 – Penali per tempistiche di progetto ............................................................................68 Tabella 31 – Standard ASA code ..................................................................................................83 Tabella 32 – Anagrafe Destinazioni Filiali ...................................................................................86 Tabella 33 – Anagrafe Destinazioni Servizi .................................................................................86 Tabella 34 – Anagrafe Liste Destinazioni.....................................................................................86 Tabella 35 – Anagrafe Classi di Stampa .......................................................................................87 Tabella 36 – Caratteristiche minime del Project Manager ............................................................89 Tabella 37 – Caratteristiche minime del membro del Gruppo di Progetto ...................................89 Tabella 38 – Caratteristiche minime dell’esperto per l’assistenza sul prodotto............................90 Tabella 39 - Lista dei documenti richiesti .....................................................................................92

G858 - 009/12 – Pag. 7 di 97

GLOSSARIO

Termini tecnici utilizzati nel capitolato: AC Insieme di servizi, risorse umane e tecnologiche presenti presso le

sedi dell’Amministrazione Centrale di Roma della Banca d’Italia

ArchiMate Linguaggio di modellazione architetturale. http://www3.opengroup.org/subjectareas/enterprise/archimate

ASA Code Standard utilizzato per la stampa in ambiente mainframe che prevede l’utilizzo di uno speciale carattere per il controllo della spaziatura verticale. Tale carattere è posizionato nella prima colonna di ogni riga del testo di stampa.

ASF Acquisizione e Spedizione Flussi – Infrastruttura applicativa che costituisce l’interfaccia unica per gli scambi di file e messaggi delle applicazioni del Servizio RES.

Base Informativa Codice numerico di 6 caratteri: i primi 3 identificano l’applicazione e i successivi 3 identificano il tipo messaggio all’interno dell’applicazione.

CDM Centro Donato Menichella, polo elaborativo primario della Banca d’Italia sito in Largo Guido Carli, 1 00044 Frascati (Roma).

Classe (Coda) di Stampa Indirizzamento logico di secondo livello (referenziato dall’applicazione) che identifica tabulati omogenei dal punto di vista del trattamento o del contenuto.

Cluster Failover Un cluster è un insieme di sistemi indipendenti che funzionano insieme per aumentare la disponibilità di servizi e applicazioni. I server inclusi nel cluster (denominati nodi) sono connessi mediante cavi fisici e software ed al verificarsi di problemi in un nodo, i servizi verranno forniti da un altro nodo (processo di failover).

DB2 Sistema di gestione basi dati di IBM, di tipologia relazionale, installato sugli ambienti mainframe di Banca.

DL/1 Data Language One - linguaggio utilizzato per accedere ai database IBM IMS, e ai suoi sistemi di scambio dei dati.

ESAG Evoluzione Servizi Applicativi Generalizzati GARI Gestore Applicazioni Reti Interbancarie - Infrastruttura applicativa

per l’instradamento dei dati sulle reti telematiche. GESPED Gestione Spedizioni – Applicazione deputata al controllo e alla

gestione delle spedizioni. Hypervisor Componente base per l’implementazione di sistemi virtualizzati

che svolge attività di controllo sulle macchine virtuali “ospitate” (virtual guest).

IMS Sistema IBM di gestione di database gerarchici e transazionali.

INGE Input gestionale - Infrastruttura applicativa per la gestione dei file in ingresso presso i sistemi informativi della Banca, ricevuti da enti esterni.

LB Largo Bastia, polo elaborativo secondario della Banca d’Italia sito in Largo Bastia, 35 00181 Roma.

MQSeries Middleware di comunicazione IBM basato sulla tecnologia “message queing”, che permette di connettere e integrare

G858 - 009/12 – Pag. 8 di 97

applicazioni residenti su piattaforme distribuite. NRG Nuova Rete Geografica - è l’infrastruttura di rete TCP/IP che

collega le sedi periferiche della Banca d’Italia con i servizi ed i server dell’A.C.

OPC Operations Planning & Control – Prodotto IBM preposto alla schedulazione di gruppi elaborativi sui sistemi centrali dell’Istituto, ora noto con il nome di TWS.

OTMA Open Transaction Manager Access - componente IMS che implementa un protocollo di comunicazione client-server di tipo “connectionless” in ambiente mainframe z/OS. Permette tra l’altro la comunicazione tra risorse IMS (LTERM) ed il middleware MQSeries.

PEGASO Produzione E Gestione Automatica Supporti Output - Infrastruttura applicativa preordinata alla produzione dei file in uscita dai sistemi informativi della Banca verso enti esterni.

RDVI Raccolta Dati Via Internet - Infrastruttura per la raccolta dei dati via Internet.

SSL/TLS Transport Layer Security (TLS) e Secure Sockets Layer (SSL); sono protocolli crittografici che consentono di stabilire una comunicazione autenticata e riservata tra le parti comunicanti, client e server.

SSPP Codice di 4 caratteri che identifica un’applicazione o una procedura di Banca sui sistemi centrali.

TWS Tivoli Workload Scheduler – Nuovo nome dell’OPC.

UFT Unità Fisica Trasmittente – rappresenta il codice assegnato ad una sede periferica (Filiale) della Banca.

UNL/UOP Unità Logica o Unità Operativa – rappresenta il codice assegnato ad una Filiale/Servizio della Banca; è sempre “ospitata” da una Unità Fisica, con la quale può essere coincidente o meno. Rappresenta l’indirizzamento logico di primo livello (referenziato dall’applicazione) per un tabulato.

VSAM Virtual Storage Access Method - schema di immagazzinamento dei dati IBM utilizzati per il virtual storage su piattaforma mainframe.

z/OS Sistema operativo per elaboratori di classe mainframe prodotto esclusivamente da IBM.

G858 - 009/12 – Pag. 9 di 97

INTRODUZIONE

Il presente capitolato contiene le specifiche, i requisiti e i servizi richiesti per la realizzazione, messa in opera ed esercizio del progetto E.S.A.G. (Evoluzione Servizi Applicativi Generalizzati), nel seguito ESAG.

L’iniziativa ESAG prevede la realizzazione di una soluzione integrata per la gestione dei flussi di dati e dei tabulati utilizzati sui sistemi della Banca d’Italia (di seguito Banca).

La caratteristica più rilevante della soluzione dovrà essere quella di offrire, in modo generalizzato, un insieme di servizi di trasformazione, memorizzazione, monitoraggio, instradamento di flussi/tabulati tra le applicazioni di Banca e controparti interne o esterne, definite genericamente d’ora innanzi “partner”; tali servizi dovranno essere realizzati in modalità indipendente dalla piattaforma, centrale o intermedia, sulla quale le applicazioni sono attestate. In questo modo le applicazioni non dovranno occuparsi degli aspetti connessi alla modalità di ricezione o di spedizione del dato ovvero alla tipologia di quest’ultimo.

Questo documento si articola in quattro sezioni:

• la prima sezione contiene la descrizione della situazione attuale;

• la seconda sezione contiene la descrizione della soluzione richiesta;

• la terza sezione contiene il dettaglio dell’oggetto della fornitura;

• la quarta sezione contiene la descrizione delle condizioni di erogazione della fornitura.

G858 - 009/12 – Pag. 10 di 97

1 SEZIONE PRIMA - SITUAZIONE ATTUALE

L’oggetto della fornitura deve sostituire:

• la soluzione per la Gestione dei Flussi di Dati basata sulle applicazioni proprietarie INGE, PEGASO e GESPED;

• la soluzione per la Gestione dei Tabulati distribuiti a Filiali e Servizi basata sulle applicazioni proprietarie FAGDD, APMAIN, PDLSTAMPA e STAMPA.

1.1 La Gestione dei Flussi di Dati

La soluzione attuale per la gestione dei flussi di dati è basata sulle applicazioni proprietarie INGE, PEGASO, GESPED che assicurano i servizi di identificazione univoca del flusso (numero di protocollo), di trasformazione dei files (ASCII/EBCDIC e viceversa, sbustamento/imbustamento XML, zip/unzip, etc…), di magazzino (conservazione storica dei flussi e dei files in essi contenuti) e di interazione con le applicazioni della Banca, a prescindere dalla modalità di trasmissione dei flussi stessi (reti telematiche, supporti magnetici e ottici) e dalla tipologia dei file trattati (file in formato ASCII, EBCDIC, XML, ecc.).

In particolare: • INGE (INput GEstionale) presiede alla gestione dei flussi di dati in ingresso, una volta

che questi siano già stati trasferiti da enti esterni sui sistemi informativi della Banca, e all’attivazione dei sistemi informativi destinatari; l’applicazione INGE utilizza un’organizzazione VSAM dei dati di archivio;

• PEGASO (Produzione E Gestione Automatica Supporti Output) presiede alla produzione e gestione dei flussi di dati in uscita dai sistemi informativi della Banca verso enti esterni, assicurando il loro confezionamento nei vari supporti prestabiliti e l’attivazione dei canali di collegamento, già presenti in Istituto, con le reti telematiche; l’applicazione PEGASO utilizza basi di dati IBM DB2 for z/OS;

• GESPED (GEstione SPEDizioni) presiede alla gestione materiale e amministrativa di tutte le spedizioni relative ai flussi prodotti su supporto fisico dalle applicazioni dell’Istituto che si avvalgono dei servizi di PEGASO; l’applicazione GESPED utilizza basi di dati IBM DB2 for z/OS.

L’obiettivo più rilevante conseguito dall’attuale architettura di scambio dei dati è stato quello

di svincolare le applicazioni destinatarie/mittenti dei flussi informativi sia dalla tipologia del dato (ASCII, EBCDIC, XML), sia dal vettore trasmissivo utilizzato (cassetta, CD-ROM, rete telematica). Le applicazioni sono pertanto esonerate dal dover presiedere a un insieme di operazioni quali, ad esempio, quelle legate alla gestione degli eventi (trasmissione/ricezione dei flussi), al riconoscimento delle tipologie di flussi, al loro imbustamento/sbustamento.

Le applicazioni INGE, PEGASO e GESPED operano in ambiente mainframe IBM z/OS e

gestiscono circa 1500 (millecinquecento) tipologie di flussi complessivi tra interni al mainframe e provenienti da sistemi intermedi (AIX, LINUX, Windows), in quest’ultimo caso mediante trasferimenti dedicati (di tipo “punto – punto”).

G858 - 009/12 – Pag. 11 di 97

Il monitoraggio dei flussi avviene mediante postazioni di lavoro standard dotate di emulatori che permettono l’accesso ai descritti ambienti elaborativi. Alcune postazioni di lavoro sono invece dedicate al trattamento dei flussi trasmessi o ricevuti mediante supporti fisici (floppy disk, cassette magnetiche, CD-ROM, DVD).

Con riferimento ai flussi gestiti dalle componenti INGE, PEGASO e GESPED, l’attuale architettura del sistema di scambio dei dati può essere rappresentata come illustrato nella figura seguente:

Figura 1 - Attuale architettura per lo scambio dei dati tramite INGE, PEGASO e GESPED

In dettaglio:

▪ per lo scambio tramite reti telematiche, intermediato dal GARI, le applicazioni possono avvalersi o meno dei servizi di INGE/PEGASO/GESPED. Nel primo caso, si tratta dei flussi inviati sulla RNI tramite file transfer, ovvero sul canale Internet: per questi tipi di scambio le applicazioni non devono preoccuparsi di interfacciarsi con il GARI, in quanto tale funzione è assicurata da INGE/PEGASO. Nel secondo caso, di flussi veicolati sulla RNI tramite Message switching, ovvero diretti verso la SWIFTNet: per questi tipi di scambio le applicazioni si devono far carico della connessione con il GARI.

▪ lo scambio tramite supporto fisico è sempre intermediato da INGE/PEGASO. Rileva, a tal fine, che le fasi di ricezione dei supporti fisici (nel seguito denominata PORTINERIA) sono eseguite tramite componenti applicative che presiedono alla lettura dei supporti e all’invio dei flussi verso INGE;

▪ per i flussi riguardanti alcune applicazioni, INGE/PEGASO colloquiano esclusivamente con l’applicazione ASF, preordinata a veicolare i flussi ai sistemi informativi destinatari;

G858 - 009/12 – Pag. 12 di 97

▪ costituiscono un’eccezione al modello descritto, limitatamente allo scambio tramite reti telematiche:

� lo scambio di flussi verso la BCE: in questo caso le applicazioni inviano ad ASF i flussi di dati e ASF indirizza i flussi medesimi verso ESCB-Net tramite l’infrastruttura EXDI;

� lo scambio dei flussi tramite il vettore Internet vede la presenza di un altro componente (webMethods) che svolge funzioni di business to business integration;

� lo scambio di flussi della Cassa Sovvenzioni e Risparmio fra il personale della Banca d’Italia (CSR), gestito da INGE e PEGASO, è veicolato verso il centro elaborativo della società CEDACRI mediante un collegamento basato sul protocollo NFTP, non intermediato dal GARI .

Per ulteriori dettagli sulle applicazioni si rimanda all’Allegato A. Le applicazioni

INGE/PEGASO/GESPED.

1.2 La Gestione dei Tabulati

La Banca d'Italia opera sul territorio con Filiali, insediate nei capoluoghi regionali e in alcuni capoluoghi di provincia1 e Servizi dell’Amministrazione Centrale (AC) localizzati a Roma.

Ogni Filiale e Servizio della Banca è identificato dal punto di vista funzionale ed applicativo da un codice denominato UNL (Unità Logica). Esiste poi un codice denominato UFT (Unità Fisica Trasmittente) che la caratterizza dal punto di vista delle risorse fisiche assegnate. Ogni codice UNL è “ospitato” da un codice UFT con il quale può coincidere2.

In ogni sede periferica è presente una coppia di server in tecnologia Intel/Linux che offre agli utenti della Filiale un insieme di servizi in alta affidabilità (cluster failover): in particolare uno dei servizi (Stampa Tabulati) permette la visualizzazione e stampa (dai posti di lavoro degli utenti) dei tabulati generati da applicazioni residenti in ambiente centrale IMS e distribuiti alle Filiali destinatarie.

Dal punto di vista della comunicazione di rete, tutte le dipendenze periferiche sono interconnesse con i sistemi e le applicazioni ospitate nei CED della Banca siti a Frascati e Roma3, tramite una rete geografica che garantisce una banda disponibile tra 4 e 16 MB.

Il servizio di Stampa Tabulati è offerto anche agli utenti delle Segreterie dei Servizi utilizzando un cluster (di tipologia e configurazione identica a quelli di Filiale) installato presso il sito elaborativo primario del CDM 4.

1 L’attuale assetto territoriale prevede la presenza di 58 Filiali, localizzate in altrettanti capoluoghi di provincia, ed

un numero di utenti totale pari a circa 3000. 2 Si cita l’esempio delle Filiali chiuse a seguito della riforma organizzativa il cui codice logico (UNL) continua ad

essere referenziato dalle procedure applicative anche se “ospitato” dal codice fisico (UFT) di un'altra Filiale. 3 Si tratta del sito primario del Centro Donato Menichella (CDM) e del sito secondario di Largo Bastia (LB)

utilizzato come sito di Disaster Recovery. 4 I Servizi dell’AC sono caratterizzati da UNL ospitate tutte su una stessa UFT.

G858 - 009/12 – Pag. 13 di 97

L’infrastruttura di distribuzione dei tabulati attuale è illustrata nella figura 2 e composta dalle componenti di seguito descritte.

Figura 2 - Attuale architettura per la distribuzione dei tabulati

Applicazione FAGDD

Rappresenta la componente infrastrutturale centralizzata (su piattaforma mainframe) interfacciata dalle applicazioni (in ambiente IMS) che producono tabulati destinati alle Filiali/Servizi5.

I tabulati e le loro caratteristiche identificative6 (estratte dalla testata prodotta dall’applicazione) sono caricati nella base dati mediante fasi elaborative notturne e/o giornaliere (circa 200 job batch) che elaborano i dataset prodotti dalle applicazioni o tramite chiamate dirette all’interno dei programmi applicativi.

5 L’Allegato B descrive con maggior dettaglio il funzionamento della componente ed il formato dei tabulati in

formato FAGDD. 6 Nel resto del documento con il termine “payload” si indica il contenuto del tabulato mentre con il termine “testata”

o “busta” viene indicata la struttura dati che ne identifica le caratteristiche.

G858 - 009/12 – Pag. 14 di 97

Nella base dati ogni tabulato è individuato da un record che contiene una serie di informazioni che consentono non solo di identificarne il contenuto e le caratteristiche, ma anche di indirizzarne l’invio presso le Filiali destinatarie.

La destinazione è individuata da un “indirizzamento di primo livello” (indicato dall’applicazione mittente) coincidente con il codice UNL fornito dall’applicazione, che è ridiretto dalla FAGDD verso il codice UFT ospitante il codice UNL. Esiste poi un “indirizzamento di secondo livello” (indicato dall’applicazione mittente) che identifica la Classe di Stampa ossia il “contenitore logico” assegnato a tabulati omogenei dal punto di vista del contenuto o del trattamento.

L’applicazione FAGDD gestisce la trasmissione di ogni tabulato verso le componenti periferiche ed è in grado, utilizzando meccanismi di sincronizzazione e di notifica, di monitorarne e tenerne aggiornato lo stato durante tutto il suo arco di vita, dall’inserimento nella base dati alla trasmissione in periferia, dalla avvenuta stampa alla sua cancellazione finale.

I tabulati sono instradati sfruttando meccanismi comunicativi dell’IMS (interfaccia OTMA) e sono trasmessi alle Filiali utilizzando risorse dedicate di tipologia “message queing” (code e canali MQSeries).

Una componente periferica (APMAIN) provvede a rimuovere i tabulati dalle code MQSeries e ad inserirli nella base dati presente in Filiale.

Questa tipologia di flusso (indicata in rosso nella figura 2) comprende circa 350 modelli di tabulato7 e rappresenta il 75% del totale dei tabulati trasmessi giornalmente in Filiale.

Esiste poi un’altra tipologia di flusso (indicata con colore verde nella figura 2, comprendente circa 20 modelli e che rappresenta circa il 15% dei tabulati totali giornalieri) utilizzata da alcune applicazioni IMS, che non prevede l’utilizzo dell’interfaccia e dei servizi offerti dall’applicazione FAGDD. In tal caso l’applicazione IMS comunica direttamente con la componente MQSeries per indirizzare i tabulati verso la periferia nel formato riconosciuto dall’applicazione APMAIN. Infrastruttura MQSeries

Costituisce il middleware di comunicazione utilizzato per la trasmissione dei tabulati (in forma di messaggi) dalla componente centrale FAGDD alle componenti periferiche site presso le Filiali.

I tabulati destinati alle Filiali vengono veicolati attraverso un Gestore Code MQSeries presente su z/OS ed uno presente su un sistema AIX centralizzato destinato ad ospitare le risorse (code e canali) utilizzate dalle Filiali8. Applicazione APMAIN

Rappresenta la componente periferica ospitata sui server della Filiale che acquisisce i tabulati destinati alla Filiale ed inviati dall’applicazione infrastrutturale FAGDD o direttamente dalle

7 Nel resto del documento con il termine “modello di tabulato” viene indicato l’insieme delle caratteristiche (formato, requisiti, ciclo di vita) che identificano una tipologia specifica di tabulato.

8 Le risorse MQSeries delle Filiali sono distribuite su 4 server AIX configurati in modo da assicurare funzionalità di High Availability e Disaster Recovery.

G858 - 009/12 – Pag. 15 di 97

applicazioni IMS. L’acquisizione avviene utilizzando un client MQSeries ed un processo in continua lettura sulla coda MQ dedicata alla Filiale.

Tale modalità di comunicazione prevede l’utilizzo di una testata (compilata dall’applicazione mittente) che contiene i dati caratteristici del tabulato che vengono estratti, elaborati ed inseriti nella base dati locale (implementata su database MySQL). Il tabulato “fisico” viene memorizzato su file system. Applicazione IC

Costituisce l’attuale interfaccia (in forma di eseguibile) richiamabile da applicazioni presenti sul server Linux. Attualmente è utilizzata dalla sola applicazione “Specimen di Firma” (flusso indicato con colore viola nella figura 2 che comprende 2 modelli di tabulato che rappresentano 1% dei tabulati totali giornalieri).

Interfaccia LPTAB

Costituisce l’attuale interfaccia (in forma di libreria DLL) richiamabile da applicazioni presenti sui server centralizzati AIX ospitanti i servizi di Filiale.

Tale interfaccia apre un “socket comunicativo” con un servizio infrastrutturale presente sul posto di lavoro (PAPSERVICE) al quale consegna il payload e la busta contenente i dati caratteristici del tabulato. Il processo PAPSERVICE richiama il processo PDLSTAMPA, risiedente sul server Linux di Filiale, il quale memorizza il payload su file system e inserisce la busta dei metadati nella base dati periferica.

Attualmente è utilizzata dalla componente “Motore” dell’applicazione Sportello (flusso indicato con colore azzurro nella figura 2 e comprende 3 modelli di tabulato che rappresentano circa il 4% dei tabulati totali giornalieri). Applicazioni STAMPA e STAMPA GRAFICA

Sono le applicazioni disponibili sui posti di lavoro degli utenti delle Filiali per la gestione (visualizzazione, stampa) dei tabulati in modalità grafica (STAMPA GRAFICA) o tramite comandi specifici (STAMPA).

Le informazioni sulle caratteristiche e lo stato dei tabulati disponibili vengono acquisite utilizzando i servizi del processo PDLSTAMPA che esegue le query sui record presenti nella base dati periferica.

Le stampe vengono indirizzate sulle stampanti configurate sul posto di lavoro utilizzando una libreria di stampa (LP) proprietaria in grado di interfacciare non solo stampanti di rete ma anche stampanti specializzate per le attività di Sportello.

Per quanto riguarda le modalità di autenticazione e di autorizzazione occorre tenere in conto quanto segue: - gli utenti dei Servizi dell’AC e delle Filiali sono definiti all’interno di ‘Unità Organizzative’

(OU) del dominio generale UTENZE, configurato nel sistema di directory aziendale (Microsoft Active Directory, di seguito MS AD); ad ogni Filiale/Servizio corrisponde una OU;

- l’accesso alle postazioni di lavoro avviene utilizzando credenziali centralizzate nella struttura MS AD;

- gli utenti della Filiale abilitati all’utilizzo delle applicazioni di Stampa sono inseriti in un gruppo autorizzativo definito per ogni Filiale in MS AD;

G858 - 009/12 – Pag. 16 di 97

- non esiste un controllo abilitativo a livello delle Classi di Stampa, ciò vuol dire che un utente abilitato all’applicazione Stampa è in grado di visualizzare i tabulati destinati a tutte le classi di stampa di tutte i codici UNL ospitati dal codice UFT corrispondente alla OU di appartenenza9.

9 Per le Filiali, sussiste una corrispondenza univoca fra OU e UFT perché ciascuna Filiale è dotata dei propri sistemi

fisici; i Servizi dell’AC, invece, hanno ciascuno la propria OU, ma condividono un unico sistema fisico e quindi un’unica UFT.

G858 - 009/12 – Pag. 17 di 97

2 SEZIONE SECONDA - SOLUZIONE RICHIESTA

In questa sezione viene descritta l’architettura logica e le componenti che dovranno essere

oggetto della fornitura. A tale scopo sono descritti i requisiti di dettaglio relativi ai prodotti che dovranno fornire supporto ai processi di ESAG.

I requisiti sono stati suddivisi in funzionali e non funzionali.

I requisiti funzionali e non funzionali sono tutti OBBLIGATORI e sono da considerarsi requisiti minimi indispensabili per la formulazione dell’offerta tecnica della fornitura: la mancanza di tali requisiti comporta l’esclusione dalla gara in sede di valutazione tecnica.

2.1 Architettura di riferimento

La nuova soluzione dovrà articolarsi nei componenti logici descritti e rappresentati nella figura seguente:

Figura 3 - Componenti Logici di ESAG

La Figura 3 illustra i componenti logici che implementano l’architettura di ESAG: • ESAG Suite

• ESAG U2A

• ESAG A2A

G858 - 009/12 – Pag. 18 di 97

Nella componente “ESAG Suite” sono raffigurati i moduli applicativi relativi ai processi di Gestione Accesso, Gestione Flussi, Servizi Flussi, Gestione Base Dati Flussi, Gestione Tabulati, Servizi Tabulati, Gestione Base Dati Tabulati e Servizi Supporti Fisici.

Nella componente “ESAG U2A” sono contenuti i moduli per la gestione dei processi di interazione User-to-Application (U2A); essa si compone di tutti i moduli che consentono agli utenti (operatori, amministratori, gestori, …) di interagire con la soluzione, in modalità grafica interattiva (invocabile mediante web browser) o da linea di comando.

Nella componente “ESAG A2A” sono contenuti i moduli per la gestione dei processi di interazione Application-to-Application (A2A); essa comprende tutti i moduli che consentono l’integrazione tra la soluzione stessa e le applicazioni presenti in Banca, al fine dello scambio di flussi dati/tabulati o dell’invocazione remota di azioni o eventi.

In coerenza con quanto rappresentato in figura, nei successivi paragrafi verranno descritti, in termini qualitativi, i singoli componenti oggetto della fornitura. Per ciascun componente sono descritti in forma tabellare l’elenco dei requisiti che devono essere soddisfatti dalla soluzione proposta, indicando per ciascun requisito:

• il codice del requisito, costituito dal nome del componente, del modulo e da un numero progressivo univoco, tale da consentire di individuare univocamente il requisito;

• la descrizione del requisito, costituito da una descrizione delle caratteristiche richieste.

2.2 ESAG Suite

La componente “ESAG Suite“ raggruppa l’insieme delle funzioni “core” che la soluzione proposta deve implementare.

2.2.1 Gestione Accesso

Il modulo Gestione Accesso contiene l’insieme delle funzioni necessarie per la gestione dei profili abilitativi della soluzione. In questo modulo vengono inoltre definite le modalità e le politiche di autenticazione ed

autorizzazione che la soluzione deve implementare. Sono previste le seguenti tipologie di utenze: - amministratori del prodotto, utenti amministratori del prodotto che devono poter

visualizzare tutti i flussi e i tabulati presenti nelle basi dati ed agire in modalità “full control” sulle anagrafi. Gli amministratori appartengono ad una specifico gruppo abilitativo di Active Directory (Amm_ESAG); - amministratori della sicurezza, utenti amministratori per la componente di sicurezza del

prodotto che permette di gestire la profilatura dei ruoli assegnati agli altri utenti. Gli amministratori della sicurezza appartengono ad uno specifico gruppo abilitativo di Active Directory (Amm_Sic_ESAG); - operatori tabulati, utenti di Filiale/Servizio che debbono poter visualizzare e stampare i

tabulati presenti nell’Archivio dei Tabulati. L’utente appartiene ad una specifica Organizational Unit (OU) di Active Directory; - gestori tabulati, utenti responsabili di specifiche tipologie (modelli) di tabulati e che devono

poter visualizzare, per tutte le tipologie di cui sono responsabili, lo stato dei tabulati inviati a

G858 - 009/12 – Pag. 19 di 97

tutte le Filiali/Servizi. Esiste uno specifico gruppo abilitativo di Active Directory per ogni gestore applicativo; - gestori flussi, utenti responsabili di specifici flussi e che devono poter visualizzare lo stato

per tutti i flussi di cui sono responsabili. Esiste uno specifico gruppo abilitativo di Active Directory per ogni gestore applicativo.

La seguente tabella definisce i requisiti funzionali richiesti.

Codice Descrizione

Suite-GAC-001

Autenticazione Il prodotto/la soluzione deve integrarsi con l’infrastruttura Microsoft Active Directory (MS AD) di Banca (attraverso l’uso del protocollo Kerberos e/o NTLM) per consentire l’autenticazione degli utenti in modalità Single Sign-On (utilizzando le credenziali richieste all’utente al momento dell’autenticazione sul posto di lavoro). Non deve essere necessario definire utenze all’interno del prodotto.

Suite-GAC-002

Autorizzazione Il prodotto/la soluzione, utilizzando i gruppi abilitativi definiti nel servizio aziendale di controllo degli accessi (MS AD) deve permettere l’assegnazione di ruoli agli operatori, agli amministratori, agli amministratori della sicurezza e ai gestori del prodotto.

Suite-GAC-003

Gestione Ruoli Operatore Un utente “operatore tabulati” deve poter visualizzare e stampare i tabulati dell’Archivio destinati a tutti i codici UNL ospitati dal codice UFT a cui l’utente appartiene. L’associazione tra OU e codice UFT è ricavabile da AD (come attributo della OU). L’associazione tra codice UFT e codice UNL deve essere ottenuta utilizzando ’Anagrafe delle Destinazioni’ definita all’interno del prodotto.

Suite-GAC-004

Gestione Ruoli Operatore Un utente “operatore tabulati” appartenente ad un codice UFT non deve poter visualizzare/stampare i tabulati presenti nell’Archivio e destinati a codici UNL che siano associati (ospitati) a codici UFT diversi da quello di appartenenza.

Suite-GAC-005

Gestione Ruoli Amministratore Gli amministratori del prodotto devono poter visualizzare tutti i tabulati (di tutti i codici UNL) presenti nell’Archivio e visualizzare/modificare le Anagrafi secondo quanto riportato al § 2.3.2).

Suite-GAC-006

Gestione Ruoli Gestore Tabulati Un utente “gestore tabulati” deve poter visualizzare i tabulati dell’Archivio di cui è responsabile (system owner). L’associazione tra utente gestore e generico tabulato è ricavabile dal campo Utente_Gestore presente nell’Archivio il quale è valorizzato utilizzando l’omonimo campo dell’Anagrafe Modelli di Tabulato.

Suite-GAC-007

Gestione Ruoli Gestore Flussi Un utente “gestore flussi” deve poter visualizzare i flussi di cui è responsabile (system owner). L’associazione tra utente gestore e flusso può essere definita al momento della creazione del flusso o successivamente e tale informazione viene memorizzata nella Base Dati Flussi.

Tabella 1 – ESAG Suite - Requisiti “Gestione Accessi”

2.2.2 Gestione Flussi

Il modulo Gestione Flussi contiene l’insieme delle funzioni necessarie per creare, modificare, cancellare e monitorare i flussi.

Per flusso si intende l'associazione tra partner, base informativa e unità di supporto, descritti nel componente di Gestione Basi Dati Flussi.

G858 - 009/12 – Pag. 20 di 97


Codice Descrizione

Suite-GF-001 Disegno Flusso Il prodotto/la soluzione devono includere funzioni di creazione, modifica, cancellazione e monitoraggio dei flussi tramite regole configurabili.

Suite-GF-002

Regole di riconoscimento Il prodotto/la soluzione deve permettere la definizione di regole di riconoscimento automatizzato del flusso per associarlo alla relativa base informativa e la definizione di regole di riconoscimento automatizzato del file per associare ogni singolo file al flusso appropriato. Il numero delle regole da definire è dell'ordine di 500 regole. Le regole devono poter essere applicate sul contenuto dei dati, ad esempio: - sul contenuto del file (per i file XML sia sui dati di busta che sul payload); - sul nome del file; - su parametri esterni forniti dalle interfacce al prodotto/soluzione (per esempio, in ricezione il VirtualFileName dal GARI).

Suite-GF-003

Regole di trasformazione Il prodotto/la soluzione deve permettere la configurazione di funzioni di trasformazione (cfr. Suite-Servizi, da Suite-SF-002 a Suite-SF-008). Ad esempio: per la funzione di UNBULK, dovrà essere possibile definire la stringa delimitatore dei singoli files all'interno del flusso; per la funzione di Conversione, dovrà essere possibile definire i formati di partenza e di arrivo; etc.

Suite-GF-004

Regole di routing Il prodotto/la soluzione deve permettere di definire sia l’applicazione destinataria/mittente con la relativa modalità di invocazione, sia le caratteristiche di consegna/ricezione. Le funzioni di routing dovranno interfacciarsi verso i seguenti componenti middleware già presenti in Istituto: ASF, GARI, TWS, NetView FTP. Ad esempio: - per i flussi che transitano via ASF deve essere possibile specificare le caratteristiche di consegna/ricezione (FIFO, ALL-in-ONE, definito dall'utente);

- per i flussi che transitano via GARI deve essere possibile specificare le caratteristiche di consegna/ricezione (FIFO, ALL-in-ONE, definito dall'utente);

- per i flussi che transitano via TWS deve essere possibile specificare le modalità di attivazione (PUSH, PULL) e le caratteristiche di consegna/ricezione (ogni file viene passato all'applicazione, i file vengono accodati e poi passati tutti insieme all'applicazione, i file vengono accodati e sarà l'applicazione a decidere quando elaborarli);

- per i flussi che transitano via NetView FTP deve essere possibile specificare le caratteristiche di consegna (FIFO, ALL-in-ONE, definito dall'utente).

Le regole definite hanno carattere generale e possono essere assegnate a più flussi. I parametri di dettaglio, per esempio il nome dell'applicazione TWS da invocare, sono definiti in ogni singolo flusso.

Suite-GF-005

Monitoraggio Flussi Il prodotto/la soluzione deve fornire una visione end-to-end del trattamento dei flussi. A tale scopo il prodotto/la soluzione deve essere aperto all’interazione con altri prodotti (quale ad esempio il System Services del GARI) attraverso interfacce standard (ad esempio IBM WebSphere MQ). Tutte le funzioni di monitoraggio devono essere profilabili: in base al ruolo dell'utente connesso saranno visibili informazioni/funzioni diverse.

Suite-GF-006

Monitoraggio Flussi: Verifica flussi acquisiti Il prodotto/la soluzione deve consentire di verificare il trattamento del flusso acquisito, evidenziando anche in forma grafica lo stato di avanzamento dello stesso all'interno del sistema. Deve evidenziare chi e quando ha utilizzato il flusso (processi o utenti e su quali sistemi); eventuali trasformazioni subite dal flusso e/o dal suo contenuto; gli eventi associati al flusso. Deve inoltre evidenziare i malfunzionamenti (p.e. contenuto non conforme o caratteristiche difformi da quelle previste) e prevedere la possibilità di inviare segnalazioni automatiche ai sistemi di monitoraggio dell'istituto, specificando il tipo di malfunzionamento rilevato.

G858 - 009/12 – Pag. 21 di 97

Codice Descrizione

Infine deve segnalare automaticamente il rischio di mancato utilizzo del flusso entro cut-off specifici ed eventualmente attivare processi automatici.

Suite-GF-007

Monitoraggio Flussi: Verifica flussi in spedizione Consente di verificare il trattamento di un flusso in spedizione, evidenziando anche in forma grafica lo stato di avanzamento del flusso stesso all'interno del sistema. Deve evidenziare chi e quando ha utilizzato il flusso (processi o utenti e su quali sistemi); eventuali trasformazioni subite dal flusso e/o dal suo contenuto; gli eventi associati al file. Deve inoltre evidenziare i malfunzionamenti (p.e. contenuto non conforme o caratteristiche difformi da quelle previste) e prevedere la possibilità di inviare segnalazioni automatiche ai sistemi di monitoraggio dell'istituto, specificando il tipo di malfunzionamento rilevato. Infine deve segnalare automaticamente il rischio di mancata spedizione del flusso entro cut-off specifici ed eventualmente attivare processi automatici.

Suite-GF-008

Monitoraggio Flussi: Verifica stato dei servizi Deve consentire di monitorare lo stato dei servizi previsti dal prodotto/dalla soluzione evidenziando con specifici alert, l'eventuale rischio di problemi (rallentamenti, accodamenti, problemi di spazio, ecc.)

Suite-GF-009

Monitoraggio Flussi: Reportistica Deve consentire di ottenere report relativi ai flussi scambiati con l'esterno secondo molteplici variabili di classificazione, significative per la rappresentazione del fenomeno (ad esempio il mittente/destinatario, i punti di passaggio attraverso i sistemi, la numerosità dei flussi per base informativa, periodo temporale considerato – ore, giorno, settimana, anno – vettori utilizzati, grandezza del singolo file, etc.) .

Suite-GF-010

Monitoraggio Flussi: Gestione Eventi Il prodotto/soluzione deve offrire una funzione di controllo e gestione degli eventi: deve registrare in un log gli eventi significativi dal punto di vista applicativo/sistemistico e/o utente che hanno interessato i processi coinvolti (es. timestamp di arrivo di un flusso, registrazione degli stati di lavorazione dei flussi etc.).

Suite-GF-011

Monitoraggio Flussi: Gestione Errori Il prodotto/soluzione dovrà segnalare a video e scrivere su log qualsiasi anomalia rispetto ai normali processi di acquisizione e spedizione dei flussi, suggerendo agli utenti la modalità di correzione dell’errore a fronte di codici di ritorno noti. Il prodotto/soluzione deve offrire la modalità di gestione degli errori, deve permettere agli utenti autorizzati (gestore) di forzare alcune operazioni sui file (come per esempio l'associazione di un file a uno specifico flusso in caso di errore per mancato riconoscimento automatizzato) e di riavviare il processo a seguito della correzione dell'errore stesso.

Suite-GF-012 Monitoraggio Flussi: Gestione Stato Il prodotto/soluzione deve consentire agli utenti autorizzati di variare manualmente lo stato dei file/flussi.

Tabella 2 – ESAG Suite - Requisiti “Gestione Flussi”

2.2.3 Servizi Flussi

Il modulo Servizi Flussi contiene l’insieme delle funzionalità che la soluzione deve mettere a disposizione per il trattamento dei flussi e che devono poter essere richiamate in modo personalizzato per ciascuna tipologia di flusso.


G858 - 009/12 – Pag. 22 di 97

Codice Descrizione

Suite-SF-001

Protocollo File Il prodotto/la soluzione deve essere in grado di assegnare a ogni file in ingresso e in uscita un numero di protocollo univoco (gestione elettronica di un numero progressivo per la identificazione dei flussi telematici). Il protocollo univoco deve essere alfanumerico di 6 cifre.

Suite-SF-002 Trasformazione: Conversione Il prodotto/soluzione deve offrire la conversione dei dati nei vari formati. Al momento i formati trattati sono EBCDIC, ASCII, UTF-8.

Suite-SF-003

Trasformazione: Sbustamento Il prodotto/soluzione deve offrire una funzione di sbustamento per i file XML. Deve essere possibile estrarre il payload e ricavare dalla busta i metadati necessari (i.e. mittente, codice applicazione …).

Suite-SF-004 Trasformazione: Imbustamento Il prodotto/soluzione deve offrire una funzione di creazione di file XML a partire dal payload e dai metadati ricevuti dall'applicazione.

Suite-SF-005 Trasformazione: Compressione/decompressione Il prodotto/soluzione deve offrire funzioni di compressione/decompressione sui file.

Suite-SF-006 Trasformazione: Cifratura/Decifratura Il prodotto/soluzione deve offrire funzioni di cifratura/decifratura dei file.

Suite-SF-007 Trasformazione: Formato Il prodotto/soluzione deve offrire una funzione di trasformazione file nei principali formati utilizzati per il trasferimento dei file: ad esempio in formato pdf.

Suite-SF-008

Trasformazione: Bulk/unbulk Il prodotto/soluzione deve rendere disponibile una funzione di bulk (raggruppamento)/unbulk (spacchettamento) dei file contenuti in un flusso, sulla base della definizione del record separatore (esempio: record standard "ANABI").

Suite-SF-009

Regolatore operazioni x Flusso: per ogni tipologia di flusso deve essere configurabile il numero massimo di operazioni parallele eseguibili in ESAG; per ciascun flusso, la soluzione deve consentire di definire il numero massimo di file trattabili contemporaneamente, gestendone l'accodamento. x Sistema: A livello di sistema deve poter essere impostato il numero massimo di operazioni eseguibili parallelamente in ESAG. x Priorità: Per ogni tipologia di flusso deve essere configurabile la sua priorità. La priorità stabilisce l’ordine temporale nel quale i flussi vengono trattati. Il dominio della priorità deve prevedere almeno 5 valori. Sia la Priorità sia il Numero Massimo di Operazioni Parallele eseguibili (sia per flusso sia per sistema) devono poter essere modificate dinamicamente.

Suite-SF-010

Immagazzinamento: Ambiente Il prodotto/la soluzione deve offrire una funzione di salvataggio e conservazione dei file, che dovrà avvenire sullo stesso ambiente in cui il file verrà sfruttato dalle applicazioni e con le procedure di Data Management System specifiche dell'ambiente: - su ambiente elaborativo mainframe per i file indirizzati alle applicazioni residenti su mainframe;

- su ambiente elaborativo dipartimentale per i file indirizzati alle applicazioni residenti su sistemi dipartimentali.

Suite-SF-011

Immagazzinamento: Stadi Il prodotto/la soluzione dovrà essere in grado di conservare i file nei vari stadi di trattamento (ad es. per i file in ingresso, il file sorgente, il file dopo la conversione ASCII-EBCDIC, il file consegnato all’applicazione destinataria dopo eventuali attività di trasformazione/arricchimento).

Suite-SF-012

Immagazzinamento: Tempi Il prodotto deve offrire una funzione di mantenimento dei file a fini probatori, di consultazione e di conservazione per tempi differenziati per flusso: il numero di giorni di mantenimento deve essere configurabile per ogni tipologia di flusso. La funzione deve però mantenere in linea i metadati necessari all'eventuale restore del file e per la relativa consegna alle applicazioni. Il restore potrà avvenire su richiesta delle applicazioni. Dovranno essere disponibili funzioni di

G858 - 009/12 – Pag. 23 di 97

Codice Descrizione

ricerca file con impostazione di filtri sui metadati (ad es. data, partner, base informativa, protocollo, ecc.) .

Suite-SF-013

Riacquisizione/Rispedizione File Il prodotto/soluzione deve consentire agli utenti autorizzati di rieffettuare la lavorazione di un flusso/file già acquisito e lavorato o la rispedizione di un flusso/file precedentemente trasmesso: tali operazioni saranno possibili entro scadenze prefissate definite per ciascuna tipologia di flusso.

Suite-SF-014 Trasformazione: Firma Digitale/Verifica della firma digitale Il prodotto/soluzione deve offrire una funzione di firma digitale dei file e verifica della stessa.

Tabella 3 – ESAG Suite - Requisiti “Servizi Flussi”

2.2.4 Gestione Base Dati Flussi

Il modulo Gestione Base Dati Flussi descrive le variabili che la soluzione/prodotto deve gestire per permettere il trattamento di un flusso.


Codice Descrizione

Suite-DBF-001 DBMS Il prodotto/la soluzione deve utilizzare un Data Base Management System (DBMS) per la conservazione e la gestione dei metadati associati ai flussi, ai file e ai messaggi.

Suite-DBF-002

Base Informativa La soluzione deve prevedere la definizione delle caratteristiche dei flussi in arrivo e in partenza e delle eventuali regole di riconoscimento nell'anagrafe delle Basi Informative. Per caratteristiche si intende: 1) Descrizione sintetica del flusso; 2) Lunghezza record logico; 3) Lunghezza record fisico; 4) Formato del record; 5) Input oppure output; 6) Codice dell’applicazione (SSPP); 7) Modalità di sfruttamento dei dati; 8) La possibilità di inserire delle note esplicative; 9) Una serie di campi contenenti regole e costanti necessari per il riconoscimento del flusso; 10) codice applicazione SIA.

Suite-DBF-003 Funzioni di stralcio/import La soluzione deve prevedere funzioni di stralcio e import massivo dalla/nella base dati.

Suite-DBF-004

Partner La soluzione deve prevedere la definizione di tutte le controparti che scambiano dati con la Banca d'Italia, identificate con un codice, in genere il codice ABI, un sottocampo, in genere codice ufficio, e un nome del partner.

Suite-DBF-005 Utenti Autorizzati La soluzione deve prevedere la definizione di tutti gli utenti abilitati ad accedere all'applicazione e la classe di appartenenza che indichi il loro livello autorizzativo.

Suite-DBF-006 Servizi Utenti La soluzione deve prevedere la definizione di tutti i servizi dell'A.C. che si interfacciano con l'applicazione.

Suite-DBF-007 Applicazioni La soluzione deve prevedere la definizione di tutte le applicazioni che scambiano dati con l'esterno.

Suite-DBF-008 Errori La soluzione deve prevedere la codifica di tutti i codici di errore e la loro descrizione.

Suite-DBF-009 Siti La soluzione deve prevedere la definizione di tutte le porte d'ingresso dei dati.

G858 - 009/12 – Pag. 24 di 97

Codice Descrizione

Suite-DBF-010 Supporti La soluzione deve prevedere la definizione di tutti i supporti fisici, su cui vengono registrati i dati, individuati con un codice , una descrizione ed un tipo supporto.

Suite-DBF-011

Cartellini La soluzione deve prevedere la definizione di tutti i cartellini ossia degli oggetti che contengono le informazioni necessarie per la spedizione. Il cartellino è composto da tre campi: codice identificativo alfanumerico, mittente e descrizione di ciò che viene spedito dall’applicazione.

Suite-DBF-012 Archiviazione La soluzione deve prevedere la definizione di modalità di archiviazione standard e personalizzate a seconda delle specifiche richieste.

Suite-DBF-013 Applicazione Rete La soluzione deve prevedere la definizione delle applicazioni rete secondo la nomenclatura SIA.

Tabella 4 – ESAG Suite - Requisiti “Gestione Basi Dati Flussi”

2.2.5 Gestione Tabulati

I tabulati prodotti dalle applicazioni non devono essere distribuiti e immagazzinati presso le sedi periferiche (come nell’attuale soluzione) ma sono: - acquisiti tramite le interfacce previste dalla componente ESAG A2A; - elaborati e memorizzati su una piattaforma centralizzata utilizzando i servizi e le strutture dati

definite nella componente ESAG Suite (Servizi Tabulati e Gestione Base Dati Tabulati); - resi disponibili agli utenti utilizzando le interfacce previste dalla componente ESAG U2A. Il modulo Gestione Tabulati stabilisce le regole che definiscono il trattamento di un tabulato

nella nuova soluzione/prodotto. La seguente tabella definisce i requisiti funzionali richiesti.

Codice Descrizione

Suite-GT-001

Interazione con componente A2A (interfaccia FAGDD) La soluzione deve gestire tabulati generati da applicazioni residenti in ambiente IMS che utilizzano il formato FAGDD. La presa in carico dei tabulati di suddetta tipologia avviene tramite apposita interfaccia (cfr. § 2.4.5 - ESAG A2A Interfaccia FAGDD).

Suite-GT-002

Interazione con componente A2A (interfaccia APMAIN) La soluzione deve gestire tabulati/notifiche prodotti da applicazioni residenti in ambiente IMS che utilizzano il formato APMAIN. La presa in carico dei tabulati di suddetta tipologia avviene tramite apposita interfaccia (cfr. § 2.4.6 - ESAG A2A Interfaccia APMAIN).

Suite-GT-003

Interazione con componente A2A (interfaccia LPTAB) La soluzione deve gestire tabulati generati da applicazioni residenti su piattaforma AIX che utilizzano il formato LPTAB. La presa in carico dei tabulati di suddetta tipologia avviene tramite apposita interfaccia (cfr. § 2.4.8 - ESAG A2A Interfaccia LPTAB).

Suite-GT-004

Interazione con componente A2A (interfaccia IC) La soluzione deve gestire tabulati generati da applicazioni residenti su piattaforma Linux che utilizzano il formato IC. La presa in carico dei tabulati di suddetta tipologia avviene tramite apposita interfaccia (cfr. § 2.4.7 - ESAG A2A Interfaccia IC).

Suite-GT-005

Elaborazione La soluzione deve prevedere funzioni centralizzate di elaborazione (parsing) della ‘busta identificativa’ prodotta dall’applicazione (acquisita per mezzo delle apposite interfacce definite in ESAG A2A) e di estrazione dei dati identificativi del tabulato (metadati) in essa contenuti.

G858 - 009/12 – Pag. 25 di 97

Codice Descrizione

Suite-GT-006 Immagazzinamento La soluzione deve prevedere funzioni centralizzate di immagazzinamento dei dati identificativi contenuti nella busta del tabulato in un repository denominato Archivio dei Tabulati.

Suite-GT-007

Immagazzinamento La soluzione deve permettere funzioni centralizzate di immagazzinamento del contenuto (payload) dei tabulati prodotti dalle applicazioni (acquisito per mezzo delle apposite interfacce definite in ESAG A2A).

Suite-GT-008

Riconoscimento La soluzione deve essere in grado di associare, in fase di acquisizione, un generico tabulato ad un ‘modello’ che identifica caratteristiche comuni ai tabulati ad esso appartenenti. L’insieme dei modelli è definito all’interno di una struttura dati denominata Anagrafe dei Modelli di Tabulato.

Suite-GT-009

Indirizzamento La soluzione deve gestire l’indirizzamento logico di primo livello del tabulato, specificato dall’applicazione e coincidente con una o più destinazioni logiche (UNL). Nel caso di tabulato indirizzato a più UNL il prodotto dovrà creare per ogni UNL destinataria un’istanza di tabulato (indipendente dalle altre).

Suite-GT-010

Indirizzamento La soluzione deve permettere l’associazione tra l’indirizzamento logico di primo livello (codice UNL) ed un corrispondente indirizzamento fisico di primo livello (codice UFT) utilizzato dalle funzioni di interfaccia utente. La suddetta associazione deve essere implementata tramite un Anagrafe delle Destinazioni che costituisce elemento di flessibilità (evitando impatti nei riguardi delle applicazioni nel caso di attività di “riorganizzazione” delle risorse fisiche). Ad un codice UFT possono essere associati più codici UNL. Ad un codice UNL deve essere associato un solo codice UFT.

Suite-GT-011

Indirizzamento La soluzione (in aggiunta al codice Suite-GT-009) deve poter gestire un indirizzamento logico di primo livello rappresentato da un alias che identifica una lista di codici UNL destinatari. Il prodotto dovrà quindi gestire tante istanze di tabulati diverse (e tra loro indipendenti) quante sono le destinazioni presenti nella lista. L’associazione tra la lista-alias e i rispettivi codici UNL deve essere implementata tramite un Anagrafe delle Liste di Destinazioni.

Suite-GT-012

Indirizzamento La soluzione deve gestire un indirizzamento logico di secondo livello del tabulato, specificato dall’applicazione, che permette di raggruppare in un unico contenitore (Classe di Stampa) tabulati simili per tipologia e/o trattamento.

Suite-GT-013

Indirizzamento La soluzione deve permettere l’associazione univoca tra un indirizzamento logico di secondo livello (Classe di Stampa), utilizzato dall’applicazione, e un corrispondente indirizzamento fisico di secondo livello (Coda di Stampa) utilizzato dalle funzioni di interfaccia utente. La suddetta associazione deve essere implementata tramite un Anagrafe delle Classi di Stampa che costituisce elemento di flessibilità (evitando impatti nei riguardi delle applicazioni nel caso di attività di ridefinizione delle classi di stampa). Ad una coda di stampa possono essere associate più classi di stampa. Ad una classe di stampa deve essere associata una ed una sola coda di stampa.

Suite-GT-014

Gestione Errori/Eventi La soluzione deve gestire situazioni di errore generate in fase di elaborazione della busta (es. tabulato destinato ad un codice UNL non definito nell’Anagrafe) forzando l’inserimento temporaneo del tabulato in una Coda dei Tabulati in Quarantena. In corrispondenza di tali eventi il prodotto deve evidenziare l’anomalia su file di log/audit ed inviare un allarme ad una console centralizzata per la gestione degli errori.

Suite-GT-015 Gestione Errori/Eventi Una volta rimossa la causa (es. definizione nell’Anagrafe del codice UNL precedentemente non censito) che ha generato l’errore di cui al codice precedente, la soluzione deve essere in grado di

G858 - 009/12 – Pag. 26 di 97

Codice Descrizione

“reinserire” manualmente (o automaticamente su base temporale) il tabulato nell’Archivio dei Tabulati.

Suite-GT-016

Interazione con componente U2A La soluzione deve permettere l’interazione con gli utenti operatori per l’implementazione delle funzioni di ricerca e visualizzazione del contenuto dell’Archivio tramite oppurtuna interfaccia (cfr. § 2.3.2 ESAG U2A).

Suite-GT-017

Interazione con componente U2A La soluzione deve permettere l’interazione con gli utenti operatori per l’implementazione delle funzioni di stampa e salvataggio dei tabulati su dispositivi locali al posto di lavoro (cfr. § 2.3.2 ESAG U2A).

Suite-GT-018

Interazione con componente U2A La soluzione deve permettere l’interazione con gli utenti amministratori del prodotto per l’utilizzo delle funzioni di configurazione delle Anagrafi (e della Coda dei Tabulati in Quarantena) (cfr. § 2.3.2 ESAG U2A).

Suite-GT-019

Gestione Stato Stampato/Visualizzato La soluzione deve, per ogni tabulato acquisito, tenere traccia delle attività di visualizzazione e stampa (eseguite dall’utente operatore) mediante l’utilizzo di variabili di “stato” che indichino se un tabulato è stato stampato o meno oppure se è stato visualizzato o meno. In corrispondenza di tali eventi il prodotto deve aggiornare automaticamente tali variabili di stato.

Suite-GT-020

Gestione Stato Archiviato/Cancellato La soluzione deve gestire procedure automatiche di archiviazione e/o cancellazione. dei tabulati provvedendo ad aggiornare una variabile di stato del tabulato che indichi se il tabulato è stato archiviato..

Suite-GT-021 Caricamento/Import/Export Anagrafi La soluzione deve prevedere funzioni e fornire procedure (batch) per il caricamento, l’importazione e l’esportazione di dati dalle Anagrafi definite ai punti precedenti.

Suite-GT-022

Ripresa Dati La soluzione deve prevedere la funzione e fornire una procedura (richiamabile in modalità batch) per l’acquisizione di tabulati esportati (mediante una procedura già esistente) dall’archivio dell’attuale soluzione e strutturati nel formato FAGDD.

Suite-GT-023 Formato documenti La soluzione deve poter gestire documenti prodotti in formato PDF e Windows Office.

Tabella 5 – ESAG Suite - Requisiti “Gestione Tabulati”

2.2.6 Servizi Tabulati

Il modulo Servizi Tabulati contiene l’insieme delle funzionalità e dei servizi di base che la soluzione/prodotto deve rendere disponibili.


Codice Descrizione

Suite-ST-001

Elaborazione/Immagazzinamento Il modulo, a seguito dell’acquisizione di un tabulato (proveniente da una qualsiasi delle interfacce previste nell’ambito modulo ESAG A2A), deve: - effettuare (se necessario) la conversione dei dati nel corretto formato (es. ASCII-EBCDIC); - immagazzinare il payload (contenuto del tabulato depurato della busta identificativa).

G858 - 009/12 – Pag. 27 di 97

Codice Descrizione

Suite-ST-002

Elaborazione Il modulo, a seguito dell’acquisizione di un tabulato (proveniente da una qualsiasi delle interfacce previste nell’ambito del modulo ESAG A2A), deve: - elaborare il contenuto della busta estraendo i seguenti metadati che identificano il tabulato:

- Id_Applicazione

- Codice_Tabulato

- Modello_Tabulato

- Id_Richiesta_Tab

- Versione

- UNL

- Classe_Stampa

- Data_Contabile

- Ora_Produzione

- Data_Produzione.

Suite-ST-003

Indirizzamento Il modulo deve offrire un servizio in grado di applicare le regole di indirizzamento di primo livello definite per il tabulato nell’ambito della Gestione Tabulati (cfr. Suite-GT-009, Suite-GT-010, Suite-GT-011). A tale scopo il servizio deve estrarre dalla busta il campo che identifica la/le destinazioni e, per ogni destinazione indicata dall’applicazione, deve verificare l’esistenza di tale valore come codice UNL nell’Anagrafe delle Destinazioni. Nel caso in cui la destinazione sia una lista, il modulo deve risolvere i codici UNL ad essa associati estraendoli dall’Anagrafe delle Liste di Destinazioni. Se il risultato della verifica è negativo (UNL o lista non presente) il servizio deve: creare un’istanza nella Coda dei Tabulati in Quarantena, evidenziare l’anomalia su file di log e inviare una segnalazione di errore. Se il risultato della verifica è positivo, il modulo (per ogni destinazione) deve eseguire i controlli definiti dal codice successivo.

Suite-ST-004

Indirizzamento Il modulo deve offrire un servizio in grado di applicare le regole di indirizzamento di secondo livello definite per il tabulato nell’ambito della Gestione Tabulati (cfr. Suite-GT-012). In particolare il servizio deve verificare l’esistenza della classe di stampa specificata dall’applicazione nell’Anagrafe delle Classi di Stampa. Se il risultato della verifica è negativo (la coda di stampa non è presente) il servizio deve: creare un’istanza nella Coda dei Tabulati in Quarantena, evidenziare l’anomalia su file di log ed inviare una segnalazione di errore. Se il risultato della verifica è positivo, il modulo (per ogni destinazione) deve eseguire i controlli definiti dal codice successivo.

Suite-ST-005

Riconoscimento Il modulo deve offrire un servizio in grado di applicare le regole di riconoscimento definite per il tabulato nell’ambito della Gestione Tabulati (cfr. Suite-GT-008). In particolare il servizio deve verificare l’esistenza del modello di tabulato specificato dall’applicazione nell’Anagrafe dei Modelli di Tabulato. Se il risultato della verifica è negativo (il modello indicato non è presente) il servizio deve: associare al tabulato l’insieme di parametri definiti per il modello di default, evidenziare l’anomalia su file di log ed inviare una segnalazione di warning (durante la fase realizzativa potranno essere valutate alternative quali l’inserimento del tabulato nella Coda dei Tabulati in Quarantena). Se il risultato della verifica è positivo, il servizio (per ogni destinazione) deve eseguire la funzione di immagazzinamento (cfr. Suite-ST-006).

Suite-ST-006

Immagazzinamento Se i risultati delle verifiche eseguite dai codici precedenti (cfr. Suite-ST-003, Suite-ST-004 e Suite-ST-005) sono positivi il modulo, per ogni destinazione specificata, deve: - creare nell’Archivio dei Tabulati un’istanza, caratterizzata da un identificativo univoco (Id_Oggetto), e valorizzarne i campi copiando i rispettivi dati contenuti nella busta del tabulato (cfr. Suite-ST-002);

G858 - 009/12 – Pag. 28 di 97

Codice Descrizione

- valorizzare nell’Archivio i campi relativi a data ed ora di caricamento (Data_Pubblicazione, Ora_Pubblicazione); - valorizzare il campo Coda_Stampa dell’Archivio con il valore associato nell’Anagrafe delle Classi di Stampa (cfr. codice Suite-ST-004); - associare all’istanza di tabulato le caratteristiche indicate nell’Anagrafe per il modello in questione (Utente_Gestore, Numero Copie, Obbligo_Stampa, Modulo_Stampa, Orientamento_Pagina, Numero_Righe, Numero_Colonne, Formato_Compresso); - valorizzare nell’Archivio il campo Numero_Pagine dopo aver calcolato tale valore analizzando il payload.

Suite-ST-007

Gestione Errori Il modulo deve implementare una funzione di scansione (su base richiesta o automatica) della Coda dei Tabulati in Quarantena che, per uno specifico tabulato in coda (o per tutti), verifichi la persistenza delle anomalie che hanno causato l’inserimento del tabulato nella coda: in caso negativo (cause non più presenti) il tabulato deve essere inserito nell’Archivio dei Tabulati.

Suite-ST-008

Gestione Stato/Archiviazione Tabulato Il modulo deve offrire un servizio in grado di applicare le regole per la gestione dello stato di un tabulato definite nell’ambito della Gestione Tabulati (cfr. Suite-GT-020). In particolare il prodotto deve monitorare la data di archiviazione per ogni tabulato (definita dal campo Periodo_Archiviazione nell’ambito del modello di tabulato) ed al raggiungimento di tale data deve: - attivare una opportuna procedura automatica (oggetto di fornitura) che provveda ad archiviare il tabulato su nastroteca (non cancellando dall’Archivio il record dei metadati che lo identifica); - aggiornare la variabile di stato Stato_Archiviato del record metadati tabulato nell’Archivio; - memorizzare data ed ora dell’attività nel campo Data_Ora_Archiviazione del record metadati tabulato nell’Archivio.

Suite-ST-009

Gestione Stato/Cancellazione Tabulato Il modulo deve offrire un servizio in grado di applicare le regole per la gestione dello stato di un tabulato definite nell’ambito della Gestione Tabulati (cfr. Suite-GT-020). In particolare il prodotto deve monitorare la data di cancellazione per ogni tabulato precedentemente archiviato (definita dal campo Periodo_Cancellazione nell’ambito del modello di tabulato) ed al raggiungimento di tale data deve attivare una opportuna procedura automatica (oggetto di fornitura) che provveda a cancellare definitivamente il record dei metadati del tabulato dall’Archivio. Nel caso in cui il prodotto gestisca il multi-indirizzamento utilizzando un unico tabulato (payload) referenziato da più record dei metadati nell’archivio (uno per ogni destinazione), la cancellazione del tabulato è condizionata al fatto che esso sia stato stampato, se esiste l’obbligo di stampa, da almeno un utente per ogni codice UNL destinatario.

Suite-ST-010

Gestione Stato/Stampato Il modulo deve offrire un servizio in grado di applicare le regole per la gestione dello stato di un tabulato definite nell’ambito della Gestione Tabulati (cfr. Suite-GT-019). In particolare il prodotto deve monitorare l’avvenuta stampa del tabulato, eseguita da un utente, aggiornando di conseguenza: - la variabile di stato Stato_Stampa del tabulato; - il campo Data_Ora_Stampa con la data corrente di sistema; - il campo Uid_Stampa con l’identificativo dell’utente che ha richiesto la stampa del tabulato.

Suite-ST-011

Gestione Stato/Visualizzato Il modulo deve offrire un servizio in grado di applicare le regole per la gestione dello stato di un tabulato definite nell’ambito della Gestione Tabulati (cfr. Suite-GT-019). In particolare il prodotto deve monitorare l’avvenuta visualizzazione del tabulato, eseguita da un utente, aggiornando di conseguenza: - la variabile di stato Stato_Visione del tabulato; - il campo Data_Ora_Visione con la data corrente di sistema; - il campo Uid_Visione con l’identificativo dell’utente che ha visualizzato il tabulato.

Tabella 6 – ESAG Suite - Requisiti “Servizi Tabulati”

G858 - 009/12 – Pag. 29 di 97

2.2.7 Gestione Base Dati Tabulati

Il modulo Gestione Base Dati Tabulati definisce l’implementazione delle seguenti strutture dati utilizzate all’interno della soluzione:

• Anagrafe delle Destinazioni: riporta l’insieme degli indirizzamenti logici (di primo livello) e la loro corrispondenza con gli indirizzamenti fisici relativi alle Filiali e i Servizi destinatari;

• Anagrafe delle Liste di Destinazioni: riporta l’insieme degli indirizzamenti logici (di primo livello) che non identificano direttamente una destinazione finale ma un gruppo (lista) di destinatari o un alias di una destinazione finale;

• Anagrafe delle Classi di Stampa: riporta l’insieme degli indirizzamenti logici (di secondo livello) e la loro corrispondenza con gli indirizzamenti fisici (code di stampa) visualizzati dagli utenti operatori;

• Anagrafe dei Modelli di Tabulato: definisce l’insieme di parametri che individuano caratteristiche tipiche per tutti i tabulati appartenenti ad uno specifico modello (in termini di formato, ciclo di vita, requisiti derivanti da normativa);

• Archivio dei Tabulati: comprende i record (metadati) che descrivono le caratteristiche identificative, le proprietà e lo stato di ogni tabulato durante l’intero ciclo della sua esistenza.

La tabella seguente elenca le specifiche relative al formato dei campi record dell’archivio

tabulati e delle anagrafi.

Codice Descrizione

Suite-DBT-001

Anagrafe dei Modelli di Tabulato I campi che caratterizzano un modello di tabulato all’interno dell’Anagrafe sono i seguenti: Modello_Tabulato: campo obbligatorio (25 caratteri) che identifica in modo unico il modello di appartenenza di un tabulato; Descrizione_Modello: campo opzionale (20 caratteri) che descrive il modello; Obbligo_Stampa: campo (booleano) che indica l’obbligatorietà o meno della stampa del tabulato da parte di almeno uno degli utenti abilitati; Numero_Copie: numero di copie (da 1 a 9) che l’utente deve stampare (nel caso in cui ci sia obbligo di stampa)[Default=1]; Periodo_Archiviazione: durata di mantenimento in linea (da 1 a 365 giorni) del tabulato nell’Archivio [Default=30] prima di procedere ad archiviarlo in nastroteca. Periodo_Cancellazione: periodo temporale (da 1 a 1825 giorni) dopo il quale un tabulato, precedentemente archiviato, viene definitivamente cancellato dall’Archivio mediante opportuna procedura. [Default=365] Modulo_Stampa: modulo di stampa del tabulato (obbligatorio 4 caratteri - può assumere i valori STD2, STD8, STD9, BIVA, *STD); Orientamento_Pagina: può assumere i seguenti valori:

- orizzontale (landscape) - verticale (portrait);

Numero_Righe: indica il numero di righe della generica pagina di un tabulato del modello (assume di default il valore 66); Numero_Colonne: indica il numero di colonne della generica pagina di un tabulato del modello (assume comunemente i valori 80 per i moduli *STD e 133 per i modelli STD2 e STD9);

G858 - 009/12 – Pag. 30 di 97

Codice Descrizione

Formato_Compresso: campo booleano; Utente_Gestore: campo (20 caratteri) che riporta il nome del gruppo MS AD che contiene gli utenti gestori del modello di tabulato.

Suite-DBT-002

Anagrafe delle Destinazioni I campi che caratterizzano un generico record all’interno dell’Anagrafe sono i seguenti: - UNL: codice (obbligatorio - 5 caratteri) che rappresenta l’indirizzamento logico di primo livello; - Sigla: sigla della Filiale/Servizio (3 caratteri); - Descrizione: campo descrittivo (20 caratteri); - UFT: codice (obbligatorio 5 caratteri) che rappresenta l’indirizzamento fisico di primo livello associato univocamente a una UNL. Le Tabelle 32 e 33 dell’Allegato B. L’applicazione FAGDD elencano le attuali associazioni definite tra gli indirizzamenti logici (UNL) e fisici (UFT) di primo livello rispettivamente per Filiali e Servizi.

Suite-DBT-003

Anagrafe delle Liste di Destinazioni I campi che caratterizzano un generico record all’interno di tale anagrafe sono i seguenti: - ListaAlias: nome della lista o di un alias (obbligatorio - 6 caratteri) utilizzato dall’applicazione come indirizzamento logico di primo livello; - Tipo: carattere che può assumere il valore “E” se la destinazione effettiva è un elemento finale (coincidente con un codice UNL) oppure il valore “L” se la destinazione è a sua volta un’altra lista o un insieme di alias; - Destinazione: insieme del/dei codici UNL che identificano l’alias o identificativo di un’altra lista annidata; - Descrizione: campo descrittivo (20 caratteri) per la lista. La Tabella 34 dell’Allegato B. L’applicazione FAGDD elenca le liste di destinazione attualmente definite.

Suite-DBT-004

Anagrafe delle Classi di Stampa I campi che caratterizzano un generico record all’interno dell’Anagrafe sono i seguenti: - Classe_Stampa: campo (2 caratteri) che rappresenta l’indirizzamento logico di secondo livello; - Descrizione: campo descrittivo (20 caratteri - opzionale); - Coda_Stampa: campo (3 caratteri) che rappresenta l’indirizzamento logico di secondo livello associato univocamente ad una classe di stampa. La Tabella 35 dell’Allegato B. L’applicazione FAGDD elenca le classi di stampa attualmente definite.

Suite-DBT-005

Archivio dei Tabulati Il record che identifica un tabulato, all’interno dell’Archivio, dovrà contenere i seguenti campi: - Id_Oggetto: identificativo univoco rappresentante l’oggetto tabulato all’interno dell’archivio (8 caratteri); - UNL: indirizzamento logico di primo livello rappresentante il codice UNL destinatario del tabulato (5 caratteri); - Classe_Stampa: indirizzamento logico di secondo livello rappresentante la classe di stampa destinataria del tabulato (2 caratteri); - Coda_Stampa: indirizzamento fisico di secondo livello rappresentante la coda di stampa destinataria del tabulato (3 caratteri); - Modello_Tabulato: descrizione amministrativa del tabulato (stringa di 25 caratteri); - Id_Applicazione: stringa alfanumerica che rappresenta il codice SSPP o il nome dell’applicazione che ha originato il tabulato (4 caratteri); - Codice_Tabulato: stringa alfanumerica che rappresenta il codice identificativo del tabulato nell’ambito dell’applicazione che lo ha originato il tabulato (3 caratteri); - Id_Richiesta_Tab: codice numerico che identifica univocamente la produzione di un tabulato nell’ambito di un applicazione (7 caratteri – campo opzionale); - Data_Contabile: Data di riferimento amministrativo o contabile del tabulato nella forma AAMMGG (6 caratteri – campo opzionale);

G858 - 009/12 – Pag. 31 di 97

Codice Descrizione

- Versione: Numero di 2 cifre che identifica all’occorrenza versioni successive nell’ambito della data contabile (2 caratteri – campo opzionale); - Data_Produzione: Data di elaborazione applicativa del tabulato nella forma AAMMGG; - Ora_Produzione: Ora di elaborazione applicativa del tabulato nella forma HHMMSS; - Data_Pubblicazione: Data di caricamento del tabulato nell’archivio nella forma AAMMGG; - Ora_Pubblicazione: Ora di caricamento del tabulato nell’archivio nella forma HHMMSS; - Numero_Pagine: numero di pagine (da 1 a 999) che compongono il tabulato. Questi campi vengono valorizzati in fase di immagazzinamento del tabulato (cfr. Suite-ST-006) a partire dai valori contenuti della busta del tabulato.

Suite-DBT-006

Archivio dei Tabulati Il record identificativo di un tabulato dovrà contenere i seguenti campi: Utente_Gestore, Numero_Copie, Obbligo_Stampa, Modulo_Stampa valorizzati in fase di immagazzinamento del tabulato (cfr. Suite-ST-006) a partire dai valori acquisiti dall’Anagrafe dei Modelli.

Suite-DBT-007

Archivio dei Tabulati Il record identificativo di un tabulato dovrà contenere il campo Data_Ora_Archiviazione (formato AAMMGGHHMMSS) riportante data ed ora dell’archiviazione su nastroteca del tabulato. Tale campo viene modificato automaticamente da apposita procedura (cfr. Suite-ST-008) alla scadenza del periodo di mantenimento in linea del tabulato.

Suite-DBT-008

Archivio dei Tabulati Il record identificativo di un tabulato dovrà contenere un campo che ne identifichi lo “stato di stampato” e che venga gestito in modo automatico dal prodotto. Tale campo (denominato Stato_Stampa), impostato a “NO” in fase di acquisizione del tabulato, assume il valore “SI” alla prima richiesta di stampa da parte di un utente.

Suite-DBT-009

Archivio dei Tabulati Il record identificativo di un tabulato dovrà contenere un campo che ne identifichi lo “stato di visionato” e che venga gestito in modo automatico dal prodotto. Tale campo (denominato Stato_Visione), impostato a “NO” in fase di acquisizione del tabulato, assume il valore “SI” alla prima richiesta di visualizzazione da parte di un utente.

Suite-DBT-010

Archivio dei Tabulati Il record identificativo di un tabulato dovrà contenere un campo che identifichi lo “stato di archiviato” e che venga gestito in modo automatico dal prodotto. Tale campo (denominato Stato_Archiviazione), impostato a “NO” in fase di acquisizione del tabulato, assume il valore “SI” successivamente alla richiesta di archiviazione su nastroteca.

Suite-DBT-011

Archivio dei Tabulati Il record identificativo del tabulato dovrà contenere i seguenti campi (gestiti automaticamente dal sistema): - Data_Ora_Stampa: indica la data ed ora della prima stampa del tabulato (nel formato AAMMGGHHMMSS); - Uid_Stampa: indica l’identificativo del primo utente che ha richiesto la stampa del tabulato (8 caratteri); - Data_Ora_Visione: indica la data e l’ora (nel formato AAMMGGHHMMSS) della prima richiesta di visualizzazione del tabulato; - Uid_Visione: indica l’identificativo del primo utente che ha visualizzato il tabulato.

Tabella 7 – ESAG Suite - Requisiti “Gestione Base Dati Tabulati”

2.2.8 Servizi Supporti Fisici

Il modulo Servizi Supporti Fisici contiene le funzionalità richieste dal modulo Gestione Flussi per il trattamento dei files registrati su supporti magneto-ottici.


G858 - 009/12 – Pag. 32 di 97

Codice Descrizione

Suite-SSF-001

Protocollo Supporto Il prodotto/la soluzione deve essere in grado di assegnare, sia in ricezione che in spedizione, un protocollo di portineria univoco per ogni tipo di supporto fisico quali floppy, cd, dvd, cassette, carta (stampe). Tale protocollo deve permettere di individuare tutti gli eventuali file che appartengono ad uno stesso supporto.

Suite-SSF-002

Lettura/Upload supporti magneto-ottici Il prodotto/soluzione deve offrire una funzione, fruibile tramite web-browser, per il caricamento dei dati pervenuti su supporti magnetici (floppy, cassette 3490, USB storage) od ottici (CD, DVD) e dei relativi metadati (es- mittente, destinatario, ecc..). Tale funzione deve prevedere la lettura dei vari supporti magneto-ottici, l'upload dei file verso il Sistema destinatario dei dati e la stampa su etichetta del numero di protocollo supporto assegnato: tale etichetta sarà poi applicata sul supporto lavorato.

Suite-SSF-003

Scrittura cassette (3490) Il prodotto/soluzione deve offrire la funzione di scrittura file su cartucce 3490. In particolare deve essere possibile la scrittura : - di un file singolo; - di tutti i file che hanno stesso numero di protocollo supporto; - di tutti i file passati tramite lista parametrica; La soluzione dovrà presentare anche una funzione per la stampa dell'etichetta da applicare sul supporto.

Suite-SSF-004

Stampa file Il prodotto/soluzione deve fornire funzioni di stampa in formato A4 di file nei formati PCL, DJDE, PDF su stampanti che supportano PostScript e PCL; le funzioni di stampa devono essere invocabili via JCL su piattaforma z/OS tramite batch. Tali funzioni di stampa devono integrarsi con i prodotti/protocolli già presenti in Banca rispettivamente: - LPR per l’invio di stampe PCL; - DocBridge Software per la conversione da PDF a PCL; - Xerox Printer Access Facility (XPAF) per la conversione da DJDE a PCL.

Suite-SSF-005

Scrittura floppy, cd e dvd Il prodotto/soluzione deve consentire la scrittura su vari supporti come floppy, cd e dvd. La scrittura sarà effettuata utilizzando macchine dipartimentali e potrà anche utilizzare il software datamat già esistente; dovrà essere stampata anche l'etichetta da applicare sul supporto.

Suite-SSF-006

Quadratura Supporti Il prodotto/soluzione deve fornire funzioni di identificazione, tracciatura e quadratura dei supporti sia in ingresso che in spedizione; in spedizione il prodotto deve consentire la quadratura tra il numero dei supporti prodotti e dei colli spediti.

Suite-SSF-007

Stampa Etichette/Distinte di Spedizione Il prodotto/soluzione deve fornire una funzione di stampa sia delle etichette, da apporre sui plichi di stampe cartacee da spedire via Poste Italiane Spa., sia delle distinte descrittive del contenuto degli stessi. La soluzione dovrà produrre anche gli elenchi delle spese giornaliere per le spedizioni via corriere e/o via Poste Italiane Spa. Riguardo a queste ultime, la soluzione deve calcolarne il costo consentendo sia la produzione dell’informativa sulle movimentazioni del conto corrente postale per le macchine affrancatrici, sia il raffronto mensile delle fatturazioni presentate dai corrieri.

Tabella 8 – ESAG Suite - Requisiti “Servizi Supporti Fisici”

G858 - 009/12 – Pag. 33 di 97

2.3 ESAG U2A

La componente “ESAG U2A“ raggruppa l’insieme dei moduli per la gestione dei processi

di interazione User-to-Application (U2A) che consentono agli utenti (operatori, amministratori, gestori) di interagire con la soluzione, in modalità grafica interattiva (invocabile mediante web browser) o da linea di comando. Nel presente capitolo sono descritti i requisiti funzionali che l’interfaccia utente-applicazione

dovrà soddisfare.

2.3.1 Interfaccia Utente Flussi

Il modulo Interfaccia Utente Flussi contiene l’insieme delle funzionalità che l’interfaccia utente deve fornire per consentire la realizzazione dei seguenti processi: • Disegno dei flussi; • Gestione dei Supporti Magnetico-ottici; • Monitoraggio dei Flussi; • Servizi sui flussi. Interfaccia - Disegno dei flussi

Il disegno dei flussi è la funzionalità che consente di inserire e modificare nel sistema le informazioni necessarie al trattamento di un flusso da acquisire o da spedire. La soluzione deve fornire un’interfaccia con l’applicazione che consenta di realizzare il disegno dei flussi, deve prevedere l’inserimento di una serie di informazioni necessarie al censimento e al trattamento di un flusso in ingresso o in uscita. Per la definizione di ogni flusso deve essere specificato quanto segue:

• il partner (controparte) al quale il flusso deve essere inviato o dal quale il flusso deve essere ricevuto;

• il mezzo trasmissivo utilizzato per la ricezione o per la trasmissione del flusso (rete, supporto magnetico-ottico, ecc);

• la base informativa che fornisce indicazioni sull’applicazione che utilizza il flusso. • le regole di trattamento che forniscono indicazioni sulle azioni che intervengono nel

momento di presa in carico del flusso da parte del prodotto/soluzione. Tali regole comprendono la priorità, che definisce l’ordine di presa in carico del flusso, il numero massimo di file trattabili contemporaneamente per tipologia di flusso e la gestione dell’accodamento, le azione da compiere sui dati che comprendono la conversione nei formati EBCDIC, ASCII, UTF-8 (con possibilità di ampliamento ad altri formati), la funzione di sbustamento per i file XML, la compressione/decompressione del flusso, la cifratura/decifratura del flusso, la trasformazione del flusso in un formato dati diverso (PDF, EXCEL, WORD, ecc), la funzione di bulk/unbulk, per raggruppare o spacchettare i dati di un flusso;

• le regole di riconoscimento e di routing che consentono di di riconoscere il file in base a specifiche caratteristiche (p.e. presenza di stringhe alfa-numeriche in specifiche posizioni all’interno del file oppure regole di naming convention) e ruotare i file verso/da applicazioni specifiche o interfacciarsi verso componenti middleware già presenti in Istituto (ASF, GARI, TWS, NetView FTP).

G858 - 009/12 – Pag. 34 di 97

Interfaccia - Gestione dei Supporti Magnetico-ottici

La funzionalità di Gestione dei Supporti Magneto-ottici, in caso di ricezione, deve provvedere all’acquisizione dei flussi inviati dalle controparti alla Banca d'Italia attraverso supporti magneto-ottici e, in caso di spedizione, deve predisporre supporti analoghi per la spedizione dei flussi alle controparti. La soluzione deve fornire un’interfaccia con l’applicazione che consenta di gestire i supporti

magneto-ottici. Interfaccia - Monitoraggio dei Flussi

La funzionalità di Monitoraggio dei Flussi deve fornire la visibilità sullo stato dei flussi gestiti dalla soluzione evidenziandone errori o situazioni critiche. Deve inoltre prevedere l’interazione con i sistemi di monitoraggio dell’istituto per l’invio e/o la ricezione di eventuali segnalazioni. La soluzione deve fornire un’interfaccia con l’applicazione che consenta di visualizzare

complessivamente lo stato delle varie tipologie di flussi definiti in ESAG, evidenziandone eventuali situazioni di errore/anomalia. L’interfaccia deve inoltre consentire la selezione dei flussi attraverso filtri di ricerca (es. selezione di un periodo, partner mittente/destinatario, applicazione mittente/destinataria, ecc.) e fornire, per ciascun flusso, le informazioni di dettaglio relative ai file che lo compongono e il rispettivo stato. Qualora non fosse possibile eseguire una o più delle funzioni richieste, le relative segnalazioni

devono essere segnalate dall’interfaccia attraverso idonea messaggistica a video (p.e. utente non autorizzato alla richiesta, dati non disponibili, ecc). Interfaccia - Servizi sui Flussi

I Servizi sui Flussi consentono all’utente di interagire con il prodotto/la soluzione al fine di assicurarne il corretto funzionamento e di definire le azioni automatiche e/o manuali da eseguire sui flussi. Le diverse funzionalità utilizzabili dall’utente dipenderanno dalla tipologia del flusso e dal profilo autorizzativo dell’utente. La soluzione deve fornire un’interfaccia con l’applicazione che consenta di associare i servizi,

che saranno eseguiti automaticamente, alle diverse tipologie di flussi definiti in ESAG. L’interfaccia deve consentire la selezione dei flussi attraverso filtri di ricerca (es. selezione di un periodo, partner mittente/destinatario, applicazione mittente/destinataria, ecc.). In aggiunta al trattamento automatico, il prodotto/la soluzione deve fornire un’interfaccia all’utente per richiamare alcuni servizi manualmente. I Servizi sui flussi possono essere di tipo generalizzato o specifici per tipologia di flusso. La

possibilità di richiedere servizi sui flussi dipende inoltre dal profilo autorizzativo dell’utente che li richiede. Qualora non fosse possibile eseguire uno o più dei servizi richiesti, le relative segnalazioni devono essere evidenziate dall’interfaccia attraverso idonea messaggistica a video. La seguente tabella definisce i requisiti funzionali richiesti.

Codice Descrizione

U2A-UIF-001

Interfaccia utente Il prodotto/la soluzione deve essere accedibile tramite interfaccia web-browser. In aggiunta all’accesso tramite web-browser, la soluzione deve prevedere delle modalità alternative di accesso ai sistemi utilizzati (p.e. linee di comando o query di accesso alla base dati), al fine di garantire la possibilità verificare il corretto funzionamento del sistema e dei processi di trattamento dei dati in caso d’indisponibilità dell'interfaccia web.

G858 - 009/12 – Pag. 35 di 97

Codice Descrizione

U2A-UIF-002 Interfaccia utente Il prodotto/la soluzione deve permettere la fruizione di un servizio di Help On Line relativo alle funzioni presenti nelle pagine utilizzate dagli utenti.

U2A-UIF-003

Interfaccia utente Per ognuna delle informazioni inserite attraverso l’interfaccia utente, la soluzione deve eseguire controlli di tipo formale (p.e. controlli sul formato delle date, verifica caratteri su campi numerici, ecc.) e controlli relativi al tipo di operazione che si sta eseguendo (p.e. verifica dell’esistenza di un partner al momento dell’associazione con il flusso). In caso di rilievi le relative segnalazioni devono essere segnalate dall’interfaccia attraverso idonea messaggistica a video.

U2A-UIF-004

Disegno Flussi Il prodotto/la soluzione deve fornire un'interfaccia per il disegno (inserimento e modifica) dei flussi accedibile sia tramite web-browser sia tramite modalità alternativa (cfr. U2A-UIF-001). Attraverso l'interfaccia deve essere possibile disegnare un nuovo flusso informativo attraverso la funzione Inserimento/Modifica Flusso. Un flusso è composto dalle seguenti informazioni: - Partner - Base Informativa - Mezzo Trasmissivo Al fine di definire un nuovo flusso occorre richiamare le seguenti funzioni: 1.Inserimento/Modifica Partner 2.Inserimento/Modifica Base Informativa 3.Inserimento/Modifica Mezzo Trasmissivo 4.Inserimento/Modifica Regole di Trattamento 5.Inserimento/Modifica Regole di riconoscimento e di routing

U2A-UIF-005

Gestione Supporti Magneto-ottici Il prodotto/la soluzione deve fornire un'interfaccia, accedibile sia tramite web-browser sia tramite modalità alternativa (cfr. U2A-UIF-001), per la gestione dei supporti Magneto-ottici inviati alla Banca d'Italia quali Floppy-Disk, CD-ROM, DVD, Cassetta 3490, pen-drive e unità disco esterne. In acquisizione l'interfaccia deve consentire di richiamare le seguenti funzioni: 1. caricamento dei dati, per caricare nel sistema i flussi presenti nel supporto; 2. caricamento dei metadati, per caricare nel sistema i metadati associati al supporto ricevuto (es. mittente, destinatario, ecc.) qualora nel processo di caricamento automatico si siano verificati dei problemi; 3. generazione e stampa numero di protocollo supporto; 4. stampa su etichetta del numero di protocollo supporto assegnato. In spedizione l'interfaccia deve consentire di richiamare le seguenti funzioni: 1. copia sul supporto dei dati da spedire; il prodotto/soluzione deve consentire la scrittura su vari supporti come floppy, cd e dvd; la scrittura sarà effettuata utilizzando macchine dipartimentali e potrà anche utilizzare il software già esistente in Banca; 2. generazione e stampa numero di protocollo supporto; 4. stampa su etichetta del numero di protocollo supporto assegnato.

U2A-UIF-006

Monitoraggio Flussi Il prodotto/la soluzione deve fornire un'interfaccia, accedibile sia tramite web-browser sia tramite modalità alternativa (cfr. U2A-UIF-001), per l'attivazione delle funzionalità di monitoraggio end-to-end; in particolare il prodotto/la soluzione deve: - garantire la visibilità complessiva sullo stato delle varie tipologie di flussi definiti in ESAG, evidenziandone eventuali situazioni di errore/anomalia; - consentire la selezione dei flussi attraverso filtri di ricerca (es. intervallo di tempo, partner mittente/ destinatario, applicazione mittente/destinataria, etc.); - avere, per ciascun flusso, le informazioni di dettaglio sui file che lo compongono e il rispettivo stato.

G858 - 009/12 – Pag. 36 di 97

Codice Descrizione

U2A-UIF-007

Servizi sui Flussi Il prodotto/la soluzione deve fornire un'interfaccia, accedibile sia tramite web-browser sia tramite modalità alternativa (cfr. U2A-UIF-001), per la definizione e l'attivazione dei Servizi sui Flussi; in particolare attraverso l'interfaccia deve essere possibile richiamare le seguenti funzioni dipendenti dalla tipologia del flusso e dal livello di autorizzazione dell’utenza: - Funzioni per la definizione delle regole di accesso allo scopo di definire il livello di riservatezza del flusso e di indicare quali sono i profili e/o le utenze che possono richiedere servizi sul flusso; - Funzioni per la gestione dello stato dei flussi che consentono di visualizzare lo stato di uno specifico flusso e di modificarlo (p.e. per renderlo nuovamente disponibile ad una applicazione che lo ha precedentemente elaborato o per procedere ad una nuova spedizione di un flusso già inviato); - Funzioni di visualizzazione e modifica del contenuto dei flussi che consentono di visualizzare il contenuto del flusso ed eventualmente di modificarlo soltanto agli utenti autorizzati ed in specifiche situazioni di emergenza; - Funzioni di immagazzinamento che consentono di definire il periodo di conservazione del flusso e il tipo di conservazione che può riferirsi al flusso così come è stato ricevuto/spedito o comprendere anche il salvataggio del flusso che ha subito eventuali trattamenti all’interno del prodotto / della soluzione (p.e. dopo una conversione ASCII-EBCDIC); - Funzioni di tuning che consentono di agire sul funzionamento del prodotto/della soluzione impostando il numero massimo di flussi gestiti parallelamente, gestendo gli eventuali accodamenti, modificando le priorità dei flussi, etc; - Funzioni di trasformazione che consentono di eseguire manualmente le trasformazioni previste dalle Regole di Trattamento, qualora esse non avvengano automaticamente; - Funzioni di riconoscimento e di routing che consentono di eseguire manualmente le operazioni previste dalle Regole di Riconoscimento, qualora esse non avvengano automaticamente; - Funzioni di accesso al LOG che consentono di eseguire accessi al Log della soluzione, per la verifica delle operazioni che sono tracciate all’interno della soluzione stessa.

Tabella 9 – ESAG U2A - Requisiti “Interfaccia Utente Flussi"

2.3.2 Interfaccia Utente Tabulati

Il modulo Interfaccia Utente Tabulati deve implementare un’interfaccia grafica fruibile da un utente operatore di Filiale/Servizio (nell’ambito della visibilità individuata dalle funzioni di Gestione Accesso), per la visualizzazione dei tabulati presenti nell’Archivio, e da un utente amministratore del prodotto per le funzioni di configurazione delle Anagrafi e le attività di monitoraggio e supporto in caso di errore o anomalia. L’interfaccia deve inoltre consentire la selezione dei tabulati attraverso filtri di ricerca e fornire, per ciascun tabulato, le informazioni di dettaglio relative ai metadati che lo caratterizzano e il rispettivo stato. Deve inoltre essere possibile visualizzare, salvare su supporto fisico locale e stampare

(utilizzando le stampanti definite sul posto di lavoro) il contenuto del tabulato.

Funzioni di Visualizzazione e Ricerca

La seguente tabella elenca i requisiti dell’interfaccia utente per le funzionalità di visualizzazione e ricerca.

G858 - 009/12 – Pag. 37 di 97

Codice Descrizione

U2A-UIT-001

HomePage/Presentazione metadati La pagina iniziale presentata ad un utente (appartenente ad una Filiale caratterizzata univocamente da una OU e da un codice UFT) deve presentare la lista dei tabulati presenti nell’Archivio e destinati a tutti i codici UNL associati al codice UFT della Filiale/Servizio cui l’utente è assegnato. La presentazione dei record risultanti deve prevedere un ordinamento primario riferito al campo UNL e un ordinamento secondario riferito al campo Coda_Stampa. Devono essere visualizzati tutti i tabulati presi in carico dalla soluzione ma non ancora stampati (se è richiesto l’obbligo di stampa) o non ancora visualizzati da alcun utente (se non è richiesto l’obbligo di stampa).

U2A-UIT-002

HomePage/Presentazione metadati

Per ogni record, di cui al codice precedente, devono essere visualizzati almeno i seguenti campi (“visualizzazione ridotta”):

- Id_Oggetto;

- Modello_Tabulato;

- Id_Applicazione;

- Codice_Tabulato;

- Numero_Pagine;

- Obbligo_Stampa;

- Stato_Stampa;

- Stato_Visione;

- Stato_Archiviazione;

- Data_Pubblicazione;

- Ora_Pubblicazione.

U2A-UIT-003

Presentazione tabulato

Selezionando un qualsiasi record dell’Archivio deve essere possibile visualizzare il contenuto (testo) del tabulato.

U2A-UIT-004

Presentazione tabulato

In fase di visualizzazione del contenuto deve essere garantita l’originaria suddivisione in pagine del tabulato.

U2A-UIT-005

Presentazione tabulato In fase di visualizzazione devono essere garantite le caratteristiche che definiscono il formato della pagina (es. orientamento, numero righe, etc) e che devono essere ricavate, per il modello cui il tabulato appartiene, dall’Anagrafe dei Modelli.

U2A-UIT-006

Presentazione metadati Il modulo deve fornire (in aggiunta alla modalità di visualizzazione “ridotta” definita nel codice U2A-UIT-002) una modalità di visualizzazione “completa” che permetta di visualizzare il contenuto di tutti i campi definiti nel record identificativo di un generico tabulato.

U2A-UIT-007

Ricerca Deve essere possibile effettuare delle ricerche sull’Archivio utilizzando come filtri di ricerca almeno i seguenti campi: - Id_Oggetto; - Id_Applicazione; - Codice_Tabulato; - Id_Richiesta_Tab; - Modello_Tabulato; - UNL; - Coda_Stampa; - Obbligo_Stampa; - Stato_Stampa; - Stato_Visione;

G858 - 009/12 – Pag. 38 di 97

Codice Descrizione

- Stato_Archiviazione; - Data_Produzione; - Data_Contabile; - Data_Pubblicazione. Sui campi di ricerca devono essere previste almeno le seguenti operazioni: - maggiore di; - minore di; - uguale a; - maggiore o uguale a; - minore o uguale a; - diverso da.

U2A-UIT-008

Ricerca Deve essere possibile effettuare ricerche sui campi definiti al codice U2A-UIT-007 utilizzando filtri multipli (in AND logico). Esempio1: Ricerca di tutti i tabulati per i quali è stato richiesto l’obbligo di stampa e non sono stati ancora stampati [(“Obbligo_Stampa” uguale a “SI”) AND (“Stato_Stampa” = “NO”) Esempio2: Ricerca di tutti i tabulati archiviati acquisiti tra il 3 Gennaio 2012 ed il 7 Gennaio 2012. [(“Stato_Archiviazione” = “SI”) AND (‘Data_Pubblicazione” maggiore o uguale a “120103”) AND (‘Data_Pubblicazione” minore o uguale a “120107”)]

U2A-UIT-009 Ricerca Deve essere possibile effettuare ordinamenti (crescenti o decrescenti per i campi visualizzati) sui risultati delle ricerche descritte ai codici U2A-UIT-007 e U2A-UIT-008.

U2A-UIT-010 Gestione Errori Eventuali esiti negativi per le funzioni richieste devono essere segnalati dall’interfaccia attraverso idonea messaggistica a video.

Tabella 10 – ESAG U2A - Requisiti Interfaccia Visualizzazione Tabulati"

Funzioni che utilizzano dispositivi locali (Stampa)

La seguente tabella elenca i requisiti dell’interfaccia utente per le funzionalità che utilizzano dispositivi locali al posto di lavoro dell’utente (stampanti, dischi locali, etc).

Codice Descrizione

U2A-UIT-011 Salvataggio in formato testo Il modulo deve permettere all’utente il salvataggio del contenuto di un tabulato in formato testo su un dispositivo locale al posto di lavoro (es. disco locale, dispositivo USB).

U2A-UIT-012 Salvataggio in formato PDF Il modulo deve permettere all’utente il salvataggio di un tabulato selezionato in formato PDF su un dispositivo locale.

U2A-UIT-013

Stampa Il modulo per ogni tabulato visualizzato deve permetterne la stampa completa o di singole pagine (selezionabili) utilizzando le stampanti predefinite sul posto di lavoro dell’utente. Per il soddisfacimento di tale requisito non deve essere necessario configurare le stampanti all’interno del prodotto/soluzione.

U2A-UIT-014 Formato In fase di stampa il modulo deve garantire l’originaria suddivisione in pagine del tabulato e il rispetto delle caratteristiche di formato definite nel modello del tabulato.

G858 - 009/12 – Pag. 39 di 97

U2A-UIT-015 Invio Allegato Posta Deve essere possibile allegare un tabulato selezionato (in formato PDF) ad un messaggio da inviare ad una generica casella di posta.

Tabella 11 – ESAG U2A - Requisiti Interfaccia Stampa Tabulati

Funzioni di Disegno

La seguente tabella elenca i requisiti dell’interfaccia utente per le funzionalità di configurazione delle strutture dati utilizzate dalla soluzione.

Codice Descrizione

U2A-UIT-016 L’amministratore del prodotto deve poter modificare l’associazione tra un codice UNL ed un codice UFT all’Anagrafe delle Destinazioni oppure deve poter definire un nuovo codice UNL ed associargli il rispettivo codice UFT.

U2A-UIT-017 L’amministratore del prodotto deve poter visualizzare o modificare il contenuto di una Lista nell’Anagrafe delle Destinazioni (es. “connettendo” una destinazione (UOP o Lista) ad una lista_alias)..

U2A-UIT-018 L’amministratore del prodotto deve poter modificare il contenuto di un record (es. modificare il campo Descrizione) nell’Anagrafe delle Classi di Stampa oppure deve poter definire una nuova classe.

U2A-UIT-019 L’amministratore del prodotto deve poter visualizzare o modificare un campo di un modello (es. modificare il campo Obbligo_Stampa) nell’Anagrafe dei Modelli oppure deve poter definire un nuovo modello di tabulato.

U2A-UIT-020 L’amministratore del prodotto deve poter accedere alla Coda dei Tabulati in Quarantena al fine di forzare il reinstradamento del tabulato nell’Archivio (una volta eliminata la causa che ha generato la quarantena).

Tabella 12 – ESAG U2A - Requisiti Interfaccia Disegno Tabulati

G858 - 009/12 – Pag. 40 di 97

2.4 ESAG A2A

Nella componente “ESAG A2A” sono contenuti i moduli per la gestione dei processi di interazione Application-to-Application (A2A); essa comprende tutti i moduli che consentono l’integrazione tra la soluzione stessa e le applicazioni presenti in Banca, al fine dello scambio di flussi dati/tabulati o dell’invocazione remota di azioni o eventi. In particolare è oggetto di fornitura la realizzazione dell’integrazione tra l’ESAG Suite, e le componenti esterne già presenti nel contesto di Banca d’Italia quali: - ASF per la gestione dello scambio di informazioni tra le procedure del Servizio RES e il

sistema creditizio; - GARI per le operazioni di trasferimento file tra i sistemi dell’Istituto e le reti esterne; - Tivoli Workload Scheduler per le operazioni di schedulazione dei job; - Netview FTP per i collegamenti FTP punto-punto; - FAGDD per la gestione dei tabulati prodotti dalle applicazioni IMS che utilizzano il formato

FAGDD per la compilazione della busta che contiene le caratteristiche del tabulato; - APMAIN per la gestione dei tabulati prodotti dalle applicazioni IMS che utilizzano il formato

APMAIN per la compilazione della busta che contiene le caratteristiche del tabulato; - IC per la gestione dei tabulati prodotti dalle applicazioni Unix che utilizzano il formato IC per

la compilazione della busta che contiene le caratteristiche del tabulato; - LPTAB per la gestione dei tabulati prodotti dalle applicazioni Unix che utilizzano il formato

LPTAB per la compilazione della busta che contiene le caratteristiche del tabulato.

2.4.1 Interfaccia ASF

L’applicazione infrastrutturale ASF costituisce l’interfaccia per alcune tipologie di flussi scambiati da applicazioni in ingresso e in uscita. Il prodotto/la soluzione deve includere lo sviluppo di una interfaccia con l’applicazione infrastrutturale ASF. La seguente tabella definisce i requisiti funzionali richiesti.

Codice Descrizione

A2A-IntASF-001 Per i flussi in ingresso, il prodotto deve essere in grado di fornire all’infrastruttura ASF, in ambiente mainframe, per ogni applicazione definita e per mezzo trasmissivo, una coppia di dataset contenenti nello specifico, il primo, la lista dei file contenenti i dati da ricevere, il secondo, i dati di etichetta, per ogni file fisico scaricato, in un tracciato ben definito.

A2A-IntASF-002 Per i flussi in uscita, il prodotto deve fornire all’infrastruttura ASF una funzione in grado di accedere ad un’area di memoria su piattaforma mainframe in cui ASF scrive tutte le informazioni di etichetta necessarie per la corretta spedizione.

A2A-IntASF-003 Per i flussi in uscita, il prodotto deve essere in grado di allocare un dataset su piattaforma mainframe sul quale l’applicazione ASF scriverà il file da spedire. Utilizzando le informazioni di etichetta, contenute nell’area di colloquio, e il file da spedire, contenuto sul dataset, la soluzione dovrà provvedere alla spedizione.

A2A-IntASF-004 Per i flussi in uscita, la soluzione, in caso di errore, dovrà essere in grado di gestire le ripartenze.

A2A-IntASF-005 Sia per i flussi in ingresso che in uscita, la soluzione dovrà recepire l’avvenuta elaborazione dei file forniti ad ASF e provvedere ad aggiornarne lo stato nel catalogo informativo di ESAG.

Tabella 13 – ESAG A2A - Requisiti "Interfaccia ASF"

G858 - 009/12 – Pag. 41 di 97

2.4.2 Interfaccia GARI

Il GARI, Gestore Applicazioni Reti Interbancarie, è l’infrastruttura applicativa, operante in ambiente mainframe z/OS, utilizzata in Banca per l’instradamento dei dati sulle reti telematiche (RNI, ESCBNet, SWIFT, Internet) sia in ricezione che in spedizione.

Il prodotto/la soluzione deve includere moduli di interfaccia per il dialogo con il GARI secondo i requisiti funzionali di seguito descritti. La seguente tabella definisce i requisiti funzionali richiesti.

Codice Descrizione

A2A-IntGARI-001

RNI-Spedizione Per effettuare la SPEDIZIONE via RNI, il prodotto/la soluzione dovrà interfacciarsi con il GARI, sottomettendo un JCL del GARI, già precostituito (PRENOTA), che nel caso della spedizione dovrà contenere le seguenti variabili obbligatorie: - Nome della applicazione RNI - Nome del file da spedire - Indirizzo univoco RNI del mittente - Indirizzo univoco RNI del destinatario Quando il file viene recapitato al destinatario il GARI a sua volta sottomette una fase di ESITO, contenente un insieme di variabili tra cui il nome del file spedito. Il prodotto/la soluzione deve utilizzare le variabili ricevute dalla fase di ESITO, deve aggiornare in una base dati di ESAG lo stato del file in "Delivered" ed utilizzare tale stato per procedere con l'elaborazione, eventualmente verificando se esistono altri file da spedire, trasmettendo al GARI il primo della lista.

A2A-IntGARI-002

RNI-Ricezione Per la RICEZIONE via RNI, al ricevimento del flusso, il GARI sottomette un JCL già precostituito (ESITO), contenente un insieme di variabili tra cui le seguenti: - Nome della applicazione RNI - Nome del file ricevuto - Indirizzo univoco RNI del mittente - Indirizzo univoco RNI del destinatario Il prodotto/la soluzione deve innescare il processo di caricamento dei dati in ESAG utilizzando le variabili ricevute dalla fase di ESITO.

A2A-IntGARI-003

Internet-Spedizione Per la SPEDIZIONE via Internet, il prodotto/la soluzione deve copiare il file da spedire in uno specifico “File System”, nella partizione USS di z/OS: al termine dell'operazione di copia, il prodotto/la soluzione deve creare nello stesso File System un nuovo file con lo stesso nome ed estensione ".ok", al fine di notificare il completamento della copia e la disponibilità del file alla spedizione. Quando il file viene recapitato al destinatario il GARI a sua volta sottomette una fase di ESITO, contenente un insieme di variabili tra cui il nome del file spedito. Il prodotto/la soluzione deve utilizzare le variabili ricevute dalla fase di ESITO, deve aggiornare in una base dati di ESAG lo stato del file in "Delivered" ed utilizzare tale stato per procedere con l'elaborazione, eventualmente verificando se esistono altri file da spedire, trasmettendo al GARI il primo della lista.

A2A-IntGARI-004

Internet-Ricezione Per la RICEZIONE via Internet, al ricevimento del flusso, il GARI sottomette un JCL già precostituito (ESITO), contenente un insieme di variabili tra cui le seguenti:- Nome della applicazione - Nome del file ricevuto - Indirizzo del mittente- Indirizzo del destinatario- Base informativa. Il prodotto/la soluzione deve innescare il processo di caricamento dei dati in ESAG utilizzando le variabili ricevute dalla fase di ESITO.

Tabella 14 – ESAG A2A - Requisiti “Interfaccia GARI”

G858 - 009/12 – Pag. 42 di 97

2.4.3 Interfaccia TWS

Il Tivoli Workload Scheduler (TWS) è lo schedulatore, attualmente in uso in Banca, delle applicazioni batch in ambiente mainframe z/OS. Il prodotto/la soluzione dovrà includere l’integrazione con il TWS per i servizi di

coordinamento di processo, di modellazione dei flussi di dati e di monitoraggio del ciclo di trasferimento dei file. Tali servizi dovranno prevedere la gestione delle eccezioni e delle anomalie (es. superamento vincoli temporali predefiniti) attraverso strumenti integrati con gli standard CBE (Common Base Event) presenti in Banca d’Italia. La seguente tabella definisce i requisiti funzionali richiesti.

Codice Descrizione

A2A-IntTWS-001

PUSH Il prodotto/soluzione deve rendere disponibile un'interfaccia TWS per l'attivazione dell'applicazione TWS destinataria nella modalità PUSH. In questo caso il prodotto attiva l'applicazione destinataria in TWS passandole i metadati necessari.

A2A-IntTWS-002

PULL Il prodotto/soluzione deve rendere disponibile un'interfaccia TWS per l'attivazione dell'applicazione TWS destinataria nella modalità PULL. In questo caso il prodotto deve fornire una funzione con le seguenti caratteristiche: - la funzione deve essere richiamabile in modalità batch (JCL) dalle applicazioni destinatarie; - la funzione deve individuare i files non ancora elaborati appartenenti all'applicazione invocante; - la funzione deve restituire all'applicazione obbligatoriamente il nome file e opzionalmente altri metadati a scelta dell'applicazione tra quelli disponibili (es. Protocollo File, Nome Partner,...).

Tabella 15 – ESAG A2A - Requisiti “Interfaccia TWS”

2.4.4 Interfaccia Netview FTP

NetView File Transfer Program (abbreviato in NetView FTP) è un’applicazione ACF/VTAM dell’IBM, utilizzata in Banca d'Italia in ambiente mainframe z/OS, che consente di trasferire e ricevere files sequenziali da un nodo della rete SNA dell’Istituto ad un altro nodo della rete della controparte. Il prodotto/la soluzione dovrà interagire tra il Netview FTP e le procedure applicative attraverso l’attivazione di un’applicazione batch definita in TWS, la cui attivazione si differenzia in funzione di quale azione deve essere innescata: ricezione o trasferimento. La seguente tabella definisce i requisiti funzionali richiesti.

Codice Descrizione

A2A-IntNFTP-001

La ricezione sarà innescata dall’arrivo di un file, precedentemente definito, inviato da una controparte che attiverà via ett (risorsa speciale) lo specifico gruppo batch, all’interno del quale ci sarà il job di attivazione del prodotto/soluzione che avrà il compito di: - recepire l’avvenuta ricezione del file e provvedere al suo salvataggio, aggiornare lo stato nel catalogo ESAG; - rendere disponibile il file pervenuto all’applicazione destinataria con il nome concordato;

G858 - 009/12 – Pag. 43 di 97

Codice Descrizione

- cancellare il file pervenuto dalla controparte e rendere pronto l’Istituto alla ricezione di un successivo file della stessa tipologia.

A2A-IntNFTP-002

La trasmissione sarà innescata da uno specifico gruppo elaborativo batch, attivato dalla procedura applicativa della Banca che avrà preparato il file da spedire alla controparte, con il nome atteso dal prodotto/soluzione, che avrà il compito di : - recepire l’avvenuta ricezione del file e provvedere al suo salvataggio, aggiornare lo stato nel catalogo ESAG; -rendere disponibile per la spedizione verso la controparte il file pervenuto dall’applicazione dell’Istituto con il nome concordato tra le controparti; - cancellare il file pervenuto dalla procedura applicativa per essere pronto alla spedizione di un successivo file della stessa tipologia.

Tabella 16 – ESAG A2A - Requisiti "Interfaccia Netview FTP"

2.4.5 Interfaccia FAGDD

Il prodotto/la soluzione deve includere lo sviluppo di un’interfaccia in grado di acquisire i tabulati prodotti da applicazioni IMS residenti su piattaforma z/OS che utilizzano il formato FAGDD. Ogni dataset contiene al suo interno uno o più tabulati da distribuire a diversi destinatari. Ogni tabulato è un insieme di pagine associato univocamente a uno o più destinatari ed

omogeneo sotto il profilo delle caratteristiche applicative (codice tabulato, riferimenti amministrativi, riferimenti all’elaborazione). Il prodotto dovrà gestire tante istanze diverse di tabulati (tra loro indipendenti) quante sono le

destinazioni del tabulato. L’insieme di pagine di ogni tabulato è compreso tra un record descrittivo di testa ed uno di

coda: la testata (di seguito indicata come busta) contiene informazioni che definiscono le caratteristiche fisiche del tabulato, ne permettono l’identificazione in modo univoco e ne specificano le destinazioni finali. La seguente tabella definisce le caratteristiche dell’interfaccia FAGDD10.

Codice Descrizione

A2A-IntFAG-001

Interfaccia Asincrona L’interfaccia deve acquisire un tabulato prodotto in modalità batch. In tale modalità l’applicazione dopo aver preparato il dataset, contenente uno o più tabulati (comprensivi della testata), richiama asincronamente un programma che costituisce l’interfaccia e che provvede alla corretta acquisizione del tabulato.

In alternativa si può valutare l’utilizzo di un adapter in grado di acquisire automaticamente i dataset prodotti dall’applicazione.

A2A-IntFAG-002

Interfaccia Sincrona

L’interfaccia deve rendere disponibile un programma (Cobol) richiamabile (tramite chiamata CALL) dai programmi applicativi. L’applicazione fornisce il puntamento ad un dataset sequenziale che contiene il tabulato (comprensivo della busta descrittiva). Il codice di ritorno

10 Per ulteriori dettagli sui tabulati in formato FAGDD si rimanda all’Allegato B. L’applicazione FAGDD.

G858 - 009/12 – Pag. 44 di 97

Codice Descrizione

fornito dall’interfaccia deve risultare positivo solo nel caso di corretto trasferimento del tabulato all’interno del prodotto/soluzione.

A2A-IntFAG-003

Formato busta tabulato FAGDD La seguente tabella descrive i campi forniti dall’applicazione e la loro posizione all’interno della busta (testata) associata al tabulato. Tali valori, in fase di elaborazione del tabulato, devono essere utilizzati dalle funzioni Servizio Tabulati per valorizzare i rispettivi campi del record identificativo del tabulato nell’Archivio:

Campo Posizione Descrizione Codice_Applicazione: 005-008 Codice SSPP (4 caratteri) che identifica l'applicazione Codice_Tabulato: 009-011 Codice numerico (3 caratteri) che identifica il tabulato

nell'ambito dell’applicazione. Modello_Tabulato: 077-101 Campo descrittivo che indica il modello di tabulato

prodotto (128 caratteri - es. ESTRATTO CONTO) Id_Richiesta_Tab: 032-038 Codice numerico (7 cifre) che identifica univocamente

la richiesta nell'ambito dell'applicazione Versione: 018-019 Numero di due cifre che identifica, all'occorrenza,

iterazioni o versioni elaborative diverse nell'ambito della stessa data contabile.

UNL 102-106

111-114

118-122

126-130

Campo che definisce l’indirizzamento logico di primo livello o UNL (5 caratteri)

Classe_Stampa 108-109

116-117

124-125

132-133

Campo che definisce l’indirizzamento logico di secondo livello o classe di stampa destinataria (2 caratteri - es. CN)

Data_Contabile 012-017 Data di riferimento amministrativo o contabile del tabulato nel formato AAMMGG

Data_Produzione 020-025 Data di elaborazione applicativa del tabulato nel formato AAMMGG

Ora_Produzione 026-031 Ora di elaborazione applicativa del tabulato nel formato HHMMSS

A2A-IntFAG-004

Gestione Errori L’interfaccia in caso di malfunzionamento generico che impedisca l’acquisizione o il trattamento dei file forniti dall’applicazione deve inviare una segnalazione di errore alla console centralizzata di gestione degli allarmi.

Tabella 17 – ESAG A2A - Requisiti Interfaccia FAGDD

2.4.6 Interfaccia APMAIN

Il prodotto/la soluzione deve includere lo sviluppo di un’interfaccia in grado di acquisire i tabulati prodotti da applicazioni IMS residenti su piattaforma z/OS che utilizzano il formato APMAIN.

La seguente tabella definisce le caratteristiche dell’interfaccia APMAIN.

G858 - 009/12 – Pag. 45 di 97

Codice Descrizione

A2A-IntAPM-001 Il prodotto deve permettere il caricamento di un tabulato prodotto in forma di messaggio disponibile su una code MQSeries. Il messaggio MQ relativo al tabulato sarà composto da - un header sistemistico che riporta informazioni relative alla comunicazione in modalità message queing; - una busta compilata dall’applicazione mittente che riporta i dati identificativi del tabulato; - il tabulato vero e proprio (payload).

A2A-IntAPM-002 Formato busta tabulato APMAIN La seguente tabella descrive i campi forniti dall’applicazione all’interno della busta associata al tabulato. Tali valori, in fase di elaborazione del tabulato, devono essere utilizzati dalle funzioni Servizio Tabulati per valorizzare i rispettivi campi del record identificativo del tabulato nell’Archivio:

In questo caso i campi, Codice_Tabulato, Id_Richiesta_Tab, Versione, Data_Contabile, Data_Produzione, Ora_Produzione non sono valorizzati dall’applicazione e devono essere impostati a “NULL”, mentre il campo Codice_Applicazione sarà valorizzato su base tabellare a partire dal valore presente nel campo Nome_Applicazione.

Modello_Tabulato: Campo che indica il modello di tabulato prodotto (128 caratteri) Nome Applicazione Campo descrittivo dell’applicazione che ha prodotto il

messaggio UNL Campo che definisce l’indirizzamento logico di primo livello o

UNL (5 caratteri) Classe_Stampa Campo che definisce l’indirizzamento logico di secondo livello

o classe di stampa destinataria (2 caratteri )

A2A-IntAPM-003 Post-esecuzione A seguito della corretta acquisizione del messaggio l’interfaccia provvederà a rimuoverlo dalla coda MQSeries.

A2A-IntAPM-004 Gestione Errori L’interfaccia in caso di malfunzionamento generico che impedisca l’acquisizione o il trattamento dei file forniti dall’applicazione deve inviare una segnalazione di errore alla console centralizzata di gestione degli allarmi e non rimuovere il messaggio dalla coda.

Tabella 18 – ESAG A2A - Requisiti Interfaccia APMAIN

2.4.7 Interfaccia IC

Il prodotto/la soluzione deve includere lo sviluppo di un’interfaccia in grado di acquisire i tabulati prodotti da applicazioni residenti su piattaforma Linux che utilizzano il formato IC. Ciascun tabulato deve essere distribuito ad un’unica destinazione. La seguente tabella definisce le caratteristiche dell’interfaccia IC.

Codice Descrizione

A2A-IntIC-001 Interfaccia Asincrona L’interfaccia deve acquisire un tabulato tramite un adapter in grado di prendere in carico i file generati dall’applicazione e resi disponibili su spazio disco (directory in un file system Unix).

A2A-IntIC-002

Interfaccia Sincrona In alternativa al precedente requisito, l’interfaccia deve rendere disponibile un programma (eseguibile, script) richiamabile dai programmi applicativi. Il codice di ritorno fornito dall’interfaccia deve risultare positivo solo nel caso di corretto trasferimento del tabulato

G858 - 009/12 – Pag. 46 di 97

Codice Descrizione

all’interno del prodotto/soluzione.

A2A-IntIC-003

Formato interfaccia IC In entrambe i casi descritti l’applicazione fornirà il tabulato all’interfaccia utilizzando 2 file aventi lo stesso nome ma estensione diversa:

- una busta contenente i dati descrittivi (metadati) del tabulato; - un file contenente il contenuto (payload) del tabulato.

Il nome dei file forniti identificherà in modo univoco il tabulato.

A2A-IntIC-004

Formato busta tabulato IC La seguente tabella descrive i campi forniti dall’applicazione nel file (in formato testo) che costituisce la busta del tabulato. Tali valori, in fase di caricamento tabulato, devono essere utilizzati dal prodotto per valorizzare i rispettivi campi del record identificativo del tabulato nell’Archivio:

Codice_Applicazione: Codice SSPP (4 caratteri) che identifica l'applicazione Codice_Tabulato: Codice numerico (3 caratteri) che identifica il tabulato

nell'ambito dell’applicazione. Modello_Tabulato: Campo che indica il modello di tabulato prodotto (128 caratteri

- es. STAMPA MOVIMENTI DEL GIORNO) Id_Richiesta_Tab: Codice numerico opzionale (7 cifre) che identifica

univocamente la richiesta nell'ambito dell'applicazione Versione: Numero di due cifre che identifica, all'occorrenza, iterazioni o

versioni elaborative diverse nell'ambito della stessa data contabile.

UNL Campo che definisce l’indirizzamento logico di primo livello o UNL (5 caratteri)

Classe_Stampa Campo che definisce l’indirizzamento logico di secondo livello o classe di stampa destinataria (2 caratteri - es. FI)

Data_Contabile Data di riferimento amministrativo o contabile del tabulato nel formato AAMMGG

Ora_Produzione Ora di elaborazione applicativa del tabulato nel formato HHMMSS

Data_Produzione Data di elaborazione applicativa del tabulato nel formato AAMMGG

A2A-IntIC-005 Post-esecuzione A seguito del corretto trasferimento del tabulato all’interno del prodotto/soluzione l’interfaccia provvederà a rimuovere i file prodotti dall’applicazione.

A2A-IntIC-006

Gestione Errori L’interfaccia in caso di malfunzionamento generico che impedisca l’acquisizione o il trattamento dei file forniti dall’applicazione deve inviare una segnalazione di errore alla management console centralizzata.

Tabella 19 – ESAG A2A - Requisiti Interfaccia IC

2.4.8 Interfaccia LPTAB

Il prodotto/la soluzione deve includere lo sviluppo di un’interfaccia in grado di acquisire i tabulati prodotti da applicazioni residenti su piattaforma Unix/AIX che utilizzano il formato LPTAB. Ciascun tabulato deve essere distribuito ad un’unica destinazione.

G858 - 009/12 – Pag. 47 di 97

La seguente tabella definisce le caratteristiche dell’interfaccia LPTAB.

Codice Descrizione

A2A-IntLPT-001

Interfaccia Asincrona L’interfaccia deve acquisire un tabulato tramite un adapter che sia in grado di prendere in carico i file generati dall’applicazione e resi disponibili su spazio disco (directory in un file system Unix).

A2A-IntLPT-002

Interfaccia Sincrona In alternativa al precedente requisito, l’interfaccia deve rendere disponibile un programma (eseguibile, script) richiamabile all’interno dei programmi applicativi. Il codice di ritorno fornito dall’interfaccia deve risultare positivo solo nel caso di corretto trasferimento del tabulato all’interno del prodotto/soluzione.

A2A-IntLPT-003

Formato interfaccia LPTAB In entrambe i casi descritti l’applicazione fornirà il tabulato all’interfaccia utilizzando 2 file aventi lo stesso nome ma estensione diversa:

- una busta contenente i dati descrittivi (metadati) del tabulato; - un file contenente il contenuto (payload) del tabulato.

Il nome dei file forniti identificherà in modo univoco il tabulato.

A2A-IntLPT-004

Formato busta tabulato LPTAB La seguente tabella descrive i campi forniti dall’applicazione nel file dei metadati (in formato testo). Tali valori, in fase di caricamento tabulato, devono essere utilizzati dal prodotto per valorizzare i rispettivi campi del record identificativo del tabulato nell’Archivio: Codice_Applicazione: Codice SSPP (4 caratteri) che identifica l'applicazione Codice_Tabulato: Codice numerico (3 caratteri) che identifica il tabulato

nell'ambito dell’applicazione. Modello_Tabulato: Campo che indica il modello di tabulato prodotto (128

caratteri - es. MOD. 25 UDR) Id_Richiesta_Tab: Codice numerico opzionale (7 cifre) che identifica

univocamente la richiesta nell'ambito dell'applicazione Versione: Numero di due cifre che identifica, all'occorrenza, iterazioni

o versioni elaborative diverse nell'ambito della stessa data contabile.

UNL Campo che definisce l’indirizzamento logico di primo livello o UNL (5 caratteri)

Classe_Stampa Campo che definisce l’indirizzamento logico di secondo livello o classe di stampa destinataria (2 caratteri - es. FI)

Data_Contabile Data di riferimento amministrativo o contabile del tabulato nel formato AAMMGG

Ora_Produzione Ora di elaborazione applicativa del tabulato nel formato HHMMSS

Data_Produzione Data di elaborazione applicativa del tabulato nel formato AAMMGG

A2A-IntLPT-005 Post-esecuzione A seguito del corretto trasferimento del tabulato all’interno del prodotto/soluzione l’interfaccia provvederà a rimuovere i file prodotti dall’applicazione.

A2A-IntLPT-006

Gestione Errori L’interfaccia in caso di malfunzionamento generico che impedisca l’acquisizione o il trattamento dei file forniti dall’applicazione deve inviare una segnalazione di errore alla management console centralizzata.

Tabella 20 – ESAG A2A - Requisiti Interfaccia LPTAB

G858 - 009/12 – Pag. 48 di 97

2.5 Requisiti Non Funzionali

In questa sezione sono descritti i requisiti non funzionali.

2.5.1 Requisiti Tecnologici e d’Integrazione

In questo paragrafo sono descritti i requisiti tecnologici e d’integrazione richiesti alla soluzione.

Le versioni indicate per sistemi, middleware e prodotti, sono quelle attualmente presenti in Banca: la soluzione dovrà tenere conto degli aggiornamenti per essi intervenuti nel periodo di tempo compreso tra la produzione del Capitolato e l’impianto della soluzione.

La seguente tabella definisce i requisiti richiesti.

Codice Descrizione

RNF-Arc-001 Componente server La componente “core” (i.e. ESAG-Suite) della soluzione deve essere installata e supportata su piattaforma Linux Red Hat v 6.x.

RNF-Arc-002

Componenti adapter Le componenti necessarie per l’integrazione con le applicazioni (adapter e/o interfacce) devono essere installate e supportate sulle seguenti piattaforme: - z/OS v 1.13 - AIX v 6.x - Windows Server 2008 R2 - Linux Red Hat v 5.x, 6.x

RNF-Arc-003

Componente Base Dati La soluzione deve utilizzare un sistema di Gestione di Base di Dati basato su: - database di terze parti (Oracle v 10.2 o MySQL); - struttura dati fornita e gestita internamente dal prodotto.

RNF-Arc-004

Componente Presentation L’application platform della soluzione (ove presente) deve essere di tipo JAVA Enterprise Edition, supportato su piattaforma Linux Red Hat, e compreso tra i seguenti prodotti: - JBOSS v5 - Application Server fornito e gestito internamente dal prodotto.

RNF-Arc-005 Virtualizzazione Le componenti del prodotto residenti su piattaforma Linux devono essere virtualizzabili su hypervisor VMware vSphere v5.

RNF-Arc-006

Alta affidabilità Le componenti del prodotto residenti su piattaforma Linux devono integrarsi con soluzioni architetturali (es. clustering) che garantiscano l’alta disponibilità del servizio e la gestione di scenari di Disaster Recovery.

RNF-Arc-007

Componenti browser Al fine di evitare l’installazione di componenti client sui posti di lavoro degli utenti, l’accesso ai servizi offerti dal prodotto (per attività di visualizzazione/stampa tabulati e gestione flussi) deve utilizzare componenti browser, corredati al più di eventuali plug-in oggetto della fornitura (scaricabili via http). La soluzione deve permettere l’utilizzo dei seguenti browser: - Microsoft Internet Explorer (v 7.0); - Mozilla Firefox (v 17.x).

RNF-Arc-008

Client grafici e/o 3270 L’utilizzo di client in emulazione 3270 (compatibili con IBM Personal Communication) o di client grafici per l’accesso al prodotto è permesso solo per attività di amministrazione o sviluppo.

G858 - 009/12 – Pag. 49 di 97

Codice Descrizione

RNF-Arc-009

Componenti client Le componenti client (inclusi eventuali plug-in del browser) devono essere compatibili con le seguenti piattaforme: - Microsoft Windows XP; - Windows 7.

RNF-Arc-010

Monitoraggio

Il prodotto deve permettere il monitoraggio e la rilevazione di eventuali anomalie presenti nel funzionamento delle sue componenti.

RNF-Arc-011

Monitoraggio

La segnalazione di eventi/allarmi, riguardanti le anomalie di cui al punto precedente, deve integrarsi con gli strumenti di monitoraggio utilizzati dalla Banca (invio di trap SNMP ad una Network Management Console e/o scrittura di un evento sul syslog di sistema).

RNF-Arc-012

API L’accesso alle funzionalità del prodotto deve essere possibile tramite comandi richiamabili da librerie API (rese disponibili per gli environment COBOL e JAVA) o tramite utilizzo di Web Services per permettere l’effettuazione di attività di gestione/amministrazione (anche in modalità batch) e di interrogazione sull’archivio dei tabulati.

Tabella 21 – ESAG Requisiti Architetturali e di Integrazione

2.5.2 Requisiti di Sicurezza

La seguente tabella descrive i requisiti di sicurezza richiesti per il prodotto e per la soluzione implementata.

Codice Descrizione

RNF-Sec-001 Integrità La soluzione deve garantire l’integrità dei dati (payload) presi in carico.

RNF-Sec-002 Filtering La comunicazione tra le componenti del prodotto deve utilizzare un numero di porte TCP limitato in modo da permetterne un filtraggio tramite opportuni presidi di sicurezza.

RNF-Sec-003

Autenticazione La connessione tra le componenti client e quelle server deve utilizzare procedure di autenticazione (almeno lato server) e garantire caratteristiche di riservatezza (ad esempio mediante utilizzo protocolli SSL, HTTPS).

RNF-Sec-004 Audit Il prodotto deve garantire funzioni di auditing registrando in un file di log gli accessi al prodotto (inclusi quelli non autorizzati) per attività di visualizzazione e amministrazione.

RNF-Sec-005

Audit Il prodotto deve garantire funzioni di auditing registrando in un file di log le attività di caricamento, modifica e cancellazione di un tabulato eseguite da applicazioni o procedure batch.

RNF-Sec-006 Audit Il prodotto deve garantire funzioni di auditing registrando in un file di log le attività di inserimento, modifica e cancellazione eseguite da un utente amministratore del prodotto.

RNF-Sec-007 Acceso diretto ai dati L’accesso ai dati da parte degli utenti deve essere possibile soltanto attraverso le interfacce della soluzione.

Tabella 22 – ESAG Requisiti Sicurezza

G858 - 009/12 – Pag. 50 di 97

2.5.3 Requisiti Prestazionali

In questo paragrafo sono forniti dati utili per il dimensionamento delle componenti della soluzione e vengono definiti i requisiti prestazionali richiesti al prodotto. Di seguito vengono indicati i dati di carico utili a valutare il dimensionamento delle

componenti della soluzione per le funzionalità di Gestione Flussi e Gestione Tabulati . Nella soluzione proposta deve essere indicata la configurazione hardware e software (anche

per le eventuali componenti di terze parti fornite dalla Banca) necessaria per supportare il carico previsto nel periodo di picco, sia per le attività di spedizione/caricamento dei flussi/tabulati sia per le richieste di accesso Web alle funzionalità di visualizzazione e stampa.

Gestione Flussi Per quanto attiene ai volumi totali dei flussi input/output gestiti dall’attuale infrastruttura

gli ordini di grandezza del traffico complessivo I/O si assestano sul valore di circa 250 GB/mese, con picchi giornalieri di circa 70GB, dove oltre il 90% del traffico è traffico rete.

La seguente tabella definisce i requisiti prestazionali richiesti al modulo di Gestione Flussi.

Codice Descrizione

RNF-PrfFlu-001 Cartucce/mese La soluzione (comprendente il prodotto e le interfacce implementate) dovrà consentire la presa in carico e l’inserimento in archivio di 17 flussi/mese in media su cartuccia.

RNF-PrfFlu-002 CDROM/mese La soluzione (comprendente il prodotto e le interfacce implementate) dovrà consentire la presa in carico e l’inserimento in archivio di 450 flussi/mese in media su CDROM.

RNF-PrfFlu-003 Floppy Disk 3,5”/mese La soluzione (comprendente il prodotto e le interfacce implementate) dovrà consentire la presa in carico e l’inserimento in archivio di 500 flussi/mese in media su Floppy Disk 3,5”.

RNF-PrfFlu-004 Internet/mese La soluzione (comprendente il prodotto e le interfacce implementate) dovrà consentire la presa in carico e l’inserimento in archivio di 3.500 flussi/mese in media via Internet.

RNF-PrfFlu-005

RETE/mese La soluzione (comprendente il prodotto e le interfacce implementate) dovrà consentire la presa in carico e l’inserimento in archivio di 50.000 flussi/mese in media via RETE (RNI/SWIFTNET).

RNF-PrfFlu-006

RETE/picco ricezione La soluzione (comprendente il prodotto e le interfacce implementate) dovrà consentire la presa in carico e l’inserimento in archivio di circa 300 flussi contemporanei in ricezione via RETE (RNI), ove la dimensione media di ciascun flusso è circa 30K.

RNF-PrfFlu-007

RETE/picco spedizione La soluzione (comprendente il prodotto e le interfacce implementate) dovrà consentire la presa in carico e l’inserimento in archivio di circa 200 flussi contemporanei in spedizione via RETE (RNI) , ove la dimensione media di ciascun flusso è circa 80K.

Tabella 23 – ESAG Requisiti Prestazionali Flussi

G858 - 009/12 – Pag. 51 di 97

Gestione Tabulati

Acquisizione tabulati

- Il numero medio giornaliero di tabulati e notifiche distribuiti presso tutte le Filiali ed i Servizi dell’A.C. è pari a circa 8.000. Di questi in media 6000 tabulati provengono da applicazioni IMS con interfaccia FAGDD e 1500 da applicazioni con interfaccia APMAIN. Il numero di tabulati complessivi generati da piattaforme Unix/Linux è trascurabile rispetto ai precedenti (circa 300 unità).

- La dimensione media di un tabulato è circa 20 KB.

- Nell’ora di picco per i tabulati IMS con interfaccia FAGDD (compresa tra le 00.00 e le 01.00 corrispondente all’attivazione di batch di acquisizione notturni) deve essere caricato un numero di tabulati massimo pari a circa 2800 (nello stesso periodo il numero di tabulati caricato da altre interfacce è trascurabile (qualche decina). I tabulati indicati sono il risultato dell’acquisizione di un numero minore di dataset contenenti tabulati destinati a più (tutte) le Filiali.

- Nell’ora di picco per i tabulati IMS con interfaccia APMAIN (compresa tra le 08.00 e le 09.00) deve essere caricato un numero massimo di tabulati/notifiche pari a circa 650 (nello stesso periodo il numero di tabulati caricato dall’interfaccia FAGDD è pari a circa 250 tabulati).

Visualizzazione tabulati

- Il numero totale di utenti abilitati ad accedere alle funzioni di visualizzazione e stampa tabulati è 2000.

- Il numero massimo di terminali che contemporaneamente accedono alle funzioni di visualizzazione e stampa tabulati durante il giorno è pari a circa 250.

- Il numero totale di operazioni di visualizzazione e di stampa di tabulati effettuate dagli utenti di tutte le Filiali/Servizi durante un intera giornata lavorativa (ore 7.00-18.00) è compreso tra 7000 ed 8500.

- Il numero massimo di operazioni di visualizzazione e stampa nell’ora di picco (tra le 8.00 e le 9.00) effettuate dagli utenti di tutte le Filiali/Servizi è pari a circa 2100. Il numero di utenti collegati in tale periodo è pari a circa 250.

- Il numero massimo di richieste di accessi nei dieci minuti di picco (tra le 8.10 e le 8.20) effettuate dagli utenti di tutte le Filiali/Servizi è pari a circa 360.

La seguente tabella definisce i requisiti prestazionali richiesti al modulo di Gestione Tabulati.

Codice Descrizione

RNF-PrfTab-001

Acquisizione Tabulati z/OS La soluzione (comprendente il prodotto e le interfacce implementate per il caricamento dei tabulati da piattaforma z/OS) dovrà consentire la presa in carico e l’inserimento in archivio del singolo tabulato in un tempo non superiore ad 1 secondo (al netto dei ritardi dovuti all’infrastruttura di rete). In particolare, e come caso di esempio, il trattamento e l’acquisizione di un dataset in formato FAGDD contenente 60 tabulati (es. modello

G858 - 009/12 – Pag. 52 di 97

distribuito a tutte le Filiali) non deve superare i 60 secondi.

RNF-PrfTab-002

Acquisizione Tabulati Unix La soluzione (comprendente il prodotto e le interfacce implementate per il caricamento dei tabulati da piattaforma Unix) dovrà consentire la presa in carico e l’inserimento in archivio di un tabulato generato in ambiente Unix in un tempo non superiore a 4 secondi (al netto dei ritardi dovuti all’infrastruttura di rete).

RNF-PrfTab-003

Visualizzazione Tabulati Il prodotto, nelle condizioni di carico previste nei 10 minuti di picco della giornata, dovrà permettere ad un utente di accedere alla pagina iniziale con un tempo di risposta medio non superiore a 6 secondi (al netto dei ritardi dovuti all’infrastruttura di rete e alla fase di autenticazione).

RNF-PrfTab-004

Visualizzazione Tabulati Il prodotto, nelle condizioni di carico previste nei 10 minuti di picco della giornata, dovrà permettere ad un utente di visualizzare la lista dei tabulati presenti nell’archivio con un tempo di risposta medio non superiore a 10 secondi dall’accesso alla pagina iniziale (al netto dei ritardi dovuti all’infrastruttura di rete).

RNF-PrfTab-005

Stampa Tabulati Il prodotto, sottoposto al carico descritto nei 10 minuti di picco della giornata, dovrà permettere ad un utente di lanciare localmente in esecuzione la stampa di un tabulato selezionato entro un tempo non superiore a 10 secondi dall’invio della richiesta (al netto dei ritardi dovuti all’infrastruttura di rete).

Tabella 24 – ESAG Requisiti Prestazionali Tabulati

G858 - 009/12 – Pag. 53 di 97

3 SEZIONE TERZA - OGGETTO DELLA FORNITURA

In questa sezione vengono descritti i servizi che l’aggiudicatario della gara (di seguito Fornitore) dovrà assicurare e che comprendono:

• la licenza d’uso e la manutenzione dei prodotti software;

• servizi professionali nella fase di progetto;

• servizi professionali nella fase di stabilizzazione;

• servizi professionali nella fase di esercizio.

Tutta la documentazione a supporto, richiesta nella fornitura di tali servizi, dovrà essere redatta in formato elettronico (utilizzando strumenti di Office Automation Microsoft Office) e in lingua italiana; la documentazione di dettaglio relativa ai prodotti software utilizzati potrà essere fornita in lingua inglese o italiana.

I servizi saranno erogati presso i locali della Banca siti in Roma (Largo Bastia) e Frascati (Centro Donato Menichella).

3.1 Licenze d’uso del software

La soluzione deve essere realizzata attraverso prodotti software presenti sul mercato e già disponibili nel catalogo del Fornitore al momento della presentazione dell’offerta: per prodotto software si intendono sia le componenti che implementano i requisiti richiesti nella Sezione Seconda, sia le eventuali componenti necessarie per la gestione della soluzione fornita (es. eventuali client o tools necessari per la configurazione e l’amministrazione del prodotto).

Per i prodotti software inclusi nella fornitura dovrà essere fornita la licenza d’uso, con accluso diritto alla manutenzione e agli aggiornamenti per tutto il periodo di garanzia e manutenzione indicato in § 3.2.

Le licenze dovranno essere fornite per gli ambienti di Test, Collaudo e Produzione per entrambi i siti elaborativi11. E’ inoltre richiesto che le licenze d’uso del prodotto e di tutte le componenti accessorie offerte siano indipendenti dal numero degli utenti utilizzatori, dal volume dei dati trattati, dal numero di processi di movimentazione e trattamento e dalle caratteristiche delle risorse hardware utilizzate dal prodotto (es. numero di processori o core, memoria). Ciò nonostante, al fine di fornire elementi utili per la valutazione dell’utilizzo del prodotto, si stima che il numero di utenti utilizzatori sia suddiviso come segue nei vari ambienti:

- Produzione – 2000 utenti totali di cui 350 concorrenti;

- Collaudo – 60 utenti totali di cui 10 concorrenti;

- Test – 50 utenti totali di cui 10 concorrenti.

11 Per ogni ambiente la soluzione deve essere configurata in modalità “active-standby” nel sito primario del Centro

Donato Menichella (CDM) e nel sito secondario di Largo Bastia (LB), utilizzato come sito di Disaster Recovery.

G858 - 009/12 – Pag. 54 di 97

Non sono oggetto di fornitura le componenti hardware, le licenze dei sistemi operativi e le eventuali componenti di middleware (es. database, application server, web server) realizzate da terze parti ed utilizzate dal prodotto per l‘erogazione dei servizi e per l’integrazione con gli ambienti infrastrutturali di Banca. Tali componenti saranno messe a disposizione dalla Banca.

La Banca acquisirà la proprietà dell’eventuale codice (script, exit routine, procedure)

sviluppato ad hoc, per la personalizzazione del prodotto e per la realizzazione delle interfacce, che quindi potrà essere utilizzato anche allo scadere del servizio di manutenzione .

I prodotti dovranno essere forniti nell’ultima versione disponibile alla data di consegna. Il Fornitore dovrà garantire che per i prodotti offerti sia assicurata la manutenzione per

tutta la durata del contratto, ivi compreso l’eventuale anno di proroga.

3.2 Servizi di manutenzione del software

La fornitura comprende i servizi di manutenzione per tutti i prodotti costituenti la soluzione, al fine di assicurare i livelli di servizio (SLA) indicati nel capitolo 4.2. E’ richiesta la garanzia a copertura totale di 12 (dodici) mesi a partire dal primo giorno del mese successivo al superamento del collaudo finale propedeutico al rilascio in produzione. Per tutto il tempo antecedente a tale data, i sistemi in fornitura saranno soggetti alla garanzia standard del Fornitore ed eventuali malfunzionamenti software dovranno essere gestiti come guasti in fornitura.

La durata del servizio di manutenzione è fissata in 48 (quarantotto) mesi a decorrere dal termine del periodo di garanzia. La Banca si riserva la facoltà di estendere il contratto di manutenzione per un ulteriore periodo di 12 (dodici) mesi, da esercitarsi entro i 3 (tre) mesi precedenti la scadenza contrattuale, alle stesse condizioni economiche previste per il periodo iniziale di 48 (quarantotto) mesi.

Nell’ambito del servizio di manutenzione offerto, il fornitore si impegna a fornire la disponibilità immediata delle patch/PTF e delle nuove versioni del prodotto (inclusa la relativa documentazione).

Per tutte le componenti elencate, laddove il Fornitore intenda offrire un software open source, questo dovrà essere di tipo ”supported open source”. Dovrà quindi trattarsi di un prodotto di cui è disponibile, contemporaneamente: - almeno una versione aggiornata, distribuita secondo i termini di una licenza approvata dalla

Open Source Initiative (http://www.opensource.org/licenses/); - il supporto da parte del Fornitore che, nell’ambito di specifici contratti di manutenzione

commerciale, cura la certificazione di compatibilità con le piattaforme hardware/software indicate nel Capitolato e fornisce le opportune patch in caso di malfunzionamenti.

3.3 Servizi professionali nella fase di progetto

Entro massimo un mese dalla stipula del contratto, la Banca organizzerà un primo incontro (kick-off meeting) con i responsabili della ditta al fine di pianificare le attività successive. Al kick-off meeting i responsabili della ditta presenteranno il responsabile tecnico (in seguito chiamato Project Manager), incaricato di curare il coordinamento tecnico delle prestazioni in fase di realizzazione e di migrazione, nonché di svolgere la funzione di unico referente nei

G858 - 009/12 – Pag. 55 di 97

confronti della Banca. In particolare, al responsabile tecnico fanno capo, tra gli altri, gli adempimenti di seguito indicati:

• coordinare le relazioni con la Banca; • curare la selezione, il coordinamento e la comunicazione alla Banca del gruppo di

progetto che dovrà seguire le attività tecniche; • curare la definizione ed il coordinamento della realizzazione del “progetto esecutivo”

(cfr. Allegato D. Documentazione richiesta); • assicurare il rilascio nei tempi previsti di tutta la documentazione di progetto; • assicurare la disponibilità delle risorse e del personale specializzato per le attività di

realizzazione; • coordinare tutte le comunicazioni previste dal contratto; • controllare le scadenze sulla base delle pianificazioni concordate; • rappresentare il Fornitore nelle riunioni di avanzamento e di coordinamento lavori

durante le fasi di realizzazione e di stabilizzazione. L’eventuale nomina di un nuovo Project Manager in sostituzione del precedente deve essere

comunicata alla Banca con un anticipo di almeno 10 (dieci) giorni lavorativi rispetto alla data di attuazione del provvedimento.

L’Allegato C. Figure professionali del fornitore descrive le caratteristiche minime richieste per la figura professionale del Project Manager e dei componenti del gruppo di progetto nonché le regole che il Fornitore deve seguire in caso di variazioni della composizione delle risorse specialistiche dedicate al progetto.

Al momento dell’avvio del progetto, la Banca nominerà un proprio referente (Direttore dell’esecuzione del contratto - DEC) quale controparte del responsabile tecnico del fornitore.

La data del kick-off meeting sarà assunta come Data di Inizio Lavori (DIL). I servizi professionali nella fase di progetto saranno impiegati per la realizzazione delle seguenti attività:

• Pianificazione e progettazione; • Realizzazione; • Collaudo e Rilascio in Produzione; • Assistenza all’avvio; • Migrazione dei flussi e dei tabulati.

G858 - 009/12 – Pag. 56 di 97

Stesura piano esecutivo

Kick off

Installazione in ambiente TEST

Collaudo tecnico

OK

Installazione in ambiente COLLAUDO

Sviluppo interfacce per flussi pilota e tabulati pilota

Collaudo accettazione

ok

no

si

no

Rilascio in esercizio

flussi pilota e tabulati pilota

Migrazione tabulati e flussi

fine progetto

si

Sviluppo interfacce per tabulati pilota e flussi di test

Installazione in ambiente PROD

Sviluppo interfacce per flussi pilota e tabulati pilota

FaseStabilizzazione

Collaudo Finale

ok si

no

Figura 4 - Progetto ESAG

G858 - 009/12 – Pag. 57 di 97

3.3.1 Pianificazione e progettazione

Il Project Manager avrà l’onere di redigere, con il supporto del personale della Banca, il T1_1 Documento di Progetto Esecutivo (cfr. Allegato D. Documentazione richiesta) relativo alle attività di pianificazione, installazione, configurazione, personalizzazione, collaudo e rilascio della infrastruttura e migrazione dei flussi/tabulati.

L’architettura e le configurazioni definite e documentate nel progetto esecutivo saranno

oggetto di verifica da parte della Banca: il Fornitore si impegna, entro 10 gg lavorativi dalla eventuale richiesta di approfondimento della Banca, ad apportare modifiche e/o integrazioni, senza ulteriore onere per la Banca, ove la documentazione non tenga conto in modo esaustivo delle specifiche indicate nel capitolato tecnico.

Il documento di Progetto esecutivo dovrà essere presentato dal Fornitore, in bozza entro 20

gg lavorativi a partire dalla data di inizio lavori e in versione finale entro i successivi 30 gg lavorativi dalla consegna della bozza: l’approvazione finale del progetto esecutivo sarà vincolante per il prosieguo delle attività.

Successivamente all’approvazione del piano esecutivo il Project Manager dovrà provvedere alla redazione dei seguenti documenti (cfr. Allegato D. Documentazione richiesta) relativi ai collaudi:

• T2_2 Descrizione del Collaudo Tecnico Preliminare dei Prodotti relativo al Collaudo Tecnico della soluzione;

• T3_1 Descrizione del Collaudo di Accettazione relativo al Collaudo di Accettazione della soluzione.

• T4_1 Descrizione del Collaudo Finale relativo al Collaudo Finale della soluzione prima del Rilascio in Produzione.

Tutta la documentazione richiesta potrà essere consolidata soltanto a seguito di approvazione

da parte della Banca.

Al fine di consentire una valutazione delle tempistiche da indicare nel cronoprogramma e delle risorse da prevedere per la realizzazione del progetto, si fornisce di seguito una pianificazione con l’indicazione delle macro-fasi in cui il progetto verrà suddiviso e dei tempi massimi entro i quali dovrà avvenirne il completamento.

G858 - 009/12 – Pag. 58 di 97

Figura 5 - Piano di massima del progetto

Si sottolinea che la durata indicata per il completamento del progetto (18 mesi solari) è la massima prevista: il fornitore può proporre una riduzione della durata o una diversa articolazione delle attività nel periodo massimo concesso.

L’esecuzione con esito positivo delle suddette fasi e la conseguente approvazione dei risultati da parte del Direttore dell’esecuzione (DEC) nominato dalla Banca sarà vincolante per l’erogazione dei pagamenti relativi alla fornitura (cfr. § 4.1) .

3.3.2 Realizzazione

Nella fase realizzativa del progetto, in conformità a quanto previsto nella fase di progettazione, il Project Manager e il gruppo di progetto dovranno eseguire negli ambienti elaborativi richiesti (test, collaudo e produzione) le attività di seguito indicate:

- installazione delle componenti del prodotto sulle piattaforme elaborative interessate;

- configurazione di base del prodotto;

- personalizzazione (ove necessario) della configurazione standard delle componenti fornite dalla Banca e necessarie per il funzionamento del prodotto (es. Web Server, Database, Application Server, etc);

- attività di sviluppo rivenienti da personalizzazioni del prodotto e dalla realizzazione delle interfacce necessarie;

- attività di migrazione di almeno 50 (cinquanta) modelli di tabulati pilota e di almeno 300 (trecento) tipologie di flussi pilota selezionati costituenti il 20% del totale12 (il numero totale di tipologie da migrare ammonta a circa 1.500 flussi e 400 tabulati).

I tabulati pilota sono prodotti da applicazioni presenti in tutti e tre gli ambienti (test, collaudo e produzione) e pertanto l’attività di migrazione dei tabulati pilota potrà essere eseguita in

12 La percentuale indicata costituisce il valore minimo e può essere estesa previo accordo tra il Project Manager e il

DEC.

G858 - 009/12 – Pag. 59 di 97

ambiente di test e successivamente replicata negli ambienti di collaudo e produzione. Relativamente alle attività di migrazione dei flussi, invece occorre tener conto di quanto segue:

� in ambiente di test non sono disponibili flussi e quindi non potranno essere eseguite migrazioni ma dovranno essere eseguite soltanto simulazioni (flussi di test);

� in ambiente di collaudo sono disponibili soltanto alcuni flussi pilota, che dovranno essere migrati nella nuova infrastruttura;

� in ambiente di produzione si provvederà a replicare la migrazione dei flussi pilota già eseguita in ambiente di collaudo e si effettuerà la migrazione di altri flussi, presenti soltanto in produzione, fino al raggiungimento del 20% del totale dei flussi di produzione;

L’attività di migrazione comprende, coerentemente con la soluzione proposta, anche l’adeguamento dell’ambiente di schedulazione (circa 200 gruppi batch in Tivoli TWS).

- attività di integrazione con le infrastrutture di Banca con particolare riferimento alle funzionalità di autenticazione, gestione dei ruoli, monitoraggio, logging, auditing, back-up ed automazione.

Durante l’esecuzione delle attività indicate il Project Manager dovrà predisporre un documento denominato T2_1 Documento di Installazione (cfr. Allegato D. Documentazione richiesta).

3.3.3 Collaudo

Il collaudo della soluzione prevede le attività di seguito descritte.

Nell’ambiente di Test deve essere effettuato un collaudo tecnico (sulla base del documento T2_2 Descrizione del Collaudo Tecnico Preliminare dei Prodotti) volto a verificare la corretta installazione e le funzionalità di base di tutte le componenti del prodotto e il successo della migrazione dei tabulati pilota e dei flussi di test13. Terminato con esito positivo il collaudo tecnico, il Project Manager dovrà produrre il documento T2_3*Rapporto di Esecuzione del Collaudo Tecnico Preliminare dei Prodotti.

Nell’ambiente di Collaudo dovranno essere effettuate le seguenti attività:

- attività di fine tuning tesa a realizzare la configurazione ottimale del prodotto nei riguardi dei requisiti di performance attesi;

- Collaudo di Accettazione (eseguito da personale di Banca, con il supporto del gruppo di progetto, sulla base del documento T3_1 Descrizione del Collaudo di Accettazione) volto a verificare, per i tabulati pilota e i flussi pilota presenti a partire dall’ambiente di Collaudo, il rispetto dei requisiti funzionali, di sicurezza, prestazionali, e di integrazione con le risorse della Banca che il prodotto deve soddisfare14. Terminato con esito positivo il collaudo, il Project Manager dovrà produrre il documento T3_2*Rapporto di esecuzione del Collaudo di

Accettazione.

13 I flussi pilota da migrare esistono soltanto a partire dall’ambiente di Collaudo, pertanto in ambiente di Test

verranno simulati alcuni flussi di test per verificare il corretto funzionamento della soluzione. 14 Verranno tra l’altro verificate le corrette funzionalità delle interfacce flussi e tabulati, le procedure di “ripresa

dati” e le procedure previste per gli scenari di Cluster-FailOver (System Fault) e Disaster Recovery.

G858 - 009/12 – Pag. 60 di 97

Nell’ambiente di Produzione dovranno essere effettuate le seguenti attività:

- attività di fine tuning tesa a realizzare la configurazione ottimale del prodotto nei riguardi dei requisiti di performance attesi;

- Collaudo Finale (eseguito da personale di Banca, con il supporto del gruppo di progetto, sulla base del documento T4_1 Descrizione del Collaudo Finale) volto a verificare, prima dell’effettivo rilascio in produzione, il funzionamento della soluzione e la corretta esecuzione della migrazione dei tabulati e dei flussi pilota.

Terminato con esito positivo il collaudo, il Project Manager dovrà produrre il documento T4_5*Rapporto di esecuzione del Collaudo Finale, propedeutico per il Rilascio in Produzione della soluzione.

La società dovrà garantire la presa in carico degli eventuali malfunzionamenti15 riscontrati durante le fasi di test e collaudo, curandone la correzione e garantendo lo sviluppo e la distribuzione delle modifiche necessarie (a partire dall’ambiente di test) al fine di permettere l‘esecuzione di un nuovo collaudo. Ove necessario il T2_1 Documento di Installazione deve essere opportunamente aggiornato. Eventuali attività relative a PTF/fixpack/patch del prodotto per la soluzione dei malfunzionamenti riscontrati nei successivi ambienti dovranno essere applicate e verificate a partire dall’ambiente di test.

Nei venti giorni solari che precedono la fine dei collaudi il fornitore non potrà apportare modifiche alla soluzione senza il preventivo assenso della Banca.

3.3.4 Migrazione dei Flussi e dei Tabulati

Nella precedente fase realizzativa è prevista l’attività di migrazione di un sottoinsieme dei Tabulati e dei Flussi, detto pilota, selezionato a cura della Banca. Il completamento delle attività relative alla Migrazione dei Flussi e dei Tabulati non ancora migrati dovrà essere effettuato a seguito del Rilascio in Produzione. Durante l’esecuzione delle attività indicate, il Project Manager dovrà predisporre i documenti denominati T5_1 Descrizione del Collaudo dei Tabulati e Flussi migrati e T5_2 Rapporto di esecuzione del Collaudo dei Tabulati e Flussi migrati aventi rispettivamente l’obiettivo di fornire la lista dei collaudi da eseguire, per la verifica del corretto funzionamento di ciascun tabulato e flusso migrato, e il risultato delle attività di collaudo eseguite (cfr. Allegato D. Documentazione richiesta). Entro 10 (dieci) giorni lavorativi dal completamento della fase di Migrazione dei Flussi e dei Tabulati la ditta aggiudicataria ha l’onere di redigere, con il supporto del personale della Banca, il T5_3*Verbale di Fine Lavori, che dovrà contenere una sintesi delle attività eseguite nel corso del progetto.

3.3.5 Assistenza all’avvio

L’assistenza all’avvio prevede le attività di seguito descritte.

Documentazione

Almeno 15 giorni lavorativi prima del Rilascio in Produzione, il Project Manager dovrà produrre i seguenti documenti (cfr. Allegato D. Documentazione richiesta), i cui contenuti saranno concordati con i responsabili della Banca:

15 Riferiti a specifiche funzionali, prestazionali, di sicurezza e di integrazione richieste in sede di Capitolato

Tecnico.

G858 - 009/12 – Pag. 61 di 97

• T4_2 Manuale di amministrazione

• T4_3 Manuale di gestione. • T4_4 Guida Utente

Formazione

Il Fornitore curerà i servizi di formazione per il personale di Banca, fino ad un massimo di 20 giorni di corsi in aula, nei locali di Banca in Roma e/o Frascati.

Le date dei corsi saranno concordate tra le parti ed in ogni caso dovranno aver luogo a partire da almeno 20 giorni lavorativi prima del rilascio in produzione della nuova soluzione.

I corsi – che saranno replicati nell’ambito di più sessioni - saranno di tipo tecnico orientati agli specialisti della funzione IT (amministratori del prodotto, personale addetto al supporto tecnico di primo e secondo livello) per un numero totale di discenti non superiore a 60 unità.

Le sessioni formative saranno tenute in lingua italiana e il Fornitore predisporrà la documentazione di supporto in lingua italiana.

I dettagli sulle tematiche da trattare e la suddivisione in sessioni verranno definite tra il Fornitore e la Banca nella fase di esecuzione del progetto anche se in ogni caso le sessioni dovranno illustrare:

o le funzionalità generali del software installato;

o l’architettura generale della nuova soluzione;

o le modalità di configurazione del prodotto;

o le modalità di interfacciamento con le applicazioni e le soluzioni implementate per la migrazione dei tabulati/flussi;

o le modalità di utilizzo dell’interfaccia per la gestione amministrativa del prodotto;

o le modalità di utilizzo dell’interfaccia grafica a disposizione dell’utente finale;

o le modalità di controllo e monitoring dell’attività quotidiana;

o le procedure di recovery atte a garantire l’alta affidabilità della soluzione;

o le azioni da effettuare a fronte di eventuali inconvenienti riscontrati nella elaborazione di un tabulato/flusso e nel funzionamento delle componenti;

o le procedure di gestione utili alla risoluzione dei malfunzionamenti (workaround) e atte alla ricerca delle cause originarie (problem determination).

3.4 Servizi professionali nella fase di stabilizzazione

Il Rilascio in Produzione di un servizio informatico in Banca prevede un periodo di stabilizzazione atto a verificarne il corretto funzionamento sul campo. Tale periodo di stabilizzazione avrà una durata minima di 2 (due) mesi a partire dal Rilascio in Produzione, affiancherà l’attività di migrazione dei flussi e tabulati residui e potrà concludersi soltanto un mese dopo la migrazione in produzione dell’ultimo flusso/tabulato.

La fine della fase di stabilizzazione sarà sancita dalla sottoscrizione del documento T6_1* Verbale di Fine Periodo di Stabilizzazione da parte del Project Manager e del DEC.

G858 - 009/12 – Pag. 62 di 97

La fase di stabilizzazione nel progetto ESAG prevede le attività di seguito descritte.

3.4.1 Servizio di Presidio e Reperibilità

Il servizio di Presidio e Reperibilità sarà svolto nei locali della Banca siti presso Frascati e Roma e dovrà riguardare tutte le funzionalità comprese nella fornitura software, incluse quelle rivenienti da personalizzazioni e sviluppi (interfacce).

Il servizio include le seguenti attività:

• supporto di secondo livello sul prodotto negli ambienti elaborativi di Collaudo e di Produzione durante l’orario di lavoro compreso tra le 9:00 e le 18:00 dal Lunedi al Venerdi;

• mantenimento dei contatti tra la Banca e le strutture di supporto del Fornitore per tutte le tipologie di manutenzione16;

• analisi dei malfunzionamenti del prodotto, individuazione dei relativi interventi e ove necessario installazione e collaudo delle patch.

Il Fornitore durante lo stesso periodo dovrà inoltre svolgere il servizio di reperibilità, al di

fuori del normale orario di lavoro, nella fascia oraria dalle 6:30 alle 9:00 e dalle 18:00 alle 3:00 dal Lunedi al Venerdi e nella fascia 9:00-13:00 il Sabato, su chiamata del personale di Banca nel caso di malfunzionamenti evidenziati dal prodotto17 e dalle interfacce di caricamento.

La figura professionale richiesta per i servizi di presidio e reperibilità è quella di “esperto per l’assistenza sul prodotto” con caratteristiche minime descritte nell’Allegato C. Figure

professionali del fornitore. Per quanto attiene la gestione dei malfunzionamenti nell’ambiente elaborativo di Produzione, il Fornitore dovrà assicurare, secondo la classificazione del malfunzionamento occorso, i livelli di servizio (SLA) indicati nel capitolo 4.2.

Per ogni intervento di manutenzione, indipendentemente dalla sua tipologia, l’esperto per l’assistenza sul prodotto dovrà:

• censire gli interventi qualificandoli con un identificativo univoco, una descrizione, il livello di gravità/priorità;

• definirne l’effort realizzativo;

• pianificare l’intervento di concerto con il personale di Banca;

• installare, di concerto con il personale di Banca, le conseguenti modifiche negli ambienti elaborativi di Test, Collaudo, e Produzione della Banca, utilizzando gli strumenti di gestione della configurazione previsti per questi ambienti;

• verificare, di concerto con il personale di Banca, il funzionamento a seguito dell’intervento.

16 Raccolta delle segnalazioni dei problemi e dei malfunzionamenti del prodotto e, ove possibile, comunicazione di

chiarimenti e suggerimenti per l’immediata soluzione degli stessi. 17 In caso di necessità - a giudizio del personale della Banca - il reperibile dovrà raggiungere i locali della Banca

entro 1 ora e 30 minuti dalla chiamata telefonica, per effettuare in loco gli interventi necessari (l’accesso da remoto ai sistemi di Banca non è consentito).

G858 - 009/12 – Pag. 63 di 97

3.5 Servizi professionali nella fase di esercizio

Il Fornitore dovrà erogare, su richiesta della Banca, un servizio di supporto specialistico on-site sulla nuova soluzione finalizzato ad attività di tipo “evolutivo” e di tipo “corrente” da fruire nel periodo di validità del contratto (incluse le eventuali estensioni stabilite) a partire dalla fine del periodo di stabilizzazione.

3.5.1 Servizi di assistenza sistemistica di tipo ”evolutivo”

Le attività di assistenza sistemistica di tipo “evolutivo” prevedono:

• migrazioni di nuovi Flussi e/o Tabulati;

• nuove configurazioni a seguito di evoluzione del prodotto;

• gestione problemi di sicurezza;

• introduzione di nuove funzioni del software oggetto della fornitura, a seguito di sopraggiunte esigenze applicative e/o evoluzioni della soluzione, comprensiva della verifica d’impatto sui servizi e sulle infrastrutture esistenti;

• installazione e collaudo delle nuove versioni del software;

• aggiornamento della documentazione di progetto derivante dagli eventuali interventi di cui ai punti precedenti.

Le risorse deputate all’erogazione dei servizi di tipo “evolutivo” dovranno assicurare il servizio in presenza nei giorni lavorativi dalle ore 9,00 alle 18,00; il servizio sarà svolto nei locali della Banca siti presso il CDM e Largo Bastia.

La pianificazione delle attività sarà comunicata al Fornitore con un preavviso minimo di cinque giorni lavorativi. I servizi di assistenza di tipo “evolutivo” saranno erogati a consumo in unità orarie per un totale di 800 ore/uomo La Banca si riserva la facoltà di richiedere al Fornitore l’erogazione dei servizi, alle medesime condizioni economiche, anche al di fuori del normale orario di lavoro e durante le giornate prefestive e festive, fino ad una quota massima del 5% delle ore/uomo totali di assistenza di tipo “evolutivo”. La pianificazione delle attività straordinarie da svolgersi nelle giornate prefestive e festive è stabilita dalla Banca e sarà comunicata al Fornitore con un preavviso minimo di cinque giornate lavorative. La Banca si riserva la facoltà, nel periodo di validità del contratto (inclusa l’eventuale estensione richiesta), di esercitare l’opzione per l’acquisizione di ulteriori ore/uomo allo stesso prezzo, fino al raggiungimento di un valore massimo pari a 2.400 ore/uomo.

Per i servizi di assistenza sistemistica di tipo “evolutivo” saranno richieste caratteristiche professionali analoghe a quelle richieste per i componenti del gruppo di progetto (v. Allegato C. Figure professionali del fornitore).

G858 - 009/12 – Pag. 64 di 97

3.5.2 Servizi di assistenza sistemistica di tipo ”corrente”

Le attività di assistenza sistemistica di tipo “corrente” consisteranno nella manutenzione preventiva e nel supporto a quella correttiva sull’intera infrastruttura per effettuare regolazioni, controlli, aggiornamenti e/o sostituzioni al fine di consentire la perfetta funzionalità del sistema, migliorarne l’affidabilità e la sicurezza, prevenirne i malfunzionamenti e/o la caduta dei livelli di servizio. In tale ambito rientrano:

• il supporto nel controllo dell’infrastruttura oggetto di questo capitolato;

• l’applicazione delle correzioni ai prodotti software forniti, per prevenire o rimuovere eventuali malfunzionamenti;

• lo svolgimento di attività di fine-tuning per garantire, nell’esercizio quotidiano, le prestazioni ottimali per i servizi applicativi;

• il supporto nello svolgimento di verifiche sulle funzionalità di procedure di gestione;

• l’analisi dei malfunzionamenti e l’individuazione delle modalità correttive anche mediante la predisposizione del materiale necessario all’individuazione delle cause;

• aggiornamento della documentazione di progetto derivante dagli eventuali interventi di cui ai punti precedenti.

Le risorse deputate all’erogazione dei servizi di assistenza sistemistica di tipo “corrente” dovranno assicurare il servizio ordinario in presenza nei giorni lavorativi dalle ore 9:00 alle ore 18:00 (8 ore lavorative e un’ora di pausa pranzo); il servizio sarà svolto nei locali della Banca siti presso il CDM. I servizi di assistenza di tipo “corrente” saranno erogati a consumo in unità orarie per un totale di 1.000 ore/uomo. La Banca si riserva la facoltà di richiedere al Fornitore l’erogazione dei servizi, alle medesime condizioni economiche, anche al di fuori del normale orario di lavoro e durante le giornate prefestive e festive, fino ad una quota massima del 5% delle ore/uomo totali di assistenza di tipo “corrente”. La pianificazione delle attività straordinarie da svolgersi nelle giornate prefestive e festive è stabilita dalla Banca e sarà comunicata al Fornitore con un preavviso minimo di cinque giornate lavorative. La Banca si riserva la facoltà, nel periodo di validità del contratto (inclusa l‘eventuale estensione richiesta), di esercitare l’opzione per l’acquisizione di ulteriori ore/uomo allo stesso prezzo, fino al raggiungimento di un valore massimo pari a 2.800 ore/uomo.

La figura professionale richiesta per i servizi di assistenza sistemistica di tipo “corrente” è quella di “esperto per l’assistenza sul prodotto” con caratteristiche minime descritte nell’Allegato C. Figure professionali del fornitore.

G858 - 009/12 – Pag. 65 di 97

4 SEZIONE QUARTA – CONDIZIONI DI EROGAZIONE DELLA FORNITURA

In questa sezione vengono descritte le modalità di pagamento e le condizioni di erogazione dei servizi oggetto di fornitura del presente Capitolato.

4.1 Modalità di pagamento

Gli oggetti della fornitura hanno diverse tipologie di pagamento come indicato nella seguente tabella.

Oggetto della Fornitura Tipologia di Pagamento

Licenze d’uso del Software per Gestione Flussi e Gestione Tabulati

A CORPO

Servizi di Manutenzione del Software per Gestione Flussi e Gestione Tabulati

CANONE semestrale

Servizi Professionali nella fase di Progetto A CORPO

Servizi Professionali nella fase di Stabilizzazione A CORPO

Servizi Professionali nella fase di Esercizio A CONSUMO, con fatturazione trimestrale posticipata

Tabella 25 – Tipologie di pagamento

G858 - 009/12 – Pag. 66 di 97

L’erogazione dei pagamenti relativi alla fornitura è subordinata all’esecuzione con esito positivo delle macro-fasi del progetto indicate al § 3.3.1; l’esito positivo di ciascuna macrofase è sancito dalla sottoscrizione del DEC del documento previsto come indicato nella tabella seguente (per la descrizione della documentazione richiesta vedi “Allegato D. Documentazione richiesta”):

Con riferimento alle suddette macro-fasi del progetto viene di seguito indicata la distribuzione dei pagamenti:

Tabella 27 – Modalità di pagamento

Macro-fase di progetto Documento

T2 - Collaudo Tecnico Ambiente di TEST

T2_3* - Rapporto di Esecuzione del Collaudo Tecnico Preliminare dei Prodotti

T3 - Collaudo Accettazione Ambiente di COLLAUDO

T3_2* - Rapporto di Esecuzione del Collaudo di Accettazione

T4 – Collaudo Finale e Rilascio Ambiente di PRODUZIONE

T4_5* - Rapporto di Esecuzione del Collaudo Finale

T5 – Migrazione Tabulati Flussi T5_3* - Verbale di Fine Lavori

T6 – Periodo di Stabilizzazione T6_1* - Verbale di Fine Periodo di Stabilizzazione

Tabella 26 - Documenti di chiusura macro-fasi

Macro-fase di progetto Distribuzione dei pagamenti

T2 - Collaudo Tecnico Ambiente di TEST

- 20% delle licenze dei prodotti software previsti in fornitura

- 20% servizi professionali nella fase di progetto

T3 - Collaudo Accettazione Ambiente di COLLAUDO



T4 – Collaudo Finale e Rilascio Ambiente di PRODUZIONE



T5 – Migrazione Tabulati Flussi - 30% delle licenze dei prodotti software previsti in fornitura


T6 – Periodo di Stabilizzazione 100 % servizi professionali nella fase di stabilizzazione

G858 - 009/12 – Pag. 67 di 97

4.2 Livelli di Servizio (SLA)

Il Fornitore deve mantenere un livello di servizio tale da garantire un tempo di intervento inferiore ai valori indicati nella Tabella seguente, in funzione della fascia dell’orario di servizio in cui viene effettuata la segnalazione del malfunzionamento e della sua tipologia.

Orario di Servizio Tipologia Guasto18 Tempi massimi di intervento19

Lavorativo Bloccante 2 ore solari

Lavorativo Non bloccante 4 ore solari

Non lavorativo Bloccante 4 ore solari

Non lavorativo Non bloccante 8 ore solari

Tabella 28 – Tempi massimi di intervento

Il Fornitore deve mantenere un livello di servizio tale da garantire un tempo di ripristino inferiore ai valori indicati nella Tabella seguente, in funzione della fascia dell’orario di servizio in cui viene effettuata la segnalazione del malfunzionamento e della sua tipologia.

Orario di Servizio Tipologia Guasto Tempi massimi di ripristino20

Lavorativo Bloccante 3 ore solari

Lavorativo Non bloccante 8 ore solari

Non lavorativo Bloccante 8 ore solari

Non lavorativo Non bloccante 16 ore solari

Tabella 29 – Tempi massimi di ripristino

Il Fornitore garantirà un servizio di ricezione delle richieste di intervento sette giorni su sette, ventiquattro ore al giorno (cd. 24x7).

18 Guasto non bloccante: viene definito non bloccante il guasto di uno o più componenti di una piattaforma, il cui verificarsi rende indisponibili alcune funzionalità del servizio. Gli utenti sono in grado di usufruire del servizio anche se le prestazioni risultano degradate. Guasto Bloccante: viene definito bloccante il guasto di uno o più componenti di una piattaforma, il cui verificarsi rende indisponibili agli utenti tutte o alcune funzionalità essenziali del servizio. Gli utenti non sono in grado di usufruire del servizio ovvero le prestazioni risultano fortemente degradate. 19 Tempo di intervento: il tempo di intervento è l’intervallo di tempo che intercorre tra la segnalazione del malfunzionamento effettuata dal personale della Banca al servizio di help-desk messo a disposizione dal Fornitore e la presa in carico del malfunzionamento da parte del Fornitore per il ripristino del guasto. 20 Tempo di ripristino: il tempo di ripristino è l’intervallo di tempo che intercorre tra la segnalazione di malfunzionamento effettuata dal personale della Banca al servizio di help-desk messo a disposizione dal Fornitore e il momento in cui le funzionalità del servizio sono completamente ripristinate.

G858 - 009/12 – Pag. 68 di 97

Il Fornitore dovrà intervenire entro 4 (quattro) ore dall’apertura della chiamata e comunque in tempo utile a garantire i tempi di ripristino precedentemente indicati.

Il Fornitore dovrà produrre e consegnare alla Banca con cadenza semestrale, in formato cartaceo ed elettronico, un rapporto dettagliato relativo alle attività di manutenzione correttiva effettuate sulla base delle segnalazioni di malfunzionamento ricevute dalla Banca. Tale rapporto dovrà contenere almeno le seguenti informazioni:

• numero progressivo della segnalazione;

• descrizione della problematica;

• servizi/componenti affetti dal guasto;

• livello di gravità (bloccante, non bloccante);

• data e ora di apertura della segnalazione;

• data e ora di chiusura della segnalazione;

• descrizione dell’intervento effettuato;

• durata totale del guasto.

4.3 Penali

Il mancato rispetto, per cause imputabili al fornitore, dei livelli di servizio indicati al paragrafo 4.2 e delle tempistiche di progetto indicate al paragrafo 3.3.1 comporterà l’applicazione di penali rapportate all’importo del contratto al netto delle opzioni, come indicato nel presente paragrafo.

Non si dà luogo all’applicazione delle penali ove il ritardo nelle tempistiche di progetto o il mancato rispetto dei livelli di Servizio sia riconducibile alla Banca o dipenda da caso fortuito o da forza maggiore, purché tali ultime due evenienze siano comunicate per iscritto alla Banca entro 5 (cinque) giorni lavorativi dal loro verificarsi.

Penali relative alle tempistiche di progetto

• per ogni giorno solare di ritardo rispetto alla data di esecuzione del collaudo di accettazione, la penale sarà pari allo 0,5 per mille rispetto all’importo dei servizi professionali nella fase di progetto;

• per ogni giorno solare di ritardo rispetto alla data di rilascio in produzione, la penale è specificata nella Tabella seguente da calcolarsi rispetto all’importo dei servizi professionali nella fase di progetto.

Giorni solari di ritardo Penale

da 1 a 7 0,5 per mille per ciascun giorno di ritardo

da 8 a 15 1 per mille per ciascun giorno di ritardo

oltre 15 3 per mille per ciascun giorno di ritardo

Tabella 30 – Penali per tempistiche di progetto

G858 - 009/12 – Pag. 69 di 97

Penali relative al non rispetto degli SLA (in Produzione)

• per ogni ora (o frazione) di ritardo rispetto ai tempi massimi di ripristino previsti per i guasti non bloccanti in giorni lavorativi, la penale sarà pari allo 0,1 per mille del canone di manutenzione annuo per l’intera infrastruttura – al netto dell’I.V.A.;

• per ogni ora (o frazione) di ritardo rispetto ai tempi massimi di ripristino previsti per i guasti bloccanti in giorni lavorativi, la penale sarà pari allo 0,5 per mille del canone di manutenzione annuo per l’intera infrastruttura – al netto dell’I.V.A.;

• qualora, su base semestrale, venga riscontrato un numero di guasti bloccanti superiore a 2 verrà applicata una penale pari all’1 per mille del canone di manutenzione annuo – al netto dell’I.V.A.per ogni guasto bloccante oltre la predetta soglia di 2 guasti nel semestre.

L’importo complessivo delle penali non potrà superare il 10% (dieci per cento) del corrispettivo del contratto, al netto dell’IVA, ferma restando la facoltà per la Banca, al raggiungimento di tale limite, di risolvere il contratto ai sensi e per gli effetti dell’art. 1456 c.c., fatto salvo il diritto di risarcimento di ulteriori danni.

G858 - 009/12 – Pag. 70 di 97

Allegato A. Le applicazioni INGE/PEGASO/GESPED

Vengono di seguito dettagliati i modelli architetturali relativi ai processi di business

attualmente realizzati rispettivamente dalle applicazioni INGE, PEGASO e GESPED, che dovranno essere sostituite dall’oggetto della presente fornitura.

Il linguaggio di modellazione adottato è ArchiMate®, di cui nella figura seguente viene descritta la legenda degli elementi utilizzati.

Figura 6 - Elementi di notazione ArchiMate

G858 - 009/12 – Pag. 71 di 97

Applicazione infrastrutturale INGE

Il processo di business dei flussi input, attualmente realizzato tramite INGE, è schematizzato

nella figura seguente e presiede all’acquisizione dei flussi di dati in ingresso e al relativo inoltro ai sistemi informativi destinatari.

Figura 7 - INGE Global View

INGE realizza i seguenti processi di business: • Consegna e Ricezione dei flussi include le diverse fasi che intervengono da quando il

flusso arriva in Banca fino a quando è acquisito nel sistema; obiettivo del processo è il Trattamento dei supporti in modo generalizzato basato sulla codifica dei supporti stessi (sia fisici, sia telematici) e sull’utilizzo di procedure specializzate per singoli supporti;

• Acquisizione INGE dei flussi comprende i processi a cui INGE sottopone i flussi in ingresso e include la conversione dei dati da ASCII ad EBCDIC standard, il trattamento (“sbustamento”) dei file in formato XML veicolati dall’infrastruttura Raccolta Dati Via Internet, la scelta automatica dell’applicazione di destinazione sulla base di una codifica del flusso dei dati e dei mittenti abilitati al loro invio, la registrazione dell’arrivo del flusso sull’archivio “INGE” e su archivi di appoggio (“pozzi”), l’attribuzione di un numero di protocollo e l’eventuale notifica dell’arrivo dei dati all’Utente gestore, gestione di eventuale errore fisico di supporto e/o di errore di tipologia dei dati;

• Trattamento e consegna dei dati alle applicazioni destinatarie, svolta nel rispetto delle norme di sicurezza previste dal Sistema Gestionale (SIGE) e dal RACF (Remote Access Control Facilities) per la gestione delle applicazioni aziendali e dei relativi

G858 - 009/12 – Pag. 72 di 97

sistemi informativi, che include la gestione dello “stato” di utilizzo del flusso dei dati, la consegna standardizzata alle applicazioni, l’archiviazione standard dei dati scambiati mediante utilizzo del prodotto di sistema DMS (Data Management System). Dopo aver acquisito il flusso nella propria base dati, INGE ne effettua il riconoscimento in base alle informazioni presenti sull’anagrafe delle basi dati e presso l’archivio degli eventi, e provvede al trattamento dei flussi dati e all’attivazione delle applicazioni destinatarie.

• Servizi sui dati acquisiti in INGE prevedono inquiry guidato dell’archivio INGE, riutilizzo dei dati per esigenze applicative e gestione dell’indirizzario dei partner mittenti. I Servizi di accesso al dato forniti da INGE prevedono:

o inquiry guidato dell’archivio INGE e dei “pozzi dati”; o riutilizzo dei dati per esigenze applicative; o gestione dell’indirizzario dei mittenti.

Sono previste due tipologie di utenze: o utenza “tecnica” con accesso completo (in SIUD) ai dati o utenza “utilizzatrice” con accesso in sola lettura ai dati.

Data la loro complessità, nei successivi due paragrafi sono descritti in maggior dettaglio i

processi di business di “Consegna e Ricezione” e “Acquisizione INGE”, indicando anche le applicazioni che li implementano.

INGE - Consegna e Ricezione

Il processo di “Consegna e Ricezione” include tutti i processi che entrano in gioco da quando un flusso arriva in Banca a quando tale flusso arriva in input all’applicazione INGE. Questa vista descrive quale applicazione supporta ciascun componente del processo di business “Consegna e Ricezione” dei dati in arrivo in Banca d’Italia.

G858 - 009/12 – Pag. 73 di 97

Figura 8 - INGE Consegna e Ricezione

Il processo di “Consegna e Ricezione” si differenzia a seconda del canale dal quale provengono i

dati; sono stati individuati 2 diversi canali:

1. Consegna dati supporto magneto-ottico

2. Consegna dati da rete (pubblica-Internet e privata-RNI)

Vengono di seguito descritti i processi corrispondenti ai 2 sopra elencati canali e le relative applicazioni INGE coinvolte.

1 Consegna dati supporto magneto-ottico

• Consegna LB/CDM: I supporti magneto-ottici possono essere recapitati o a Largo Bastia o al CDM; tali supporti sono quindi sottoposti al processo successivo di

trattamento e protocollazione di ricezione.

•••• Trattamento e protocollazione di ricezione: L’addetto al trattamento dei supporti utilizza la prima etichetta disponibile e la appone come numero di portineria, fornito

da INGE, al supporto fisico, sia esso CD, cassetta o DVD. Ovviamente sullo stesso

supporto potrebbero essere contenuti più file: in questo caso quindi a tale numero di

portineria o etichetta corrisponderanno più file. La stampa delle etichette è una

G858 - 009/12 – Pag. 74 di 97

funzionalità di INGE: due gruppi OPC di INGE, programmati settimanalmente tutti i

lunedi, verificano l’esaurimento delle etichette, sia per il CDM che per Largo Bastia

e, in caso di carenza, provvedono alla stampa. Il numero di portineria così assegnato

al supporto riveste un ruolo fondamentale soprattutto in caso di problemi, ad esempio

dispositivi danneggiati, per poter forzare il caricamento.

•••• Acquisizione: Dopo l’apposizione dell’etichetta l’addetto inserisce il supporto nel PC e avvia il caricamento del flusso che viene inoltrato al processo di ricezione dati a

sistema. Le applicazioni coinvolte in ESAG nel processo INPUT Consegna dati

supporto magneto-ottico sono le seguenti:

INGE - Acquisizione cassette: i dati ricevuti su supporti magnetici “Cassette 3490”

sono acquisiti mediante l’utilizzo di un comando del sistema operativo mainframe,

che provvede immediatamente a trasmetterli all’applicazione INGE residente sul

sistema centrale.

INGE - Acquisizione Floppy/CD: i dati ricevuti sui supporti floppy disk e CD-

ROM/DVD sono letti mediante apposite funzionalità presenti su una postazione di

lavoro di tipo stand alone che provvede successivamente a inviarli all’applicazione

INGE residente sul sistema centrale.

INGE – QUADINGE e INGE – QUADUIF: programmi elaborativi per la verifica delle quadrature tra i supporti magnetici pervenuti e quelli caricati.

La gestione amministrativa del flusso è esterna all’ambito di INGE.

2 Consegna dati da rete (pubblica-Internet e privata-RNI)

Tutti i flussi in arrivo via rete vengono gestiti tramite processi di “Interfaccia Rete” che

sono esterni all’ambito del progetto e non costituiscono oggetto di fornitura nel presente

capitolato.

I dati ricevuti tramite rete sono acquisiti dal GARI. Il GARI fornirà ad INGE tutte le

informazioni necessarie all’acquisizione e successivo trattamento dei dati:

GARI-INGE:

o nome applicazione

o nome del file ricevuto

o indirizzo del mittente

o indirizzo del destinatario INGE – Acquisizione INGE

Il processo di “Acquisizione INGE” include tutti i processi a cui un file può essere sottoposto dopo essere arrivato sul mainframe in Banca e prima di essere consegnato in input all’applicazione destinataria.

G858 - 009/12 – Pag. 75 di 97

Figura 9 - INGE Acquisizione

Vengono di seguito descritte le funzioni (obbligatorie e a richiesta) di INGE che supportano

i processi da considerare nell’ambito del progetto:

• Protocollazione dei dati acquisiti: (obbligatoria) Questa funzione in INGE ha l’obiettivo di attribuire un numero di protocollo a ogni “pozzo” dati, dove per “pozzo” dati si

intende il dataset sequenziale nel quale INGE salva il flusso trasmesso.

• Trasformazione dei dati: (a richiesta) Questa funzione garantisce la conversione dei dati da ASCII a EBCDIC standard

• Sbustamento dei dati: (a richiesta) Questa funzione garantisce, per i file XML veicolati dall’infrastruttura Raccolta Dati Via Internet (RDVI), l’estrazione dei dati di busta e del

relativo pay-load. Il file XML trattato è scomponibile in due parti:

- una parte di “intestazione” o “busta” che contiene le informazioni utili al

riconoscimento e all’instradamento del “payload”;

- una parte di “payload” o “documento di business” che contiene i dati oggetto di

acquisizione ed elaborazione da parte dell’applicazione di trattamento e

controllo destinataria.

G858 - 009/12 – Pag. 76 di 97

• Immagazzinamento dei dati: (obbligatoria) Questa funzione permette di conservare i file e di renderli disponibili per futuri utilizzi a richiesta dell’utente.

G858 - 009/12 – Pag. 77 di 97

Applicazione infrastrutturale PEGASO

Il processo di business dei flussi output, attualmente realizzato tramite PEGASO, è schematizzato nella figura seguente e presiede alla produzione dei flussi in output forniti dai sistemi informativi della Banca e al loro confezionamento nei vari supporti prestabiliti ovvero all’inoltro verso i canali di collegamento con le reti telematiche.

Figura 10 - PEGASO Global View

PEGASO realizza i seguenti processi di business:

• Acquisizione Flusso Dati che comporta: i) la presa in carico dei flussi prodotti dalle applicazioni della Banca, predisposti con modalità standard; ii) caricamento e registrazione dei flussi su un proprio archivio e su archivi di appoggio (“pozzi”); iii) verifica dei destinatari abilitati; iv) attribuzione di un numero di protocollo; v) gestione di eventuale errore di tipologia dei dati;

• Trattamento Flusso Dati, nel rispetto delle norme di sicurezza previste dal SIGE e dal RACF, basato su i) un trattamento generalizzato per ogni singolo tipo di supporto (sia fisici che telematici); ii) procedure specializzate per singoli supporti; iii) archiviazione standard; iv) conversione dei dati da EBCDIC ad ASCII standard;

• Produzione Flusso Dati, in modalità standard, per; i) file provenienti dai sistemi centrali (file dati su “Cassette 3490” e su CD-ROM e/o Floppy Disk; file PDF su CD-ROM; spedizione via telematica; stampa su carta o via MAN per i Servizi dell’A.C.); ii) file XML da veicolare tramite l’infrastruttura Raccolta dati via Internet;

G858 - 009/12 – Pag. 78 di 97

iii) file provenienti dai sistemi intermedi (file PDF su CD-ROM da file TAR; stampa su carta da file PDF; stampa su carta da file PCL);

• Servizi sui dati acquisiti, che forniscono: i) certezza della produzione dei dati sui supporti fisici previsti; ii) certezza della consegna dei dati ai destinatari in caso d’invio telematico; iii) inquiry guidato dell'archivio; iv) possibilità di riprodurre i dati sul supporto previsto, o su supporto diverso, senza intervento applicativo; v) gestione dell'indirizzario dei destinatari. Sono previste due tipologie di utenze:

o utenza “tecnica” con accesso completo (in SIUD) ai dati; o utenza “utilizzatrice” con accesso in sola lettura ai dati.

La descrizione delle suddette macrofunzionalità fornisce, implicitamente, l’evidenza del

flusso procedurale (consegna, trattamento dei flussi e dei supporti, produzione dei flussi), attualmente impiegato in Banca per la gestione dei flussi in uscita.

Data la complessità, nel successivo paragrafo viene descritto in maggior dettaglio il processo di business di “Produzione Flusso Dati” indicando anche le applicazioni che lo implementano.

PEGASO – Produzione Flusso Dati Il processo di “Produzione Flusso Dati” include tutti i processi che entrano in gioco per

produrre i flussi dati in uscita. Questa vista ha l’obiettivo di illustrare i servizi di produzione dei flussi dati in uscita.

Figura 11 - PEGASO Produzione Flusso Dati

G858 - 009/12 – Pag. 79 di 97

Le applicazioni coinvolte nel processo “Produzione Flusso Dati” sono le seguenti:

• GESPED di cui verrà fornita la descrizione nel successivo paragrafo. • PEGASO-RNI Per effettuare una spedizione di un flusso FTS via RNI, occorre

sottomettere una fase precostituita denominata “Prenota” al GARI, specificando in una apposita DD un record che specifica:

- nome applicazione - nome del file da spedire - indirizzo del mittente - indirizzo del destinatario

• PEGASO-Internet Per effettuare una spedizione di un flusso FTS via rete pubblica

(Internet), occorre copiare in una specifica directory una coppia di file (dato + ready).

PEGASO-Stampe Per effettuare una spedizione di un flusso stampato, PEGASO:

• utilizza il protocollo LPR per gestire le stampe PCL: • interfaccia il software di stampa DocBridge Software per la conversione da PDF a

PCL; • interfaccia il software di stampa Xerox Printer Access Facility (XPAF) per la

conversione da DJDE a PCL.

G858 - 009/12 – Pag. 80 di 97

Applicazione infrastrutturale GESPED

GESPED (GEstione SPEDizioni) assicura il controllo e la gestione amministrativa delle spedizioni dei flussi dati via supporto magneto-ottico. Nella figura seguente viene evidenziato il processo di business “Produzione Flusso Supp.Magn.”, realizzato tramite GESPED.

Figura 12 - GESPED Produzione Flusso Supporti Magneto-ottici

GESPED costituisce pertanto una componente ancillare del sistema di interscambio: in caso di flussi di dati in uscita su supporti fisici, e quindi da spedire via posta tradizionale o corriere, GESPED si interfaccia con l’applicazione preposta alla spedizione dei flussi in uscita (PEGASO) dalla quale riceve le informazioni necessarie per registrare i dati sui supporti fisici.

In particolare, sono prodotte:

o le etichette da apporre sui plichi; o le distinte descrittive del contenuto degli stessi; o gli elenchi delle spese giornaliere per le spedizioni via corriere e/o via Poste

Italiane Spa. Riguardo a queste ultime, GESPED ne calcola il costo consentendo sia la produzione dell’informativa sulle movimentazioni del conto corrente postale per le due macchine affrancatrici, sia il raffronto mensile delle fatturazioni presentate dai corrieri.

G858 - 009/12 – Pag. 81 di 97

Allegato B. L’applicazione FAGDD

Il seguente allegato descrive il funzionamento dell’attuale applicazione infrastrutturale FAGDD (cfr. § 1.2) e il formato dei tabulati prodotti dalle applicazioni che la interfacciano con particolare riferimento alla busta (testata) che identifica le caratteristiche del tabulato.

Applicazione infrastrutturale FAGDD

La componente FAGDD è un applicazione infrastrutturale proprietaria sviluppata in linguaggio Assembler, operante in ambiente IMS su piattaforma z/OS e che utilizza come base dati un archivio gerarchico IMS-DL/1.

Il generico dataset prodotto dall’applicazione è composto da un unico tabulato (da inviare a tutte le Filiali) oppure da più tabulati (ciascuno relativo ad una destinazione diversa). Un tabulato è quindi un insieme di pagine univocamente associato a uno o più destinatari ed omogeneo sotto il profilo delle caratteristiche applicative (codice tabulato, riferimenti amministrativi, riferimenti all'elaborazione). La suddivisione in tabulati all’interno del dataset (e in pagine all’interno di un tabulato) e le caratteristiche di ogni tabulato (incluse le sue destinazioni) sono specificate dalle applicazioni mediante l'inserimento di appositi record identificativi nel dataset.

La sezione “Formato dei tabulati FAGDD” di questa appendice riporta la descrizione di dettaglio delle caratteristiche del dataset .

I destinatari dei tabulati sono specificati dai programmi applicativi tramite inserimento in un apposito campo nel record identificativo (testata) del dataset. I destinatari cui si fa riferimento sono le Filiali e i Servizi (UNL).

L’indicazione può essere di tipo elementare e, quindi, esprimere direttamente codici di Filiale/Servizio (UNL) o di tipo complesso e fare riferimento a gruppi o liste di destinatari elementari. Il controllo e la gestione dei codici di destinazione, sia elementari che di gruppo, è effettuato dalla applicazione utilizzando un database delle destinazioni.

Nell’ambito di una medesima UNL è possibile destinare un tabulato all’interno di un contenitore logico (classe di stampa) che conterrà tabulati omogenei dal punto di vista della tipologia, del trattamento o dell’Ufficio destinatario.

Le tabelle presenti nella sezione “Formato delle Anagrafi di Filiale” di questa appendice riportano esempi di riferimento per la lista delle destinazioni elementari (UNL), la lista delle destinazioni di gruppo e la lista delle classi di stampa.

Una volta acquisito un tabulato l’applicazione FAGDD provvede ad inoltrarlo automaticamente alle applicazioni periferiche (APMAIN): l’invio avviene tramite comandi IMS (ISRT ALT-PCB) ed una componente di interfaccia denominata OTMA che utilizza per la comunicazione con il gestore delle comunicazioni MQSeries delle code denominate TPIPE. I tabulati vengono quindi “convertiti” in messaggi MQSeries che vengono inseriti in code associate (in modo esclusivo) alle Filiali destinatarie.

Nella comunicazione con l’applicazione periferica, l’applicazione FAGDD valorizza una testata di sistema ed una applicativa che include parte delle caratteristiche del tabulato presenti nel record identificativo del dataset originario ed altre informazioni che vengono memorizzate nella base dati periferica.

I tabulati vengono trasmessi in forma compressa eliminando i caratteri “blank” al momento dell’invio; una routine simmetrica e inversa opera in sede di ricezione al momento della stampa.

G858 - 009/12 – Pag. 82 di 97

Il formato richiesto per la stampa del tabulato è gestito mediante un’informazione scambiata tra l’applicazione FAGDD e l’applicazione periferica.

Presso il sistema periferico (vedi paragrafo successivo) la fase di ricezione dei tabulati opera in modo autonomo e asincrono rispetto alle fasi di stampa. I tabulati ricevuti vengono registrati su disco e la stampa viene effettuata in base a richieste locali eseguite dagli operatori ai posti di lavoro della Filiale.

L'avvenuta stampa di ogni tabulato è segnalata all’applicazione FAGDD, mediante una segnalazione automatica inviata dall’applicazione periferica.

I tabulati possono essere cancellati con apposite transazioni accettate solo qualora i tabulati risultino stampati. La cancellazione è di tipo logico: un tabulato oggetto rimane archiviato sul DB centrale fino a quando tutti i destinatari non l'abbiano ricevuto, stampato e cancellato.

La depurazione degli archivi centrali viene eseguita con una fase post-TP che, oltre alle operazioni di cancellazione, riorganizza le code dei tabulati-oggetto rimasti in archivio. La fase produce una stampa di controllo che elenca i tabulati ancora disponibili e quelli cancellati. Ad ogni modo, in caso di necessità, anche dopo la loro eliminazione dagli archivi, i tabulati possono essere recuperati dalle copie di salvataggio e reinseriti nel ciclo di distribuzione in filiale.

L’utente di Filiale in generale non ha necessità di accedere direttamente all’applicazione FAGDD in quanto utilizza le applicazioni periferiche, tuttavia sono state rese disponibili transazioni (richiamabili tramite interfaccia di tipo emulazione 3270) per il controllo dello stato dei tabulati e per richiederne la ritrasmissione in caso di mancata ricezione.

Lo stato di un tabulato può assumere i seguenti valori:

“0”: tabulato per il quale non hanno ancora avuto inizio le operazioni di spedizione;

“1”: tabulato per il quale la spedizione è in corso;

“3”: tabulato completamente inviato ma non ancora stampato in periferia;

“5”: tabulato inviato e stampato;

“9”: tabulato cancellato.

Formato dei tabulati FAGDD

Struttura generale

I tabulati generati dalle applicazioni IMS in formato FAGDD sono memorizzati su dataset sequenziali ed hanno le seguenti caratteristiche generali:

• record lunghi 138 bytes composti da:

- righe di 133 caratteri con il primo carattere di controllo spaziatura verticale secondo lo standard ASA CODE (cfr. Tabella 32);

- progressivo di controllo sequenza in coda ad ogni record di 9 cifre (5 caratteri formato signed packed EBCDIC) del tipo "collating sequence" ad iniziare da 1;

• record di tipo "1***" per l'identificazione dei moduli di stampa;

• record di tipo "1&&&" per l'identificazione dei tabulati;

G858 - 009/12 – Pag. 83 di 97

• record di tipo "1%%%" per l'identificazione applicativa delle pagine (opzionale);

• record di tipo "1???" per l'identificazione della fine del file-spool;

• codifica "ASA" del carattere di controllo della spaziatura verticale. Tali caratteristiche sono ammesse dal programma di stampa-spool off-line, che e' stato opportunamente modificato, attualmente in uso nell'installazione della Banca.

ASA Character Action

1 Advance to next page (form feed)

2–9, A, B, C Advance to vertical tab stop

blank Advance 1 line (single spacing)

0 Advance 2 lines (double spacing)

- Advance 3 lines (triple spacing)

+ Do not advance any lines before printing, overstrike the previous line

Tabella 31 – Standard ASA code

Record di identificazione del tabulato (testata del tabulato)

E' caratterizzato dalla costante "1&&&" nelle prime quattro posizioni.

Tutte le pagine registrate tra un record identificativo e il successivo (o la fine dello spool) costituiscono un tabulato, cui la funzione assegna automaticamente un codice di identificazione univoca (codice o numero oggetto). La prima riga di tabulato successiva al record d’identificazione è di norma caratterizzata dal carattere di controllo di inizio pagina, cioe' "canale 1".

Il record ha il seguente tracciato. Posizione Descrizione del campo

001-004 Tipo record: "1&&&" 005-011 codice-tabulato: è un codice di 7 cifre composto, nelle prime 4, dal codice SSPP

dell'applicazione che lo produce e nelle ultime 3 da un numero identificativo del tabulato nell'ambito della stessa procedura; identifica tipologicamente il tabulato in modo univoco nell'ambito del sistema IMS di riferimento.

012-017 data-di-riferimento: è la data di riferimento amministrativo o contabile del tabulato nella forma "AAMMGG".

018-019 iterazione-versione: è un numero di due cifre che identifica, all'occorrenza, iterazioni o versioni elaborative diverse nell'ambito della data di riferimento.

020-025 data-di-produzione: è la data di elaborazione applicativa del tabulato nella forma "AAMMGG".

026-031 ora-di-produzione: è l'ora di elaborazione applicativa del tabulato nella forma "HHMMSS".

032-038 codice-richiesta: è un codice numerico che identifica univocamente la richiesta dell'utente, per la produzione dell'elaborato, nell'ambito dell'applicazione.

039-044 data-richiesta: è la data in cui è stata effettuata la richiesta utente di elaborazione del tabulato, ha la forma "AAMMGG".

045-052 utente-richiedente: è una sigla alfanumerica che identifica l'utente o l'applicazione che ha richiesto la produzione del tabulato.

G858 - 009/12 – Pag. 84 di 97

053-060 chiave-di-sicurezza: attualmente non implementata sui sistemi di Filiale, valorizzare con caratteri 'blank' (" ").

061-062 Campi non utilizzati: valorizzare con "00". 063-069 Funzioni di riaggancio tabulato: attualmente non implementate sui sistemi di

Filiale, valorizzare con la stringa '0200000'. 070-072 priorità: è un numero di tre cifre sulla base del quale vengono ordinate le code

dei tabulati da inviare; valori bassi corrispondono ad alte priorità di invio. I valori utilizzabili sono compresi tra "500" e "800".

073-076 modulo-di-stampa: è un codice alfanumerico che indica il modulo di stampa del tabulato; tra i valori assunti "STD2" corrispondente a carta bianca standard 66 righe.

077-101 descrizione-tabulato: stringa alfanumerica che rappresenta la descrizione amministrativa del il tabulato.

102-133 destinazione-tabulato: è un campo alfanumerico di 8 caratteri che può essere replicato fino a quattro volte per indicare un massimo di 4 destinazioni diverse. Ogni destinazione (8 caratteri) è formata da un campo da 5 caratteri e da un campo da 2 caratteri (separati da uno spazio). Nel campo di cinque caratteri è indicata la UNL di destinazione nella forma di un codice simbolico che identifica uno specifico codice di Filiale nella forma NNNSA (ad esempio "135SA") oppure nella forma di una lista di raggruppamento contenente una o più Filiali (“L135GN” o “LTESOR”). Nel campo da 2 caratteri è indicata la classe di stampa nell'ambito della Filiale a cui è destinato il tabulato.

Record di identificazione della pagina

E' caratterizzato dalla costante "1%%%" nelle prime quattro posizioni.

Questo record è opzionale ed è utilizzato per l'esplicitazione del codice di riaggancio associato ad ogni pagina, ai fini della sua identificazione applicativa, nel solo caso in cui esso sia stampato nel corpo del tabulato in posizione non predefinita e costante. Attualmente non sono implementate funzioni di gestione automatica del codice di riaggancio delle pagine. Record di fine File

E' caratterizzato dalla costante "1???" nelle prime quattro posizioni. Indica la conclusione del file-spool. E' richiesto per il controllo di integrità del file-spool nell'ambito della fase di acquisizione dei tabulati.

Il record ha il seguente tracciato. Posizione Descrizione del campo

001-004 Tipo record : "1???" 005-133 Filler : "*"

G858 - 009/12 – Pag. 85 di 97

Esempio di tabulato FAGDD

Viene fornito di seguito un esempio di tabulato (modello MOD. 4 POP) in formato FAGDD destinato alla classe di stampa RS del codice UNL 453SA.

G858 - 009/12 – Pag. 86 di 97

Formato delle Anagrafi di Filiale

La Tabella seguente riporta un estratto dell’attuale anagrafe degli indirizzamenti logici di primo livello (UNL) e dei rispettivi indirizzamenti fisici di secondo livello (UFT) associati al codice UNL.

UNL Filiale UFT 110SA Alessandria 114SA 111SA Asti 114SA 112SA Cuneo 114SA 113SA Novara 114SA 114SA Torino 114SA 115SA Vercelli 113SA 116SA Biella 113SA 117SA Verbania 113SA 120SA Aosta 120SA 127SA Bergamo STC 127SA 128SA Lecco 132SA 129SA Lodi 135SA 130SA Bergamo 135SA 132SA Como 132SA 135SA Milano 135SA …. ………. …..

Tabella 32 – Anagrafe Destinazioni Filiali

La Tabella seguente riporta un estratto dell’attuale anagrafe degli indirizzamenti logici di primo livello (UNL) e dei rispettivi indirizzamenti fisici di secondo livello (UFT) associati al codice UNL per alcuni Servizi dell’A.C.

UNL Sigla UFT 858SA NCA 858SA 838SA RES 858SA 858SA ELI 858SA 908SA ISI 858SA …. ….. …..

Tabella 33 – Anagrafe Destinazioni Servizi

La Tabella seguente riporta un estratto dell’attuale anagrafe dei multi-indirizzamenti logici di primo livello (Liste). ListaAlias Tipo Destinazioni (Liste/Uop) Descrizione LTESOR L L110GN, L111GN, L112GN, L113GN, L114GN, L115GN Lista tesoreria

L110GN E 110SA Lista default 110SA Alessandria

L111GN E 111SA Lista default 111SA Asti

L112GN E 112SA Lista default 112SA Cuneo

L113GN E 113SA Lista default 113SA Novara

L114GN E 114SA Lista default 114SA Torino

L115GN E 115SA Lista default 115SA Torino

Tabella 34 – Anagrafe Liste Destinazioni

G858 - 009/12 – Pag. 87 di 97

La Tabella seguente riporta un estratto dell’attuale anagrafe delle Classi di Stampa utilizzata dalle applicazioni delle Filiali.

Il campo Classe_Stampa indica il valore referenziato dall’applicazione nella testata identificativa (busta) mentre il campo Coda_Stampa indica il valore visualizzato dall’utente nell’interfaccia grafica.

Classe_Stampa Coda_Stampa Descrizione CC CCC MOD 15 UDC CN CCN LISTE DI CONTABILITA (ROB, VABI, CAT) CR CCR VIGILANZA CS CCS TABULATI DI CASSA (14 DIR, 15 DIR) DU CDU DELEGA UNICA TESORERIA CFI CFI FIRME LP CLP MOD. 19 GIP, MOD. 9 OPV

RS CRS TABULATI VARI SG CSG ARIBAN, ICSR

ST CST USATA PER COMUNICAZIONI DI STANZA

TE CTE TESORERIA, PAGAMENTI INPS RNI

TF CTF TRASFERIMENTO FONDI

01 CSG MESSAGGI NOTIFICA

0R CRS MESSAGGI

Tabella 35 – Anagrafe Classi di Stampa

G858 - 009/12 – Pag. 88 di 97

Allegato C. Figure professionali del fornitore

Il personale del Fornitore addetto al progetto sarà composto dalle seguenti figure professionali:

• 1 (uno) responsabile tecnico (Project Manager);

• almeno 2 (due) membri del gruppo di progetto;

• almeno 1 (uno) esperto per l’assistenza sul prodotto (per le attività di presidio e reperibilità).

Le figure professionali devono essere in grado di parlare e scrivere correntemente in lingua

italiana.

Ove la Banca ritenga che la figura professionale proposta o utilizzata non sia idonea allo svolgimento dell’attività contrattuale, ne darà comunicazione al Fornitore che si impegna a procedere ad una nuova proposta entro il termine di 5 (cinque) giorni lavorativi dalla predetta comunicazione e, se richiesto, a sospendere l’impiego – anche con effetto immediato – della risorsa ritenuta non adeguata.

Caratteristiche del Project Manager

Il Project Manager dovrà possedere le caratteristiche minime di seguito indicate nella seguente tabella:

Caratteristiche Descrizione

Titolo di studio • Laurea in discipline economico-scientifiche Esperienze lavorative • Almeno tre anni di comprovata esperienza nella funzione di Capo

progetto

• Coordinamento di progetti complessi negli ambienti elaborativi su cui dovrà operare

• Nell’ambito della conduzione di progetti, esperienza nella gestione di: o risorse umane;

o tempi e costi;

o rapporto con i clienti;

o comunicazione;

o rischi;

o qualità;

o modifiche e configurazioni.

Conoscenze • Uso di tecniche e prodotti software per il project management • Ingegneria dei requisiti • Tecniche e strumenti per la modellazione delle informazioni • Metodologie di analisi e disegno di applicazioni software • Progettazione e implementazione di applicazioni software • Strumenti e tecniche di sviluppo e collaudo di applicazioni • Sicurezza applicativa • Realizzazione di prospetti (report)

G858 - 009/12 – Pag. 89 di 97


• Metodologie di progettazione di test • Scrittura di documentazione

Tabella 36 – Caratteristiche minime del Project Manager

Caratteristiche dei componenti del gruppo di progetto

Il gruppo di progetto del fornitore sarà costituito dall’insieme delle risorse specialistiche che verranno impegnate nell’ambito della fornitura. Ciascun componente del gruppo di progetto dovrà possedere le caratteristiche minime indicate nella seguente tabella:


Titolo di studio e Esperienze Lavorative

Possiede almeno uno dei seguenti requisiti:

• Laurea tecnico-scientifica triennale o superiore e almeno 2 anni di esperienza lavorativa nel settore ICT di competenza.

• Diploma e almeno 4 anni di esperienza lavorativa nel settore ICT di competenza.

Conoscenze • Conosce le componenti hardware/software dei sistemi della soluzione e le problematiche gestionali di integrazione tra piattaforme diverse.

• E’ in grado di gestire operativamente i prodotti di competenza: sia quelli relativi al software di base sia quelli relativi all'area applicativa.

• Conosce il software di base, le procedure gestionali e gli aspetti operativi dei prodotti; è in grado di dare supporto ai settori operativi.

• Conosce anche aree specifiche del software di base; é in grado di gestire e risolvere problematiche di installazione, manutenzione del software e corretto utilizzo dello stesso.

• E’ richiesta l'attitudine alla diagnosi e alla risoluzione dei problemi per dare supporto su sistemi proprietari o aperti e su configurazioni ibride.

• E’ in grado di controllare le prestazioni dei prodotti conosciuti e curarne il tuning.

• E’ a conoscenza delle problematiche di clustering e di virtualizzazione dei sistemi.

• E’ a conoscenza delle problematiche inerenti alla sicurezza e alle prestazioni.

• Almeno uno dei componenti del team deve conoscere ed essere in grado di operare in ambiente mainframe IBM z/OS e avere competenze nella scrittura di job JCL.

• Almeno uno dei componenti del team deve conoscere ed essere in grado di operare con lo strumento di schedulazione TWS in ambiente mainframe IBM z/OS.

Tabella 37 – Caratteristiche minime del membro del Gruppo di Progetto

Il Project Manager del Fornitore si impegna a contenere il turnover dei componenti del

gruppo di progetto: eventuali sostituzioni dovranno essere effettuate mantenendo il livello del gruppo coerente, sotto il profilo professionale (competenze specifiche, certificazioni e esperienza ICT), con l’offerta presentata. Le comunicazioni relative alle richieste di sostituzioni di risorse dovranno essere considerate valide solo se sottoscritte dal referente della Banca.

G858 - 009/12 – Pag. 90 di 97

Caratteristiche dell’Esperto per l’assistenza sul prodotto


Titolo di studio e Esperienze Lavorative

• Diploma e almeno 3 anni di esperienza lavorativa nel settore ICT di competenza.

Conoscenze • Conosce le componenti hardware/software dei sistemi della soluzione e le problematiche gestionali di integrazione tra piattaforme diverse.

• Esperienza di tutte le problematiche relative agli specifici prodotti/applicazioni su cui dovrà operare.

• E’ capace di dare supporto orientato alla gestione e agli aspetti tecnico/amministrativi dei prodotti e dei relativi servizi.

• Conosce il software di base, le procedure gestionali e gli aspetti operativi dei prodotti; è in grado di dare supporto ai settori operativi.

• Conosce anche aree specifiche del software di base; é in grado di gestire e risolvere problematiche di installazione, manutenzione del software e corretto utilizzo dello stesso.

• E’ richiesta l'attitudine alla diagnosi e alla risoluzione dei problemi per dare supporto su sistemi proprietari o aperti e su configurazioni ibride.

Tabella 38 – Caratteristiche minime dell’esperto per l’assistenza sul prodotto

G858 - 009/12 – Pag. 91 di 97

Allegato D. Documentazione richiesta

Nel presente allegato vengono elencati i documenti richiesti nella fornitura alla ditta aggiudicataria; per ciascun documento viene riportata la descrizione e la scadenza; il codice del documento è formato dalla macro-fase (cfr. § 3.3.1) in cui deve essere prodotto e da un progressivo che lo identifica; l’asterisco accanto al codice del documento segnala che alla sottoscrizione del documento da parte del DEC corrisponde un pagamento (cfr. § 4.1).

Tutta la documentazione richiesta potrà essere consolidata soltanto a seguito di approvazione da parte della Banca.

Cod. Documento

Titolo Documento Contenuti Scadenza

T1_1 Documento di Progetto Esecutivo

Piano dettagliato delle attività di sviluppo, installazione, configurazione e rilascio dell'infrastruttura.

Entro 50 gg lavorativi da DIL

T2_1 Documento di Installazione Checklist dettagliata delle attività necessarie per il rilascio della soluzione in un generico ambiente.

Almeno 20 gg lavorativi prima della data pianificata per il Collaudo Tecnico dei prodotti.

T2_2 Descrizione del Collaudo Tecnico Preliminare dei Prodotti

Lista dettagliata dei test da eseguire per il Collaudo Tecnico dei prodotti, dei tabulati pilota e flussi di test migrati.

Almeno 10 gg lavorativi prima della data pianificata per il Collaudo Tecnico dei prodotti.

T2_3* Rapporto di Esecuzione del Collaudo Tecnico Preliminare dei Prodotti

Risultato delle attività del Collaudo Tecnico dei prodotti e dei tabulati e flussi migrati.

Entro i 10 gg lavorativi successivi alla data pianificata per la conclusione del Collaudo Tecnico dei prodotti

T3_1 Descrizione del Collaudo di Accettazione

Lista dettagliata dei test da eseguire per l’esecuzione del Collaudo di Accettazione della soluzione.

Almeno 15 gg lavorativi prima della data pianificata per il Collaudo di Accettazione

T3_2* Rapporto di Esecuzione del Collaudo di Accettazione

Risultato delle attività del Collaudo di Accettazione della soluzione.

Entro i 10 gg lavorativi successivi alla data pianificata per la conclusione del Collaudo di Accettazione.

T4_1 Descrizione del Collaudo Finale

Lista dettagliata dei test da eseguire per la verifica del corretto funzionamento della soluzione relativamente ai tabulati e flussi pilota migrati in produzione, prima del loro definitivo rilascio in produzione.

Almeno 15 gg lavorativi prima della data pianificata per il Collaudo Finale.

T4_2 Manuale di Amministrazione

Guida all’utilizzo delle funzioni di amministrazione della soluzione relative alla definizione di un nuovo modello e alla gestione dei modelli esistenti.

almeno 15 gg lavorativi prima della data pianificata per il rilascio in produzione.

T4_3 Manuale di Gestione Guida all’utilizzo delle funzioni di gestione della soluzione (es.operatività day-by-day, recovery, gestione degli allarmi per problem determination).


G858 - 009/12 – Pag. 92 di 97

T4_4 Guida Utente Guida all’utilizzo delle funzioni con cui l’utente finale può accedere alla soluzione e può eseguire le attività di ricerca e visualizzazione di flussi e tabulati e di stampa dei tabulati.


T4_5* Rapporto di Esecuzione del Collaudo Finale

Risultato delle attività del Collaudo Finale della soluzione.

Entro i 10 gg lavorativi successivi alla data pianificata per la conclusione del Collaudo Finale.

T5_1 Descrizione del Collaudo dei Tabulati e Flussi migrati

Dettaglio dei test da eseguire per la verifica del corretto funzionamento di ciascun tabulato e flusso migrato, durante la fase di Migrazione prevista a seguito del Rilascio in Produzione.

Almeno 5 gg lavorativi prima della data pianificata per il collaudo di nuovi Tabulati e Flussi migrati in produzione

T5_2 Rapporto di esecuzione del Collaudo dei Tabulati e Flussi migrati

Risultato delle attività di Collaudo dei Tabulati e dei Flussi migrati.

Entro 10 gg lavorativi successivi alla data pianificata per la conclusione del Collaudo dei nuovi Tabulati e Flussi migrati in produzione.

T5_3* Verbale di Fine Lavori Sintesi delle attività eseguite nel corso del progetto.

Entro 10 gg lavorativi dal completamento della fase di Migrazione di Tabulati/Flussi

T6_1* Verbale di Fine Periodo di Stabilizzazione

Sintesi delle attività di presidio e reperibilità eseguite nel periodo di Stabilizzazione.

Entro 10 gg lavorativi dal completamento della fase di Stabilizzazione..

Tabella 39 - Lista dei documenti richiesti

T1_1 - Documento di Progetto Esecutivo

La ditta aggiudicataria ha l’onere di redigere, con il supporto del personale della Banca, il documento di progetto esecutivo relativo alle attività di sviluppo, installazione, configurazione e rilascio della infrastruttura. Il documento dovrà contenere le seguenti informazioni:

• la composizione del gruppo di lavoro corredato da informazioni sugli skill dei componenti, esperienze lavorative pregresse e ruolo nel progetto;

• il disegno architetturale della soluzione complessiva proposta;

• il disegno di dettaglio di tutti i sistemi/sottosistemi coinvolti nella soluzione comprendente sia le componenti infrastrutturali (configurazione dei prodotti) sia le componenti di personalizzazione e realizzazione delle interfacce con le applicazioni. Ove la soluzione utilizzi componenti di terze parti, non comprese dal prodotto ma fornite dalla Banca, il documento deve riportare anche le risorse hardware e software necessarie e le configurazioni richieste per tali componenti;

• il piano di lavoro contenente il dettaglio delle fasi realizzative (di seguito cronoprogramma) redatto in formato GANTT al fine di rappresentare i parallelismi e le dipendenze tra le diverse attività. Il cronoprogramma, aggiornato su base bi-settimanale durante la fase esecutiva per evidenziare eventuali scostamenti dalle stime iniziali (baseline), sarà presidiato dal Project Manager e dal referente di Banca che, nell’ambito di riunioni periodiche (di norma settimanali), valuteranno gli eventuali scostamenti e le eventuali azioni correttive da porre in essere, al fine di mitigare i rischi di progetto. Entro

G858 - 009/12 – Pag. 93 di 97

due giorni lavorativi dallo svolgimento delle citate riunioni, il Project Manager sottoporrà all’accettazione di Banca un documento di Stato Avanzamento dei Lavori (SAL) con il dettaglio sullo stato delle attività e delle criticità, le azioni correttive e le decisioni assunte nel corso della riunione e gli eventuali aggiornamenti al cronoprogramma;

• il piano dettagliato delle attività (WBS – Work Breakdown Structure) comprensivo delle fasi di sviluppo, installazione, configurazione, migrazione, test, collaudo e relativa fase di formazione e addestramento; per ciascuna delle fasi dovrà essere presentata una scheda dettagliata comprensiva delle seguenti informazioni: • obiettivo; • responsabilità; • prerequisiti; • tempi di esecuzione; • potenziali disservizi e criticità; • risorse impiegate; • potenziali rischi e loro impatto.

Il documento di Progetto esecutivo dovrà essere presentato dal Fornitore, in bozza entro 20 gg lavorativi a partire dalla data di inizio lavori e in versione finale entro i successivi 30 gg lavorativi dalla consegna della bozza: l’approvazione finale del progetto esecutivo da parte della Banca sarà vincolante per il prosieguo delle attività.

T2_1 - Documento di Installazione

La ditta aggiudicataria ha l’onere di redigere il Documento di Installazione contenente la lista dettagliata (checklist) delle attività necessarie per il rilascio della soluzione in un generico ambiente. Tale lista include tra l’altro le attività di installazione, configurazione dei prodotti inclusi quelli eventuali di terze parti, personalizzazione delle interfacce, integrazione con le infrastrutture di Banca. Tale documento verrà utilizzato come riferimento per l’installazione degli ambienti successivi e dovrà essere costantemente aggiornato a seguito di nuove attività inserite e/o modifiche apportate.

Il Documento di Installazione dovrà essere presentato dal Fornitore almeno 20 gg lavorativi prima della data pianificata per il Collaudo Tecnico dei prodotti. T2_2 - Descrizione del Collaudo Tecnico Preliminare dei Prodotti

La ditta aggiudicataria ha l’onere di redigere, con il supporto del personale della Banca, il documento di Descrizione del Collaudo Tecnico Preliminare dei Prodotti contenente la lista dei test che devono essere eseguiti durante il collaudo tecnico preliminare. Il collaudo tecnico dovrà essere volto a verificare il rispetto dei requisiti funzionali dei prodotti, facenti parte della soluzione, e la corretta funzionalità dei tabulati pilota e dei flussi di test migrati. Il documento di Descrizione del Collaudo Tecnico Preliminare dei Prodotti dovrà essere

presentato dal Fornitore almeno 10 gg lavorativi prima della data pianificata per il Collaudo Tecnico dei prodotti.

G858 - 009/12 – Pag. 94 di 97

T2_3*- Rapporto di Esecuzione del Collaudo Tecnico Preliminare dei Prodotti

La ditta aggiudicataria ha l’onere di redigere, con il supporto del personale della Banca, il documento di Rapporto di Esecuzione del Collaudo Tecnico Preliminare dei Prodotti relativo al risultato delle attività di collaudo tecnico dei prodotti e dei tabulati e flussi migrati. Il documento di Rapporto di Esecuzione del Collaudo Tecnico Preliminare dei Prodotti

dovrà essere presentato dal Fornitore entro i 10 gg lavorativi successivi alla data pianificata per la conclusione del Collaudo Tecnico dei prodotti. T3_1 - Descrizione del Collaudo di Accettazione

La ditta aggiudicataria ha l’onere di redigere, con il supporto del personale della Banca, il documento di Descrizione del Collaudo di Accettazione contenente la lista dei test che devono essere eseguiti durante il collaudo di accettazione della soluzione. Il collaudo di accettazione dovrà essere volto a verificare, per alcuni flussi dati e tabulati “pilota”, il rispetto dei requisiti funzionali, di sicurezza, prestazionali, e di integrazione con le risorse della Banca che il prodotto deve soddisfare. Il collaudo di accettazione verrà eseguito da personale di Banca con l’assistenza del Fornitore. Il documento di Descrizione del Collaudo di Accettazione dovrà essere presentato dal

Fornitore almeno 15 gg lavorativi prima della data pianificata per il Collaudo di Accettazione. T3_2*- Rapporto di Esecuzione del Collaudo di Accettazione

La ditta aggiudicataria ha l’onere di redigere, con il supporto del personale della Banca, il documento di Rapporto di Esecuzione del Collaudo di Accettazione relativo al risultato delle attività del collaudo di accettazione della soluzione. Il documento di Rapporto di Esecuzione del Collaudo di Accettazione dovrà essere

presentato dal Fornitore entro i 10 gg lavorativi successivi alla data pianificata per la conclusione del Collaudo di Accettazione.

T4_1 - Descrizione del Collaudo Finale

La ditta aggiudicataria ha l’onere di redigere, con il supporto del personale della Banca, il documento di Descrizione del Collaudo Finale contenente le istruzioni per l’esecuzione dei test di verifica del corretto funzionamento della soluzione relativamente ai tabulati e flussi pilota migrati in produzione, prima del loro rilascio. Il collaudo finale verrà eseguito da personale di Banca con l’assistenza del Fornitore. Il documento di Descrizione del Collaudo Finale dovrà essere presentato dal Fornitore

almeno 15 gg lavorativi prima della data pianificata per il Collaudo Finale.

G858 - 009/12 – Pag. 95 di 97

T4_2 - Manuale di Amministrazione

La ditta aggiudicataria ha l’onere di redigere il documento Manuale di Amministrazione contenente elementi utili per gli amministratori dei prodotti facenti parte la soluzione, illustrando le modalità con cui è possibile provvedere alla definizione di un nuovo modello, e alla gestione di modelli esistenti, di tabulato o di tipologia di flusso, di coda di stampa o di destinazione logica per i tabulati. Deve inoltre descrivere le attività necessarie per l’amministrazione della sicurezza del prodotto.

Il Manuale di Amministrazione dovrà essere presentato dal Fornitore almeno 15 gg lavorativi prima della data pianificata per il rilascio in produzione. T4_3 - Manuale di Gestione

La ditta aggiudicataria ha l’onere di redigere il documento Manuale di Gestione contenente elementi utili al personale addetto alle attività di supporto di primo e secondo livello sui prodotti facenti parte la soluzione. Particolare attenzione dovrà essere posta alla gestione degli allarmi, della incident analysis, della problem determination. Deve inoltre descrivere le procedure necessarie per l’operatività day-by-day e le procedure di recovery definite, al fine di garantire l’alta affidabilità della soluzione.

Il documento Manuale di Gestione dovrà essere presentato dal Fornitore almeno 15 gg lavorativi prima della data pianificata per il rilascio in produzione.

T4_4 - Guida Utente

La ditta aggiudicataria ha l’onere di redigere il documento Guida Utente contenente le modalità di accesso e di utilizzo corrente dell’interfaccia grafica della soluzione da parte dell’utente finale (es. attività di ricerca e visualizzazione di flussi/tabulati e di stampa dei tabulati).

Il documento Guida Utente dovrà essere presentato dal Fornitore almeno 15 gg lavorativi

prima della data pianificata per il rilascio in produzione. T4_5*- Rapporto di Esecuzione del Collaudo Finale

La ditta aggiudicataria ha l’onere di redigere, con il supporto del personale della Banca, il documento di Rapporto di Esecuzione del Collaudo Finale relativo al risultato delle attività del collaudo finale della soluzione. Il documento di Rapporto di Esecuzione del Collaudo Finale dovrà essere presentato dal

Fornitore entro i 10 gg lavorativi successivi alla data pianificata per la conclusione del Collaudo Finale.

G858 - 009/12 – Pag. 96 di 97

T5_1 - Descrizione del Collaudo dei Tabulati e Flussi migrati

La ditta aggiudicataria ha l’onere di redigere, con il supporto del personale della Banca, il documento di Descrizione del Collaudo dei Tabulati e Flussi migrati contenente per ciascun tabulato e flusso migrato, durante la fase di Migrazione prevista a seguito del Rilascio in Produzione, la scheda che ne descrive il test di verifica del corretto funzionamento. Il Fornitore dovrà, di volta in volta, aggiornare il documento inserendo le schede specifiche per i nuovi tabulati e flussi migrati. Il collaudo verrà eseguito da personale di Banca con l’assistenza del Fornitore. Il documento di Descrizione del Collaudo dei Tabulati e Flussi migrati dovrà essere

aggiornato e presentato dal Fornitore, ogni volta, almeno 5 gg lavorativi prima della data pianificata per il collaudo di nuovi Tabulati e Flussi migrati in produzione. T5_2 - Rapporto di esecuzione del Collaudo dei Tabulati e Flussi migrati

La ditta aggiudicataria ha l’onere di redigere, con il supporto del personale della Banca, il documento di Rapporto di Esecuzione del Collaudo dei Tabulati e Flussi migrati relativo al risultato delle attività del collaudo: il documento dovrà contenere per ciascun tabulato e flusso migrato, il risultato del test di verifica della migrazione. Il Fornitore dovrà, di volta in volta, aggiornare il documento inserendo le schede specifiche per i nuovi tabulati e flussi migrati. Il documento di Rapporto di Esecuzione del Collaudo dei Tabulati e Flussi migrati dovrà

essere aggiornato e presentato dal Fornitore, ogni volta, entro 10 gg lavorativi successivi alla data pianificata per la conclusione del Collaudo dei nuovi Tabulati e Flussi migrati in produzione.

T5_3*- Verbale di Fine Lavori

La ditta aggiudicataria ha l’onere di redigere, con il supporto del personale della Banca, il Verbale di Fine Lavori: il documento dovrà contenere una sintesi delle attività eseguite nel corso del progetto. L’accettazione di tale documento è vincolata alla conclusione con esito positivo di tutti i flussi e i tabulati previsti. Il Verbale di Fine Lavori dovrà essere presentato dal Fornitore entro 10 gg lavorativi dal

completamento della fase di Migrazione dei Tabulati e Flussi.

T6_1* - Verbale di Fine Periodo di Stabilizzazione

La ditta aggiudicataria ha l’onere di redigere, con il supporto del personale della Banca, il Verbale di Fine Periodo di Stabilizzazione: il documento dovrà contenere una sintesi delle attività di presidio e reperibilità eseguite nel periodo di Stabilizzazione. Il Verbale di Fine Periodo di Stabilizzazione dovrà essere presentato dal Fornitore entro 10

gg lavorativi dal completamento della fase di Stabilizzazione.

G858 - 009/12 – Pag. 97 di 97

FINE DEL DOCUMENTO

Il presente documento è conforme all'originale contenuto ... · PDF fileOTMA Open...

Documents

Transcript of Il presente documento è conforme all'originale contenuto ... · PDF fileOTMA Open...