GARA EUROPEA A PROCEDURA APERTA

For.Te. è il Fondo paritetico interprofessionale nazionale per la formazione continua costituito con DM 31 ottobre 2002, ai sensi dell’art. 118, Legge N. 388, e s.m.i., a seguito dell’accordo interconfederale del 25 Luglio 2001, così come modificato in data 31 ottobre 2007, da Confcommercio, Confetra, CGIL, CISL e UIL.

Istituito come Associazione ai sensi del capo II, titolo II – Libro primo del codice civile, non ha fini di lucro ed opera a favore di tutte le aziende che decidano di aderire, versando – per il tramite dell’INPS - al Fondo il contributo dello 0,30% istituito dall’articolo 25, quarto comma, della legge 21 dicembre 1978, n.845, e s.m.i. Ai sensi del comma 1 dell’art. 118 L. n. 388/2000 e s.m.i., For.Te. finanzia Piani e Progetti formativi concordati tra le Parti sociali.

Missione, statuto, regolamento, accordo istitutivo, normative di riferimento, organi e struttura di For.Te. sono pubblicati sul sito web: xxx.xxxxxxxxxx.xx .

L’attività del Fondo si esplica attraverso due procedure di finanziamento:

1. Il Conto individuale, attivato, in via d’ufficio, per le aziende aderenti che occupano da 250 dipendenti e oltre (e da 150 a 249 dipendenti, dietro richiesta dell’azienda), sui quali viene cumulato, in coerenza con quanto previsto dalla Legge 2/09 e con le regole del Fondo, l’80% dei contributi versati e trasferiti dall’Inps per il finanziamento e la realizzazione di Piani e Progetti formativi, al netto dei costi del Fondo. A titolo esemplificativo, nel 2017, i Piani finanziati attraverso questa modalità, sono stati 241, per un totale di finanziamenti concessi, pari ad € 17.115.963,51.

2. Gli Avvisi periodicamente emanati da For.Te. per il cui funzionamento il Consiglio di Amministrazione stanzia risorse dedicate dal Conto generale, costituito dalla sommatoria dei contributi versati e trasferiti dall’Inps al Fondo dalle aziende aventi da uno a 149 dipendenti, al netto dei costi del Fondo, e dal 20% delle aziende di cui al precedente punto 1.

Gli Avvisi sono finalizzati al finanziamento di Voucher, di piani e/o progetti aziendali, settoriali, territoriali, per i quali le aziende aderenti fanno richiesta. Ogni anno, il Fondo emana una media di tre avvisi, con due scadenze per ogni avviso (e ove possibile anche più scadenze). Gli avvisi possono essere di carattere generale, oppure speciale/tematico.

Al fine di dare una stima dei numeri che ne conseguono, si riportano (a mero titolo esemplificativo) i dati relativi ad alcuni Avvisi. In particolare, attraverso l’Avvisto generalista 1/17 (per il comparto commercio, turismo e servizi), nella sola prima scadenza, sono stati approvati 271 piani, per un importo complessivo pari a € 18.975.343,67. Attraverso l’Avviso generalista 2/17 (per il comparto logistica, spedizione e trasporti), nelle due scadenze, sono stati approvati 37 piani per un importo complessivo pari a € 3.812.689,24. L’Avviso speciale 5/12 ha avuto ben quattro scadenze, con un totale di 167 piani approvati, per un importo complessivo pari a € 7.217.624,31.

Inoltre, tra gli Avvisi emanati, il Fondo annualmente emana Invito pubblico rivolto ad organismi ed enti specializzati nella formazione continua, per la costruzione di un Catalogo nazionale on line di iniziative di formazione continua. Definito il Catalogo, pubblicato sul sito, le aziende aderenti al Fondo, possono procedere all’acquisizione di voucher formativi individuali, per i loro lavoratori.

A titolo esemplificativo, sulla base dell’ultimo Invito 1/15, attraverso il relativo Avviso 1/16, che prevedeva 3 distinte scadenze, sono stati finanziati 1.760 voucher formativi, per un totale di finanziamenti erogati pari ad € 3.354.118,94.

È possibile consultare i diversi Avvisi e l’intera documentazione agli stessi attinente, sul sito di For.Te., xxx.xxxxxxxxxx.xx

Per quanto riguarda il monitoraggio dei finanziamenti concessi, si tenga conto che la durata massima di un Piano formativo è di 24 mesi, nel caso degli Avvisi generalisti, e di 12 mesi, nel caso degli Avvisi tematici/speciali.

1.2 Introduzione al sistema informativo

Al fine di gestire l’intero processo connesso all’erogazione dei finanziamenti, a partire dalla presentazione dei Piani/Progetti formativi, passando attraverso il monitoraggio dei finanziamenti concessi, fino alla rendicontazione finale delle spese sostenute, il Fondo si è dotato di piattaforme tecnologiche dedicate.

Il Fondo, si è inoltre attrezzato per la gestione del flusso dati relativo alle adesioni e ai versamenti delle aziende aderenti provenienti dall’INPS, nonché per la trasmissione delle informazioni di monitoraggio da inviare all’ANPAL semestralmente costituite da:

1. le attività realizzate attraverso i Piani formativi finanziati dai Fondi, tenendo conto delle diverse tipologie di intervento, delle caratteristiche dell’attività realizzata e del soggetto attuatore/impresa e di altre caratteristiche che vengono raccolte a livello di piano e di progetti componenti i piani;

2. i destinatari della formazione, ovvero imprese e lavoratori coinvolti, identificati attraverso il conferimento dei codici fiscali anche tenendo conto dell’articolazione tipologica dei Piani formativi.

Allo scopo di migliorare l’efficienza dell’infrastruttura informatica e di garantire un servizio di supporto e assistenza con elevate garanzie e performance nei confronti degli utilizzatori sia interni che esterni, il Fondo è intervenuto sulla strumentazione e sull’architettura gestionale ripensandola in una logica di Piattaforma Globale, modulare, versatile, scalabile, facilmente aggiornabile.

Nel triennio 2015-2017 il sistema informativo si è evoluto integrando molte delle procedure relative alle attività del Fondo nelle piattaforme PGA (sistema di front-office in uso agli utenti esterni) e ACRF (sistema di back-office in uso al personale del Fondo).

1.3 Obiettivi e benefici attesi

Nel prossimo triennio il FONDO proseguirà nell’attività di progettazione e sviluppo del sistema informativo e si propone i seguenti obiettivi:

• Migliorare l’interoperabilità tra le diverse piattaforme componenti il sistema informativo in modo da ottimizzare i processi e migliorare l’efficienza nell’erogazione dei servizi;

• Integrare funzionalità e procedure oggi implementate in piattaforme più datate, nelle nuove piattaforme ACRF e PGA, in modo da realizzare un ambiente omogeneo sia dal punto di vista dei dati gestiti (database) che delle interfacce utente proposte;

• Adeguare, dove necessario, le procedure e i sistemi alle più recenti soluzioni e standard tecnologici al fine di ottenere una consultazione dei dati rapida, efficiente e un miglioramento dei servizi erogati.

• Realizzare un sistema di Business Intelligence che raccoglie e organizza il “patrimonio dati” generato dal FONDO e lo trasforma in informazioni utili al supporto decisionale.

2. OGGETTO DEL CAPITOLATO

Il presente capitolato tecnico si articola nei seguenti gruppi di attività che dovranno essere svolte dall’Affidatario per un periodo di 36 mesi dalla stipula del contratto.

Obiettivo primario del FONDO è quello di realizzare un ambiente operativo nel quale le piattaforme comunichino tra loro e interagiscano, al fine di velocizzare e semplificare le attività. Requisiti fondamentali sono quindi l’interoperabilità tra le piattaforme esistenti e future, e la scalabilità dell’intero sistema, soprattutto al crescere della quantità di dati gestiti.

2.1 Sviluppo software e manutenzione evolutiva (MEV)

Lo sviluppo software ad hoc e la manutenzione evolutiva (entrambe di seguito indicate anche solo con MEV), descritte al paragrafo 6.1, comprendono gli interventi volti ad arricchire il sistema informativo di nuove funzionalità o comunque a modificare o integrare le funzionalità dello stesso, ad evolverlo tecnologicamente, aumentandone le performance.

Nell’ottica di un miglioramento continuo delle piattaforme utilizzate e dell’adeguamento delle procedure alle più recenti soluzioni e standard tecnologici, sono apprezzati suggerimenti relativi l’evoluzione del sistema informativo e sono ammesse proposte ben dettagliate di nuove soluzioni e funzionalità.

2.2 Manutenzione adeguativa correttiva (MAC) e assistenza

Il servizio di manutenzione adeguativa correttiva, descritto al paragrafo 6.2, è definito dalle prestazioni da erogare ogni qualvolta se ne presenti la necessità per tutta la durata del contratto, ed è finalizzato:

• alla rimozione delle cause e degli effetti dei malfunzionamenti delle procedure e dei programmi in esercizio;

• ad assicurare il funzionamento del sistema secondo i livelli di servizio ed i requisiti richiesti;

• ad assicurare la costante aderenza degli applicativi all’evoluzione dell’ambiente tecnologico del sistema informativo;

• a garantire l’adeguamento del software a seguito di modifiche di norme o disposizioni di legge, modifiche organizzative, amministrative, dei processi interni o delle esigenze funzionali;

Tali attività dovranno essere erogate, per l’intero patrimonio di software applicativi, composto da quelli esistenti e da quelli che saranno realizzati nel corso dell’affidamento oggetto del presente capitolato.

2.3 Servizio di Help Desk

Il servizio richiesto, dettagliato al paragrafo 6.3, consta di un sistema di assistenza tecnica destinato:

• al personale del FONDO, per le segnalazioni di malfunzionamenti, richieste di interventi MAC, richieste di assistenza;

• agli utenti esterni al FONDO, per il supporto tecnico nell’utilizzo delle procedure a questi dedicate.

3. RESPONSABILE DI PROGETTO E GRUPPO DI PROGETTO

L’Affidatario dovrà nominare un proprio Responsabile di Xxxxxxxx al quale verranno affidate le mansioni di supervisione e coordinamento delle attività svolte dall’Affidatario stesso nell’esecuzione del contratto.

Il Responsabile di Progetto dell’Affidatario (Capo Progetto) rappresenterà il referente unico del Direttore dell’esecuzione nominato dal FONDO ed assicurerà, tra l’altro, la necessaria assistenza consulenziale al FONDO, anche al fine di definire le interazioni con sistemi di organizzazioni sociali, enti ed istituzioni.

Inoltre, per tutte le attività di gestione e conduzione del progetto, dovrà essere operativo, per l’intera durata dell’affidamento, un gruppo di progetto misto, composto dal Responsabile di Progetto dell’Affidatario, supportato adeguatamente dai referenti tecnici coinvolti nel progetto, secondo il mix di professionalità richiesto, dal Direttore dell’Esecuzione nominato dal FONDO, coadiuvato eventualmente dai referenti delle varie aree operative.

Tale gruppo dovrà coordinare tutte le attività oggetto del presente Capitolato verificandone lo stato di avanzamento e l’adeguatezza delle soluzioni tecniche implementate e valuterà l’esigenza di eventuali modifiche o variazioni rispetto alle specifiche tecniche contrattuali. Inoltre il gruppo, nella fase di analisi dei requisiti, dovrà approvare, mediante sottoscrizione, tutti i documenti di specifica delle funzionalità prima dell’avvio della fase implementativa. Tale gruppo di lavoro potrà riunirsi, a discrezione del FONDO o su richiesta formale dell’Aggiudicatario, presso la sede indicata dal FONDO.

L’Aggiudicatario dovrà predisporre, concordandolo con il gruppo di progetto, un repository digitale, interrogabile tramite interfaccia web, in cui rendere disponibile tutta la documentazione di progetto e d’utente.

Per le attività del gruppo di progetto non vi sarà alcun tipo di compenso aggiuntivo rispetto a quanto previsto per i singoli servizi dell’affidamento.

4. DESCRIZIONE DEL SISTEMA INFORMATIVO

In questo capitolo viene fornita una descrizione del sistema informativo del FONDO così come ad oggi è stato implementato:

4.1 Infrastruttura hardware

L’infrastruttura dei server componenti il sistema informativo è rappresentata nel seguente schema:

DC1

DOMAIN

CONTROLLER

SHAREPOINT

DB1

ACRF

PLESK 1

PGA + SITO

DC0

DOMAIN CONTROLLER

ARXIVAR

CONTABILITA

PLESK1-STAGING

XXXXXXXXX

XX0

WEBSHARE IIS FE1

WEB SERVER IIS

UFFICI DEL FONDO

IAAS - CLOUD

Ad eccezione del Domain Controller principale (DC0), costituito da un server fisico ospitato presso gli uffici del FONDO, l’intera infrastruttura è delocalizzata in una web farm esterna e implementata con un servizio IaaS di cloud computing (“Private Cloud” fornito da Aruba spa) dimensionato con le seguenti caratteristiche:

• Potenza di calcolo complessiva: 22 GHz dedicati

• RAM: 192 GB

• Spazio disco: 4520 GB (SSD+SAS)

• Rete dedicata con 16 IP pubblici

• Cloud Backup: 5 TB

Il collegamento tra gli uffici del FONDO e l’infrastruttura cloud è realizzato con una linea VPN implementata su una connessione in fibra ottica FTTH (punto-punto e dedicata), caratterizzata da una banda simmetrica garantita di 100 Mb/s.

Nell’infrastruttura cloud sono presenti 20 server virtuali, dei quali una parte, rappresentata nello schema precedente ed elencata di seguito, è utilizzata per implementare le componenti del sistema informativo descritte nel presente capitolato, una parte è utilizzata per gestire attività complementari (ex. Mail Server, Server backup…)

Nome Server	Sistema Operativo Servizi installati	Funzione
DC0	Windows 2012 R2	Domain Controller
PLESK1	S.O. CentOS 6.9 - 64bit Web server: Apache DBMS: MySql	Sito istituzionale Piattaforma PGA
ARXIVAR	Windows 2012R2 Standard	Applicazione Arxivar
CONTABILITA	Windows 2012R2 Standard	Server destinato a ospitare le applicazioni contabilità portate su 2012
DB1	Windows 2012R2 SE FileMaker Sql Server 2012	Piattaforma ACRF
DC1	Windows 2012R2 Standard	Domain Controller
FE1	Windows 2012R2 Standard	SERVIZI WEB SU IIS
NS1	Windows 2012R2 Standard	Ospita la share folder con le applicazioni per IIS
PLESK1- STAGING	CentOS 6.9 – 64bit	Web server di staging
SHAREPOINT	Windows 2012R2 Standard	Server destinato a ospitare la versione su 2012 di sharepoint

BACKUP

L’intera infrastruttura cloud è ridondata su un datacenter secondario ed è sottoposta ad un backup quotidiano con una retention di 7 giorni. Viene inoltre effettuato quotidianamente un backup dell’unica macchina fisica (DC0) presente negli uffici del FONDO; tale backup viene trasferito nell’infrastruttura cloud, ed è soggetto quindi alla stessa retention-policy.

4.2 Architettura software

PIATTAFORMA

ACRF

PIATTAFORMA

PGA

ARXIVAR

DOCUMENTALE / BPM

PIATTAFORMA CIA

SISTEMA CONTABILITA’

SITO WEB

ISTITUZIONALE

SHAREPOINT

PG2F

Operatori interni

UFFICI DEL FONDO

INFRASTRUTTURA CLOUD

Utenti esterni

INTERNET

MONITORAGGIO

FORMULARIO

GESTIONE CONTI

L’architettura software del FONDO, rappresentata nella seguente figura, è costituita da diverse piattaforme e componenti parzialmente interconnesse fra di loro:

La piattaforma ACRF (“Aderenti Contabilizzazione Risorse Formazione”) è lo strumento di back-office utilizzato dal FONDO a supporto delle attività di gestione delle adesioni, dei conti, degli accrediti delle risorse, degli avvisi e dei piani finanziati.

La PGA (“Piattaforma Gestione Avvisi”), realizzata con una applicazione web pubblicata su Internet, rappresenta il front-end a cui gli utenti esterni accedono per la gestione delle diverse fasi relative agli avvisi e agli inviti pubblicati dal FONDO: richiesta, monitoraggio, rendicontazione.

La Piattaforma CIA, costituita da diverse web application, è dedicata alla presentazione, monitoraggio e rendicontazione dei piani presentati dalle aziende titolari di un Conto Individuale Aziendale. Tale piattaforma dovrà essere riprogettata e integrata nelle più recenti piattaforme descritte sopra.

Arxivar è la soluzione documentale utilizzata dal FONDO: comprende in un unico prodotto un sistema per la digitalizzazione e l’archiviazione dei documenti e un flessibile strumento di Business Process Management. Uno degli obiettivi primari del FONDO è quello di integrare le funzionalità di Arxivar negli altri componenti del sistema informativo.

Il sistema contabilità, utilizzato dall’area Amministrazione, è implementato tramite una delle più diffuse soluzioni di gestione contabile sul mercato: Gamma Enterprise, prodotto da Team System.

Il sito web del FONDO, pubblicato all’indirizzo web xxxx://xxx.xxxxxxxxxx.xx, è implementato con Wordpress, uno dei sistemi CMS (Content Management System) più diffusi.

La piattaforma PG2F, utilizzata per la gestione degli avvisi prima dell’attivazione delle più recente PGA: è costituita da un’applicazione web, sviluppata su architettura LAMP, attualmente utilizzata solo per la consultazione dei dati gestiti.

Un’installazione di Microsoft Sharepoint è utilizzata per la condivisione e pubblicazione di una parte dei documenti in uso agli operatori del FONDO.

Altri componenti del sistema sono:

• la procedura per lo scambio di flussi informativi con il Ministero del Lavoro e le Politiche Sociali tramite la quale semestralmente il fondo invia una rendicontazione dettagliata dei piani formativi approvati e conclusi.

• la procedura di trasmissione dei dati al Registro Nazionale Aiuti.

Nei successivi paragrafi, al fine di definire con maggior dettaglio il sistema informativo, vengono descritte in maniera più approfondita le funzionalità delle singole piattaforme e procedure.

4.2.1 ACRF - Piattaforma Aderenti Contabilizzazione Risorse Formazione

La piattaforma “Aderenti Contabilizzazione Risorse Formazione” (ACRF) è lo strumento di back-office; la struttura del sistema si compone di aree distinte per contenuti e accessi e per ciascuna sono presenti funzionalità specifiche di stampa ed esportazione dei dati.

La soluzione è sviluppata con FileMaker 14, sia nella parte client che server e utilizza Jasper Report per la generazione della reportistica.

4.2.1.1 Acquisizione dei dati dal sito INPS.

Il database gestito dalla piattaforma ACRF è alimentato dai dati provenienti dall’INPS con il quale è stata concordata una modalità di fornitura degli stessi, relativi ai versamenti ed alle adesioni, basata su un accesso automatizzato mediante protocollo SFTP ai file in formato MS Access.

L’implementazione si articola nei seguenti punti:

• INPS ha predisposto un server FTP sul quale, dopo la prenotazione da parte del FONDO, sono trasferiti gli aggiornamenti dei file relativi alle aziende aderenti e dei contributi da queste versati. I file messi a disposizione sono generati esclusivamente in formato Access e sono compressi in formato zip. Il tracciato dei file è stato concordato con tutti i fondi interprofessionali; ogni modifica che dovesse alterare il tracciato originale dei file sarà comunicata con un anticipo tale da permettere l’aggiornamento delle strutture dei dati e dei relativi programmi di gestione;

• è stato comunicato ad INPS l’indirizzo IP della macchina abilitata a prelevare i file messi a disposizione sul server FTP;

• L' INPS ha comunicato al FONDO l’indirizzo IP del server e tutte le informazioni necessarie per consentire il prelevamento dei dati.

• Sul server FTP è stata predisposta una directory denominata “FITE” e all’interno di tale directory sono presenti i file oggetto dello scambio con il FONDO: sono file con estensione .zip che contengono un file MS Access avente lo stesso nome del file compresso che lo racchiude.

• Il FONDO procede con il download di tutti i file disponibili nel server FTP. Questi, al termine della corretta esecuzione dello stesso, vengono cancellati e, nella tabella di tracciamento dei flussi INPS, vengono posti nello stato finale ‘scaricato’.

• Per le aziende agricole è stata concordata con l’INPS una differente modalità di fornitura, in formato Excel, dei dati relativi ai versamenti ed alle adesioni.

• Un modulo dedicato (FM2DB) si occupa del trasferimento dei dati all’interno del database utilizzato da ACRF.

4.2.1.2 Area Adesioni

Quest’area contiene le informazioni “storiche” relative alle adesioni delle aziende al FONDO. Come indicato al paragrafo precedente, la banca dati è alimentata dai dati provenienti dall’INPS con frequenza periodica mensile.

La sezione include:

• le anagrafiche di dettaglio delle aziende e le informazioni sullo stato di adesione;

• i dettagli relativi ai versamenti effettuati dalle singole aziende e trasmessi dall’INPS;

• i dettagli sulla “tipologia” conto (generale o individuale/gruppo).

4.2.1.3 - Area Conti

Le imprese aderenti al FONDO sono “associate” al conto generale o ad uno specifico conto individuale o di gruppo, a seconda di specifici requisiti di natura dimensionale, per i quali sono previste differenti regole di partecipazione agli avvisi per la concessione dei finanziamenti per la formazione aziendale.

L’area Conti è composta da molteplici sezioni, in particolare:

• gestione, contenente la composizione del conto (aziende singole e collegate);

• disponibilità, contenente i dettagli delle risorse finanziarie distinte per tipologia, annualità, azienda, scadenza e disponibilità complessiva, e l’estratto conto;

• piani formativi, con le informazioni di dettaglio su aziende coinvolte, quote, ripartizione dell’approvato per annualità, riconosciuto, pagato;

4.2.1.4 - Area Accrediti e risorse

Le risorse del Fondo sono trasmesse e comunicate dall’INPS periodicamente con frequenza variabile nel corso delle singole annualità. L’area relativa alla gestione delle risorse contiene i dettagli sui singoli accrediti che il Fondo riceve e i dati di sintesi e riepilogo per annualità, utilizzati dall’Area Amministrazione del Fondo, a supporto delle attività relative alla contabilità e al bilancio.

4.2.1.5 - Area Avvisi

L’area avvisi è utilizzata in maniera trasversale da parte di diverse aree del Fondo. Contiene le sezioni relative alle varie fasi degli avvisi, dalla presentazione alla rendicontazione.

In particolare:

• sezione istruttoria, a cui accede il personale per le verifiche di ammissibilità dei piani; contiene per ciascun avviso e scadenza gli elenchi dei piani presentati e istruiti e le informazioni di dettaglio e i documenti di presentazione dei piani,

• sezione valutazione, a cui accedono sia il personale del Fondo per la parte relativa alla valutazione di tipo quantitativo, sia i componenti del nucleo di valutazione esterno al Fondo per la parte relativa

alla valutazione di tipo qualitativo; sono presenti le funzionalità per la predisposizione automatica delle graduatorie finali di approvazione e assegnazione finanziamenti,

• sezione monitoraggio, a cui accede il personale del Fondo, area Monitoraggio e area Ispettorato, per le attività relative alla gestione della parte attuativa della formazione, visualizzazione di dettaglio e di sintesi della formazione programmata, gestione delle richieste di variazione inviate dagli utenti (parte web, utenti front office)

4.2.1.6 - Area Formazione a Catalogo

L’area Voucher è utilizzata specificamente dal personale dell’area Ispettorato per la gestione delle attività relative all’attuazione del dispositivo “Formazione a Catalogo” e dal personale dell’area Amministrazione per la parte relativa ai pagamenti. L’area è composta da sezioni distinte per:

• la gestione delle variazioni richieste dagli utenti (lato web, front office),

• verifica dello stato di attuazione della formazione programmata,

• gestione delle richieste di liquidazione, con accesso ai dati e documenti di dettaglio delle richieste per le verifiche documentali,

• gestione delle richieste di liquidazione, per l’inserimento dei pagamenti.

4.2.1.7 - Utilità

Nella piattaforma ACRF sono presenti alcune sezioni trasversali di supporto alle attività. Le sezioni, presenti nel menu principale di accesso alla piattaforma ACRF, si riferiscono a:

• reportistica, contiene grafici sul trend e lo stato delle adesioni e revoche delle aziende, e un set predefinito di report con dati di sintesi e di dettaglio, per mese e anno, aggiornato mensilmente in concomitanza con l’aggiornamento dei dati sule adesioni trasmessi dall’INPS,

• verifica adesioni e tentativi, per facilitare da un lato le operazioni di verifica e controllo sullo stato di adesione di matricole / aziende in maniera massiva e dall’altro per verificare i tentativi falliti di iscrizione al Fondo.

Si rimanda all’allegato tecnico ALL-01 per una descrizione dettagliata dell’architettura della piattaforma, dell’ambiente e delle tecnologie di sviluppo adottate.

4.2.2 – Piattaforma Gestione Avvisi (PGA)

La PGA rappresenta il front-end web ed è costituita dai moduli per la gestione delle fasi relative agli avvisi e agli inviti pubblicati dal Fondo per la concessione di finanziamenti. La soluzione è implementata su una classica piattaforma LAMP (sistema operativo Linux, web server Apache, DBMS MySql e linguaggio di sviluppo PHP) ed utilizza il framework applicativo Symphony.

4.2.2.1 - Area Avvisi generali

La sezione “Avvisi” è attiva per le fasi relative alla partecipazione agli avvisi da parte dei soggetti presentatori. Il modulo software è composto dalle sezioni per:

• Presentazione e invio dei piani formativi,

• Ammissibilità

• Valutazione

• Monitoraggio (fase attuativa),

• Rendicontazione e liquidazione.

4.2.2.2 - Area VOUCHER

La sezione “Voucher” è attiva per le fasi relative alla partecipazione all’invito per la presentazione delle proposte formative da parte dei soggetti erogatori e per le fasi relative alla partecipazione all’avviso per la richiesta delle aziende di assegnazione voucher, in particolare:

• il modulo “Offerta” per:

o la presentazione delle offerte,

o la valutazione delle proposte,

o la pubblicazione degli esiti,

o la pubblicazione del Catalogo dell’offerta formativa,

• il modulo “Domanda” per:

o la presentazione delle richieste di assegnazione voucher,

o l’istruttoria di ammissibilità delle domande,

o la pubblicazione degli esiti,

o la gestione delle attività formative e l’attivazione dei voucher assegnati,

o la richiesta di liquidazione dei voucher.

Si rimanda all’allegato tecnico ALL-01 per una descrizione dettagliata dell’architettura della piattaforma, dell’ambiente e delle tecnologie di sviluppo adottate.

4.2.3 - Piattaforma CIA (Conti individuali / gruppi aziendali)

L’attuale piattaforma CIA consente agli operatori del Fondo (servizio assistenza tecnica, area Amministrazione, area Monitoraggio e area Ispettorato) e ai titolari dei singoli Conti (aziende e soggetti da queste abilitati), di operare per la richiesta di approvazione dei piani formativi e per le relative attività di monitoraggio.

La piattaforma è costituita da tre applicazioni web sviluppate sul framework XXX.XXX (.NET 2.0), pubblicate su un unico Web Server (Internet Information Server 8.5), ciascuna delle quali utilizza un database distinto gestito con MS SQL Server 2012:

• Gestione Conti (Sviluppata in XX.XXX)

• Formulario (Sviluppata in C#)

• Monitoraggio (Sviluppata in XX.XXX)

L’accesso alle applicazioni è consentito previa autenticazione, sia per gli operatori del FONDO sia per gli utenti esterni e le funzionalità disponibili dipendono dai ruoli assegnati (Amministratore, operatore formulario, operatore monitoraggio); l’implementazione di un sistema di S.S.O. (Single Sign On) consente, in alcuni contesti operativi, il passaggio da un’applicazione all’altra senza richiedere nuovamente le credenziali.

L’integrazione tra le tre applicazioni è realizzata prevalentemente a livello dati: specifiche query e script in linguaggio SQL si occupano della sincronizzazione delle informazioni (ad esempio lo spostamento dei dati relativi i formulari approvati dall’applicazione dedicata alla loro compilazione a quella utilizzata per il monitoraggio).

La Piattaforma è organizzata nelle seguenti sezioni:

• Anagrafiche (informazioni relative al titolare del Conto, ai soggetti attuatori, al responsabile del Piano);

• Compilazione del formulario on line per la presentazione dei Piani;

• Attività di monitoraggio fisico e finanziario;

Alcune delle funzionalità di tale piattaforma sono state già integrate nella nuova piattaforma ACRF.

4.2.4 – Sito web

Il sito web del FONDO, pubblicato all’indirizzo web xxxx://xxx.xxxxxxxxxx.xx, è implementato con uno dei sistemi CMS (Content Management System) più diffusi, Wordpress: un sistema open source scritto in linguaggio PHP e pubblicato con licenza open source GNU GPL.

Wordpress è uno strumento, inizialmente progettato per la semplice realizzazione di blog, che negli anni si è fortemente evoluto fino a diventare una delle piattaforme applicative di riferimento per la creazione e la pubblicazione, in maniera semplice e veloce, di siti Internet dinamici, dotati di grandi potenzialità e sicurezza. Le operazioni di creazione e modifica delle pagine del sito possono essere effettuate in modalità codeless, cioè senza necessità di produrre o modificare linee di codice.

Particolare importanza riveste la presenza di un editor integrato (WYSIWYG), la cui interfaccia utente, simile a quella delle popolarissime applicazioni “Office”, aiuta l’utente a creare agevolmente i contenuti che intende realizzare.

Le principali caratteristiche del CMS in uso sono:

• pubblicazione di contenuti informativi su siti/portali web, senza necessità di approfondite competenze tecnologiche da parte della struttura redazionale di back-end;

• possibilità di visualizzare l'anteprima dei contenuti prima che questi vengano pubblicati, ovvero resi disponibili agli utenti del sito;

• gestione dei contenuti informativi (archiviazione, strutturazione, inserimento mediante editor html, ecc.);

• gestione della comunicazione con gli utenti tramite servizi applicativi web (quali, ad esempio, Forum e Newsletter);

• Possibilità di proteggere i contenuti definendo preventivamente gli utenti e/o i ruoli che possono accedervi;

La struttura del portale favorisce una consultazione rapida delle informazioni di interesse per i principali interlocutori del FONDO (gli enti di formazione e le aziende aderenti) e può essere suddivisa, dal punto di vista funzionale, nelle seguenti aree:

• una serie di sezioni con contenuti statici che includono informazioni sulle finalità e sulle attività del FONDO, i riferimenti legislativi e i regolamenti;

• una sezione dinamica contenente news, avvisi e informazioni generiche che il FONDO aggiorna costantemente e che vengono proposte sia in home page che in un’area interna dedicata;

• un’area destinata alla pubblicazione di materiale utile al monitoraggio dei piani i cui contenuti e documenti sono pubblici, eccetto alcune risorse protette e accessibili solo con l’inserimento di una password;

• una serie di pagine che raccolgono i link di accesso alle aree riservate delle altre piattaforme accessibili via web (Piattaforma CIA, PGA…)

Nella seguente tabella vengono forniti i dettagli tecnici dell’implementazione:

Tipo e versione server e Sistema Operativo del server	• Sistema operativo virtualizzato tramite VMware • GNU/Linux CentOS 6.9 (Final) – 64 bit, • Versione kernel: 2.6.32-696.13.2.el6.x86_64, • RAM: 24GB • Swap: 4GB • Processore: GenuineIntel, Intel(R) Xeon(R)CPU E5-2697 v3 @ 2.60GHz
Versione Wordpress	4.3.15
Versione PHP	5.4.45
Versione di MySql	5.1.73
Plugin installati nel CMS	• Advanced Custom Fields – vers. 4.4.3 • Attachments – vers. 3.5.7 • Custom Post Type UI – vers. 1.1.2 • Custom Taxonomy Order NE – vers. 2.6.6 • Divas Cookies - vers. 0.9.1 • Dropdown Menu Widget - vers. 1.9.4 • HTML Page Sitemap - vers. 1.2 • MailPoet Newsletters - vers. 2.6.18 • NK Google Analytics - vers. 1.4.12 • Photo Gallery - vers. 1.2.62 • PHP Code Widget - vers. 2.3 • Shortcodes Ultimate - vers. 4.9.8.1 • TinyMCE Advanced - vers. 4.2.5 • Ultimate Posts Widget - vers. 2.0.5 • WP Splash Page - vers. 1.2

4.2.5 – Altre procedure per lo scambio dei flussi

4.2.5.1 - Procedura flussi XML per monitoraggio semestrale del Ministero del Lavoro

L’interfacciamento con il Sistema di Monitoraggio del Ministero del Lavoro prevede la rilevazione dei dati da parte dei Fondi interprofessionali per la formazione continua in due diversi momenti (che corrispondono alle fasi in cui i Fondi stessi trattano le informazioni rilevanti per il monitoraggio):

a) dopo la fase di approvazione dei Piani formativi, che coincide con la decisione di finanziamento sulla base delle procedure previste da ciascun Fondo, e riguarda le informazioni relative ai piani e ai progetti formativi finanziati;

b) dopo la fase di conclusione delle attività formative, che riguarda anche le informazioni relative alle caratteristiche dei lavoratori e delle imprese coinvolte;

Ogni singolo invio semestrale (scadenze 31 luglio e 31 gennaio) contiene:

• l’approvato del semestre precedente;

• il concluso del semestre precedente;

• le eventuali rettifiche di informazioni inviate in precedenza.

Ogni invio semestrale è composto da singoli flussi in formato XML, ognuno dei quali identifica un singolo Piano formativo (con il dettaglio di tutte le informazioni previste) nei due momenti considerati (approvazione o conclusione).

Di seguito si riportano alcuni dei dati presenti in un flusso:

• codice piano

• tipologia piano

• data di approvazione

• data di fine attuazione

• totale ore

• dimensione finanziaria

• totale contributo fondo

• numero totale di imprese coinvolte

• numero totale di lavoratori.

Per i dettagli implementative delle procedure di trasmissione dei flussi si rimanda al “Protocollo tecnico per la trasmissione dei dati di monitoraggio” allegato (ALL-02) al presente capitolato.

4.2.5.2 - Sistema di comunicazione con il Registro Nazionale Aiuti

Il Registro Nazionale Aiuti (xxxxx://xxx.xxx.xxx.xx), operativo dal 12 Agosto 2017, è uno strumento attivato dal Ministero dello Sviluppo Economico e permette di verificare che le agevolazioni pubbliche siano concesse nel rispetto delle disposizioni previste dalla normativa comunitaria, specie al fine di evitare il cumulo dei benefici e, nel caso degli aiuti de minimis, il superamento del massimale di aiuto concedibile imposto dall’Unione europea.

Nel sistema informativo del FONDO sono attive le procedure che, mediante degli script, accedono ai servizi esposti dal RNA ai soggetti accreditati: i servizi sono basati sul protocollo di comunicazione SOAP, attraverso la presentazione di un Web Service Description Language (WSDL).

Le procedure scambiano quindi un flusso di dati XML, la cui struttura è definita nella documentazione tecnica reperibile sul sito dedicato (xxxxx://xxx.xxx.xxx.xx/xxxxx/XxxxxxxXXX/xx_XX/xxxxxxxxxxxxxx_xxxxxxx); in particolare, le operazioni si riferiscono a:

• verifica Massimale de Minimis e Deggendorf - effettuate alla chiusura delle fasi di presentazione degli avvisi; per ciascuna operazione viene archiviato l’esito fornito da RNA;

• invio dati sugli aiuti concessi - effettuate a seguito di approvazione ufficiale dei piani;

• invio degli annullamenti - effettuate al verificarsi di revoche e rinunce sui piani;

4.2.6 – Arxivar

Arxivar è la soluzione documentale utilizzata dal FONDO per gestire la digitalizzazione e l’archiviazione dei documenti, è una piattaforma modulare che permette di archiviare, organizzare e gestire le informazioni aziendali sfruttando un potente motore di processi (workflow) definibili attraverso un modellatore grafico.

Le principali caratteristiche e funzionalità del prodotto sono:

• Archiviazione dei documenti elettronici di qualsiasi tipo (Word, Excel, Power point, immagini, video, mail…) provenienti da diversi sistemi informativi;

• Organizzazione dei documenti secondo diversi attributi e classi documentali strutturate in maniera gerarchica;

• Possibilità di collegare i documenti in modo manuale o automatico tramite fascicoli, pratiche, relazioni;

• Esecuzione di ricerche in modo strutturato e/o destrutturato;

• Protezione delle informazioni con la definizione di politiche di accesso basate sui ruoli;

• Disponibilità di un potente motore OCR integrato che riconosce il contenuto dei documenti e consente di indicizzare le informazioni acquisite;

• Profilazione automatica mediante barcode;

• Possibilità di creare modelli aziendali per la creazione di svariate tipologie di documenti: circolari, verbali, contratti, moduli qualità, etc;

• Disponibilità di un potente e flessibile sistema di Business Process Management, che, affiancato ad un Workflow Designer, consente di definire i processi aziendali in maniera molto semplice;

A titolo di esempio, sono elencati di seguito alcuni contesti in cui Arxivar viene utilizzato nell’attuale implementazione del sistema informativo del FONDO:

• Profilazione dei documenti gestiti dagli operatori interni secondo una ben definita struttura gerarchica di classi documentali: ogni utente, compatibilmente con il ruolo assegnato, ha accesso a specifiche classi di documenti e archivia i file generati dalla propria attività (verbali, circolari, contratti) e/o provenienti da sorgenti esterne (email, documenti cartacei);

• Profilazione dei documenti allegati da parte degli utenti esterni al FONDO durante la procedura di presentazione dei piani formativi tramite la piattaforma PGA: alla presentazione di un piano, viene richiesto all’utente il caricamento via web di una serie di documenti (domanda di finanziamento, autocertificazioni, documenti di riconoscimento), questi sono automaticamente trasferiti in Arxivar, profilati e collegati mediante il RUP che identifica univocamente il piano.

• Sfruttando le funzionalità di BPM e i modelli aziendali, è stato implementato, tramite il Workflow Designer, un processo che coordina la Direzione e la Segreteria nell’invio delle comunicazioni via PEC: la Segreteria, utilizzando i modelli documentali definiti in Arxivar, prepara le comunicazioni da inoltrare attraverso le caselle di posta elettronica certificata (in alcuni casi può trattarsi anche di una comunicazione massiva realizzata con una stampa-unione), attraverso la piattaforma il documento viene trasferito alla Direzione che appone la firma e ne autorizza l’invio; il processo ritorna quindi alla segreteria che procede all’inoltro delle mail. Nei vari passaggi della procedura le mail generate e i documenti utilizzati vengono automaticamente archiviati e profilati nel sistema.

Arxivar offre molteplici opzioni per interagire ed integrarsi con gli altri componenti del sistema informativo, in particolare pubblica interfacce di programmazione basate sulle più diffuse tecnologie rivolte alla interoperabilità:

• ARXivar SDK, un modulo basato su una libreria OLE/COM, consente di accedere ad una serie di funzionalità, rivolte alla ricerca e alla profilazione dei documenti, richiamando funzioni native di ARXivar.

• ARXivar WEB SERVICES, costituita da una ampia famiglia di Web Services, con interfacce basate su WSDL/SOAP, che permettono di archiviare, ricercare, visualizzare i profili dei documenti, aprirli, utilizzare i modelli fino ad accedere ai tasks dei workflow.

• ARXivar WCF service, la più recente e potente interfaccia pubblicata, basata su Windows Communication Fundation, espone il più ampio set di metodi e funzioni alle applicazioni terze in maniera affidabile e sicura.

Per una descrizione approfondita del prodotto si rimanda al sito internet del produttore (xxxx://xxx.xxxxxxx.xx )

5. OBIETTIVI MEV PREVISTI

Obiettivo primario del FONDO è quello di realizzare un ambiente operativo nel quale le piattaforme interagiscano tra loro, al fine di velocizzare e semplificare le attività. Requisiti fondamentali sono quindi l’interoperabilità tra le piattaforme esistenti e future, e la scalabilità dell’intero sistema, soprattutto al crescere della quantità di dati gestiti.

Nei seguenti sotto-paragrafi vengono forniti dettagli relativi alle attività MEV già individuate dal FONDO, per ciascuna delle quali, nell’offerta tecnica, è richiesta una sintetica proposta progettuale che includa la composizione del gruppo di lavoro dedicato e la pianificazione delle attività, con particolare riferimento alle tempistiche di realizzazione.

5.1 - Progettazione e realizzazione del modulo CIA

Il modulo è destinato alla gestione dei piani formativi a valere sui Conti Individuali Aziendali: consente di gestire le fasi di presentazione del formulario da parte delle aziende e di monitoraggio dell’attività formativa.

Requisiti primari sono l’integrazione nella piattaforma ACRF - per la parte di back-end - e nella PGA - per il front-end - con le quali condividerà e utilizzerà parte dei dati gestiti (ad esempio i dati anagrafici delle aziende aderenti e le disponibilità dei singoli conti).

Elenchiamo di seguito le principali aree funzionali:

• Gestione degli utenti e delle credenziali d’accesso ai conti;

• Gestione delle anagrafiche relative i rappresentanti legali e i responsabili dei piani;

• Presentazione dei piani formativi: area destinata ai soggetti presentatori, che, accedendo via web (PGA), compilano il formulario di presentazione.

• Ammissibilità: area destinata all’ammissibilità dei piani presentati.

• Valutazione: area destinata alla valutazione dei piani presentati.

• Monitoraggio Fisico: area destinata al monitoraggio delle attività formative durante la loro esecuzione.

• Monitoraggio Finanziario: area destinata alla gestione della ripartizione delle spese sostenute e all’acquisizione della relativa documentazione (es: documentazione relativa ai pagamenti).

• Disponibilità conto: area destinata agli utenti esterni per la visualizzazione dettagliata della situazione finanziaria del proprio conto.

• Report: dovranno essere previsti una serie di report ad esempio Quadro sinottico formulario, Quadro sinottico monitoraggio, Stato avanzamento lavori, Ore di didattica erogate, Elenco dei lavoratori formati, Elenco dei lavoratori non formati.

È inoltre richiesta l’interoperabilità con il sistema documentale: le procedure sopra descritte, e, in particolare quelle relative la presentazione e il monitoraggio, dovranno prevedere l’interfacciamento con Arxivar per la protocollazione della relativa documentazione.

5.2 Realizzazione di una piattaforma di Business Intelligence per l’analisi dei dati.

Le funzionalità di Business Intelligence devono consentire di definire e produrre report statistici relativi all’andamento del Fondo e finalizzati ad analizzarne le varie attività svolte nel corso delle sue operazioni. I dati devono essere visualizzati nella modalità preferita sia sotto forma di tabelle che di grafici (tipi standard: a barre, torta, ecc.), con possibilità di scelta tra rappresentazioni 2D o 3D. I dati cui fare riferimento sono quelli che caratterizzano le principali attività del Fondo. Per esempio:

• avvisi messi a bando

• piani gestiti

• ore di formazione

• ispezioni effettuate

• importi erogati

L’analisi deve poter essere articolata con riferimento a:

• avvisi

• piani formativi

• soggetti finanziati

• attuatori

• imprese aderenti

• settori merceologici

• territorialità

• discenti

• caratteristiche della formazione erogata

Le voci elencate sono indicative. Le informazioni trattate, la loro sintesi e articolazione, gli indicatori e quant’altro si rende necessario dovranno essere concordati in fase di analisi con il Fondo.

Sulla base delle informazioni presenti il sistema dovrà fornire indicatori, che potranno essere semplici (come lo scostamento tra erogazioni preventivate ed erogazioni consuntivate) oppure complessi.

Al fine di supportare le attività di questa funzionalità il sistema dovrà permette l’utilizzo di strumenti di:

• ETL (extract, transform and load) per estrarre e adattare opportunamente i dati provenienti da sorgenti eterogenee (es. base di dati, fogli excel ecc.) e presentarli in formato adeguato per l’integrazione nei report.

• Analisi dei dati (Metadata Modeling), per la realizzazione delle tabelle navigabili d’interesse (es. per avviso/anno di esercizio/territorio/comparto, per finanziamento erogati/disponibili).

• Reports basati su template definibili attraverso meccanismi grafici interattivi: dal dato sintetico dovrà essere possibile entrare nel dettaglio con effetto zooming.

Il sistema consentirà a ogni utente (ciascuno per le proprie competenze ed in base al profilo a cui appartiene) di costruire autonomamente interrogazioni sul database, di effettuare interrogazioni già predisposte e prestabilite in fase di analisi.

Oltre all’analisi dei dati effettivi, il sistema dovrà essere in grado di produrre proiezioni preventive e trend (per esempio importi da erogare al termine di tutti i piani in base alle informazioni presenti in fase di presentazione).

Vari processi legati al Fondo prevedono l’utilizzo di report statistici al fine di monitorare l’operatività dello stesso ed eventualmente definire azioni di rimodulazione dell’offerta. Dovrà essere possibile esportare i report in formato PDF o in formato Microsoft Excel.

È apprezzato il fatto che l’Affidatario fornisca, nell’offerta tecnica, uno schema (anche ad elevato livello di astrazione) del modello multidimensionale dei dati che supporta la Business Intelligence richiesta.

5.3 Realizzazione del sito web istituzionale del FONDO

La realizzazione del sito web del FONDO dovrà fornire un prodotto che, oltre ad offrire le stesse funzionalità e a preservare gli stessi contenuti della corrente implementazione, soddisfi i seguenti requisiti:

• Garantire semplicità di utilizzo, autonomia nella modifica e nell’inserimento dei contenuti da parte del personale del FONDO. Tali contenuti potranno essere anche di tipo multimediale quali video e gallerie di immagini;

• Assicurare la possibilità di attivare facilmente e in maniera autonoma funzionalità utili a promuovere eventi e iniziative (ad esempio splash screen iniziali sulla home-page, notifiche automatiche su tutte o alcune pagine);

• Mantenere un’impostazione grafica semplice, pulita e seguire le raccomandazioni e gli standard di usabilità;

• Adottare un design responsivo, gestire l’accesso anche da parte di dispositivi mobile al fine di agevolare la fruizione delle informazioni;

• Ottimizzare il posizionamento SEO al fine di migliorare l’indicizzazione dei contenuti nei motori di ricerca;

• Essere predisposto all’integrazione con eventuali canali social attivati dal FONDO (Facebook, Twitter, Google+, …);

• Utilizzare un servizio di monitoraggio degli accessi e dei comportamenti (ex. Google Analytics…);

• Consentire la protezione dei contenuti e la definizione di politiche di accesso per ruolo in modo da creare aree con contenuti riservati solo ad un determinato tipo di utenze;

• Rispettare la normativa sull’utilizzo dei cookie e più in generale il nuovo Regolamento UE sulla privacy (GDPR).

• Prevedere la gestione di un’area dedicata alla pubblicazione, in maniera strutturata, di dati, documenti e informazioni coerentemente con le linee guida definite dall’ANAC in tema di “Amministrazione Trasparente”;

È preferibile l’utilizzo di un sistema CMS non proprietario.

5.4 Altre attività di sviluppo

Vengono di seguito elencate altre aree di intervento individuate dal FONDO che dovranno essere oggetto della fornitura:

• Ottimizzare l’utilizzo, all’interno dell’intero sistema informativo, della piattaforma documentale Arxivar:

o Utilizzando le interfacce di programmazione del sistema documentale è possibile effettuare la profilazione, in classi documentali ben definite, dei documenti prodotti e/o gestiti dalle procedure eseguite sulle diverse piattaforme, consentendo così la protocollazione automatica dei documenti;

o Sfruttare le funzionalità di gestione della Firma Digitale;

o Trasferire in Arxivar i documenti attualmente gestiti in Sharepoint;

o Utilizzare le funzionalità di barcode recognition per automatizzare l’acquisizione di quei documenti per i quali è richiesta l’apposizione di una firma; un possibile flusso di esempio:

⮚ l’applicazione che genera il documento può assegnargli un codice e stamparlo in un’area dello stesso codificandolo con un barcode;

⮚ contemporaneamente può richiedere ad Arxivar di “prenotare” una profilazione per il suddetto codice fornendo tutti i parametri utili alla corretta classificazione;

⮚ una volta che il documento è stato stampato e firmato, può essere scansionato;

⮚ riconoscendo il barcode apposto, un servizio dedicato di Xxxxxxx profila il documento firmato secondo i parametri di profilazione precedentemente impostati;

• Al fine di ottimizzare le attività dell’area “Amministrazione” del FONDO è richiesto di interfacciare la piattaforma ACRF con il software di contabilità (GAMMA ENTERPRISE prodotto da Team System). In particolare è richiesto:

o il trasferimento automatico dei dati finanziari relativi i piani formativi (importo approvato e riconosciuto), con i relativi dati anagrafici delle aziende beneficiarie;

o il trasferimento dei dati relativi le “Lettere di Accredito” pervenute dall’INPS;

• Implementare una soluzione, alternativa agli attuali registri cartacei utilizzati presso le sedi di formazione, per ottimizzare il monitoraggio delle presenze dei partecipanti alle attività formative;

• Con riferimento alla piattaforma PGA, è richiesta l’implementazione di una sezione dedicata alla gestione delle attestazioni rilasciate ai partecipanti alle attività formative; la sezione dovrà prevedere, per ogni avviso, la possibilità di caricare, archiviare e protocollare i singoli attestati trasferendoli automaticamente nel sistema documentale in uso al FONDO.

• Prevedere procedure di storicizzazione periodica dei dati più vecchi in modo da aumentare le performance del sistema e migliorare la percezione di efficienza da parte dell’utente.

• Consentire la consultazione dei dati relativi agli avvisi gestiti con le precedenti piattaforme, oggi dismesse e il cui utilizzo è limitato alla sola consultazione dei dati.

In generale, nell’ottica descritta nell’introduzione di questo capitolo, sono apprezzati suggerimenti relativi l’evoluzione del sistema informativo e sono ammesse proposte ben dettagliate di nuove soluzioni e funzionalità.

6. SERVIZI E MODALITA DI ESECUZIONE

6.1 Servizio di Sviluppo Software e Manutenzione Evolutiva

Il servizio MEV è attivato quando si verifica la necessità di intervenire sul patrimonio applicativo con interventi di manutenzione evolutiva che modificano sostanzialmente il patrimonio software del FONDO. Comprende le azioni inerenti interventi di revisione, finalizzati a migliorare il valore o la prestazione di un sistema o di una parte di esso. L'azione manutentiva è programmabile e subordinata alle esigenze di miglioramento espresse dal FONDO, eventualmente anche su proposta del Fornitore.

Con riferimento alle attività MEV, è richiesta la redazione di un “Piano di sviluppo” e un “Piano della qualità” che costituiranno parte integrante dell’offerta tecnica. I suddetti documenti dovranno contenere una descrizione dettagliata delle metodologie di sviluppo adottate, con particolare riferimento a:

• gestione complessiva del ciclo di vita del software;

• metodologie e strumenti adottati per garantire la qualità del software rilasciato

• processo di certificazione, test e passaggio in produzione del software;

• descrizione quantitativa e qualitativa (curricula) delle figure professionali coinvolte

• metodi di misurazione degli interventi

• proposte migliorative dei livelli di servizio.

Le attività, svolte su richiesta del FONDO, saranno raggruppate in progetti e, per ciascuno di essi, andrà realizzato un ciclo completo di sviluppo in conformità alle linee guida definite più avanti.

La metrica utilizzata per definire le attività svolte, per ciascun progetto, dovrà essere espressa in giorni- uomo, documentando la previsione con un dettagliato piano di lavoro che descriva le attività (task) necessarie e le figure professionali impegnate con il relativo effort.

Nell'ambito del servizio MEV si possono individuare i seguenti sottoservizi:

• analisi, progettazione, implementazione, testing e development di nuove funzionalità e/o moduli applicativi;

• analisi, progettazione, implementazione, testing e development per la modifica di funzionalità già esistenti;

• formazione del personale del FONDO sulle nuove funzionalità e sulle modifiche;

• documentazione tecnica di progetto e manualistica d’utente.

Gli interventi di manutenzione evolutiva di dimensione inferiore o uguale a 2 GGU (giorni-uomo) rientrano nel servizio di manutenzione adeguativa e correttiva (MAC) e non in quello MEV.

La discriminazione tra un intervento di manutenzione evolutiva e un intervento di natura adattativa verrà fatta dal FONDO, congiuntamente con il Fornitore, secondo regole di correttezza, buona fede e ragionevolezza tecnica e, in nessun caso, l’onerosità della soluzione potrà essere valutata quale discriminante. Il servizio che non porta miglioramenti funzionali, in cui le funzionalità non sono incrementate ma equiparate alle precedenti, pur con miglioramenti prestazionali, non può essere compreso in ambito MEV.

I servizi realizzativi dovranno assicurare il supporto al collaudo, la migrazione dei dati e il supporto all'avvio in esercizio del software realizzato, nonché il supporto all'esecuzione dei test proceduralizzati e automatizzati. Dovranno essere, dunque, ricomprese senza oneri aggiuntivi nei servizi realizzativi le attività indicate al capitolo 15.

I cicli di sviluppo e il profilo di qualità, sicurezza e riservatezza del software e delle informazioni, espresse secondo le caratteristiche indicate dalle norme ISO relative alla qualità del prodotto software (ISO/9126 o ISO/25000) e alle norme che regolano gli aspetti di sicurezza e riservatezza, dovranno essere documentate nel piano della qualità generale della fornitura.

I servizi di cui sopra dovranno prevedere l’intero ciclo di sviluppo (analisi, implementazione, testing, deployment, collaudo, manutenzione, formazione e documentazione) secondo quanto indicato nei successivi paragrafi.

Per la realizzazione del servizio l’Affidatario dovrà utilizzare un proprio ambiente di sviluppo e di testing conforme all’architettura di esercizio dell’applicazione (anche mediante meccanismi di virtualizzazione delle risorse).

6.1.1 Processo di sviluppo

L’Affidatario deve predisporre un processo di sviluppo software che, dovrà contemplare tutte le attività previste nel ciclo di vita del software conformemente a quanto previsto dalla norma ISO/IEC 12207 information technology – software life cycle processes.

Tale processo, pertanto, deve includere le attività di seguito descritte; queste possono sovrapporsi, essere applicate in modo iterativo o in modo differente a seconda del software sviluppato, e non devono necessariamente essere eseguite nell'ordine in cui sono presentate.

Le effettive modalità di realizzazione delle stesse possono, ovviamente, essere scelte dall’Affidatario in base al proprio know-how, al proprio sistema qualità e metodologie di lavoro, ai tool di condivisione degli stati di avanzamento e relativi esiti messi a disposizione dei referenti del FONDO, purché venga garantita l'esecuzione di tutte le attività di interesse del FONDO ed il raggiungimento degli obiettivi indicati.

Organizzazione, pianificazione e supervisione del progetto.

L’Affidatario deve eseguire attività di pianificazione e supervisione per:

• Sviluppo Software

• Test funzionale e di integrazione

• System test

• Installazione del Software

Predisposizione dell’ambiente di sviluppo

L’Affidatario deve predisporre gli ambienti necessari per lo sviluppo e la manutenzione dei prodotti software, garantendone l'adeguatezza, la funzionalità e l'affidabilità necessarie allo scopo riguardo a:

• Software engineering

• Software test

• Gestione della configurazione

Analisi dei requisiti del sistema

L’Affidatario deve eseguire l'analisi dei requisiti (implici ed espliciti, cfr. ISO/IEC 8402:1995) del sistema in conformità con le procedure e le metodologie del proprio Piano di qualità. È richiesto all’Affidatario di utilizzare strumenti informatici di supporto (ad es. CASE tools), che, tra l’altro, consentano di mantenere la tracciabilità tra i requisiti formalizzati ed i casi di test progettati, facilitando così la verifica della piena aderenza delle funzionalità sviluppate ai requisiti. La tracciabilità dei requisiti deve inoltre consentire la piena visibilità degli impatti che eventuali modifiche ai requisiti possono comportare allo sviluppo del sistema. In questa fase dovrà e essere prodotta una prima stima dell’effort richiesto.

Progettazione del sistema

L’Affidatario deve eseguire la progettazione del sistema in conformità con le procedure e le metodologie del proprio Piano di qualità. In questa fase dovrà essere aggiornata la stima dell’effort e dovrà essere realizzato il prototipo delle interfacce.

Realizzazione e Unit Test del software

L’Affidatario deve eseguire test specifici su ogni unità di software realizzata. L’Affidatario deve effettuare tutte le necessarie modifiche al software e rieseguire tutti i test necessari in base ai risultati del test.

Test funzionali e di Integrazione

L’Affidatario deve predisporre opportuni casi di test (in termini di input, risultati attesi e criteri di valutazione), procedure e dati per l'effettuazione di test funzionali e di integrazione. I casi di test devono coprire tutti gli aspetti funzionali e qualitativi considerati nella progettazione del software. L’Affidatario deve eseguire i test funzionali e di integrazione in modo conforme a quanto stabilito dai casi di test e dalle relative procedure. L’Affidatario deve effettuare le modifiche al software e rieseguire tutti i test necessari in base ai risultati del test. L’Affidatario deve registrare e analizzare i risultati dei test e le anomalie eventualmente riscontrate.

Test di sistema (collaudo)

Per la pianificazione ed esecuzione del collaudo l’Affidatario deve conformarsi a quanto indicato nella Procedura di collaudo descritta nel capitolo 15.

Installazione software

L’Affidatario deve preparare il software eseguibile, inclusi i file batch, di comandi, di dati ogni altro oggetto necessario per installare e far funzionare il sistema nell'ambiente operativo previsto. L’Affidatario deve identificare e registrare la versione esatta del software predisposto per ogni ambiente operativo. Deve inoltre predisporre i manuali utente e operativi. L’Affidatario deve installare e controllare il software eseguibile sulle macchine destinatarie secondo quanto concordato caso per caso con il FONDO interfacciandosi e fornendo supporto ai servizi di gestione operativa sia condotti dall’Affidatario stesso che da altri Fornitori. L’installazione avverrà preliminarmente nell’ambiente di Test (tale ambiente riproduce quello di esercizio) e successivamente, dopo l’eventuale periodo di pre-esercizio e ad esplicita richiesta del FONDO, nell’ambiente finale di esercizio con, eventuali interruzioni programmate al di fuori del normale orario di lavoro.

Gestione della manutenzione Software

L’Affidatario deve identificare le entità da mettere sotto controllo di configurazione e deve assegnare a ciascuna una codifica univoca, deve predisporre e implementare procedure per individuare i livelli di controllo per ciascuna entità in configurazione (ad esempio controllo dell'autore, del capo progetto, del cliente); le persone o i gruppi con l'autorità per autorizzare e effettuare modifiche ad ogni livello, passi da

seguire per richiedere l'autorizzazione per modifiche, elaborare richieste di modifica, tracciare e distribuire le modifiche e mantenere le precedenti versioni del software.

Devono essere mantenute le registrazioni dello stato della configurazione di tutte le entità poste sotto controllo. Queste registrazioni devono essere mantenute per tutta la durata del contratto e devono contenere, a seconda dei casi, la corrente versione di ogni entità, informazioni su tutte le modifiche che hanno subito da quando sono state inserite sotto controllo di configurazione e sullo stato in cui si trovano.

Assicurazione sulla qualità del software

L’Affidatario deve effettuare, in modo continuativo, verifiche sulle attività di sviluppo software e sui prodotti risultanti da queste, al fine di:

• assicurare che ogni attività sia stata eseguita in conformità con il contratto e con le procedure previste nel Piano della qualità;

• assicurare che ogni prodotto software sia stato sottoposto a verifiche, test e azioni correttive necessarie

L’Affidatario deve effettuare registrazioni di tutte le attività di assicurazione qualità svolte e deve conservarle per tutta la durata del contratto.

Azioni correttive

L’Affidatario deve produrre un rapporto di rilevazione anomalia ogni qualvolta siano rilevati problemi concernenti i prodotti software e le loro componenti poste sotto controllo di configurazione, e svolgere le attività richieste dal FONDO o descritte nel Piano della qualità.

Tali rapporti devono descrivere il problema, le azioni correttive richieste e quelle svolte alla data.

6.1.2 Linee Guida per le attività di sviluppo e documentazione

L’Affidatario deve utilizzare, per tutte le attività di sviluppo software, metodologie documentate, sistematiche ed efficaci. Queste metodologie devono essere descritte nel "Piano di Sviluppo software e MEV".

L’Affidatario deve prevedere tutte le attività necessarie a presidiare il rilascio di nuove componenti o di aggiornamenti di componenti già distribuite in produzione, secondo controlli e verifiche di coerenza con l’architettura del Sistema. La necessità di adottare nuove componenti architetturali o di aggiornare elementi già in produzione dovrà essere evidenziata nelle fasi di analisi del prodotto e sottoposta ad esplicita approvazione da parte del FONDO.

Per la realizzazione del presente servizio l’Affidatario dovrà garantire l’impiego di figure professionali adeguate in termini di competenze e numerosità per la realizzazione delle attività progettuali (Curricula) come indicato al successivo capitolo 7.

Come precedentemente indicato, le attività di sviluppo, svolte su richiesta del FONDO, saranno raggruppate in progetti e per ognuno di essi andrà realizzato un ciclo completo di sviluppo in conformità alle presenti linee guida.

L’esecuzione delle attività previste per il singolo progetto è espressamente subordinata alla approvazione da parte del FONDO del documento di progettazione esecutiva contenente la pianificazione ed il dettaglio delle attività e delle risorse impegnate predisposto dall’affidatario sulla base delle specifiche indicate dal FONDO.

Pertanto, in caso di mancata approvazione dei documenti di pianificazione e dettaglio da parte del FONDO, l’affidatario non avrà nulla a pretendere per lo svolgimento delle attività necessarie alla loro elaborazione e

non si darà luogo alla realizzazione delle attività ivi previste. Qualsiasi modifica del documento di progettazione esecutiva approvato, anche in riferimento ai componenti del gruppo di lavoro previsto, deve essere preventivamente autorizzata dal FONDO.

Il flusso di Analisi viene svolto principalmente nelle fasi di evoluzione dell’Architettura e di evoluzione delle Funzionalità, e mira a definire in modo completo ed esaustivo la struttura generale del sistema (fuoco dell’analisi nella fase di Architettura) e le funzioni da realizzare e/o modificare (fuoco dell’analisi nella fase di Funzionalità), con riferimento ai processi individuati e alle modalità con cui tali processi risulteranno visibili all'utente.

Le attività svolte all’interno di questo flusso portano a:

• descrivere formalmente l'applicazione e/o le funzioni da sviluppare in termini di esigenze funzionali dell'utenza e di esigenze non funzionali, in modo chiaro, esaustivo e sistematizzato, compresa la descrizione logica delle interconnessioni con altri sistemi/applicazioni/apparati/aree applicative;

• dove necessario, predisporre un documento di mappatura fra il prodotto del ridisegno dei processi e i requisiti dell'applicazione;

• individuare la soluzione applicativa e tecnologica adeguata al soddisfacimento delle esigenze funzionali di cui sopra, con particolare attenzione a facilitarne la comprensione da parte delle strutture tecniche, applicative ed amministrative;

• validare e dettagliare la pianificazione e la stima dello sforzo motivando eventuali scostamenti;

• progettare il piano di test con particolare attenzione all'individuazione delle tipologie di test (es. stress test, test accessibilità, ecc.), dei criteri di scelta dei test da automatizzare, l'individuazione della base dati necessaria per il test, eventuali criticità note;

• individuare i rischi di progetto e definire le opportune azioni correttive;

• realizzare i documenti di progetto e d’utente indicati come prodotti dell’attività aggiornare, in caso di modifiche intercorse, precedenti versioni di prodotti;

• produrre la progettazione esecutiva del progetto.

Qualora tecnicamente e funzionalmente possibile, le specifiche funzionali dovranno essere corredate dalla realizzazione di un prototipo che rappresenti almeno le modalità di navigazione e il layout delle interfacce.

Le attività di Disegno ovviamente, hanno come prerequisito la descrizione delle relative specifiche funzionali. Il Disegno traduce le caratteristiche della soluzione in specifiche tecniche di dettaglio necessarie alla generazione dei prodotti finali.

Gli obiettivi principali dell’attività disegno sono:

• descrivere ogni elemento da realizzare, le modalità di integrazione con gli altri elementi, i vincoli e i controlli cui devono essere sottoposti gli elementi;

• descrivere tutti i dati trattati raggruppati per insiemi logici (schema logico e fisico dei dati), e rappresentare il mapping con lo schema concettuale;

• dettagliare le modalità di interconnessione con altri sistemi / applicazioni /aree applicative / apparati;

• progettare i test;

• validare e dettagliare la pianificazione motivando eventuali scostamenti;

• aggiornare, in caso di modifiche intercorse, precedenti versioni di prodotti.

Le attività di realizzazione sono finalizzate a generare i componenti software e la base dati che realizzano il sistema, verificando inoltre la loro correttezza e funzionalità. I componenti dovranno essere realizzati coerentemente con il disegno di dettaglio.

Per quanto riguarda gli aspetti inerenti all’Architettura, la realizzazione garantirà che le diverse componenti dell’architettura possano comunicare correttamente e soddisfino i requisiti non funzionali per il sistema complessivo. Per quanto attiene alle Funzionalità, la realizzazione dovrà garantire la soddisfazione dei requisiti utente, anche per aspetti non funzionali, quali usabilità, accessibilità, disponibilità, ecc.

L’attività prevede tra l’altro di:

• effettuare l'implementazione del sistema, producendo il codice sorgente;

• eseguire i test;

• consegnare alla gestione della configurazione i componenti realizzati e la relativa documentazione;

• aggiornare, in caso di modifiche intercorse, precedenti versioni di prodotti;

• realizzare un prototipo funzionante per consentire una fase di pre-esercizio di durata concordata (di norma 30-60 giorni solari) ed a richiesta del FONDO, che rappresenterà parte integrante delle attività di collaudo.

6.1.3 Documentazione

In tutti i cicli di vita si rende necessaria la creazione e/o l'aggiornamento dei documenti di progetto. Il flusso di documentazione si svolge in continuità lungo tutte le fasi, venendo finalizzato durante la fase di messa in opera mediante una standardizzazione di quanto prodotto nelle fasi precedenti per produrre i documenti ufficiali finali del progetto.

Nell’offerta tecnica dovrà essere dettagliatamente descritte le modalità di documentazione proposte dal fornitore, in accordo alle presenti indicazioni in un apposito “Piano della documentazione di progetto”.

6.1.4 Avvio in esercizio

Il flusso di avvio in esercizio e/o in pre-esercizio inizia a partire dall’accettazione del sistema da parte del Direttore dell’esecuzione del FONDO e si occupa di predisporre l’ambiente di esercizio, di effettuare la migrazione del software e dei dati dall’attuale al software sviluppato o reingegnerizzato, di monitorare il software realizzato e/o modificato dall'obiettivo per poterne verificare l'affidabilità nei primi tre mesi di esercizio e o pre-esercizio o in altro periodo definito nella “Progettazione esecutiva” del progetto approvato. Nel corso di tale fase il Fornitore dovrà garantire adeguato supporto al Direttore dell’esecuzione. La durata del flusso sarà definita nella “Progettazione esecutiva” del progetto; esso si conclude con la consegna del rapporto delle metriche aggiornato con l'indicatore che rileva la difettosità delle funzioni utente interessate dall'obiettivo e la valutazione della qualità del software in esercizio.

6.1.5 Standard per i prodotti software

L’Affidatario dovrà garantire che tutte le attività di sviluppo software siano effettuate rispettando i seguenti standard generali che dovranno essere documentati da opportune linee guida:

• Standard di programmazione che dovrà dare, tra le altre cose, regole precise per la scrittura e documentazione dei moduli software realizzati e modificati, anche in merito al rispetto di specifiche e opportune metriche statiche. Quando applicabile, gli standard dovranno fare riferimento anche a standard già esistenti in letteratura per linguaggi specifici.

• Standard di interfaccia utente (orientati all’usabilità, accessibilità, ecc.). Quando applicabile, gli standard dovranno fare riferimento anche a standard già esistenti in letteratura per linguaggi/ambienti specifici.

• Standard di nomenclatura degli item software.

• Standard di documentazione tecnica del software applicativo.

I requisiti, di cui al precedente elenco, dovranno trovare riscontro anche nel Piano di Qualità predisposto dall’Affidatario nel quale dovranno essere previste adeguate verifiche in corso d’opera che assicurino la qualità di quanto fornito. I documenti prodotti all'inizio delle attività dovranno essere tenuti aggiornati per tutta la durata del contratto sia per l'attivazione di nuovi ambienti applicativi, sia per variazioni nelle Tecnologie.

Tale servizio deve essere svolto nel rispetto del Decreto Legislativo n.196 del 30 giugno 2003 Testo Unico – Codice Privacy ed in particolare di quanto indicato nell’Allegato B a suddetto codice e relativo alle misure di sicurezza. Il servizio dovrà essere adeguato, al momento della sua entrata in vigore, al REGOLAMENTO (UE) 2016/679 ed alle eventuali normative o regolamenti nazionali che dovessero essere emanati.

6.1.6 Accesso per ispezioni di Fondo For.Te.

L’Affidatario deve consentire l’accesso, da parte del FONDO o a personale da questa espressamente autorizzato, al sistema di gestione, monitoraggio e controllo del servizio utilizzato dall’Affidatario.

6.1.7 Accettazione dei prodotti sviluppati

L'accettazione dei prodotti da parte del FONDO. avverrà al positivo completamento dell'esecuzione delle attività di collaudo per la cui esecuzione l’Affidatario si deve conformare a quanto previsto per la procedura di Collaudo descritta al capitolo 15.

6.2 – Servizio di Manutenzione Adeguativa e Correttiva

Il servizio qui descritto si applica all’intero patrimonio software applicativo compreso quello sviluppato precedentemente al contratto e ad ogni sua successiva modificazione dovuta alle attività svolte per questo e per qualsiasi altro servizio del contratto, senza che ciò comporti, per questo servizio, alcuna variazione nel corrispettivo economico riconosciuto all’Affidatario che si considera invariabile e omnicomprensivo.

La manutenzione correttiva ha la finalità di mantenere le piattaforme costantemente funzionanti rimuovendo le cause di malfunzionamento connesse a bug informatici: prevede quindi la diagnosi e la rimozione delle cause e degli effetti, sia sulle interfacce utente sia sulle basi dati, dei malfunzionamenti delle procedure e dei programmi in esercizio.

La manutenzione adeguativa comprende le attività di manutenzione volte ad assicurare la costante aderenza delle procedure e dei programmi alla evoluzione dell’ambiente tecnologico del sistema informativo ed al cambiamento dei requisiti (organizzativi, normativi, d’ambiente).

Il servizio è normalmente attivato attraverso una segnalazione di impedimento all’esecuzione dell’applicazione/funzione o dal riscontro di differenze fra l’effettivo funzionamento del software applicativo e quello atteso, come previsto dalla relativa documentazione o comunque determinato dai controlli che vengono svolti durante l’attività dell’utente, è teso alla risoluzione dei difetti presenti nel codice sorgente, o nelle specifiche di formato o di base dati, non rilevati a suo tempo durante il ciclo di sviluppo o il collaudo.

Le attività seguono quindi una modalità di erogazione di tipo ad evento e non hanno una suddivisione in fasi, né è possibile prevedere a priori prodotti specifici. Sono caratterizzate da una non continuità tra una richiesta e la successiva e non sono sempre pianificabili.

Nell’ambito del servizio rientrano gli interventi che tipicamente non variano la consistenza del parco applicativo quali:

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

• adeguamenti necessari per innalzamento di versioni del software di base;

• adeguamenti intesi all’introduzione di nuovi prodotti o modalità di gestione del sistema;

• migrazioni di piattaforma;

• modifiche, anche massive, non a carattere funzionale, alle applicazioni.

Rientrano inoltre nel servizio anche gli interventi di assistenza al personale del FONDO svolti da parte di risorse professionali del Fornitore; sono comprese nell’ambito di questo servizio le seguenti attività indicate a titolo esemplificativo e non esaustivo:

• supporto all’avviamento in esercizio (training on the job, etc.);

• assistenza durante il periodo iniziale di esercizio delle applicazioni;

• assistenza operativa agli utenti per l’uso appropriato delle funzioni secondo le modalità previste nei manuali d’uso o help on line;

• assistenza specialistica agli utenti su tematiche funzionali/amministrative per la risoluzione di problemi;

• assistenza nell’ interpretazione delle norme d’uso, attivando se necessario i progettisti del sistema o gli esperti sulla tematica;

• supporto specialistico all’assistenza per le applicazioni in esercizio.

Le attività di manutenzione correttiva, svolte in periodo di validità della garanzia, sono da intendersi a totale carico del Fornitore, compresi gli interventi di aggiornamento e di allineamento della documentazione e delle componenti a corredo impattate dall’intervento. In tutti i casi, la garanzia deve comprendere almeno l’intervento on site e la manodopera.

Nel dimensionamento del servizio l’Affidatario dovrà prevedere:

• la predisposizione mensile di reports statistici finalizzati ad evidenziare:

o l'elenco delle inoperatività/malfunzionamenti riscontrati;

o la rilevazione analitica dell'attività di manutenzione effettuata (sia ordinaria che straordinaria), con l'evidenza dei tempi di intervento e di ripristino dei malfunzionamenti;

o l'esecuzione periodica degli interventi di manutenzione ordinaria riguardanti tutte le componenti del sistema precedentemente elencate;

• la predisposizione mensile, di "note evolutive" attraverso le quali dovranno essere illustrati gli interventi da apportare al software applicativo ed alle eventuali espansioni hardware che allo scopo si ritenessero necessarie.

• l'esecuzione degli interventi di manutenzione straordinaria, da attivarsi a seguito di richieste utente ricevute e gestite dal sistema di Help-Desk

Il servizio dovrà essere espletato in accordo con un "Piano di Manutenzione adeguativa e correttiva" da prodursi come parte integrante dell'offerta tecnica fornendo i relativi curricula professionali, il numero di risorse professionali che compongono il team dedicato, fermo restando che tali risorse possono essere impiegate in tutto o in parte in relazione alle esigenze di manutenzione ed alla pianificazione condivisa con il FONDO.

Il "Piano di Manutenzione adeguativa e correttiva" deve contenere almeno:

• la descrizione delle attività di manutenzione ordinaria, con l'indicazione analitica delle operazioni previste per ciascuna delle componenti indicate e della periodicità di esecuzione di tali operazioni;

• la descrizione delle modalità di gestione delle chiamate di assistenza per interventi di manutenzione straordinaria, nonché gli accorgimenti che l’Affidatario intende adottare per garantire i livelli di servizio indicati nel prosieguo del presente Capitolato;

• la struttura dei reports statistici finalizzati a facilitare il controllo e la verifica, da parte del FONDO, delle attività svolte dall’Affidatario nonché dei livelli di servizio erogati dal sistema;

• i livelli di servizio offerti

Nel dimensionare il servizio, l’offerente deve tener conto dell’esigenza, in occasione di ben determinati eventi durante l’anno, di supportare un numero elevato di accessi contemporanei (oltre 1000) via web : ciò è particolarmente importante per alcuni avvisi (ad esempio voucher) per i quali, il giorno della scadenza (“click day”), gli utenti devono inviare contemporaneamente le domande.

Nel "Piano di Manutenzione correttiva" devono essere altresì illustrate le modalità di svolgimento dell’affiancamento per subentro, per una durata non inferiore a due mesi, alla conclusione del contratto stipulato con la presente procedura.

Il servizio deve essere svolto nel rispetto del Decreto Legislativo n.196 del 30 giugno 2003 Testo Unico – Codice Privacy e, in particolare, di quanto indicato nell’Allegato B a suddetto codice e relativo alle misure di sicurezza. Il servizio dovrà essere adeguato, al momento della sua entrata in vigore, al REGOLAMENTO (UE) 2016/679 ed alle eventuali normative o regolamenti nazionali che dovessero essere emanati.

6.3 Servizio di Help-Desk

Il sistema di Help Desk richiesto è destinato esclusivamente al supporto tecnico ed è rivolto sia agli utenti esterni (imprese aderenti, soggetti proponenti, soggetti attuatori, ecc.) sia al personale del FONDO per la segnalazione di anomalie e la richiesta di interventi correttivi.

Il sistema dovrà utilizzare un Customer Relationship Manager (CRM) costituito da un software gestionale predisposto per la registrazione degli eventi di contatto (ticket e email) e la costruzione di un database con le domande e le risposte più frequenti al fine di fornire all'operatore le informazioni necessarie per la gestione dell'interazione.

Al fine di razionalizzare l’utilizzo del servizio è fondamentale adottare strategie utili a formare ed informare preventivamente gli utenti sulle funzionalità delle procedure realizzate, in particolare:

• integrare nei prodotti adeguata manualistica che deve essere facilmente accessibile;

• creare un’area di FAQ in cui l’utente può autonomamente trovare risposte e soluzioni alle domande più frequenti;

• includere materiale formativo, anche multimediale (video, tutorioal, slides…), che descriva in maniera esaustiva le funzionalità dei prodotti;

Le modalità di accesso al servizio help desk sono:

• invio di richiesta di assistenza tramite email generata da form presente su un sistema di ticketing;

• account mail dedicato (es: xxxxxxxxxxxxxxx@XXXX.xx);

Il servizio deve essere configurato (risorse umane, tecniche e tecnologiche) secondo le normative vigenti in materia di lavoro e sicurezza. Con riferimento al punto 6.4 della UNI EN 15838:201O, devono essere previsti backup periodici delle informazioni raccolte, per il ripristino in caso di guasti o malfunzionamenti della strumentazione di supporto.

6.3.1 Assistenza via email/Ticketing agli utenti tramite form dedicato

Il servizio di assistenza email deve prevedere l'utilizzo della funzione "Richiedi assistenza", e consiste in un modulo web tramite il quale formulare la richiesta di assistenza. L'utente potrà inviare informazioni relative a: tipologia assistenza (assistenza all'uso delle procedure o segnalazione di malfunzionamenti); dati del richiedente (nome, cognome, email personale, numero di telefono); problematica riscontrata.

Le mail generate dal modulo web saranno gestite attraverso il gestionale CRM, che consentirà:

• il collegamento per utente o per argomento/oggetto delle diverse email;

• la possibilità di inviare risposte direttamente dal CRM.

Gli elementi tracciati durante le assistenze saranno: ID, operatore e data/ora della presa in carico della richiesta di assistenza; tipologia di problematica segnalata; dati del richiedente; stato del ticket (ricevuto, preso in carico, sospeso, chiuso con invio risposta).

Nell’erogazione delle attività dovranno essere garantiti i seguenti livelli minimi di servizio:

• dal lunedì al venerdì, esclusi festivi, dalle ore 9 alle 18;

• Presa in carico della richiesta di assistenza entro 2 ore lavorative.

7 FIGURE PROFESSIONALI E GRUPPI DI LAVORO

7.1 Gruppi di lavoro

Per tutti i Servizi previsti dalla presente procedura e per i singoli progetti del Servizio di sviluppo e MEV dovranno essere impiegate figure professionali adeguate in termini di competenze e numerosità per la realizzazione delle attività progettuali. Tali figure devono far parte di gruppi di lavoro di cui l’Affidatario si impegna a fornire i profili professionali, documentati dai curricula da allegare all’offerta tecnica, con l’indicazione del numero di unità impiegate per ciascuno di essi.

Essendo opportuna la presenza continuativa dello stesso personale per tutta la durata della fornitura, le eventuali sostituzioni di personale durante l’esecuzione della medesima dovranno essere concordate preventivamente con il Direttore dell’esecuzione, dietro presentazione ed approvazione dei curricula, nel rispetto dei requisiti indicati per ciascuna figura professionale. La sostituzione richiederà un adeguato periodo di affiancamento per la risorsa entrante, il cui costo sarà interamente a carico dell’Affidatario.

Come parte integrante dell’offerta tecnica deve essere fornita, nel “Piano dell’organizzazione dei gruppi di lavoro”, contenente un’accurata descrizione dell’organizzazione delle risorse umane in relazione ai Servizi e ai singoli progetti del Servizio di sviluppo e MEV, corredata dai curricula delle risorse messe a disposizione.

Eventuali sostituzioni di risorse dovranno essere preventivamente autorizzate dal FONDO e comunque sostituite con profili professionali uguali o superiori.

7.2 Profili professionali richiesti

Le figure professionali necessarie per lo svolgimento dei Servizi applicativi dovranno aderire ai profili di seguito descritti. I curricula delle figure professionali da impiegare nei vari Servizi dovranno essere resi disponibili al Committente secondo quanto previsto dal capitolato e dal contratto, rispettando lo schema di CV Europeo. In ogni caso, dovranno essere particolarmente dettagliate le competenze, conoscenze, esperienze tecniche al fine di verificare la corrispondenza con il livello di approfondimento richiesto.

7.2.1 - REQUISITI GENERALI.

Di seguito si riporta un elenco non esaustivo delle competenze tecniche e le principali competenze trasversali e normative. Il livello di conoscenza per ogni figura professionale richiesta è riportato nelle relative schede che compaiono nei paragrafi successivi.

METODOLOGIA E TECNICHE:

• Analisi, Disegno e Programmazione ad Oggetti (OOA);

• Analisi, Disegno e Programmazione per Servizi (SOA);

• Analisi, Disegno e Progettazione Web;

• Testing del software prodotto (test unitari, test di integrazione e test di sistema) per garantire gli aspetti funzionali, qualitativi del codice, di efficienza (prestazione e carico), di accessibilità, di usabilità e di sicurezza.

TECNOLOGIE E STRUMENTI:

• Piattaforme e strumenti di sviluppo e testing del software;

• Sistemi di configuration e versioning di programmazione;

• DBMS relazionali;

• Piattaforma Microsoft;

• Piattaforma Linux;

• Strumenti di modellazione dati;

• Sistemi di Business Intelligence, OLAP e ROLAP, e processi ETL;

• Prodotti per analisi e statistiche e data mining;

• Sistemi Documentali;

• Web server e Application server;

• Sistemi di CMS;

• Prodotti di Office Automation;

• Prodotti di grafica e grafica Web;

• Tecnologie di virtualizzazione;

• Sistemi di cloud computing;

• Sistemi di Identity and Access Management;

• Strumenti di crittografia, firma digitale, firma digitale remota, firma elettronica, firma elettronica avanzata, marche temporali, e sicurezza.

LINGUAGGI ED AMBIENTI DI PROGRAMMAZIONE:

• PHP, Access, SQL, CGI, PERL, PLSQL

• ASP, XXX.XXX, XX.Xxx, C#;

• SQL Server, MySql;

• Html, CSS;

• XML / WSDL / WSS / XSLT;

• Javascript, Ajax, jQuery

• FileMaker, SharePoint

COMPETENZE TRASVERSALI:

• Conoscenza della disciplina IT Service Management in generale e dei framework ITIL;

• Tecniche e metodi di gestione e controllo dei progetti informatici;

• Conoscenza delle tecniche amministrativo-contabili.

7.2.2 - PIANO DI IMPIEGO DELLE FIGURE PROFESSIONALI

L’Affidatario dovrà garantire l’impiego di figure professionali adeguate in termini di competenze e numerosità. L’organigramma proposto dal concorrente dovrà comprendere necessariamente almeno una figura per ognuno dei seguenti profili professionali:

• Capo progetto

• Analista funzionale

• Programmatore senior

• Programmatore junior

• Sviluppatore web

Le conoscenze indicate nei prospetti delle diverse figure professionali devono essere presenti nel complesso delle risorse professionali richieste dal Committente sulle diverse attività e/o servizi e non in un’unica persona. Si precisa inoltre che:

• per cultura equivalente si considerano generalmente 5 anni aggiuntivi di esperienza professionale nell’ambito dei servizi applicativi di cui almeno 2 aggiuntivi nel ruolo specifico

• per laurea si intende la laurea specialistica/magistrale o quella vecchio ordinamento a ciclo unico (od equivalenti titoli, anche stranieri)

• in caso di laurea triennale, occorre considerare almeno 2 anni aggiuntivi di esperienza lavorativa

• le certificazioni, ove richieste, sono da intendersi in corso di validità alla data di presentazione dei profili professionali

• per tutti i profili professionali, è richiesta un’ottima conoscenza della lingua italiana e la conoscenza di strumenti di Office Automation

Si precisa che le risorse che saranno effettivamente poste a disposizione dovranno essere le medesime a cui si riferiscono i curricula proposti nell’Offerta Tecnica, salvo sopravvenute cause di forza maggiore, che dovranno essere tempestivamente comunicate.

Le prestazioni dovranno essere erogate da figure professionali competenti e formate in materia, esperte in ambito ICT, datacom e a livello applicativo. Nell’offerta tecnica è richiesto di indicare, se presente, la numerosità di personale certificato e i relativi dettagli sulle certificazioni.

Al fine di dimensionare la composizione delle risorse e la qualità del mix di profili, è richiesto di indicare nell’offerta tecnica la stima delle giornate di utilizzo, nel triennio, dei singoli profili professionali per ciascun servizio.

In particolare, con riferimento al Servizio di sviluppo e MEV, i gruppi di lavoro messi a disposizione dovranno essere complessivamente composti da un organico di almeno 10 persone ed è richiesto di rispettare i limiti

% massimi e minimi di utilizzo per GGU di seguito indicati:

Profilo	Percentuale utilizzo
Profilo	Minimo	Massimo
Capo progetto	5%	15%
Analista funzionale	15%	35%
Programmatore senior	20%	40%
Programmatore junior	10%	30%
Sviluppatore web	10%	20%

Le caratteristiche e i requisiti dei suddetti profili sono elencate nelle seguenti tabelle:

Capo progetto

Titolo di studio	Laurea in discipline tecniche o cultura equivalente
Xxxxx	Xxxxxxxx e coordina le risorse che lavorano sul progetto (di cui conosce skills, specializzazioni ed attitudini), assicurandone il committment e la condivisione degli obiettivi; svolge attività di program management affiancandosi ad una risorsa del Fondo e fornendo stati di avanzamento delle attività progettuali. Si fa portatore delle problematiche rilevate nel corso del progetto, propone opportune soluzioni e intraprende, d’accordo con il Fondo le necessarie azioni correttive anche per quanto riguarda gli aspetti connessi al sistema informatico. Sarà inoltre il referente per tutti gli aspetti contrattuali.
Anzianità lavorativa	Almeno 10 anni nella funzione o come responsabile di progetti complessi. E’ apprezzata la conoscenza del contesto operativo dei fondi interprofessionali.
Esperienze consolidate	• Comprovata esperienza nella gestione della relazione istituzionale, organizzativa e contrattuale; • Esperienza nella gestione di progetti complessi in area IT; • Comprovata esperienza nella gestione e nel coordinamento di risorse umane; • Comprovata esperienza nella stima delle risorse per la realizzazione di attività. • Comprovata esperienza nell’uso di metodologie e strumenti di project e program management e nella redazione della documentazione di progetto in realtà di grandi dimensioni; • capacità di redazione di diagrammi di GANTT.
Conoscenze, competenze e capacità	• Spiccate capacità relazionali, capacità di gestione del cliente e di risorse umane, facilità di comunicazione per poter gestire attività caratterizzate dalla continua interazione con il personale e con la dirigenza; • Conoscenze approfondite di metodologie e tecniche di project e risk management; • Conoscenze approfondite di standard e tecniche per la gestione della qualità di progetto • Autorevolezza e comprovata esperienza in progetti di grandi dimensioni; • Ottima conoscenza dei processi di change management
Certificazioni (requisito opzionale)	PRINCE2 o PMI o IPMA

Analista funzionale

Titolo di studio	Laurea in discipline tecniche o cultura equivalente
Xxxxx	Xx fa portatore della propria conoscenza relativamente a: • Metodologie di analisi dei processi • Metodologie di analisi e disegno di prodotti SW • Metodologie di analisi e disegno dati • Tecniche di controllo di progetto e di programmazione strutturata • Tematiche applicative amministrativo-contabili • Tecniche di modellazione dati
Anzianità lavorativa	Minimo 10 anni di cui almeno 7 nella funzione.
Esperienze consolidate	• Esperienza nella gestione di progetti in area IT; Comprovata esperienza nell’analisi, progettazione e reingegnerizzazione di processi e modalità di erogazione del servizio; • Comprovata esperienza nell’analisi e disegno dei dati; • Comprovata esperienza nella gestione e coordinamento di gruppi di lavoro.
Conoscenze, competenze e capacità	• Tecniche di modellazione e integrazione dati; • Capacità di comprendere i processi di business e proporre soluzioni innovative; • Capacità di lavorare in modo efficace in tutti i livelli e di ottenere consenso; • Capacità a delineare la migliore strategia di azione, individuando i rischi e superando le criticità; • Capacità di gestire le diverse fasi del ciclo di vita dello sviluppo software di sistemi, • Capacità di raccogliere e sistematizzare i requisiti di progetto e/o di Obiettivo, producendo analisi di dettaglio formalizzate in documenti e rapporti scritti di elevata qualità, tenendo conto di metodologie standard (UML, ecc.) • Capacità ed esperienze di formazione e comunicazione; • Ottima conoscenza delle tematiche legate ad architetture complesse, con particolare riguardo alle soluzioni di integrazione tra tecnologie legacy e tecnologie open.
Certificazioni (requisito opzionale)	Microsoft MCSD, Microsoft MCSA SQL Server, Microsoft MCSE MySql DBA

Analista programmatore senior

Titolo di studio	Laurea in discipline tecniche o cultura equivalente
Ruolo	E’ in grado di avere una completa autonomia nello sviluppo, nella preparazione ed esecuzione di casi di test di unità, nella preparazione di documentazione di programmi. Partecipa alla stesura di specifiche tecniche. Partecipa a gruppi di progetto di medie dimensioni.
Anzianità lavorativa	Minimo 10 anni di cui almeno 7 nella funzione
Esperienze consolidate	• Esperienza di analisi, disegno e programmazione ASP, Object Oriented e Service Oriented; • Qualifica professionale Analista Programmatore; • Redazione di documentazione di progetto; • Verifica della corretta applicazione di metodi e standard e nell’accurata documentazione di procedure; • Esperienza nella programmazione e nella preparazione, esecuzione di test; • Partecipazione a gruppi di progetto di medie/grandi dimensioni.
Conoscenze, competenze e capacità	• Tecniche di programmazione Object Oriented e Service Oriented; • Metodologie di disegno di prodotti software; • Ottima conoscenza dei sistemi operativi Windows e Unix; • Capacità di progettare l'accessibilità, l'usabilità, e la coerenza grafica del prodotto realizzato; capacità di organizzare l'esecuzione di test di usabilità del prodotto • Ottima conoscenza dell’ambiente FileMaker Pro • Tecniche di realizzazione di Applicazioni Web, Web Services; • Conoscenza di: Java, HTML/XHTML, XML, XSL, SQL, JavaScript; • Installazione e personalizzazione di sistemi anche complessi; • Progettazione ed integrazione di sistemi; • Ottima conoscenza di SQL, e dei principali RDBMS in uso: MS SQL Server e MySql; • Scrittura di documentazione, manualistica e procedure operative relative alla soluzione sviluppata; • capacità di redazione di documentazione tecnica del software sviluppato • Conoscenza del sistema di autenticazione LDAP • Strumenti di Office automation
Certificazioni (requisito opzionale)	FileMaker PRO Microsoft MCSD, Microsoft MCSA SQL Server, Microsoft MCSE MySql DBA, MySql DEV

Programmatore junior

Titolo di studio	Diploma in discipline tecniche.
Ruolo	E’ in grado di sviluppare nei linguaggi di programmazione richiesti. Partecipa a gruppi di progetto di medie dimensioni.
Anzianità lavorativa	Minimo 3 anni
Esperienze consolidate	• Esperienza di analisi, disegno e programmazione Object Oriented e Service Oriented; • Verifica della corretta applicazione di metodi e standard e nell’accurata documentazione di procedure; • Esperienza nella programmazione; • Partecipazione a gruppi di progetto di medie/grandi dimensioni.
Conoscenze, competenze e capacità	• Tecniche di programmazione Object Oriented e Service Oriented; • Ottima conoscenza dei sistemi operativi Windows e Unix; • Ottima conoscenza dell’ambiente FileMaker Pro • Tecniche di realizzazione di Applicazioni Web, Web Services; • Conoscenza di: Java, HTML/XHTML, XML, XSL, SQL, JavaScript; • Ottima conoscenza di SQL, e dei principali RDBMS in uso: MS SQL Server e MySql; • Strumenti di Office Automation

Programmatore web

Titolo di studio	Diploma in discipline tecniche
Xxxxx	È in grado di sviluppare nei linguaggi di programmazione richiesti. Partecipa a gruppi di progetto di medie dimensioni.
Anzianità lavorativa	Minimo 10 anni di cui almeno 6 nella funzione
Esperienze consolidate	• Esperienza di analisi, disegno e programmazione ASP, Object Oriented e Service Oriented; • Verifica della corretta applicazione di metodi e standard; • Partecipazione a gruppi di progetto di medie/grandi dimensioni.
Conoscenze, competenze e capacità	• Tecniche di programmazione Object Oriented e Service Oriented; • Ottima conoscenza dei sistemi operativi Windows e Unix; • Capacità di progettare l'accessibilità, l'usabilità, e la coerenza grafica del prodotto realizzato; • Tecniche di realizzazione di Applicazioni Web, Web Services; • Conoscenza di: Java, HTML/XHTML, XML, XSL, SQL, JavaScript; • Buona conoscenza di SQL, e dei principali RDBMS in uso: MS SQL Server e MySql; • capacità di redazione di documentazione tecnica del software sviluppato • Strumenti di Office Automation

8. SUBENTRO, RILASCIO A TERMINE SERVIZIO E AFFIANCAMENTO

8.1 Subentro

Il subentro consiste nella presa in carico del software di base e applicativo del sistema informativo nonché dei servizi di manutenzione correttiva, conduzione tecnica e di Help-desk. Le attività di subentro devono partire alla stipula del contratto e devono essere svolte secondo un dettagliato “Piano di subentro” fornito come parte integrante dell’offerta tecnica.

Per favorire la continuità del servizio sarà disponibile, per un periodo massimo di due mesi dall’avvio della esecuzione del contratto, un servizio di affiancamento per subentro da parte del precedente Affidatario che, in tal caso, assicura il supporto per garantire, per tale periodo, i servizi di conduzione del sistema, di manutenzione correttiva e di Help Desk, affiancando con proprio personale le risorse professionali dell’Aggiudicatario per consentire l’acquisizione delle informazioni tecniche ed operative necessarie per realizzare al meglio il subentro nella conduzione dei servizi.

Le modalità del subentro, nell’ambito delle quali potrà essere manifestata l’intenzione di avvalersi di tale possibilità dovranno essere specificate nell’Offerta tecnica ed in particolare nel Capitolo dedicato al “Piano di subentro” insieme con la durata prevista dell’affiancamento per subentro per ciascuno dei servizi, entro un periodo massimo di due mesi.

8.2 Rilascio (Termine del servizio)

Il Rilascio al termine del servizio comprende tutte le attività necessarie per trasmettere al personale del FONDO (o al personale di altro Fornitore subentrante) tutte le informazioni acquisite nel corso dell'esecuzione del servizio, nonché quant'altro, anche a livello documentale, risulti necessario per garantire la regolare prosecuzione dei servizi.

L’Aggiudicatario si impegna a prestare il massimo supporto e collaborazione per consentire al FONDO o a terzi di subentrare all’Aggiudicatario stesso nell’appalto del servizio di implementazione ed evoluzione del sistema informativo.

L’Aggiudicatario si impegna inoltre a consegnare in modo collaborativo i codici sorgente, i dati e le procedure e tutta la documentazione di progetto e delle applicazioni oggetto del passaggio di consegne in formato pienamente utilizzabile, nonché le conoscenze maturate e le informazioni necessarie o utili a tale scopo, mettendo a disposizione del FONDO, e/o a terzi da questo designati, il proprio personale incaricato della gestione nel mese di rilascio, al fine di consentire al subentrante il mantenimento dei livelli di servizio richiesti dal presente capitolato.

Tutte le attività che saranno svolte in questa fase non dovranno in alcun modo gravare sull’operatività delle risorse umane e tecnologiche impiegate, né sui livelli di servizio. Inoltre, tale fase non comporterà ulteriori oneri economici per il FONDO.

In particolare l’Aggiudicatario, per un periodo di due mesi dalla fine della durata contrattuale, si impegna a:

• affiancare il personale della nuova gestione;

• rendere disponibili tutte le risorse professionali, di adeguato profilo ed esperienza, necessarie a garantire il predetto affiancamento ed il completo passaggio di consegne;

• trasferire eventuali servizi ricevuti da terzi per consentire lo svolgimento delle attività;

• trasferire i codici sorgente, il disegno dei database e degli applicativi modificati, i diagrammi entità relazioni aggiornati, le modiche effettuate al disegno dei dati, i dati in formato pienamente utilizzabile, tutti gli allegati utilizzati o riferiti dall’attività in carico, le procedure e la documentazione prodotta e/o gestita nel corso dell’appalto.

Le attività di subentro devono partire alla stipula del contratto e devono essere svolte secondo un dettagliato “Piano di affiancamento a fine contratto” fornito come parte integrante dell’offerta tecnica.

9. CONDIZIONI E TERMINI DI ESPLETAMENTO DELLE ATTIVITA’

Tutti i servizi dovranno essere svolti dall’Aggiudicatario della gara in stretto collegamento con i funzionari indicati dal FONDO che dovranno essere messi in grado di seguire i lavori in modo puntuale. In particolare tutte le attività̀ da realizzare e relative tempistiche dovranno essere concordate con il Committente.

La determinazione dei corrispettivi prevede le seguenti modalità di valorizzazione contrattuale:

• a canone, con corrispettivo fisso a fronte di una prestazione definita e nel rispetto di un altrettanto predefinito livello di servizio;

• a consumo, con individuazione di task realizzativi soggetti a specifica valutazione di impegno professionale ed economica, a scalare da una disponibilità budgetaria predefinita.

Di seguito la modalità adottata in funzione del tipo di servizio:

Servizio	Tipo corrispettivo	Importo massimo a base d’asta
Sviluppo e Manutenzione Evolutiva (MEV)	Consumo	1.540.000 €
Manutenzione Adeguativa e Correttiva (MAC)	Canone	210.000 €
Servizio di Help Desk	Consumo	50.000 €
		1.800.000 €

Per il servizo MAC, i corrispettivi a canone verranno remunerati trimestralmente, posticipatamente all’esito delle verifiche condotte da parte del FONDO, secondo le modalità previste dallo schema di contratto allegato al Disciplinare di gara.

Per il servizo MEV i corrispettivi a consumo verranno remunerati sulla base delle giornate effettivamente erogate dal Fornitore, che deve fornire al FONDO, con cadenza trimestrale, una Relazione di Avanzamento contenente la specifica delle attività̀ svolte, i vincoli/criticità rispetto all’andamento delle attività, le risorse impiegate per profilo e le relative giornate svolte, al fine di consentire un puntuale monitoraggio dell’andamento delle attività e della commessa. I corrispettivi contrattuali saranno calcolati applicando il prezzo giornaliero offerto dall’affidatario per ciascuna figura professionale, come indicato nel modello di offerta economica, con il numero di giornate uomo effettivamente erogate.

Per il servizio di Help Desk, i corrispettivi saranno remunerati a consumo sulla base delle ore erogate dal Fornitore, che deve fornire al FONDO, con cadenza trimestrale, un report dettagliato contenente le attività̀ svolte e il relativo impegno espresso in ore. I corrispettivi contrattuali saranno calcolati applicando il prezzo orario offerto dall’affidatario.

10. DOCUMENTAZIONE DI PROGETTO E D’UTENTE

Le attività di manutenzione correttive e/o evolutive devono prevedere una ampia documentazione di progetto che comprenda l’analisi, il progetto, l’implementazione ed il deployment.

Deve essere, inoltre, previsto un dettagliato dizionario dei dati ed un completo schema del/dei DB mediante il modello E/R.

Deve essere fornita copia dei sorgenti relativi alle personalizzazioni ed al software applicativo sviluppato. Si precisa che il software sviluppato deve contenere un’adeguata documentazione interna, sotto forma di commenti.

Deve essere fornita una completa manualistica d’uso personalizzata per ruolo e/o categoria di utenti ed una completa guida all’installazione ed alla configurazione; le evoluzioni del sistema comportano l’obbligo di adeguare la manualistica.

Xxxxxx, inoltre, essere forniti un “Piano dei Test” ed un “Piano di collaudo”.

Tale documentazione deve essere redatta in lingua italiana e fornita anche in formato elettronico nel repository di progetto all’uopo predisposto dall’Affidatario.

La documentazione dovrà essere relativa all’intero sistema e quindi anche alle parti precedentemente implementate pertanto l’Affidatario potrà alternativamente decidere di mantenere lo standard di documentazione pre-esistente o di migrare tutta la documentazione in altri formati e standard che verranno successivamente utilizzati durante tutta la durata del contratto.

10.1 Tipologie di documenti da produrre

10.1.1 Analisi Preliminare

Il documento di analisi preliminare ha lo scopo di raccogliere le informazioni necessarie alla formulazione del piano di lavoro del progetto e alla quantificazione delle risorse assegnate e deve pertanto definire:

• ambito ed obiettivi generali di progetto;

• finalità dei processi e le norme principali di riferimento;

• unità organizzative interessate con le relative dipendenze gerarchiche e referenti per il progetto;

• dettaglio degli obiettivi in relazione alla corretta identificazione delle principali dimensioni di riferimento (esempio necessità utenti, prestazioni, output,

• workflow, struttura, attività e relativi strumenti di supporto, risorse);

• strumenti e metodologie da utilizzare per la realizzazione del progetto.

10.2 Rapporto di analisi dei processi

Il rapporto di analisi dei processi rappresenta l'elaborazione della rilevazione "as is" secondo quanto definito nel documento di analisi preliminare e deve pertanto prevedere:

• indicazione dei processi amministrativi core;

• identificazione dei processi critici;

• descrizione della documentazione raccolta e di tutte le altre informazioni necessarie alla predisposizione del documento (organigrammi, circolari, regolamenti, legislazione, ecc.);

• descrizione del piano di interviste effettuato;

• rappresentazione grafica e descrizione di dettaglio dei processi (strutture organizzative, mappa dei processi macro e sotto processi di riferimento, ecc.) con indicazione delle singole attività, del relativo valore aggiunto, di eventuali colli di bottiglia o ridondanze, ecc.);

• indicazione degli attori di riferimento (numerosità tipologia di profili professionali con indicazione ruoli, responsabilità e competenze, ecc.);

• rilevazione dei tempi di svolgimento dei processi/attività e indicazione di strumenti di supporto (in termini di applicazioni e tecnologia utilizzata);

• identificazione delle principali criticità, delle possibili azioni correttive e dei fattori di successo;

• identificazione delle linee guida al cambiamento e match con obiettivi di performance concordati con il FONDO.

10.3 Ridisegno dei processi

Il rapporto di ridisegno dei processi rappresenta l'individuazione di nuovi processi / procedure amministrative nell'ottica, ad esempio, di eliminare fasi di lavoro ridondanti; individuare opportunità di riduzione/compressioni dei cicli di lavorazione, parallelizzare attività non sequenziali, semplificare processi e accentramento dei controlli, ecc.

Il documento dovrà pertanto riportare la rappresentazione e la descrizione di dettaglio dei nuovi processi secondo:

• aspetto organizzativo (riallocazione / accorpamento di attività, introduzione dei sistemi delega e dei sistemi di comunicazione a livello di struttura organizzativa, ecc.);

• aspetto procedurale (eliminazione di attività ridondanti, riduzione di complessità burocratiche, snellimento controlli, ecc.);

• strumenti di supporto (valutazione della coerenza e del grado di copertura funzionale applicativi a disposizione).

Dovrà inoltre essere indicata l'eventuale necessità di prevedere nuovi strumenti di supporto; in questo caso, il documento riporterà l'indicazione dei processi e delle relative macro funzioni che devono essere gestite mediante l'introduzione di nuovi strumenti informatici.

10.4 Specifiche Funzionali e Progettazione esecutiva

Le specifiche contengono in modo completo ed esaustivo l'analisi dei requisiti sia relativamente ai processi e alle modalità con cui tali processi risulteranno visibili agli utenti finali, sia al disegno logico dei dati secondo il modello relazionale, sia per quanto riguarda gli aspetti non funzionali (architettura, sicurezza, accessibilità, vincoli, prestazioni, ecc.), sia alla documentazione delle interfacce (incluso esempi di layout delle principali schermate utente, ecc.), sia nei casi in cui è previsto l'utilizzo di un prototipo.

Il risultato finale deve essere la progettazione esecutiva che riepiloga le specifiche funzionali, la pianificazione delle attività del progetto e la stima dell’effort in GGU.

Il livello di completezza richiesto deve essere tale da:

• consentire l'approvazione delle funzionalità da parte del Direttore dell’esecuzione e dei referenti delle Aree/unità del FONDO e consentire la produzione del Piano di test senza necessità di ulteriori approfondimenti;

• consentire lo svolgimento della successiva fase di disegno di dettaglio;

• consentire la verifica della stima in GGU;

• garantire la tracciabilità con quanto descritto nel documento dei requisiti.

10.5 Mappatura Ridisegno Processi/Specifiche Funzionali

Dove applicabile, il documento deve riportare la mappatura fra quanto prodotto nel documento Ridisegno Processi, le Specifiche Requisiti e le Specifiche Funzionali del progetto.

In particolare, dovranno essere tracciate le corrispondenze tra i processi / macro funzioni individuati nel documento Ridisegno Processi, i requisiti utente e le funzionalità descritte nelle Specifiche Funzionali.

10.6 Disegno di Dettaglio

I documenti di disegno di dettaglio contengono una specifica in cui le funzionalità sono trasformate e organizzate in moduli elaborativi strutturati. È compresa nel disegno di dettaglio la documentazione del disegno logico e fisico dei dati.

Ad esempio, per i vari moduli, devono essere trattati:

• descrizione delle funzioni svolte;

• tipologia (on-line, batch, ecc.);

• indicazioni sulla riutilizzabilità del componente;

• parametri scambiati con altri componenti;

• parametri di attivazione;

• accessi agli archivi/base dati;

• controlli e diagnostica;

• algoritmi di calcolo per ciascuna entità.

Per quanto riguarda il disegno logico dei dati, la tecnica di rappresentazione può variare in funzione del DBMS utilizzato.

In ogni caso dovranno essere prodotte le matrici d'uso (o matrici CRUD) degli archivi da parte dei moduli software.

Nei casi critici, per dimensioni delle basi dati e/o frequenza di utilizzo, deve essere indicata la frequenza prevista per il tipo d'uso che il modulo fa degli archivi/basi dati, le frequenze totali per tipo d'uso relative a ciascun archivio/tabella della base dati, le frequenze totali per tipo d'uso per ciascun componente.

Per quanto riguarda il caricamento iniziale dei dati, dovranno essere indicati:

• gli archivi fisici / basi dati da cui prendere i dati e il loro tracciato;

• i tracciati dei dati da caricare manualmente;

• le relazioni tra archivi fisici/basi dati e schemi logici;

• i volumi trattati, con dettaglio sulla occupazione di memoria e spazio disco;

• le modalità di inizializzazione degli archivi / basi dati;

• eventuali regole di trasformazione dalla base dati di partenza a quella di arrivo.

Deve comunque essere garantita la tracciabilità rispetto ai documenti di Specifiche funzionali, Specifiche requisiti e Glossario. I dati contenuti nel documento devono essere sempre tenuti aggiornati.

10.7 Prototipo

Il prototipo costituisce un elemento delle Specifiche funzionali, ed è rivolto solamente alla esplicitazione dell'interfaccia utente, in termini di layout e di modalità di utilizzo dell'applicazione. In tal caso la documentazione delle interfacce prevista nel documento Specifiche Funzionali riporterà la sola stampa delle videate del prototipo.

Tale prototipazione deve comprendere almeno:

• i layout delle interfacce di colloquio;

• il percorso di navigazione.

Lo strumento di realizzazione del prototipo può differire dagli strumenti che verranno utilizzati per la realizzazione del sistema.

10.8 Codice Sorgente

Per codice sorgente si intende genericamente l'insieme degli oggetti software, realizzati o sottoposti a manutenzione, che sono soggetti a esecuzione da parte di un compilatore (o analogo strumento di "program preparation") o di un interprete (es."job control program", "query manager"), a titolo esemplificativo e non esaustivo quindi:

• programmi;

• tracciati e definizioni dati;

• schermi di input/output;

• pagine web;

• procedure;

• query;

• script (anche gli script relativi ai test automatizzati);

• utility di modifica/aggiornamento dati.

Fanno parte del codice sorgente le procedure di consegna e trasferimento oggetti per gli ambienti di configuration management, nonché le procedure di creazione e popolamento delle tabelle anche attraverso la migrazione dei dati dai data base esistenti, e i relativi job di caricamento dati (per intero DB e/o porzioni secondo criteri definiti) anche per gli ambienti di sviluppo, manutenzione, collaudo ed esercizio.

Fanno parte del codice sorgente, inoltre, l'help on-line e l'eventuale manualistica online, nonché l'eventuale codice di test e collaudo. Il codice sorgente di nuova realizzazione (anche nuovo codice all'interno di programmi preesistenti) dovrà essere redatto in conformità agli standard, ove previsti, e comunque sempre secondo le indicazioni presenti nella documentazione ufficiale dei linguaggi utilizzati.

Si richiama inoltre l'attenzione al rispetto, nella stesura del codice, agli standard in vigore, sia per formalismi di redazione, sia per l'adozione dei prodotti proposti dal fornitore e condivisi dal Direttore dell’esecuzione del FONDO sia per il loro corretto utilizzo.

Gli oggetti software necessari alla predisposizione degli ambienti (collaudo, esercizio ecc.) dovranno essere consegnati almeno tre giorni prima dello scadere del termine previsto per la consegna del codice sorgente.

10.9 Piano Di Test

Il Piano di Test è un documento che accompagna ogni progetto tutto il ciclo di vita, ed è pertanto un documento che evolve nel tempo. Nel Piano di Test devono essere necessariamente comprese le verifiche della corretta predisposizione dell'ambiente di collaudo.

Il documento ha lo scopo di definire test specifici, tramite quali, saranno sottoposti a verifica i prodotti della realizzazione, con particolare riguardo alla loro validazione rispetto ai requisiti dell'utente, nonché documentare il loro esito.

Devono essere garantiti il riscontro e la corrispondenza con il documento di Specifiche funzionali, Specifiche requisiti e Disegno di dettaglio.

10.10 Documentazione Utente

La documentazione utente, rivolta all'utente finale delle applicazioni, è composta dal Manuale utente e dall'help on line (rilasciato con il codice sorgente).

Il manuale utente deve fornire una descrizione generale dell'applicazione e una guida operativa all'utilizzo delle singole funzionalità utilizzabili personalizzata per gruppo di utente (utente esterno; Utente del FONDO, Amministratore di Sistema).

La descrizione deve contemplare:

• la tipologia di utenza cui è destinata e le funzioni abilitate a ciascuna tipologia;

• gli eventuali flussi di dati scambiati con altri sistemi informativi o con specifiche tipologie di utenze;

• le modalità di attivazione e chiusura della "sessione di lavoro"; descrizione delle funzioni e della navigazione tra di esse;

• la spiegazione dettagliata dell'uso delle singole funzioni di interfaccia utente (comprensiva della funzione di richiamo dell'help);

• la descrizione degli algoritmi di calcolo utilizzati;

• la descrizione dei contenuti degli output della applicazione (es. stampe).

La descrizione delle funzionalità disponibili deve essere completa dell'elenco di tutti i codici d'errore previsti, della messaggistica a essi associata e delle azioni da intraprendere a fronte di ciascuna segnalazione.

Nel caso in cui l'applicazione preveda un utilizzo diretto dei dati da parte dell'utente, deve essere inserita anche la descrizione dettagliata della struttura dei dati interessati.

Tutte le applicazioni interattive devono prevedere le funzioni di help on line.

10.11 Manuale Di Gestione Applicativo

Il Manuale di gestione applicativo è lo strumento necessario alle strutture preposte all'installazione ed esercizio dell'applicazione. È un manuale rivolto a personale tecnico. Tale manuale dovrà essere corredato di uno schema riepilogativo contenente informazioni anagrafiche relative all'applicazione, tra le quali la dimensione e tipologia del DB, la dipendenza da altre applicazioni, i modelli di interfaccia, i tool utilizzati per lo sviluppo, ecc.

Per quello che riguarda gli ambienti di collaudo ed esercizio, il documento dovrà esplicitare i parametri di personalizzazione dei prodotti, le modalità di attuazione dei livelli di protezione dei dati, le modalità di accesso al sistema e alle transazioni, le soluzioni tecniche necessarie alla realizzazione di tali modalità.

Il documento deve contenere il Piano di adeguamento degli ambienti, cioè la documentazione sintetica di supporto alle attività di trasferimento e installazione in ambiente di collaudo, di esercizio e di correttiva.

10.12 Lista oggetti Software

Il documento di Lista Oggetti Software (LOS) deve contenere un elenco di tutti gli oggetti software realizzati, modificati o resi obsoleti nell'ambito delle attività riguardanti il progetto

La LOS deve essere completa di tutte le informazioni necessarie al FONDO per la gestione della configurazione attraverso gli strumenti dichiarati dal Direttore dell’esecuzione con riferimento a contenuti e tracciati che lo stesso si riserva di stabilire e di modificare a sua discrezione nel corso del contratto.

Le informazioni da fornire sono:

• codice e descrizione dell'area;

• codice e descrizione del progetto;

• codice e descrizione delle singole applicazioni;

• data di fine garanzia.

10.13 Manuale procedure batch

La documentazione delle procedure off line (batch, job, stored procedure, script ecc.) è destinata ai gruppi di gestione applicativi e basi dati quale supporto alle loro attività ordinarie.

L'elenco delle procedure fornisce una descrizione generale delle procedure e una guida operativa per la loro schedulazione, ordinaria e straordinaria.

La descrizione deve contemplare:

• codice identificativo della procedura;

• descrizione sintetica;

• puntamento al manuale utente;

• evento per l'attivazione della schedulazione (ad es. calendario, richiesta utente ecc.);

• ambiente;

• vincoli procedurali, con particolare attenzione ai vincoli e alle condizioni di ripartenza;

• periodicità;

• note eventuali;

• puntamento al documento di procedura.

Il documento di procedura deve fornire la descrizione operativa di ogni procedura, in particolare deve riportare:

• elenco di tutti i componenti che la costituiscono (script, stored procedure, ecc.);

• diagramma di flusso dei componenti (flow chart);

• matrice componenti/base dati;

• per ogni componente, eventuali parametri da fornire in input per l'esecuzione, l'elenco di tutti gli output e del loro significato (file, stampe ecc.), l'elenco dei codici di errore, vincoli fisici di schedulazione e le istruzioni operative in caso di malfunzionamento (job di recovery, possibilità di eliminazione, ecc.).

10.14 Rapporto Indicatori Di Qualità Degli Obiettivi e Della Fornitura

Rapporto mensile indicatori di qualità deve contenere almeno:

• riferimento al contratto, area funzionale, obiettivo;

• per ciascun indicatore applicabile occorre specificare:

o il periodo di riferimento della misura;

o riferimento agli strumenti di misura utilizzati;

o i dati rilevati;

• il valore rilevato dell'indicatore di qualità;

o eventuale scostamento dal valore di soglia;

o eventuale razionale di scostamento dai valori di soglia.

Nel caso degli indicatori relativi alla qualità del codice rilevabili con strumenti specifici tool, è necessario allegare al documento i report sulla qualità del software prodotti con tali strumenti, contenenti i risultati della rilevazione. Tali report costituiranno parte integrante ed essenziale del documento. Il Direttore dell’esecuzione del FONDO si riserva di richiedere al Fornitore accesso agli strumenti in modo da poter replicare i risultati.

Al fine di consentire ai responsabili del FONDO l’accesso in tempo reale alla documentazione di progetto e di utente durante tutte le fasi dello stesso l’Affidatario dovrà predisporre un opportuno repository interrogabile tramite interfaccia web.

Deve infine essere fornita un dichiarazione di conformità di tutti i servizi e di tutte le applicazioni fornite a quanto previsto dal Decreto Legislativo n.196 del 30 giugno 2003 Testo Unico – Codice Privacy ed in particolare a quanto indicato nell’Allegato B a suddetto codice in materia di misura minime di sicurezza.

11. LIVELLI DI SERVIZIO

L’Affidatario deve rendere disponibili al FONDO strumenti idonei all’autonoma rilevazione e verifica dei parametri oggetto dei livelli di servizio della fornitura.

Sono utilizzati gli indicatori di qualità di seguito illustrati:

Difettosità del software(DIF): questo indicatore misura l’accuratezza della fase di codifica e di testing del software realizzato. La Metrica utilizzata è il numero totale Te degli errori nel primo anno di esercizio dell’applicazione realizzata. Tale indicatore si applica solo ed esclusivamente ai nuovi sviluppi.

Scostamento rispetto al tempo di rilascio(TRLS): questo indicatore, viene utilizzato specificatamente per misurare l’aderenza del tempo di rilascio alla pianificazione fatta. Il tempo di rilascio misura le giornate intercorrenti tra la data concordata di fine realizzazione/collaudo e quella effettiva.

Soddisfazione del committente (SCOM): questo indicatore viene utilizzato per misurare il grado di soddisfazione del committente mediante la somministrazione di questionari.

Per le risposte dei questionari vanno utilizzati numeri positivi su scala da 1 a 10 dove:

• 1 corrisponde a “non soddisfatto”;

• 6 corrisponde a “appena soddisfatto”;

• 7 corrisponde a “soddisfatto”;

• 10 corrisponde a “pienamente soddisfatto”. Devono essere rilevate:

• il numero di risposte positive (risposte con valore maggiore o uguale a 7): parametro risp_pos;

• numero di domande del questionario: parametro dom_quest;

• numero dei questionari somministrati: parametro quest.

La soddisfazione del committente SCOM si calcola come:

Il risultato va arrotondato al decimo di punto per difetto se minore o uguale a 5 altrimenti per eccesso.

Orari di servizio: questi indicatori sono utilizzati per definire i periodi temporali in cui si ritiene disponibile e fruibile un determinato servizio. I valori sono espressi in termini di fasce orarie, eventualmente distinte per ciascun giorno della settimana.

Tempo medio di intervento/ripristino. Questo è un indicatore quantitativo utilizzato per valutare l'efficienza dell’Affidatario, in termini di qualità di distribuzione del lavoro e di supporto alla pianificazione, in merito agli interventi di assistenza e manutenzione effettuati sulle componenti SW di base, di servizio e applicativo costituenti il sistema. Il "tempo medio di intervento/ripristino" (Tm) può essere calcolato, in riferimento a ciascun periodo di osservazione ΔT = 1 mese solare, come media dei singoli tempi di intervento/ripristino effettuati nel predetto periodo di osservazione, attraverso la seguente formula

dove

Tm(ΔT): tempo medio di intervento/ripristino nel periodo di osservazione considerato (ΔT= 1 mese solare); N: numero totale di interventi nel periodo indicato;

di: durata totale dell'intervento "i-esimo".

Servizio di mail/ticketing. Questo metrica è utilizzata per valutare l'efficienza del servizio di Help-Desk e si basa sui seguenti indicatori:

• tempo medio di presa in carico delle richieste, valutato rispetto al numero totale di richieste pervenute su base mensile;

La rilevazione e la valorizzazione dei precedenti indicatori dovrà essere effettuata dall’Affidatario con la supervisione di un comitato di controllo nominato dal FONDO attraverso una costante e puntuale attività di monitoraggio dei livelli quantitativi e qualitativi dei servizi erogati dall’Affidatario.

11.1 Sviluppo Software e MEV

Sia per il servizio di sviluppo software che per la Manutenzione Evolutiva si prende in considerazione per la valutazione dei Livelli di Servizio la seguente composizione di metriche:

• Esito del Collaudo;

• Rispetto dei Tempi concordati;

• Tempo di Rilascio;

• Difettosità.

La tabella di seguito riassume per ognuno degli indicatori il valore di soglia per l’accettazione.

Indicatore	Metrica	Soglia
COLL: Esito Collaudo	Esito della fase di collaudo	POSITIVO
RTC: Rispetto tempi concordati.	Giornate intercorrenti tra la data consegna deliverable contrattuali (documenti di fine analisi e piano di collaudo) concordata e quella effettiva	0
TRLS: Tempo di xxxxxxxx	Xxxxxxxx intercorrenti tra la data di fine realizzazione (o fine collaudo ) concordata e quella effettiva	< 5 giorni
DIF: Difettosità del Software	Totale errori nel primo anno di esercizio dell’applicazione prodotta dal singolo progetto (per i nuovi sviluppi)	< 50

11.1.1 Tempi di risposta e accessibilità

I tempi di risposta relativi a tutte le transazioni del sistema informatico devono risultare adeguati alle funzionalità della transazione e comunque conformi ai criteri di accessibilità universalmente accettati per le transazioni gestionali. Tali tempi, concordati dal gruppo di progetto, saranno oggetto di monitoraggio continuo e dovranno essere formalizzati entro sei mesi dalla stipula del contratto o dall’avvio anticipato.

Gli eventuali scostamenti dei tempi concordati saranno soggetti alle penali previste nello schema di contratto.

Per la valutazione dell’accessibilità devono esser utilizzati i seguenti indicatori:

• Tempi di risposta concordati per le principali transazioni di sistema (a titolo esemplificativo ma non esaustivo: login, consultazione estratto conto, report riepilogativi, ricerca piani, gestione piano, rendicontazione);

• Bacino di utenza supportato dall’interfaccia web del sistema (PGA): nell’ordine di almeno 1000 sessioni attive.

• Previsione incremento utenze da 1000 a 2000 con decadimento delle prestazioni (rispetto ai tempi di risposta concordati) pari al massimo al 20%.

• Per utenze superiori al numero di 5000 il sistema potrà non garantire il livello di servizio.

Il sistema deve essere opportunamente dimensionato affinché possa gestire almeno 100.000 utenti registrati. L’affidatario nell’ambito del sistema di monitoraggio dei servizi e sistemi dovrà rendere disponibile un cruscotto certificato di verifica del presente indicatore.

La soluzione proposta deve garantire la possibilità di gestire un numero maggiore di sessioni attive di utenti e servizi registrati, al crescere delle esigenze del FONDO; tale requisito deve essere soddisfatto senza modifiche al Software applicativo e dell’architettura di riferimento utilizzata, aggiungendo o potenziando le componenti che costituiscono il sistema.

Per soddisfare i parametri precedentemente definiti, la soluzione deve essere dimensionata e realizzata nei termini delle sue componenti hardware e software, dell’architettura e delle tecnologie, in modo da soddisfare i requisiti. E’ compito dell’Affidatario comunicare con congruente anticipo l’eventuale necessità di procedere ad un’attività straordinaria di manutenzione evolutiva per qualunque adeguamento Hardware e Software si rendesse necessario per garantire i livelli di servizio stabiliti.

11.2 Servizio MAC

11.2.1 Tempi medi di intervento/ripristino

Per tale indicatore i livelli di servizio richiesti sono:

Tempo medio di intervento:

• minore di 2 ore lavorative, dalla ricezione della chiamata di assistenza; Tempo medio di ripristino:

• minore di 4 ore lavorative, dall'inizio dell’intervento, per i “malfunzionamenti bloccanti”;

• minore di 16 ore lavorative, dall'inizio dell'intervento per i “malfunzionamenti non bloccanti”;

Con il termine “malfunzionamenti bloccanti” si identificano tutte le eventuali anomalie che direttamente o indirettamente comportano il blocco o la non disponibilità di una o più funzionalità o servizi rispetto alle esigenze di una qualsiasi delle categorie di utenti.

Con il termine “malfunzionamenti non bloccanti” si identificano, per esclusione, tutte le eventuali anomalie che non rientrano nella precedente categoria.

11.3 Servizio di Help Desk

I livelli di servizio per la struttura di Help-Desk dovranno essere garantiti in relazione ai seguenti indicatori:

• orari di servizio del Help-desk;

• servizio e-mail/ticketing.

11.3.1 Orari di servizio dell’ Help Desk

Per tale indicatore deve essere garantita la seguente operatività:

• dal lunedì al venerdì: dalle ore 9.00 alle ore 18.00;

• per un massimo di sei volte per anno solare sabato 9:00-18:00;

• per un massimo di tre volte per anno domenica o festivi 9:00-18:00

11.3.2 Servizio e-mail/ticketing

Per tale indicatore i livelli di servizio richiesti, in relazione al carico concordato dal gruppo di progetto, sono: tempo massimo di presa in carico della segnalazione : 2 ore lavorative.

La verifica del rispetto dei livelli di servizio indicati potrà essere anche effettuata dal FONDO attraverso invio di richiesta a campione. E’ compito dell’Affidatario comunicare con congruente anticipo l’eventuale necessità di procedere ad un adeguamento del servizio per garantirne i livelli concordati.

11.4 Affiancamento a fine contratto

Il Fornitore deve garantire al termine della durata contrattuale un periodo di affiancamento per subentro di due mesi al nuovo fornitore, per tutti servizi oggetti del presente affidamento, in accordo con quanto previsto nel “Piano di affiancamento a fine contratto” da produrre come parte integrante dell’offerta tecnica contenente almeno:

• modalità di svolgimento dell’affiancamento per subentro;

• pianificazione temporale delle attività di affiancamento;

• la descrizione analitica delle infrastrutture logistiche e tecnologiche predisposte per l'erogazione del servizio;

• livelli di servizio offerti;

• la descrizione del numero degli operatori e dei profili professionali impiegati.

I livelli di servizio per l’affiancamento per subentro dovranno essere garantiti in relazione ai seguenti indicatori:

• tempo massimo di attivazione del servizio;

• aderenza alla pianificazione delle attività;

• soddisfazione del cliente.

11.4.1 Tempo massimo di attivazione del servizio

Il tempo massimo di attivazione viene misurato come numero di giorni dalla richiesta del FONDO dell’attivazione del servizio di affiancamento e l’effettiva attivazione.

Il valore massimo per tale indicatore è: 5 giorni.

11.4.2 Aderenza alla pianificazione delle attività

L’aderenza viene misurato come numero di giorni dalla di inizio e/o fine di ognuna delle attività previste nel piano di affiancamento per subentro.

Il valore soglia per tale indicatore è 1 giorno.

11.5 Soddisfazione del committente

La Soddisfazione del FONDO è misurata rilevando, su base semestrale, dai questionari delle interviste dei Referenti del FONDO le risposte fornite alle specifiche domande sulla soddisfazione dell’intervistato rispetto alla rilevazione. Vengono tipicamente prese in considerazione le seguenti dimensioni, che sono soggette ad integrazione a discrezione del Fornitore:

• Aspetti tangibili: qualità della documentazione di subentro fornita, qualità delle sessioni d’aula di trasferimento del Know-how, qualità delle attività di affiancamento;

• Affidabilità: capacità di fornire il servizio e le informazioni previsti in modo affidabile e preciso;

• Reattività: disponibilità a supportare in termini di rapidità della risposta;

• Assurance: competenza e cortesia del personale incaricato dal fornitore;

• Empatia: attenzione individualizzata alle esigenze.

La soddisfazione del committente SCOM deve essere pari almeno all’80%.

12. PENALI

I servizi devono essere avviati dalla data di inizio dell’attività indicata in un apposito verbale.

L’Affidatario dovrà attenersi per la realizzazione del Sistema e l’erogazione dei servizi ai livelli di servizio definiti nel capitolo 11 del presente Capitolato.

Inoltre, nel caso in cui il valore degli indicatori definiti superi le soglie stabilite si applicano le penali previste nello schema di contratto allegato al Disciplinare di gara

13. FORMAZIONE DEL PERSONALE

L’Affidatario è tenuto ad erogare, a richiesta del FONDO, formazione di base ed avanzata sull'uso del sistema informativo, rivolta al personale.

14. PIANO DELLA QUALITA’

Come parte integrante dell’offerta tecnica il Fornitore deve presentare in apposito capitolo il Piano della qualità da esso adottato che comprenda ognuno dei servizi oggetto del presente Capitolato con particolare riferimento all’organizzazione del processo e del lavoro.

Nella redazione del Piano della Qualità il Fornitore terrà come guida lo schema di riferimento di seguito descritto.

Si chiede di indicare:

• il campo di applicazione (comprese le limitazioni, cioè i casi in cui questo piano non verrà applicato);

• il Sistema di Gestione della Qualità (SGQ) usato, ad esempio, per la tenuta sotto controllo dei documenti, tenuta sotto controllo delle registrazioni della qualità, le azioni correttive, le azioni preventive, gli audit, altri piani pertinenti (ad esempio: piani di progetto, piani di gestione ambientale, di salute e sicurezza sul lavoro, di sicurezza e di gestione delle informazioni).

Si chiede di indicare i documenti che costituiscono un riferimento per quanto esposto nel Piano della Qualità, e le abbreviazioni, acronimi, definizioni che sono utilizzate all'interno del Piano della Qualità.

Si chiede di definire l'organigramma del gruppo di lavoro impegnato nell’espletamento del contratto, di indicare i ruoli e le responsabilità di ciascun elemento nell'organigramma mediante una matrice delle responsabilità; di descrivere le attività di formazione necessarie per l'espletamento delle attività contrattuali a cui il Fornitore sottoporrà le proprie risorse.

Si chiede di descrivere gli strumenti per la gestione delle attività progettuali; gli strumenti per l'analisi, la progettazione, sviluppo, creazione e generazione del codice; gli strumenti per la gestione della configurazione e della documentazione; gli strumenti per la progettazione ed esecuzione delle prove del software; gli strumenti per le reti, compreso quelli per la riservatezza, la protezione dai virus, i firewall, per le copie di salvataggio; gli strumenti di prima assistenza e di manutenzione.

Si chiede di identificare, in modo chiaro e non ambiguo, i requisiti di qualità del contratto. Per questo è necessario definire:

• gli attributi di qualità relativi a ciascun prodotto e a ciascun servizio, compresa l’usabilità delle interfacce utente;

• gli indicatori di qualità con cui misurare gli attributi identificati;

• i valori limite ritenuti accettabili con cui confrontare le misure degli attributi di qualità sulla base di indicatori di qualità definiti.

Si chiede di descrivere le modalità che saranno utilizzate dal Fornitore per valutare la qualità dei prodotti e dei servizi realizzati (output del contratto) prima che tali prodotti e/o servizi vengano consegnati/erogati. In particolare, si chiede di esplicitare:

• modalità di misura o di rilevamento utilizzati per i dati;

• modalità di calcolo e di aggregazione delle misure (per il computo di indicatori derivati);

• frequenza delle misure;

• periodi temporali di riferimento;

• le regole con cui si perviene ai giudizi di Approvazione Incondizionata /Approvazione con Riserva

/Non Approvazione di un prodotto e/o un servizio considerando i risultati delle misure relative ai singoli attributi di qualità associati al prodotto e/o livelli di servizio associati ai servizi.

Si chiede di:

• descrivere le modalità operative di identificazione, valutazione, trattamento e tenuta sotto controllo dei rischi;

• pianificare la gestione dei rischi della fornitura.

15. MODALITA’ DI COLLAUDO

I collaudi delle attività realizzate nell’espletamento del servizio oggetto del presente Capitolato saranno eseguiti, in accordo con un “Piano dei Test” ed un “Piano di collaudo” forniti come parte integrante dell’offerta tecnica, da un gruppo di collaudo nominato dal FONDO.

Scopo delle operazioni di collaudo è quello di accertare che i servizi erogati dal sistema, i prodotti forniti e le prestazioni erogate dall’Affidatario risultino conformi alle specifiche tecniche ed ai livelli di qualità riportati nel presente Capitolato.

A seguito di ciascun collaudo dovrà essere redatto apposito verbale, congiuntamente sottoscritto dal gruppo di collaudo, dal Direttore della esecuzione del contratto per il FONDO e dal Responsabile di Progetto per l’Affidatario, nel quale siano almeno indicate le seguenti informazioni:

• l'oggetto del collaudo;

• la tipologia di collaudo (provvisorio o definitivo);

• la data di inizio e di conclusione delle operazioni di collaudo;

• il contesto operativo in cui è stato effettuato il collaudo, con l'indicazione dell'infrastruttura HW, SW di base/di servizio, SW applicativo utilizzata;

• i prodotti, i servizi e le prestazioni esaminate;

• le procedure seguite per l'esecuzione del collaudo;

• i risultati ottenuti;

• l'esito del collaudo.

In caso di collaudo di servizi ripetitivi quali il servizio di Manutenzione correttiva, Help-Desk il verbale di collaudo è sostituito da una attestazione di regolare esecuzione redatta dal Direttore della esecuzione del contratto del FONDO.

In caso di mancato collaudo positivo potranno essere applicate le penali previste nello schema di contratto ed inoltre verrà stabilito dal FONDO un termine inderogabile per la correzione delle anomalie e/o per l’integrazione delle funzionalità mancanti o parziali; si provvederà quindi ad un nuovo collaudo.

Il FONDO potrà disporre l’effettuazione di uno più collaudi per ogni attività di sviluppo svolta, nell’ambito dei servizi di “Sviluppo Software e MEV” e di “Manutenzione correttiva”.

Il flusso di collaudo del software realizzato è di responsabilità del Direttore dell’esecuzione del FONDO che agirà come unica interfaccia nei confronti dell’Affidatario.

Saranno oggetto di verifica durante il collaudo tutti i prodotti e in particolare:

• software realizzato;

• manuale utente;

• manuale di gestione applicativo;

• modello dati e glossario;

• dizionario dati;

• file di configurazione;

• manuale di gestione del server;

• eventuali altri documenti.

Il Fornitore dovrà garantire almeno le macro attività elencate di seguito:

• predisposizione dell'ambiente di collaudo, supporto alle attività di collaudo, testing proceduralizzato e automatico nonché eventuali test manuali;

• la rimozione delle anomalie fino al momento dell'accettazione;

• migrazione dei dati per alimentare/aggiornare le basi dati realizzate/modificate nell’ambito degli interventi di sviluppo e manutenzione;

• supporto alle attività di passaggio in esercizio.

Nel caso in cui il FONDO ritenga di operare un periodo di pre-esercizio, mediante l’utilizzo di un prototipo pienamente funzionante, lo stesso sarà ritenuto parte integrante delle attività di collaudo e pertanto il fornitore dovrà garantire tutto il supporto logistico ed operativo necessario al suo corretto svolgimento.

16. STRUTTURA DELL’OFFERTA TECNICA

L’offerta tecnica dovrà essere redatta secondo l’indice indicato e deve rispettare i vincoli qui imposti in termini di dimensione.

16.1 Limiti di pagina e di formattazione

L’offerta tecnica, inclusa la copertina e tutte le sezioni di seguito indicate, non deve superare le 90 pagine. Devono essere incluse nel conteggio tutte le tabelle, figure, riferimenti e qualsiasi altro elemento che si ritiene essenziale e parte integrante di queste sezioni. Unica esclusione sono i curricula delle figure professionali impiegate dal Fornitore, che vanno presentati in apposita appendice.

Il limite di pagina verrà applicato automaticamente; pertanto eventuali proposte più lunghe del limite specificato, determineranno automaticamente l’esclusione del proponente dalla procedura. Per il conteggio del limite delle 90 pagine, valgono le seguenti condizioni di formattazione del documento:

• Il font di riferimento per il testo è Times New Roman (piattaforme Windows), Times/Times New Roman (piattaforme Apple) o Nimbus Roman No. 9 L (distribuzioni Linux).

• L'uso di un carattere diverso per il corpo del testo non è consigliabile ed è soggetto alle condizioni cumulative che il carattere sia leggibile e che il suo utilizzo non riduca significativamente la rappresentazione della proposta in numero di pagine rispetto all'utilizzo del font di riferimento (ad esempio in modo da ignorare il limite delle 90 pagine).

• La dimensione minima consentita (per qualsiasi tipo di font) è di 11 punti. Deve essere usata la spaziatura standard tra i caratteri e la minima interlinea deve essere quella singola (non inferiore).

• Gli elementi di testo diversi dal corpo del testo, ad esempio le intestazioni, le note a piè di pagina/note finali, le didascalie, le formule, possono deviare dal vincolo degli 11 punti di font, ma devono essere leggibili.

• La dimensione della pagina è A4 e tutti i margini (in alto, in basso, a sinistra, a destra) devono essere di almeno 15 mm (non inclusive di intestazioni in alto/basso).

16.2 Indice dell’offerta

1. Presentazione generale dell’offerta e del proponente/gruppo proponente

Concisa descrizione dell’offerta e del proponente, con descrizione sintetica di progetti simili di cui si può vantare esperienza.

2. Piano dell’organizzazione dei gruppi di lavoro e metodologie adottate

Descrizione delle modalità tecnico/organizzative con cui il proponente intende organizzare le attività, incluse le figure professionali/profili coinvolti. Breve curriculum del Responsabile di Progetto. Descrizione delle metodologie di sviluppo software che verranno adottate, delle modalità di project management, organizzazione dei task, GANTT di progetto, ecc. I curricula delle altre risorse professionali devono essere presentati in apposita appendice (senza limiti di pagina).

3. Piano di sviluppo software e MEV

Descrizione di come il proponente tecnicamente progetterà e realizzerà quanto descritto al capitolo 5.

8. Piano di collaudo

Specificato al capitolo15.

Document Metadata

Table of Contents

Free Standard Templates

GARA EUROPEA A PROCEDURA APERTA

Document Metadata

Free Standard Templates

GARA EUROPEA A PROCEDURA APERTA

GARA EUROPEA A PROCEDURA APERTA

PER L’APPALTO DI SERVIZI DI SVILUPPO, MANUTENZIONE, ADEGUAMENTO E ASSISTENZA AL SISTEMA INFORMATIVO

DEL FONDO FOR. TE. CIG: 7421028A07

CAPITOLATO TECNICO

Sommario

4.2.1 ACRF - Piattaforma Aderenti Contabilizzazione Risorse Formazione

4.2.1.1 Acquisizione dei dati dal sito INPS.

4.2.1.2 Area Adesioni

4.2.1.4 - Area Accrediti e risorse

4.2.2 – Piattaforma Gestione Avvisi (PGA)

4.2.2.1 - Area Avvisi generali

4.2.2.2 - Area VOUCHER

4.2.3 - Piattaforma CIA (Conti individuali / gruppi aziendali)

4.2.5 – Altre procedure per lo scambio dei flussi

4.2.5.1 - Procedura flussi XML per monitoraggio semestrale del Ministero del Lavoro

4.2.5.2 - Sistema di comunicazione con il Registro Nazionale Aiuti

4.2.6 – Arxivar

6.1.1 Processo di sviluppo

6.1.2 Linee Guida per le attività di sviluppo e documentazione

6.1.3 Documentazione

6.1.4 Avvio in esercizio

6.1.5 Standard per i prodotti software

6.1.6 Accesso per ispezioni di Fondo For.Te.

6.1.7 Accettazione dei prodotti sviluppati

6.3.1 Assistenza via email/Ticketing agli utenti tramite form dedicato

7.2.1 - REQUISITI GENERALI.

TECNOLOGIE E STRUMENTI:

COMPETENZE TRASVERSALI:

7.2.2 - PIANO DI IMPIEGO DELLE FIGURE PROFESSIONALI

Capo progetto

Analista funzionale

Analista programmatore senior

Programmatore junior

Programmatore web

10.1.1 Analisi Preliminare

10.2 Rapporto di analisi dei processi

10.3 Ridisegno dei processi

10.4 Specifiche Funzionali e Progettazione esecutiva

10.5 Mappatura Ridisegno Processi/Specifiche Funzionali

Soddisfazione del committente (SCOM): questo indicatore viene utilizzato per misurare il grado di soddisfazione del committente mediante la somministrazione di questionari.

Orari di servizio: questi indicatori sono utilizzati per definire i periodi temporali in cui si ritiene disponibile e fruibile un determinato servizio. I valori sono espressi in termini di fasce orarie, eventualmente distinte per ciascun giorno della settimana.

11.4.2 Aderenza alla pianificazione delle attività

1. Presentazione generale dell’offerta e del proponente/gruppo proponente

2. Piano dell’organizzazione dei gruppi di lavoro e metodologie adottate

3. Piano di sviluppo software e MEV

8. Piano di collaudo

Document Metadata

Related content