ALLEGATO A – Capitolato Tecnico

2018

SERVIZI INFORMATICI DI PROGETTAZIONE SVILUPPO E GESTIONE SOFTWARE PER AMBIENTE DATA WAREHOUSE E SISTEMI DI BUSINESS INTELLIGENCE

Redatto da: Autostrade per l’Italia S.p.A.

ITS/STW/ADW

Data: 06 marzo 2018

Sommario

Sommario 1

1. Introduzione 4

1.1 Scopo del documento 4

1.2 Definizioni, Acronimi e Abbreviazioni 4

2. Ruolo Unità Organizzativa coinvolta di Autostrade per l’Italia 5

3. Oggetto della fornitura 6

4. Ambito dei servizi 7

4.1 Ambiente tecnologico 7

4.1.1 Livello inerente l’estrazione dei dati dagli ambienti transazionali 7

4.1.2 Livello inerente i servizi di memorizzazione e storicizzazione dei dati 7

4.1.3 Livello inerente la trasformazione e il caricamento dei dati 8

4.1.4 Livello inerente i servizi di interrogazione e analisi dei dati 9

4.2 Ambiente applicativo e funzionalità 11

4.3 Dimensioni componenti applicative 12

5. Categorie di servizi - dettaglio 16

5.1 Coordinamento della fornitura 16

5.2 Nuovi sviluppi 17

5.3 Manutenzione Evolutiva 18

5.4 Supporto Applicativo 19

5.5 Supporto all’utente 19

5.6 Manutenzione Correttiva 19

5.7 Presa in carico del servizio (Start Up) 20

5.8 Rilascio del servizio (Hand Over) 21

6. Gruppo di lavoro - Figure professionali 22

6.1 Figura A – Analista Senior 22

6.1.1 Finalità del ruolo 22

6.1.2 Attività tipiche del ruolo 23

6.1.3 Requisiti minimi 23

6.1.4 Competenze necessarie 23

6.1.5 Ulteriori competenze 24

6.2 Figura B - Programmatore Senior 24

6.2.1 Finalità del ruolo 24

6.2.2 Attività tipiche del ruolo 24

6.2.3 Requisiti minimi 25

6.2.4 Competenze necessarie 25

6.2.5 Ulteriori competenze 26

6.3 Figura C - Programmatore Junior 27

6.3.1 Finalità del ruolo 27

6.3.2 Attività tipiche del ruolo 27

6.3.3 Requisiti minimi 27

6.3.4 Competenze necessarie 27

6.3.5 Ulteriori competenze 27

6.4 Elementi migliorativi del Gruppo di Lavoro 29

6.4.1 Miglioramento del Titolo di Istruzione delle risorse 29

6.4.2 Certificazioni individuali delle risorse 29

6.4.3 Esperienza specifica della Società Concorrente 29

6.5 Sostituzione di una risorsa 29

7. Erogazione dei servizi 31

7.1 Sede di lavoro e strumenti 31

7.2 Orario di servizio 31

7.3 Tabella dei servizi 32

7.4 Presa in carico del servizio (Start Up) 33

7.5 Coordinamento della fornitura 33

7.6 Nuovi Sviluppi e Manutenzione evolutiva 35

7.6.1 Procedura di escalation 35

7.6.2 Criteri di accettazione 35

7.7 Supporto Applicativo e Supporto all’utente 37

7.8 Manutenzione Xxxxxxxxxx 00

7.9 Rilascio del servizio (Hand Over) 39

8. Modello di governance e matrice delle responsabilità 41

8.1 Ruoli lato Autostrade per l’Italia 41

8.2 Ruoli lato Fornitore 42

8.3 Matrice delle responsabilità 43

8.4 Responsabilità nel Trattamento dei dati personali 44

9. Livelli di Servizio 45

9.1 SLA per Manutenzione Correttiva 45

9.1.1 Severità degli errori 45

9.1.2 SLA_01_MC – Tempestività nella risoluzione delle anomalie 46

9.1.3 SLA_02_MC – Correttezza delle soluzioni di malfunzionamenti 47

9.2 SLA per Manutenzione Evolutiva e Nuovi Sviluppi 48

9.2.1 SLA_03_EV – Tempestività nella consegna dei Documenti di Fattibilità 48

9.2.2 SLA_04_EV – Rispetto dei tempi di completamento attività 48

9.3 SLA per l’Adeguatezza del gruppo di lavoro 50

9.3.1 Titolo di Studio delle risorse 50

9.3.2 Certificazioni Individuali 50

9.3.3 Esperienza su DW e BI nel settore autostradale 50

9.4 SLA per la Stabilità del gruppo di lavoro 51

9.4.1 SLA_05_GL – Limitazione del Turn-over delle risorse 51

9.4.2 SLA_06_GL – Rispetto dei tempi di preavviso per la sostituzione di una risorsa 51

9.4.3 SLA_07_GL – Rispetto dei tempi di sostituzione di una risorsa 52

10. Garanzia 53

11. Penali 54

12. Riferimento Autostrade per l’Italia 56

13. Modelli standard 57

13.1 Modello 1 – Formalizzazione del Gruppo di Lavoro 58

13.2 Modello 2 – Verbale di Presa in Carico del Servizio 59

13.3 Modello 3 – Ordinativo di Lavoro / Verbale di Collaudo 60

13.4 Modello 4 – Documento di Prefattibilità 61

13.5 Modello 5 – Sintesi delle attività 63

13.6 Modello 6 – Piano Qualità 64

1. Introduzione

1.1 Scopo del documento

Il presente Capitolato Tecnico ha l’obiettivo di descrivere e classificare le varie attività nell’ambito della gara europea relativa all’erogazione di “Servizi informatici di progettazione, sviluppo e gestione software ambiente Data Warehouse e sistemi di Business Intelligence” per l’unità organizzativa ITS/STW/ADW di Autostrade per l’Italia (di seguito anche ASPI).

Il Capitolato Tecnico viene a disciplinare le categorie dei servizi richiesti, le relative modalità d’erogazione, le figure professionali necessarie a costituire il Gruppo di Lavoro, i livelli di servizio attesi e le relative penali in caso di mancato rispetto dei livelli stessi.

Il Capitolato Tecnico consentirà quindi ai concorrenti di poter formulare un’offerta economica per la fornitura dei suddetti Servizi.

1.2 Definizioni, Acronimi e Abbreviazioni

DW: Data Warehouse ("magazzino di dati") è un archivio informatico contenente i dati di un'organizzazione, progettati per consentire di produrre facilmente analisi e report utili a fini decisionali.

BI: Business Intelligence, insieme di tecniche e strumenti informatici finalizzati ad acquisire e manipolare masse di dati presenti su database o altre tipologie di archivi per fornire report, statistiche, indicatori, grafici costantemente aggiornati, facilmente adattabili e configurabili alle esigenze dell'utente.

ASPI: Autostrade per l’Italia.

ITS: IT e Sviluppo tecnologico, Funzione di ASPI responsabile di garantire lo sviluppo e la manutenzione del sistema informatico aziendale.

STW: Sistemi di Traffico e data Warehouse, unità organizzativa di ASPI facente parte di ITS e responsabile di garantire lo sviluppo e la manutenzione delle applicazioni informatiche per la gestione del Traffico e dei sistemi di Data Warehouse.

ADW: Applicazioni tecniche e Data Warehouse, struttura di ASPI facente parte di ITS/STW, responsabile di garantire lo sviluppo e la manutenzione dei sistemi di Data Warehouse e richiedente i servizi oggetto della presente gara d’appalto.

RIA: Responsabile Informatico di un’Applicazione. Figura definita nell’organizzazione interna di ASPI, con il ruolo di supervisionare lo sviluppo, la manutenzione e l’evoluzione di una o più applicazioni informatiche. Anche Responsabile Applicativo.

RUP: Responsabile Unico del Procedimento. Figura nominata dalla stazione appaltante, prevista dal Codice degli appalti, che vigila sullo svolgimento delle fasi di progettazione, affidamento ed esecuzione dell’intervento e provvede a creare le condizioni affinché il processo realizzativo risulti condotto in modo unitario in relazione ai tempi e ai costi preventivati, alla qualità richiesta, alla manutenzione programmata, alla sicurezza e alla salute dei lavoratori e in conformità alle disposizione di legge in materia.

DEC: Direttore dell’Esecuzione del Contratto. Figura nominata dalla stazione appaltante, prevista dal Codice degli appalti, che coadiuva il RUP nel coordinamento, direzione e controllo tecnico-contabile dell’esecuzione del contratto stipulato dalla stazione appaltante, in modo da assicurarne la regolare esecuzione.

RT: Referente Tecnico del contratto: figura nominata dall’Appaltatore e deputata al coordinamento organizzativo dell’attività lavorativa del personale impiegato nella esecuzione delle attività oggetto del contratto, nonché interfaccia nei confronti della Committente per qualsiasi esigenza ad esso connessa.

2. Ruolo Unità Organizzativa coinvolta di Autostrade per l’Italia

L’Unità “IT e Sviluppo Tecnologico/Sistemi di Traffico e Datawarehouse” (ITS/STW) rappresenta la

struttura di Autostrade per l’Italia incaricata della erogazione dei servizi IT di sviluppo/manutenzione, relativamente alle applicazioni gestionali e di base di competenza.

All’interno di ITS/STW l’Unità denominata “Applicazioni Tecniche e Data Warehouse” (ADW) coordina ed ha la responsabilità in particolare delle attività di:

- Progettare, realizzare e gestire sistemi di tipo Data Warehouse (DW), per consentire attività di query e reporting sulle informazioni provenienti dalle singole procedure informatiche operazionali e grazie a un'integrazione e correlazione di tali dati nell'ambiente DW, consentire analisi storiche e di confronto su più aree tematiche. Ha inoltre la responsabilità di allestire i relativi processi di caricamento delle informazioni verso il DW.

- Progettare, realizzare e gestire sistemi di Business Intelligence (BI) per la presentazione di KPI e cruscotti sui principali indicatori di business, avvalendosi del contenuto di dati e di informazioni delle varie aree tematiche presenti nel DW.

Tali servizi sono erogati verso ASPI e, in maniera più o meno estesa verso le altre società del

Gruppo Autostrade e verso alcune società non del Gruppo che hanno contrattualizzato un servizio di elaborazione dati.

Nell’ambito dei sistemi di Data Warehouse e Business Intelligence sono definiti numerosi moduli tematici che prendono il nome di “Applicazioni” e che saranno descritti in dettaglio nel paragrafo 4.3.

L’organizzazione interna della struttura ADW prevede che ciascuna Applicazione sia presidiata da un referente applicativo denominato RIA – Responsabile Informatico dell’Applicazione, che ha il compito di assicurarne la manutenzione correttiva ed evolutiva, il supporto e tutti gli altri servizi inerenti ad essa.

ADW, nell’ambito delle attività previste in tale Capitolato, manterrà il ruolo di project management e parteciperà con propri specialisti a tutte le fasi.

3. Oggetto della fornitura

Sono oggetto di fornitura i servizi informatici di progettazione, sviluppo e gestione software per ambiente Data Warehouse e sistemi di Business Intelligence.

Le attività previste dall’appalto sono riconducibili alle seguenti categorie di servizio:

• Coordinamento della fornitura: azioni necessarie per la corretta conduzione e coordinamento delle attività e del gruppo di lavoro messo a disposizione dal Fornitore per l’erogazione di tutti i servizi oggetto della fornitura.

• Nuovi sviluppi: analisi, progettazione e realizzazione di nuove componenti di software applicativo, che si rendono necessarie a seguito di richieste utente e di nuove necessità di business, negli ambienti Data Warehouse e Business Intelligence.

• Manutenzione Evolutiva (compresa adattativa, preventiva, migliorativa): modifica e/o aggiunta di nuove funzionalità e sviluppo di nuove componenti applicative, che si rendono necessarie a seguito di nuove esigenze o di richieste di implementazioni funzionali o architetturali atte a far evolvere i sistemi/applicazioni, negli ambienti Data Warehouse (DW) e Business Intelligence (BI).

• Supporto Applicativo: attività di supporto applicativo o legato alle conoscenze funzionali dei sistemi in ambito DW e BI. Tutti gli interventi rientranti in tale categoria non implicano alcuna modifica o correzione al codice applicativo.

• Supporto all’utente: rientrano in tale categoria tutti gli interventi di supporto agli utenti finali, mirati a consentire loro un utilizzo autonomo e corretto delle funzionalità e dei contenuti disponibili nel contesto applicativo oggetto di bando di gara, per gli ambiti DW e BI.

• Manutenzione Correttiva: azioni intraprese per identificare e rimuovere difetti (errori del codice e/o problemi di usabilità) che richiedono interventi sul codice dell’applicazione che non risulta conforme alle specifiche tecniche concordate e documentate. Il servizio riguarda esclusivamente componenti applicative installate in esercizio, per gli ambiti DW e BI.

Ai precedenti servizi sono da aggiungere altre due categorie di servizio, limitate nel tempo rispettivamente alla fase di avvio del Contratto e alla fase di conclusione del medesimo:

• Presa in carico del servizio (Start Up)

• Rilascio del servizio (Hand Over)

Nel capitolo 5 saranno descritti in maniera dettagliata la natura di ogni categoria di servizio e le attività che si richiede doversi svolgere nell’ambito della fornitura.

I Servizi sopra elencati saranno erogati secondo un modello di gestione descritto nel capitolo 7 di questo Capitolato Tecnico.

4. Ambito dei servizi

In questo capitolo vengono descritti gli ambienti tecnologico e applicativo, vengono fornite informazioni su numerosità e dimensioni dei componenti della piattaforma di Data Warehouse (DW) e Business Intelligence (BI), vengono infine descritte le attività peculiari per i servizi oggetto del contratto.

4.1 Ambiente tecnologico

Viene di seguito fornito il dettaglio dell’ambiente tecnologico e funzionale di riferimento.

In Autostrade per l’Italia i sistemi di DW e di BI sono strutturati su tre livelli operativi logicamente distinti:

4.1.1 Livello inerente l’estrazione dei dati dagli ambienti transazionali

Data la ricchezza tecnologica e architetturale del portafoglio delle applicazioni di Autostrade per l’Italia, le tipologie di sorgenti dati che alimentano l’ambiente DW (su cui si basano i sistemi di BI) sono molteplici:

• Oracle

• IBM DB2-UDB

• IBM DB2-ZOS

• Lotus Notes

• Microsoft SQL Server

• Postgres

• File (csv, excel, ecc..)

• SAP Business Warehouse

Le logiche di estrazione dagli ambienti sorgente sono definite sulla base dei requisiti utente e in collaborazione con i responsabili Informatici dell’applicazione che li gestisce.

4.1.2 Livello inerente i servizi di memorizzazione e storicizzazione dei dati

Data Modeling:

Risulta centrale, per questo livello, l’attività di progettazione della banca dati target (in modalità star-schema, snow-flake, oppure E- R) con l’utilizzo dei tool di Data Modeling:

Tool

Versione

Descrizione

XXxxx Data Modeler (Workgroup

Edition)

9.6

Client per la Gestione dei Modelli dati

XXxxx Mart Administrator

9.6

Portale per la Gestione del Repository XXxxx e degli Utenti Abillitati

Piattaforma principale di DW:

- La piattaforma tecnologica di riferimento per i servizi di memorizzazione e di storicizzazione dei dati del DW si basa su un database IBM DB2-UDB IBM 10.5 (di dimensioni attuali pari a 700 GB) installato su server AIX.

- Lo schema di organizzazione e ritenimento dei dati è perlopiù di tipo star-schema e/o snowflake.

Piattaforma accessoria per ottimizzazione accessi:

- Per l’ottimizzazione di query ed analisi particolarmente onerose, in alcuni casi i dati vengono caricati sulla piattaforma tecnologica accessoria costituita dal database con opzioni colonnare/in memory: IBM DB2 11.1.2 for Linux, Unix and Windows with BLU Acceleration, installato su server AIX.

Piattaforma Big Data:

- Per la memorizzazione di dati con volumi particolarmente elevati e/o di tipo non strutturato o semi-strutturato, in alcuni casi i dati vengono caricati sulla piattaforma Big Data costituita da Hortonworks + IBM BigSQL.

In dettaglio, tale piattaforma comprende i seguenti Servizi:

Tool	Versione	Descrizione
HDFS	2.7.3	Apache Hadoop Distributed File System
YARN + MapReduce2	2.7.3	Apache Hadoop NextGen MapReduce (YARN)
Tez	0.7.0	Tez is the next generation Hadoop Query Processing framework written on top of YARN.
Hive	1.2.1000	Data warehouse system for ad-hoc queries & analysis of large datasets and table & storage management service
HBase	1.1.2	A Non-relational distributed database, plus Phoenix, a high performance SQL layer for low latency applications.
Pig	0.16.0	Scripting platform for analyzing large datasets
Sqoop	1.4.6	Tool for transferring bulk data between Apache Hadoop and structured data stores such as relational databases
Oozie	4.2.0	System for workflow coordination and execution of Apache Hadoop jobs. This also includes the installation of the optional Oozie Web Console which relies on and will install the ExtJS Library.
ZooKeeper	3.4.6	Centralized service which provides highly reliable distributed coordination
Falcon	0.10.0	Data management and processing platform
Storm	1.1.0	Apache Hadoop Stream processing framework
Flume	1.5.2	A distributed service for collecting, aggregating, and moving large amounts of streaming data into HDFS
Accumulo	1.7.0	Robust, scalable, high performance distributed key/value store.
Ambari Infra	0.1.0	Core shared service used by Ambari managed components
Ambari Metrics	0.1.0	A system for metrics collection that provides storage and retrieval capability for metrics collected from the cluster
Atlas	0.8.0	Atlas Metadata and Governance platform
Xxxxx	0.10.1	A high-throughput distributed messaging system
Xxxx	0.12.0	Provides a single point of authentication and access for Apache Hadoop services in a cluster
SmartSense	1.4.2.2.5.2.0 -298	SmartSense - Hortonworks SmartSense Tool (HST) helps quickly gather configuration, metrics, logs from common HDP services that aids to quickly troubleshoot support cases and receive cluster-specific recommendations.
Spark	1.6.x	Apache Spark is a fast and general engine for large-scale data processing.
Spark2	2.x	Apache Spark is a fast and general engine for large-scale data processing
Zeppelin Notebook	0.7.2	A web-based notebook that enables interactive data analytics. It enables you to make beautiful data-driven, interactive and collaborative documents with SQL, Scala and more.
IBM Big SQL	5.0.0.0	SQL on Hadoop
Big SQL DSM	2.1.3.0	Data Server Manager: Tool for administering, monitoring and managing the performance of Big SQL.
Druid	0.9.2	A fast column-oriented distributed data store. This service is Technical Preview.
Mahout	0.9.0	Project of the Apache Software Foundation to produce free implementations of distributed or otherwise scalable machine learning algorithms focused primarily in the areas of collaborative filtering, clustering and classification
Slider	0.92.0	A framework for deploying, managing and monitoring existing distributed applications on YARN.

4.1.3 Livello inerente la trasformazione e il caricamento dei dati

I dati transazionali estratti dai sistemi sorgente sono trasformati, aggregati e riconciliati in informazioni con ulteriore valore aggiunto sia di tipo analitico che di tipo strategico; essi infine vengono inseriti nell’ambiente DW.

ETL:

Le fasi di caricamento nella banca dati del DW utilizzano varie tecnologie:

• Script di comandi UNIX/AIX (korn shell, bash shell) e di comandi SQL, Oracle PL/SQL, DB2 SQL PL;

• Codice Java generato con la piattaforma ETL Talend Open Studio v. 6.2;

• Programmi JAVA custom.

Strumenti di operatività:

• Filezilla, Putty, Winscp, Bladelogic

Ambiente di Schedulazione:

Indipendentemente dalla tecnologia con cui sono realizzati, i programmi di elaborazione e caricamento sono schedulati con opportuna frequenza attraverso lo schedulatore aziendale:

• BMC Control-M version 8.0

la cui gestione non rientra nell’ambito di questa gara.

E’ comunque cura del Fornitore indicare le concatenazioni logiche e temporali tra i programmi di alimentazione che saranno implementate in Control-M dall’apposita Unità Organizzativa aziendale.

L’interfaccia Control-M Workload Automation è poi utilizzata dal Fornitore in sola consultazione per monitorare l’andamento dei flussi alimentanti in tempo reale.

Sistemi di controllo versione:

• GIT , SVN

4.1.4 Livello inerente i servizi di interrogazione e analisi dei dati

I dati all'interno del DW (sia in forma aggregata che di dettaglio) sono organizzati in Applicazioni, ciascuna delle quali comprende una o più viste logiche della banca dati DW (universi) relative a specifici argomenti, report di tipo aziendale e personale.

Ogni applicazione si basa su una delle seguenti piattaforme di Business Intelligence di front-end:

Piattaforma front-end SAP Business Objects:

- E’ la piattaforma front-end di riferimento, maggiormente diffusa tra gli utenti finali, è in esercizio nella versione BI 4.2. In dettaglio, tale piattaforma comprende i seguenti tool:

Tool	Versione	Descrizione	Tipo accesso
BILaunchPad	4.2	Portale di Business Intelligence	Web
WebIntelligence	4.2	Reporting per BI e QRA	Web/Desktop
BI WorkSpace/Modulo	4.2	Cruscotti per visualizzazione contenuti analitici dell'ambiente BI	Web
Lumira	4.2	Analisi dati self service e story telling	Web/Desktop
BO Explorer	4.2	Self service BI con supporto degli spazi informativi	Web
Business Objects Analysis for OLAP	4.2	Client web per connessione a sorgenti OLAP in modalità MDAS	Web
WebI Rich Client	4.2	Versione desktop di WebI	Desktop
Widgets	4.2	Elementi analitici da inserire nel desktop del PC utente	Desktop
Live Office	4.2	Add-in per pacchetto office per la realizzazione di documenti MS Office arricchiti con elementi di BI	Desktop
Central Configuration Manager	4.2	Amministrazione server BI4	Desktop
Universe Design Tool	4.2	Universe designer tradizionale	Desktop
Data Federation Admin	4.2	Interfaccia per amministrazione e tuning di query lanciate mediante servizio di federation	Desktop
Information Design Tool	4.2	Universe designer multisorgente	Desktop
QaaWS Designer	4.2	Client per la realizzazione di query in modalità web service	Desktop
Report Conversion Tool	4.2	Conversione di formato binario da DeskI a WebI	Desktop
Translation Management Tool	4.2	Client per la localizzazione delle label degli universi nelle diverse lingue	Desktop
Upgrade Management Tool	4.2	Client di migrazione da versioni 3.x e precedenti	Desktop
wdeploy	4.2	Client per l'installazione delle web application	Desktop

Tool	Versione	Descrizione	Tipo accesso
SAP BusinessObjects Dashboards (già XCelsius)	4.2	Cruscotti in tecnologia Flash	Web/Desktop
Design Studio	4.2	Erede di Dashboard (aka Xcelsius), per la realizzazione di cruscotti HTML5/CSS3	Desktop
SAP Data Integrator/Data Services	4.2	Piattaforma integrata di ETL e Data Quality	Desktop
Business View Manager	4.2	Strumento amministrativo per la creazione di viste per report Crystal (desueto)	Desktop
Crystal Report	4.2	Strumento produzione di reporting Pixel Perfect	Web
Mobile BI	4.2	Interfaccia di fruizione via App per smartphone/tablet (Android e IOs)	Web

Piattaforma front-end SPAGOBI:

- Piattaforma front-end open source, con un utilizzo interno limitato ad alcune aree tematiche, ed utilizzata nel caso di realizzazione di sistemi di DW e reporting per gare a cui ASPI partecipa come fornitore. E’ in esercizio nella versione 3.6. In dettaglio, tale piattaforma comprende i seguenti tool:

JasperReport, BIRTReport (reporting); JFreeChart, HighCharts (dashboard); JPivot, JPalo (OLAP); QBE, Smart Filter (interrogazioni libere); MobileTable, MobileChart, MobileCockpit, MobileKPI (mobile).

Piattaforma di Predictive Analysis IBM SPSS:

- Piattaforma per l’individuazione, partendo dai dati del DW, di informazioni non esplicitamente memorizzate nel database. Si basa sull’utilizzo di algoritmi statistici e di machine learning e sulla metodologia di data mining CRISP-DM (Cross-Industry Standard Process for Data Mining). In dettaglio, tale piattaforma comprende i seguenti tool:

Tool

Versione

Descrizione

IBM SPSS

Modeler

18.0

Client con interfaccia grafica che mette a disposizione una vasta gamma di strumenti di data mining adatti a vari tipi di problematiche: classificazione, clustering, analisi eccezioni, analisi

serie temporali.

IBM SPSS

Modeler Server

18.0

E’ installato su un host server e consente a SPSS Modeler di ottenere prestazioni migliori quando si lavora su insiemi di dati di grandi dimensioni, in quanto le operazioni che richiedono un utilizzo consistente della memoria possono essere eseguite sul server senza scaricare i dati sul

computer client.

IBM SPSS

Modeler Text

Analytics

18.0

Offre funzionalità di analisi testuale, che utilizzano tecnologie linguistiche avanzate e di Natural Language Processing (NLP) per elaborare dati di testo non strutturati e, da questo testo, estrarre

e organizzare i concetti chiave.

IBM SPSS

Modeler Entity Analytics

18.0

Aggiunge una dimensione supplementare alle analisi predittive di IBM SPSS Modeler: l'analisi delle Entità si concentra sul miglioramento della coerenza dei dati correnti risolvendo i conflitti tra gli stessi record. Un'identità può essere un individuo, un'organizzazione, un oggetto o

qualsiasi altra entità per cui possa esistere ambiguità.

Sviluppi custom:

- Framework di sviluppo: Eclipse

- Linguaggi di programmazione: Java; HTML; JSP; XML; XSLT; Java Script; CSS.

- Sistemi di reporting embedded: Ireport, Jaspersoft Studio

Gli ambienti Operativo e di Sviluppo/Test sono sostanzialmente omogenei. Per tutte le aree applicative in ambito del presente servizio e per l’intera durata del servizio, ASPI metterà a disposizione un ambiente di Sviluppo/Test e si farà carico di mantenerlo sostanzialmente allineato all’ambiente di Produzione, in modo da consentire la riproduzione di eventuali anomalie che dovessero presentarsi in esercizio.

In ogni caso il Fornitore si adopererà per gestire al meglio sia la risoluzione di anomalie sia il rilascio di nuove funzionalità anche qualora vi siano disallineamenti temporanei tra gli ambienti di Sviluppo/Test e Produzione.

4.2 Ambiente applicativo e funzionalità

L’ambito delle attività riguarda allo stato attuale le seguenti Aree tematiche, corrispondenti a raggruppamenti di Applicazioni:

• DW Infrastruttura

• DW Area tematica Aree di Servizio (AdS)

• DW Area tematica Crediti

• DW Area tematica Esazione

• DW Area tematica Gestionale/Amministrativo

• DW Area tematica Gestione infrastrutture IT

• DW Area tematica Groupware e Intranet

• DW Area tematica Monitoraggio Impianti

• DW Area tematica Punti Blu

• DW Area tematica Telepass

• DW Area tematica Traffico

• DW Area tematica Viabilità

La tabella seguente mostra le applicazioni contenute in ciascun Raggruppamento:

Raggruppamento Applicazioni	Num. Applic azioni	Codici delle applicazioni
DW Infrastruttura	2	IDW	IOS
DW Area tematica AdS	5	IAS	IAV	IMA	IVR	IGO
DW Area tematica Crediti	6	ICI	IFA	IGI	IRC	ITE	IUD
DW Area tematica Esazione	3	ICM	ICP	IQS
DW Area tematica Gestionale/Amministrativo	3	ICA	IGS	IHD
DW Area tematica Gestione infrastrutture IT	6	IAB	IKI	IKP	ILA	IMD	ITM
DW Area tematica Groupware e Intranet	6	IG2	IGE	IGR	IID	IPC	IPT
DW Area tematica Monitoraggio Impianti	4	IEM	IIG	IIS	IIW
DW Area tematica Punti Blu	1	IPB
DW Area tematica Telepass	8	ICC	IEU	IGD	IMS	IPE	ITL	IVS	IWT
DW Area tematica Traffico	3	IPR	ISP	IST
DW Area tematica Viabilita	8	ICT	IEV	IIF	IMT	INC	IPM	IRE	ISM
TOTALE RAGGRUPPAMENTI APPLICAZIONI: 12
TOTALE APPLICAZIONI:	55

4.3 Dimensioni componenti applicative

Di seguito viene riportata la consistenza delle varie componenti che costituiscono i sistemi/applicazioni oggetto del servizio richiesto. L’elenco è riportato a titolo informativo e non vincolante, essendo i sistemi informatici di ASPI in piena evoluzione.

Raggr.

Applicazioni

Applicazion e

Cod. Appl.

Descrizione applicazione

Fonti Alimenta

nti

Progr. Alimenta

nti

Oggetti DB (tab e viste)

Num utenti

Soc. abiliate

Ticket 2017

Infrastruttura

Piattaforma tecnologica Data Warehouse

IDW

Piattaforma tecnologica del Data Warehouse di gruppo (Database, programmi di alimentazione, suite di prodotti di accesso al sistema, connettore Active Directory ecc.) sulla quale vengono sviluppati i singoli moduli specializzati.

405

Sistema di Business Intelligence

IOS

Piattaforma tecnologica Open Source di Business Intelligence che consente, sui relativi moduli informativi, di effettuare analisi tramite la navigazione dei dati con strumenti ad hoc.

Infrastrutt.

Raggr.

Applicazioni

Applicazion e

Cod. Appl.

Descrizione applicazione

Fonti Alimenta nti

Progr. Alimenta nti

Oggetti DB (tab e viste)

Num utenti

Soc. abiliate

Ticket 2017

DW Area tematica AdS

Info aree di servizio fino 2004

IAS

Applicazione DW che consente la consultazione dei dati di Monitoraggio AdS ante 2005: anagrafiche, qualità, fatturato, cartelli pubblicitari.

Info Contr. Venduto e Royalties in ambito Ads

IAV

Info Contr. Venduto e Royalties in ambito Ads (2004-2015). Sistema di Reporting on demand per l'effettuazione di query libere direttamente sul gestionale sorgente (CMA).

196

Info Monitor. Aree di

Servizio

IMA

Modulo DW che permette di analizzare i dati di venduto e corrispettivi delle ads per singolo marchio (affidatario).

Info CTR, Venduto e Royalties Ads

IVR

Sistema di Reporting on demand per l'effettuazione di query libere direttamente sul database operazionale della procedura CVR (Gestione Contratti, Venduto e Royalties in ADS).

120

Info Non Conformità rilevate in

Ads

IGO

Sistema di Business Intelligence per il performance mangement del processo di gestione delle Non Conformità Commerciali.

DW Area tematica AdS

384

Raggr.

Applicazioni

Applicazion e

Cod. Appl.

Descrizione applicazione

Fonti Alimenta

nti

Progr. Alimenta

nti

Oggetti DB (tab e viste)

Num utenti

Soc. abiliate

Ticket 2017

DW Area tematica Crediti

Info Crediti recupero danni Incidenti

ICI

Modulo DW contenente informazioni relative al processo di recupero danni alle infrastrutture autostradali causate da incidenti (sia attivi che passivi).

Info Fatturaz.

IFA

Modulo per l'analisi del fenomeno della fatturazione dei Telepass e del Viacard. Dati estratti da procedura Fatturazione.

Info Gestione Immagini

IGI

Modulo DW per il monitoraggio dei dati alfanumerici delle foto ai veicoli coinvolti in situazioni irregolari al momento del pedaggio.

Info Recupero Crediti

IRC

Modulo che contiene le informazioni relative al mondo del Recupero crediti, incrociando i dati provenienti dalla procedure CRC con quelli provenienti dalla procedura solleciti di Gestione

Clienti.

Info trasporti Eccezionali

ITE

Modulo DW che consente di effettuare indagini su alcuni degli aspetti principali del fenomeno dei trasporti Eccezionali, quali le Richieste Autorizzazioni, gli Attestati di Transito, i Riparti Società, l'Anagrafica dei Clienti, i Rilevamenti Sala Radio.

Info Utenti Debitori

IUD

Modulo DW contenente il dettaglio dei singoli Rapporti Mancato Pagamento (RMPP), emessi dalle società concessionarie che utilizzano la procedura TUD.

DW Area tematica Crediti

117

177

Raggr.

Applicazioni

Applicazion e

Cod. Appl.

Descrizione applicazione

Fonti Alimenta nti

Progr. Alimenta nti

Oggetti DB (tab e viste)

Num utenti

Soc. abiliate

Ticket 2017

DW Area tematica Esazione

Info Anomalie MCT

ICM

Applicazione DW che consente il monitoraggio del dettaglio delle anomalie gestite da Monitoraggio Centralizzato Tronchi corredate dagli indicatori quantitativi e temporali che consentono di misurare il processo.

Attività personale esazione

ICP

Cruscotto e sistema di query libere per il monitoraggio delle attività del personale di Esazione. Comprende indicatori relativi alle attività svolte, alle presenze, alle trasferte, alla produttività.

114

Info Qualità di Stazione

IQS

Modulo Data Warehouse che attinge dati da varie applicazioni sorgente per calcolare gli indicatori di qualità delle Stazioni: Transiti, RMPP. Anomalie MCT ecc...

DW Area tematica Esazione

133

Raggr.

Applicazioni

Applicazion e

Cod. Appl.

Descrizione applicazione

Fonti Alimenta nti

Progr. Alimenta nti

Oggetti DB (tab e viste)

Num utenti

Soc. abiliate

Ticket 2017

DW Area tematica Gestionale/Am ministrativo

Info Cost Accounting

ICA

Sistema di Reporting ed analisi sui dati relativi al processo di Cost Accounting.

Info Gestione Sicurezza personale

IGS

Modulo DW per la Reportistica e l'Analisi dei dati dell'applicazione PGS (Sistema della Sicurezza di S2S-prodotti per adempimenti L.626), relativo a rischi, visite mediche, formazione, consegna dispositivi ecc..

234

Distribuzion e dati Anagrafica

Personale

IHD

Flusso batch di estrazione dei dati dell'anagrafica dei Dipendenti da SAP HR e di distribuzione ad altre applicazioni (es: Provisioning).

DW Area tematica Gestionale/A mministr.

294

Raggr.

Applicazioni

Applicazion e

Cod. Appl.

Descrizione applicazione

Fonti Alimenta nti

Progr. Alimenta nti

Oggetti DB (tab e viste)

Num utenti

Soc. abiliate

Ticket 2017

DW Area tematica Gestione infrastrutture IT

Abilitazioni SW

applicativo

IAB

Applicazione DW che consente di verificare, in modalità report predefiniti e self-service, le abilitazioni applicative assegnate agli utenti.

Info KPI della funzione ITS

IKI

Sistema di indicatori chiave delle performance della Funzione ITS. Modulo Data Warehouse per il monitoraggio dei suddetti indicatori relativi agli ambiti: economico, attività di change, operativo ecc..

Info Key Performance Indicator

IKP

Sistema di indicatori chiave delle performance della struttura SNF Sistemi Informativi in ambito della Funzione ITS.

Info Log Accessi

ILA

Modulo DW che consente di monitorare l'accesso degli utenti ad alcune applicazioni critiche dal punto di vista della riservatezza dei dati. Alimentato con i log accessi delle applicazioni: TET - ETS - EFA.

Info MetaDati DW

IMD

Info MetaDati DW - Universi e report per il monitoraggio della piattaforma Data Warehouse, ad uso della struttura interna di sviluppo e manutenzione.

Info Telefonia

Mobile

ITM

Modulo Data Warehouse per la Reportistica e l'Analisi della Gestione della Telefonia Mobile

DW Area tematica Gestione infrastrutt. IT

168

Raggr.

Applicazioni

Applicazion e

Cod. Appl.

Descrizione applicazione

Fonti Alimenta nti

Progr. Alimenta nti

Oggetti DB (tab e viste)

Num utenti

Soc. abiliate

Ticket 2017

DW Area tematica Groupware e Intranet

Info Gestione

moduli FC02

IG2

Modulo Data Warehouse per la Reportistica e l''Analisi dei moduli FC02 compilati al Pblu.

Modulo Analisi dati email dei

clienti

IGE

Info e-mail inviate da clienti e utenti non identificabili e ricevute da ASPI. Alimentato sia a partire dalle caselle Notes sia da Gestione Clienti.

Info Gestione Reclami

IGR

Modulo Data Warehouse per la Reportistica e l'Analisi dei Reclami inviati da utenti e clienti e convogliati nel sistema Notes.

Info Intranet Domino

IID

Modulo DW che consente l'analisi e il monitoraggio degli accessi utente ai portali aziendali su piattaforma server HTTP Domino. Caricato settimanalmente con i log.

Reportistica su posta certificata

IPC

Modulo di reportistica dedicato al monitoraggio della Posta Certificata. I dati risiedono nel database operazionale dell'applicazione NEC (Pec manager).

Info Portale Talent

IPT

Modulo di reportistica verticale, realizzato all'interno della piattaforma standard di business intelligence, direttamente sul database operazionale della procedura PCT - Portale Communication and Talent. Consente di monitorare i principali indicatori di accesso e di effettuare analisi di dettaglio sulle attività svolte dagli utenti nelle varie sezioni del portale.

DW Area tematica Groupware e

Intranet

133

Raggr.

Applicazioni

Applicazion e

Cod. Appl.

Descrizione applicazione

Fonti Alimenta nti

Progr. Alimenta nti

Oggetti DB (tab e viste)

Num utenti

Soc. abiliate

Ticket 2017

DW Area tematica Monitoraggio Impianti

Info Energy Management

IEM

Modulo Data Warehouse per la Reportistica e l'Analisi a supporto della Gestione delle iniziative nel campo del risparmio energetico (Energy Management). Comprende dati di anagrafica dei Point of Delivery, dei relativi consumi fatturati mensilmente e, in prospettiva, delle misurazioni interne di controllo.

Info Impianti

Galleria

IIG

Applicazione Data Warehouse per la Reportistica e l''Analisi dei dati degli Impianti in galleria.

Info Interventi su

strutture

IIS

Modulo Data Warehouse per la Reportistica e l'Analisi dei dati del Sistema di WFM Ispezioni Strutture (CSI).

Info WFM Manutenzion e Impianti (m2i)

IIW

Modulo Data Warehouse per la Reportistica e l'analisi libera dei dati del sistema di Manutenzione Impianti. Comprende le informazioni anagrafiche degli impianti e del personale manutentore, i turni erogati per la manutenzione e i dati degli interventi (Cicli di lavoro, ODL, Consuntivi). Alimentato a

partire da M2I (CIW).

DW Area tematica Monitor.

Impianti

112

Raggr.

Applicazioni

Applicazion e

Cod. Appl.

Descrizione applicazione

Fonti Alimenta nti

Progr. Alimenta nti

Oggetti DB (tab e viste)

Num utenti

Soc. abiliate

Ticket 2017

DW Area tematica Punti Blu

Info Punti BLU

IPB

Modulo che consente di effettuare indagini sulle attività svolte nei P.Blu, sulla vendita articoli, sulla dematerializzazione dei documenti, sulla produttività e sui PBlu Express.

DW Area tematica

Punti Blu

Raggr.

Applicazioni

Applicazion e

Cod. Appl.

Descrizione applicazione

Fonti Alimenta nti

Progr. Alimenta nti

Oggetti DB (tab e viste)

Num utenti

Soc. abiliate

Ticket 2017

DW Area tematica Telepass

Info Clienti e Contratti

ICC

Info Clienti e Contratti. Contiene l'intera Customer Base di Telepass, alimentata da varie fonti (Gestione Clienti, Fatturazione, consumi ecc..). Aggiornata ogni notte, è utilizzata sia per consultazioni dei dati dei clienti, sia per estrazioni di indirizzi, e-mail e numeri telefonici per campagne di marketing e

ricerche di mercato.

268

107

Info pedaggi e consumi TLP Europa

IEU

Modulo DW che consente di monitorare i dati dei pedaggi da transito e da eventuali altri consumi effettuati dai clienti Telepass in ambito Europeo.

Info Gestione contatti con i clienti

IGD

Modulo per il monitoraggio dei documenti relativi ai contatti (fax, lettere, web-form) con i clienti relativi ai sistemi di pagamento, alimentato con i dati della gestione documentale di Gestione Clienti.

Info Monitor. Supply chain Telepass

IMS

Modulo Data Warehouse per il monitoraggio della supply chain di Telepass e per il calcolo dei relativi indici di performance. Si focalizza sulle richieste di Opzioni Premium e sulle tempistiche di evasione.

Info Pagamento Elettronico

IPE

Modulo che consente di effettuare indagini sui movimenti gestionali relativi a Contratti, Titoli di Pag. Elettronico e servizi erogati da Telepass S.p.A tramite essi.

124

112

Info apparati TLP

ITL

Modulo DW contenente informazioni sul ciclo di vita degli apparati Telepass dal punto di vista fisico/impiantistico; l''obiettivo è consentire un''adeguata pianificazione della produzione, dell''approvvigionamento e del magazzino degli

apparati.

Info contratti e Viaggi di Soccorso

IVS

Modulo Data Warehouse per la Reportistica e l''Analisi dei Clienti e Contratti Telepass che rientrano nel perimetro del soccorso (es: ambulanze) e che quindi godono di particolari condizioni ed esenzioni.

Info Web Xxxxxxxx.xx

IWT

Modulo DW contenente le informazioni sugli accessi al sito Xxxxxxxx.xx.; l''obiettivo è consentire un adeguato monitoraggio di

tutte le tipologie di operazioni effettuate.

DW Area tematica Telepass

269

596

286

Raggr.

Applicazioni

Applicazion e

Cod. Appl.

Descrizione applicazione

Fonti Alimenta nti

Progr. Alimenta nti

Oggetti DB (tab e viste)

Num utenti

Soc. abiliate

Ticket 2017

DW Area tematica Traffico

Info Percorso

Reale

IPR

Applicazione Data Warehouse per la Reportistica e l'Analisi dei dati del progetto Percorso Reale.

Info Dati da SpireTraffico

ISP

Modulo DW che consente l'analisi delle sintesi orarie dei dati provenienti dalle spire traffico (sia Famas che Tutor) collocate in itinere.

Info Statistiche Traffico

IST

Modulo contenente alcune sintesi delle statistiche di traffico elaborate da TIS (movimenti di stazione, fasce km stazioni entrata, fasce km stazioni uscita, volumi per tratta elementare, volumi per tratta funzionale, volumi per tratta fisica, ecc..) replicate in ambito Data Warehouse.

DW Area tematica Traffico

125

Raggr.

Applicazioni

Applicazion e

Cod. Appl.

Descrizione applicazione

Fonti Alimenta nti

Progr. Alimenta nti

Oggetti DB (tab e viste)

Num utenti

Soc. abiliate

Ticket 2017

DW Area tematica Viabilita

Info Cantieri

ICT

Modulo DW che consente di effettuare indagini sulla programmazione settimanale, giornaliera e sui cantieri installati, alimentato da fonte BCT. Per i cantieri installati e' disponibile il dettaglio dell'intera sequenza di stati e versioni che si sono susseguiti nel tempo.

Info EVenti di viabilità

IEV

Modulo DW contenente informazioni sugli eventi di viabilità estratti dal SIV; ha come obiettivo di consentire un adeguato monitoraggio di tutte le tipologie di eventi.

Info Indicatori di Fluidità

IIF

Applicazione di Business Intelligence realizzata convogliando i dati storici dei Total Delay dei flussi di viabilità dall'applicazione BIF verso il Data Warehouse. La consultazione dei dati avviene mediante la piattaforma standard di BI. Consente di effettuare analisi quantitative (di dettaglio e di sintesi) sulla fluidità del traffico veicolare dell'intera rete ASPI.

Info Meteo centraline MTX e da previsioni

IMT

Modulo Data Warehouse che effettua la storicizzazione dei Dati metereologici: a consuntivo provenienti dalle centraline Meteo e previsionali da enti esterni Alimentato ogni notte.

Indicatori di Incidentalità e PISM

INC

Applicazione di BI comprendente un cruscotto, reportistica e universi per query libere per monitorare gli Indicatori di Incidentalità e i Punti di Incidentalità Superiori alla Media. Il sistema attinge i dati da BIN per quanto riguarda gli incidenti consolidati, a SIV per quanto riguarda gli incidenti dell'ultimo periodo e a TIS per il calcolo del num. di km percorsi, necessari all'elaborazione degli indicatori composti di incidentalità.

Info Messaggi PMV

IPM

Modulo che consente di effettuare indagini sia di dettaglio che di sintesi sui messaggi inviati ai Pannelli Messaggio Variabile, sugli stati dgli stessi e quindi sulla combinazione messaggi-stato che determina se realmente il singolo messaggio è stato visualizzato all'utenza.

Info Rete, Viabilità e Incidenti

IRE

Modulo DW che contiene i dati anagrafici della struttura della rete autostradale (Punti, Stazioni, Autostrade, Rami, ADS, Gallerie, ecc..), di alcune tipologie di impianti (Piste esazione, Boe per la misurazione dei tempi di percorrenza, Telecamere, PMV, Colonnine SOS, Centraline meteo) e di varie tipologie di eventi di Viabilità da SIV ecc..).

188

Info Soccorsi

Meccanici

ISM

Modulo DW contenente i dati di dettaglio dei soccorsi meccanici, delle chiamate alle organizzazioni e dei carri

intervenuti sulla rete autostradale.

DW Area tematica Viabilità

197

328

149

TOTALE:

886

2.472

921

5. Categorie di servizi - dettaglio

Il presente capitolo descrive in maniera dettagliata e per ogni servizio le attività che si richiede svolgere nell’ambito della fornitura. I servizi in questione sono:

- Coordinamento della fornitura

- Nuovi Sviluppi

- Manutenzione Evolutiva (compresa adattativa, preventiva, migliorativa)

- Supporto Applicativo

- Supporto all’utente

- Manutenzione Correttiva

- Presa in carico del servizio (Start Up)

- Rilascio del servizio (Hand Over)

Viene, di seguito, fornito il dettaglio delle attività che sono contemplate nei servizi sopradescritti, raggruppandole per Tipologia.

5.1 Coordinamento della fornitura

Il servizio consiste in tutte le attività necessarie per la corretta conduzione e coordinamento delle attività e del gruppo di lavoro del Fornitore messo a disposizione per l’erogazione di tutti i servizi oggetto della fornitura. Le attività richieste al Fornitore nell’ambito di questo servizio comprendono:

Durante la fase di Start Up, la definizione congiunta con la Committente delle modalità di avviamento e gestione dei servizi. In particolare:

• la presentazione dei componenti del Gruppo di Lavoro alla Committente, la Formalizzazione del Gruppo di Lavoro, l’inserimento delle risorse;

• il presidio e il coordinamento della fase di iniziale di “Presa in carico dei servizi”;

• la definizione di un processo di governo dell’intera fornitura;

• la sottoscrizione del verbale di avvenuta “Presa in carico dei servizi” che determina l’avvio della fase di erogazione dei servizi

Durante tutto il ciclo della fornitura, per tutti i servizi richiesti, la supervisione delle attività e del Gruppo di Lavoro. In particolare:

• l’allocazione delle risorse del Fornitore sulle attività;

• la stima dell’impegno necessario allo svolgimento delle attività, in termini di giorni e figure professionali;

• il monitoraggio sullo stato di avanzamento delle attività e del piano generale;

• il costante allineamento con il DEC del Committente per qualsiasi variazione al piano concordato;

• il rispetto del Contratto stipulato con il Committente in tutti i suoi punti;

• la redazione e gestione di tutti i documenti previsti (sintesi delle attività, piano della qualità, ordinativi di lavoro, verbali di collaudo, consuntivi mensili, ecc..);

• la gestione del team del Fornitore in termini di coordinamento, di verifica delle caratteristiche delle figure professionali dichiarate in fase di offerta e di gestione delle eventuali sostituzioni.

Durante la fase di finale di Hand Over è prevista la definizione congiunta con la Committente delle modalità di rilascio dei servizi. In particolare:

• il presidio e il coordinamento della fase finale di “Rilascio dei servizi”

• la definizione delle modalità di trasferimento del parco applicativo e delle procedure gestionali al fornitore subentrante.

Le modalità di gestione del servizio sono descritte in maniera più dettagliata nel paragrafo 7.5 del presente Capitolato Tecnico.

5.2 Nuovi sviluppi

Rientrano in questa categoria tutte le attività di sviluppo applicativo conseguenti a nuove richieste ed interventi richiesti da ASPI relativi al contesto oggetto di bando di gara.

Il Servizio di Nuovi Sviluppi riguarda tipicamente le richieste di ASPI legate a:

• Analisi, progettazione e realizzazione di nuovi sistemi/applicazioni.

• Analisi, progettazione e realizzazione di nuove componenti applicative o funzionalità all’interno di sistemi/ applicazioni già esistenti.

• Re-engineering di sistemi/applicazioni o di singoli componenti esistenti.

Il fornitore dovrà attenersi alle migliori pratiche di sviluppo e seguire gli standard interni del cliente. In particolare, il software deve essere sviluppato secondo principi di security-by-design e privacy-by-design e deve rispettare i principi di sviluppo descritti nella guida pubblica OWASP Secure Coding Practice. Tutte le soluzioni, sia sviluppate ad hoc che prodotti acquistati, devono essere accompagnate da un rapporto di collaudo di vulnerability assessment e penetration test effettuati secondo gli standard di settore, necessari prima della messa in campo della soluzione.

Tali servizi saranno attivati tramite ordinativi di lavoro. Le modalità di attivazione e di gestione del servizio sono descritte in maniera più dettagliata nel paragrafo 7.6. del presente Capitolato Tecnico.

Lo Sviluppo di Nuovi sistemi/applicazioni comprende di norma una gestione che si articola nelle seguenti fasi:

• studio di fattibilità

• analisi funzionale e tecnica

• sviluppo / personalizzazione

• test

• rilascio

• formazione

Il Nuovo Sviluppo di sistemi/applicazioni richiede anche attività di gestione progettuale come: gestione delle variazioni, gestione dei problemi, gestione dell'avanzamento del progetto, ecc.

In particolare per Nuovi Sviluppi di sistemi/applicazioni in ambiente DW/BI le attività previste sono :

• Analisi dei requisiti utente ed individuazione delle applicazioni sorgente da cui prelevare i dati necessari per soddisfarli; comprensione dello schema dati e dei processi in essere nei sistemi sorgente.

• Progettazione logica della banca dati del nuovo sistema DW, in ambiente relazionale o big data. Tali strutture dovranno essere comunicate e concordate con l’UO che gestisce l’Esercizio, che si farà carico di implementarle a livello di database (la progettazione fisica del DB non è in ambito).

• Analisi e progettazione dei processi di alimentazione del database del nuovo sistema DW a partire dalle informazioni disponibili all’interno dei sistemi sorgente. Implementazione di procedure batch ETL con tecnologie Talend Open Studio, script UNIX, programmi JAVA o altre tecnologie appropriate in funziona della mole dei dati da movimentare, della complessità delle elaborazioni e della frequenza di alimentazione.

• Analisi e implementazione dello strato semantico del front-end per mezzo di nuovi universi Business Objects (con i tool BO UDT e IDT) o corrispondente tecnologia SpagoBI. In questa fase sono definiti gli oggetti informativi che mappano il database e che verranno utilizzati per le attività di query e reporting.

• Realizzazione di reportistica con i tool della suite BO o, in taluni casi SpagoBI.

• Analisi, progettazione e realizzazione di cruscotti per la navigazione guidata attraverso le informazioni, realizzati principalmente con le tecnologie della suite BO (Lumira, Design Studio, BO Dashboards).

• Analisi, progettazione e realizzazione di componenti (di DW e/o BI) per presentazione dati in forma analitica integrandosi con altri portali o con applicazioni su piattaforme georeferenziate (GIS).

• Configurazione della sicurezza tramite i pannelli di amministrazione di BO o in taluni casi di SpagoBI.

• Analisi e sviluppo di sistemi Big Data, basati su ambiente Hadoop. I sistemi di questo tipo si devono integrare, là dove necessario, con il Data Warehouse di tipo relazionale, tramite tecniche di data federation.

• Definizione di semplici modelli statistici descrittivi per la comprensione dei fenomeni di business.

• Sviluppo, addestramento e test di modelli predittivi, di classificazione e di clustering. Per lo sviluppo di questi modelli viene seguita la metodologia CRISP-DM ed utilizzato il tool IBM SPSS Modeler.

5.3 Manutenzione Evolutiva

Rientrano nella categoria Manutenzione Evolutiva (compresa adattativa, preventiva, migliorativa) le attività di modifica e/o aggiunta di nuove funzionalità e sviluppo di nuove componenti applicative all’interno delle applicazioni esistenti nell’ambito dei servizi, definite nel Cap. 4 del presente Capitolato Tecnico. Questi interventi si rendono necessari per:

• Adeguamenti alle componenti del sistema derivanti da una richiesta di modifica legata a variazioni normative, tariffarie, contabili introdotte da ASPI (manutenzione adattativa).

• Implementazioni o variazioni sulle diverse componenti del sistema, legate all’introduzione di nuove funzionalità, richieste da ASPI per rispondere a nuove o mutate esigenze di business, organizzative o operative (manutenzione evolutiva vera e propria).

• Implementazioni applicative legate a variazioni di natura architetturale decise da ASPI come ad esempio l’innalzamento dei livelli delle piattaforme SW su cui operano le componenti applicative (manutenzione preventiva).

• Implementazioni legate al miglioramento prestazionale delle prestazioni di funzionalità in esercizio (manutenzione migliorativa).

Il servizio può comprendere anche studi di fattibilità di interventi significativi su componenti e oggetti in ambito.

In generale, per ogni richiesta di Manutenzione Evolutiva verrà definito un ordinativo di lavoro. Le modalità di attivazione e di gestione del servizio sono descritte in maniera più dettagliata nel paragrafo 7.6 del presente Capitolato Tecnico.

In particolare per la Manutenzione evolutiva dei sistemi/

applicazioni di Data Warehouse e di Business Intelligence, le attività previste sono:

• Manutenzione, a livello logico, delle banche dati dei sistemi/applicazioni DW e BI, in termini di modifiche e arricchimenti da apportare sia in ambiente relazionale, sia in ambiente Big Data. Tali modifiche dovranno poi essere comunicate e concordate con l’UO che gestisce l’Esercizio, che si farà carico di implementarle a livello di database (la manutenzione fisica del DB non è in ambito).

• Analisi e modifica delle procedure di caricamento del DW, conseguentemente a modifiche effettuate nei sistemi operazionali sorgente e a variazioni dei requisiti utente.

• Attività di presidio, gestione e controllo del funzionamento dei meccanismi di alimentazione del DW.

• Attività di ottimizzazione del funzionamento dei meccanismi di alimentazione del DW e della produzione della reportistica, in modo tale da garantire l’efficienza temporale richiesta, a fronte della costante crescita del volume dei dati gestiti.

• Gestione e ottimizzazione dei sistemi/applicazioni di Data Warehouse e di Business Intelligence

• Attività di ricerca, scouting e test di nuove soluzioni architetturali finalizzate a garantire una maggiore efficienza e scalabilità dell’intero sistema DW e dei meccanismi di alimentazione.

• Attività di ricerca e scouting di nuove fonti dati, per la costruzione di nuovi indicatori ad integrazione dei moduli di reportistica e dei cruscotti già disponibili.

• Amministrazione delle piattaforme server Business Objects e SpagoBI e dei meccanismi di giunzione con i sistemi aziendali di autenticazione; gestione dei diritti applicativi degli utenti, con la profilatura di ciascun utente rispetto alle funzionalità e ai contenuti tematici di competenza.

• Attività di installazione, configurazione, patching, upgrade e migrazione delle piattaforme server Business Objects, SpagoBI, IBM SPSS, nonché del tool di ETL Talend Open Studio.

• Attività di personalizzazione sviluppate sulla piattaforma Business Objects per il tracciamento e l’audit delle attività, per la sospensione e il conseguente ripristino dell’accesso degli utenti agli universi del DW in corrispondenza con l’inizio e la fine, rispettivamente, di una sequenza di caricamenti, ecc...

• Evoluzione dei moduli di front-end per i sistemi/applicazioni in esercizio, con la modifica e l’evoluzione dei contenuti (report, cruscotti, cartelle ecc..) o l’aggiunta di nuovi nell’ambito di applicazioni esistenti.

• Ri-addestramento di modelli predittivi già rilasciati in precedenza, sulla base di dati più aggiornati e completi, allo scopo di migliorarne l’adattamento alle situazioni di business in evoluzione (tool IBM SPSS Modeler).

5.4 Supporto Applicativo

Rientrano in queste categorie le attività di supporto applicativo e consulenziale che il Fornitore eroga a fronte di richieste e segnalazioni provenienti da personale di ASPI (in particolare il personale dei Sistemi Informativi) e altre Società Clienti. Di norma tutti gli interventi rientranti in tali categorie non implicano alcuna modifica o correzione al codice applicativo.

Vengono di seguito descritte le attività previste per il servizio di supporto applicativo, pur in una lista non esaustiva delle medesime, che saranno svolte dalle risorse professionali allocate dal fornitore nel team di assistenza:

• attività di supporto di secondo livello alla risoluzione di anomalie che, a seguito dell’attività di Problem determination eseguita da Autostrade per l’Italia, risultino essere causate da un errato utilizzo da parte dell’utente, a problemi di natura sistemistica o da problemi legati alla fornitura dei dati da parte di ASPI o da malfunzionamenti di applicazioni esterne alle applicazioni in ambito;

• supporto tematico a redazione di studi, analisi di fattibilità, documenti di architettura, stima dei tempi, costi e benefici, comparazione tra diverse possibili soluzioni.

• supporto al gruppo di lavoro di ASPI dedicato all’infrastruttura, interventi straordinari per l’adeguamento di sistemi, prove di esercizio che avvengono fuori dell’orario di lavoro.

L’attivazione del servizio avverrà tramite lo strumento di ticketing in uso presso ASPI o con i dispositivi e le procedure che i Sistemi Informativi rendono disponibili per effettuare le richieste di supporto e di assistenza. Le modalità di attivazione e di gestione del servizio sono descritte in maniera più dettagliata nel paragrafo 7.7 del presente Capitolato Tecnico.

5.5 Supporto all’utente

Rientrano in questa categoria le attività di supporto che il Fornitore eroga a fronte di richieste e segnalazioni provenienti direttamente dagli utenti delle applicazioni in ambito, utenti che possono far parte di Autostrade per l’Italia e di altre Società Clienti. Di norma tutti gli interventi rientranti in tale categoria non implicano alcuna modifica o correzione al codice applicativo, essendo mirati piuttosto a consentire agli utenti finali un utilizzo autonomo e corretto delle funzionalità e dei contenuti disponibili nel contesto applicativo DW e BI.

In particolare, per il servizio di Supporto all’utente, le attività previste sono:

• presa in carico e gestione delle richieste di supporto che provengono tramite la piattaforma di Ticketing aziendale ASPI, via mail o via telefono, al fine di garantire il massimo supporto ai servizi erogati;

• creazione ed utilizzo di una knowledge base dei casi di supporto gestiti;

• attività di progettazione ed erogazione di interventi formativi degli utenti per un uso corretto ed ottimale dei sistemi/applicazioni in esercizio e l’impiego dei tools di front-end messi a disposizione; la formazione potrà essere mirata al singolo utente o effettuata in aula a gruppi di utenti;

• assistenza operativa agli utenti, per l’uso appropriato delle funzioni predefinite (report aziendali, cruscotti);

• assistenza agli utenti per il supporto all’utilizzo dei tools di front-end per la realizzazione della reportistica personale e delle query self-service;

• verifiche di completezza e congruenza dei dati resi disponibili dalle applicazioni in ambito, e più in generale supporto sul significato e qualità dei dati forniti.

Le modalità di attivazione e di gestione del servizio sono descritte in maniera più dettagliata nel paragrafo 7.7 del presente Capitolato Tecnico.

5.6 Manutenzione Correttiva

Il Servizio di Manutenzione Correttiva consiste nelle azioni intraprese per identificare e rimuovere errori o malfunzionamenti dovuti a codifica errata delle componenti e oggetti o a situazioni in cui i medesimi operino in modo non conforme alle specifiche stabilite.

Sono oggetto di manutenzione correttiva tutti gli applicativi di competenza che sono in esercizio al momento dell’attivazione del contratto, e tutte le evolutive e nuovi componenti/sistemi che vengono rilasciati durante l’erogazione dei servizi oggetto della presente fornitura.

Tale servizio sarà attivato tramite segnalazione dell’errore o dei malfunzionamenti, attraverso i meccanismi e le procedure previste da ASPI (es. Incident ticket con lo strumento di ticketing in uso presso ASPI). Le segnalazioni di errore dovranno essere costantemente controllate/monitorate da parte del Fornitore che si attiverà direttamente per rimuovere l'anomalia (acquisendo la Severità dell’errore, determinando l'effort occorrente e valutando il livello di servizio corrispondente da assicurare). Con cadenza mensile verranno consuntivati gli interventi di manutenzione correttiva effettuati, valutando per ognuno di essi l’effort profuso e il rispetto o meno dei livelli di servizio previsti al paragrafo 9.1 del presente Capitolato Tecnico.

Le modalità di attivazione e di gestione del servizio sono descritte in maniera più dettagliata nel paragrafo 7.8 del presente Capitolato Tecnico.

In particolare, il Servizio di Manutenzione Correttiva consiste nelle seguenti attività :

• Presa in carico della segnalazione: acquisizione da parte del Fornitore della segnalazione dell’anomalia, tramite i canali di segnalazione previsti, e della relativa Severità assegnata (secondo la scala indicata al punto 9.1.1 del presente Capitolato Tecnico).

• Analisi del problema: individuazione del problema. ASPI fornisce le informazioni necessarie per circostanziare l’anomalia (area applicativa, funzionalità in errore, modalità operative per cui si verifica l’errore, risultato atteso verso risultato ottenuto, esempio di caso errato..). Il Fornitore identifica la soluzione da apportare e la condivide con i Referenti di ASPI.

• Correzione del malfunzionamento: nel caso in cui l’errore dipenda da cause interne all’applicazione (es: errata codifica) saranno attuate le modifiche necessarie e idonee a rimuovere l’errore.

• Rilascio degli oggetti software corretti: predisposizione del pacchetto degli oggetti software da rilasciare e della relativa documentazione tecnica e operativa.

• Recupero o riprocessamento dati in caso di mancata, errata o incompleta alimentazione delle banche dati del DW.

• Segnalazione di situazioni incongrue dovute alle applicazioni sorgente: nel caso in cui l’Incident abbia la sua origine esternamente all’applicazione (ad esempio dati incongruenti all’origine, che quindi impediscono il completamento della procedura di alimentazione del database DW), verranno prese le misure opportune per smistare il problema al responsabile applicativo della procedura sorgente e per gestire la situazione minimizzando il disservizio che ne può derivare, eventualmente ricorrendo a workaround in attesa che il problema sia risolto in modo definitivo.

• Gestione di una knowledge base delle anomalie

In particolare per la Manutenzione correttiva dei sistemi/applicazioni di DW e BI, le attività previste sono:

• Manutenzione banche dati dei sistemi/applicazioni DW e BI, in termini di correzioni da apportare a livello logico. Tali modifiche dovranno essere comunicate e concordate con l’UO che gestisce l’Esercizio, che si farà carico di implementarle a livello di database (la manutenzione fisica del DB non è in ambito).

• Manutenzione delle procedure di estrazione, trasformazione e caricamento del DW.

• Manutenzione degli oggetti di front-end (universi, cruscotti, report) degli ambienti DW e BI.

• Manutenzione dei meccanismi di sicurezza nonché dei diritti applicativi degli utenti agli ambienti DW e alle pagine analitiche dei sistemi di BI.

5.7 Presa in carico del servizio (Start Up)

Questa attività riguarda la fase iniziale del rapporto di collaborazione tra Committente e Fornitore, durante la quale quest’ultimo deve acquisire e/o consolidare la conoscenza del parco applicativo e le modalità operative di gestione dello stesso.

La fase di Presa in carico del servizio (Start Up) ha inizio con la data di avvio del contratto ed ha una durata fissa di 60 gg solari. In questa fase, in cui il sistema è ancora pienamente in carico al Fornitore uscente, il Fornitore entrante deve acquisire dal Fornitore uscente tutte le conoscenze ritenute necessarie per l’avvio del servizio.

Durante la fase di Start Up il Fornitore concorda con ASPI l’inserimento delle risorse e presenta la composizione definitiva che Gruppo di Lavoro avrà all’avvio dell’erogazione dei servizi. Il Gruppo di Lavoro dovrà corrispondere, sia complessivamente che in ogni singola risorsa che lo compone, ai requisiti minimi descritti nel Capitolo 6.

L’erogazione delle attività della fase di Start Up non prevede alcuna corresponsione economica.

Le modalità di attivazione e di gestione del servizio sono descritte in maniera più dettagliata nel paragrafo 7.4 del presente Capitolato Tecnico.

5.8 Rilascio del servizio (Hand Over)

Questa attività si riferisce al passaggio di consegne verso il fornitore subentrante durante la fase conclusiva del rapporto contrattuale tra Committente e Fornitore.

Il Fornitore, a partire dal 60°giorno prima della scadenza del Contratto, dovrà garantire la massima disponibilità alle attività di passaggio e trasferimento informazioni e documentazione ad ASPI e/o ad altro Fornitore, in particolare tutte quelle conoscenze relative alle peculiarità delle applicazioni maturate nel periodo di erogazione dei servizi.

Durante la fase di Hand-over, la responsabilità della conduzione e gestione del Contratto rimarrà a carico del Fornitore uscente; esso dovrà continuare a garantire i livelli di servizio previsti dal contratto e in più sarà compito e responsabilità del Fornitore uscente rendere disponibile personale qualificato del gruppo di lavoro in essere per le attività di passaggio di consegne, indicando il proprio Responsabile di riferimento per queste attività.

E’ inoltre compito e responsabilità del Fornitore uscente organizzare ed integrare la documentazione funzionale e tecnica messa a disposizione da ASPI al fine di agevolare la fase di transizione verso la Società subentrante.

Le modalità di attivazione e di gestione del servizio sono descritte in maniera più dettagliata nel paragrafo 7.9 del presente Capitolato Tecnico.

Nell fase di Hand-Over il Fornitore dovrà effettuare il trasferimento delle conoscenze avendo cura di:

• Garantire la continuità del servizio fino al termine del periodo di validità del CTR di erogazione dei servizi oggetto della fornitura.

• Utilizzare una metodologia a supporto del trasferimento delle conoscenze e della documentazione verso la società subentrante e/o verso Autostrade per l’Italia.

6. Gruppo di lavoro - Figure professionali

Il Fornitore dovrà mettere a disposizione, per l’espletamento dei servizi delle fasi di Erogazione dei Servizi e di Hand Over, un gruppo di lavoro formato da risorse dedicate, costituito dalle seguenti Figure Professionali:

1 Analista Senior

2 Programmatori Senior

2 Programmatori Junior

e che nel suo insieme garantisca la piena padronanza di tutto l’ambiente tecnologico descritto al paragrafo 4.1.

Durante la fase di Start Up, per la quale non è previsto compenso economico, il dimensionamento del GdL sarà concordato tra Fornitore e Committente.

In considerazione della tipologia dei servizi e della necessità di interagire con diverse strutture aziendali, anche alla luce di esperienze pregresse, è richiesto come requisito necessario che tutte le risorse siano di madrelingua Italiana oppure, se non lo sono, possiedano un’ottima conoscenza della lingua Italiana nella comprensione, nello scritto e nel parlato, dimostrando di aver conseguito un livello di certificazione C2 (Livello di padronanza della lingua in situazioni complesse) secondo il Quadro comune europeo di riferimento per la conoscenza delle lingue.

Tutte le risorse devono essere pertanto in grado di:

• comprendere con facilità praticamente tutto ciò che sentono e leggono

• riassumere informazioni provenienti da diverse fonti sia parlate che scritte, ristrutturando gli argomenti in una presentazione coerente

• esprimersi spontaneamente, in modo molto scorrevole e preciso, individuando le più sottili sfumature di significato in situazioni complesse.

Il Fornitore garantisce che le persone che saranno impiegate per lo svolgimento delle attività oggetto della presente fornitura, posseggono i requisiti minimi e le competenze necessarie richiesti da ASPI e dovrà allegare alla propria offerta tecnica il CV di ciascuna risorsa che intende impiegare nello svolgimento delle attività.

Il CV dovrà essere redatto nel formato standard Europeo, completo di nominativo per esteso della persona proposta.

E’ in facoltà di ASPI di richiedere la sostituzione di unità di personale addetto alle prestazioni contrattuali che fossero ritenute da ASPI medesima in via obiettiva non idonee alla perfetta esecuzione dei servizi del presente capitolato, senza che ciò comporti alcun aggravio di costi per ASPI.

Autostrade per l’Italia, a seguito di esigenze che potranno verificarsi nel corso della durata contrattuale, si riserva la possibilità di concordare con il Fornitore un meccanismo di compensazione quantitativa tra le figure professionali previste nella fornitura fermo restando l‘importo complessivo del contratto e la sua durata, allo scopo di gestire al meglio eventuali variazioni del carico di lavoro rispetto a quanto oggi previsto.

ll servizio, ancorché definito quantitativamente e qualitativamente nell’offerta tecnica e nel contratto che sarà sottoscritto, dovrà essere erogato con la necessaria flessibilità operativa a seguito di necessità e/o esigenze non pianificabili alla data da ASPI, e che saranno all’occasione concordate in corso d’opera con cadenza al massimo trimestrale.

Le attività descritte nel capitolo 5 del presente Capitolato richiedono a tutte le figure richieste elevate capacità tecniche e professionali: prontezza, precisione, affidabilità e competenza per l’erogazione dei servizi richiesti.

Le Figure professionali offerte dovranno inoltre avere le seguenti caratteristiche specifiche.

6.1 Figura A – Analista Senior

6.1.1 Finalità del ruolo

E’ la figura professionale che, fungendo da Referente Tecnico del contratto (RT) per conto del Fornitore verso Autostrade per l’Italia, deve abbinare alle competenze specifiche sulle aree oggetto di fornitura capacità ed esperienza nel coordinamento di gruppi di lavoro e nella conduzione di progetti di media/alta complessità per la gestione di tutte le attività in carico al Fornitore. E’ inoltre in grado di individuare soluzioni tecniche organizzative ottimali.

E’ in grado inoltre di studiare le esigenze informative dell’utente e di supportare il gruppo di lavoro nella stesura delle specifiche funzionali e nella stima temporale ed economica per quanto attiene alle singole attività di sviluppo per poi produrre gli stati di avanzamento e le consuntivazioni concordate con Autostrade per l’Italia.

6.1.2 Attività tipiche del ruolo

• Contribuire alla corretta esecuzione dei progetti/attività in cui è coinvolto il Gruppo di Lavoro, apportando le proprie conoscenze tecniche, nel rispetto degli indirizzi e degli obiettivi stabiliti.

• Pianificare le attività richieste ed allocare le risorse.

• Evidenziare le problematiche rilevate nell’esecuzione dei progetti/attività, proporre le opportune soluzioni ed intraprendere, in accordo con Autostrade per l’Italia, le necessarie azioni correttive.

• Assicurare il corretto sviluppo dei progetti/attività nel rispetto dei tempi e dei costi pianificati, attraverso il coordinamento delle risorse ad esso dedicate..

• Collaborare con ASPI nella definizione dei requisiti dei sistemi/applicazioni.

• Collaborare con ASPI nella stesura degli studi di fattibilità, analisi funzionale e di sicurezza, valutazione dei rischi, analisi costi/benefici.

• Collaborare con ASPI nella definizione delle specifiche architetturali e funzionali del sistema/applicazione da sviluppare, indicandone tempi e costi per lo sviluppo.

• Collaborare con ASPI nella definizione delle specifiche tecniche dei componenti e oggetti (database, interfacce, meccanismi di connessione, ecc.) e assicurarne la realizzazione.

• Collaborare con ASPI nella definizione del piano di collaudo/accettazione e curarne l’implementazione, partecipando attivamente all'esecuzione e valutazione dei test/collaudi funzionali e di sicurezza.

• Assicurare l’ottimizzazione delle prestazioni dei sistemi/applicazioni.

• Assicurare la produzione e l'aggiornamento della documentazione funzionale e tecnica dei sistemi/applicazioni.

• Progettare e realizzare attività formative per l’utilizzo dei sistemi/applicazioni.

• Assicurare la corretta gestione dei dati personali secondo le disposizioni di legge e le policy aziendali.

• Produrre ed aggiornare reporting sullo stato di avanzamento delle attività.

• Produrre le consuntivazioni concordate per la liquidazione

6.1.3 Requisiti minimi

Sono di seguito elencati i requisiti minimi che la risorsa che ricoprirà il ruolo di Analista Senior deve necessariamente avere, pena la non accettazione:

a) Laurea Magistrale/vecchio ordinamento in informatica, ingegneria, matematica, statistica o fisica.

b) Xxxxxx conoscenza della lingua italiana nella comprensione, nello scritto e nel parlato da comprovare con appartenenza a madrelinqua italiana o certificazione minima C2.

c) Provata esperienza di almeno 6 anni nella conduzione e coordinamento di progetti medio/complessi.

d) Provata esperienza di almeno 6 anni nell’analisi, progettazione e realizzazione di sistemi di DW e BI basati sulle piattaforme SAP Business Objects (front-end) e ETL Talend Open Studio (back-end).

6.1.4 Competenze necessarie

Sono di seguito elencate le competenze ed esperienze necessarie allo svolgimento del ruolo di Analista Senior :

1) Approfondita conoscenza ed uso di tecniche di Project Management, nonché di assicurazione e controllo qualità sui progetti.

2) Approfondita conoscenza del ciclo di vita del software in tutte le sue fasi e delle relative problematiche.

3) Approfondita conoscenza delle metodologie di analisi dati, architetture e sistemi software, sicurezza informatica e sviluppo sicuro.

4) Approfondita conoscenza ed uso dei Data Base in ambito dei servizi di gara. Piena padronanza delle tecniche di data modeling (E-R, dimensional, big data).

5) Piena padronanza dei linguaggi di interrogazione dati SQL, Oracle PL/SQL, DB2 SQL PL.

6) Approfondita conoscenza ed uso della piattaforma di front-end SAP Business Objects

7) Buona conoscenza ed uso della piattaforma di business intelligence e SpagoBI.

8) Approfondita conoscenza ed uso della piattaforma ETL Talend Open Studio.

9) Conoscenza dei linguaggi script korn shell, bash shell, windows batch.

10) Capacità e piena autonomia nell’effettuare le customizzazioni operative necessarie al fine di ottimizzare i servizi delle piattaforme DW e BI; amministrazione dei meccanismi di sicurezza nonché dei diritti applicativi degli utenti.

11) Conoscenza ed uso dello strumento IBM SPSS Modeler

12) Conoscenza ed uso dei linguaggi JAVA, XML, JSP, XSLT, HTML, JAVASCRIPT, CSS.

6.1.5 Ulteriori competenze

Sono di seguito elencate le competenze ed esperienze aggiuntive utili per l’espletamento del ruolo di Analista Senior:

• Esperienza nella conduzione e coordinamento di progetti per l’erogazione di servizi, analoghi a quelli oggetto di gara, nel settore autostradale.

• Conoscenza dello strumento di modellazione dati Xxxxx Data Modeler.

• Conoscenza di metodologie ed algoritmi di Data Mining.

• Esperienza nella definizione, addestramento, test e validazione di modelli predittivi.

• Conoscenza della piattaforma big-data Hadoop

• Conoscenza delle problematiche di Data Governance e di Master Data Management.

• Esperienza di progettazione ed erogazione corsi d’aula su strumenti della suite SAP Business Objects.

• Conoscenza del regolamento generale europeo sulla protezione dei dati (GDPR).

6.2 Figura B - Programmatore Senior

6.2.1 Finalità del ruolo

E’ la figura professionale che, avendo acquisito ampia esperienza nell'area tematica di riferimento, è particolarmente qualificata nell'individuazione e nell'attuazione di soluzioni nel settore del DW e BI. E’ in grado di studiare le esigenze informative dell’utente e di redigere le specifiche funzionali, atte ad essere utilizzate nell’attività di sviluppo. E’ in grado di effettuare la stima temporale per quanto attiene alle singole attività di sviluppo e manutenzione.

E’ autonomo nello svolgimento delle attività di sviluppo, manutenzione, testing e documentazione. In base alle specifiche funzionali, è in grado di procedere con l’analisi di dettaglio e la realizzazione delle relative componenti.

6.2.2 Attività tipiche del ruolo

• Collaborare con il Referente Tecnico nella definizione dei requisiti dei sistemi/applicazioni.

• Collaborare con il Referente Tecnico nella stesura di studi di fattibilità, analisi funzionale e di sicurezza, valutazione dei rischi, analisi costi/benefici.

• Collaborare con il Referente Tecnico nella definizione delle specifiche architetturali e funzionali del sistema/applicazione da sviluppare, contribuendo ad indicarne tempi e costi per lo sviluppo.

• Collaborare con il Referente Tecnico nella definizione delle specifiche tecniche dei componenti e oggetti (sw, interfacce, meccanismi di connessione, ecc.) e curarne la realizzazione.

• Sulla base delle specifiche architetturali e funzionali, definire le specifiche tecniche di dettaglio

• Sulla base delle specifiche di dettaglio, implementare il sistema/applicazione sviluppando il codice

• Definire standard e tecnologie da adottare all’interno del gruppo e curarne l’applicazione

• Assicurare l’omogeneità di realizzazione dei sistemi applicativi oggetto di gara individuando possibili integrazioni e riutilizzo di componenti

• Assicurare l’ottimizzazione delle prestazioni dei sistemi/applicazioni e dei singoli componenti e oggetti sw.

• Collaborare con il Referente Tecnico nella definizione del piano di Collaudo/Accettazione e curarne l’implementazione, partecipando attivamente alla progettazione, esecuzione e valutazione dei test/collaudi funzionali e di sicurezza dei sistemi/applicazioni.

• Redigere ed aggiornare la documentazione funzionale e tecnica dei sistemi/applicazioni.

• Progettare e realizzare attività formative per l’utilizzo dei sistemi/applicazioni.

• Fornire supporto all'utente sul corretto uso delle funzionalità degli strumenti di front-end e sul significato dei dati.

• Progettare le misure atte ad assicurare la corretta gestione dei dati personali secondo le disposizioni di legge e le policy aziendali.

6.2.3 Requisiti minimi

Sono di seguito elencati i requisiti minimi che la risorsa che ricoprirà il ruolo di Programmatore Senior deve necessariamente avere,

pena la non accettazione:

a) Diploma di scuola media superiore, tecnico o scientifico.

b) Xxxxxx conoscenza della lingua italiana nella comprensione, nello scritto e nel parlato da comprovare con appartenenza a madrelinqua italiana o certificazione minima C2.

c) Provata esperienza di almeno 6 anni nella progettazione e realizzazione di sistemi di DW e BI basati sulle piattaforme

SAP Business Objects (front-end) e ETL Talend Open Studio (back-end).

6.2.4 Competenze necessarie

Sono di seguito elencate le competenze ed esperienze necessarie allo svolgimento del ruolo di Programmatore Senior :

1) Buona conoscenza del ciclo di vita del software in tutte le sue fasi e delle relative problematiche.

2) Buona conoscenza delle metodologie di analisi dati, architetture e sistemi software, sicurezza informatica e sviluppo sicuro.

3) Approfondita conoscenza ed uso dei Data Base in ambito dei servizi di gara. Piena padronanza delle tecniche di data modeling (E-R, dimensional, big data).

4) Piena padronanza dei linguaggi di interrogazione dati SQL, Oracle PL/SQL, DB2 SQL PL.

5) Approfondita conoscenza ed uso della piattaforma di front-end SAP Business Objects

6) Buona conoscenza ed uso della piattaforma di business intelligence e SpagoBI.

7) Approfondita conoscenza ed uso della piattaforma ETL Talend Open Studio.

8) Conoscenza dei linguaggi script korn shell, bash shell, windows batch.

9) Capacità nell’effettuare le customizzazioni operative necessarie al fine di ottimizzare i servizi delle piattaforme DW e BI; amministrazione dei meccanismi di sicurezza nonché dei diritti applicativi degli utenti.

10) Conoscenza ed uso dello strumento IBM SPSS Modeler.

11) Conoscenza ed uso dei linguaggi JAVA, XML, JSP, XSLT, HTML, JAVASCRIPT, CSS.

6.2.5 Ulteriori competenze

Sono di seguito elencate le competenze ed esperienze aggiuntive utili per l’espletamento del ruolo di Programmatore Senior:

• Esperienza nella progettazione, sviluppo e manutenzione di sistemi di Data Warehouse e Business Intelligence in ambito autostradale.

• Conoscenza dello strumento di modellazione dati Xxxxx Data Modeler.

• Conoscenza di metodologie ed algoritmi di Data Mining.

• Esperienza nella definizione, addestramento, test e validazione di modelli predittivi.

• Conoscenza della piattaforma big-data Hadoop

6.3 Figura C - Programmatore Junior

6.3.1 Finalità del ruolo

E’ lo specialista che è in grado di transcodificare le specifiche funzionali redatte dal Programmatore Senior al fine di procedere alle attività di sviluppo. E’ in grado di effettuare la stima temporale ed economica per quanto attiene alle attività di sviluppo e manutenzione dei singoli componenti e oggetti sw.

Nella maggior parte dei casi è autonomo nello svolgimento delle attività di sviluppo, manutenzione, testing e documentazione. In base alle specifiche funzionali, è in grado di procedere con l’analisi di dettaglio e la realizzazione delle relative componenti.

6.3.2 Attività tipiche del ruolo

• Collaborare con il Programmatore Senior nella fase di progettazione tecnica dei sistemi/applicazioni.

• Curare le fasi realizzative mediante la codifica dei programmi/moduli software, la definizione del piano di test dei programmi/moduli software, l’effettuazione e registrazione dei test e dei collaudi del sistema/applicazione.

• Assicurare l’ottimizzazione delle prestazioni di componenti e oggetti sw

• Eseguire e registrare i test funzionali e di sicurezza dei sistemi/applicazioni.

• Progettare, eseguire e registrare i test funzionali e di sicurezza di componenti e oggetti sw.

• Redigere ed aggiornare la documentazione tecnica di componenti e oggetti sw.

• Fornire supporto all'utente sul corretto uso delle funzionalità degli strumenti di front-end e sul significato dei dati

• Implementare le misure atte ad assicurare la corretta gestione dei dati personali secondo le disposizioni di legge e le policy aziendali.

6.3.3 Requisiti minimi

Sono di seguito elencati i requisiti minimi che la risorsa che ricoprirà il ruolo di Programmatore Junior deve necessariamente avere,

pena la non accettazione:

a) Diploma di scuola media superiore, tecnico o scientifico.

b) Xxxxxx conoscenza della lingua italiana nella comprensione, nello scritto e nel parlato da comprovare con appartenenza a madrelinqua italiana o certificazione minima C2.

c) Provata esperienza di almeno 2 anni nella progettazione e realizzazione di sistemi di DW e BI basati sulle piattaforme

SAP Business Objects (front-end) e ETL Talend Open Studio (back-end).

6.3.4 Competenze necessarie

Sono di seguito elencate le competenze ed esperienze necessarie allo svolgimento del ruolo di Programmatore Junior:

1) Buona conoscenza ed uso dei Data Base relazionali. Conoscenza delle tecniche di data modeling (E-R, dimensional).

2) Piena padronanza del linguaggio di interrogazione dati SQL.

3) Buona conoscenza ed uso della piattaforma di front-end SAP Business Objects

4) Buona conoscenza ed uso della piattaforma ETL Talend Open Studio.

5) Conoscenza dei linguaggi script korn shell, bash shell, windows batch.

6) Conoscenza ed uso dei linguaggi JAVA, XML, JSP, XSLT, HTML, JAVASCRIPT, CSS.

6.3.5 Ulteriori competenze

Sono di seguito elencate le competenze ed esperienze aggiuntive utili per l’espletamento del ruolo di Programmatore Junior:

• Esperienza nella progettazione, sviluppo e manutenzione di sistemi di Data Warehouse e Business Intelligence in ambito autostradale.

• Conoscenza dello strumento di modellazione dati Xxxxx Data Modeler.

• Conoscenza ed uso della piattaforma di business intelligence e SpagoBI.

• Conoscenza di metodologie ed algoritmi di Data Mining.

• Conoscenza ed uso dello strumento IBM SPSS Modeler.

• Esperienza nella definizione, addestramento, test e validazione di semplici modelli predittivi.

• Conoscenza della piattaforma big-data Hadoop

• Conoscenze di metodologie e tecniche standard di sicurezza e di sviluppo sicuro.

6.4 Elementi migliorativi del Gruppo di Lavoro

Le risorse proposte per la formazione del Gruppo di Lavoro dovranno necessariamente avere i requisiti minimi e le competenze necessarie indicati nei paragrafi precedenti.

Poiché la composizione del Gruppo di Lavoro, in termini di livello di istruzione e competenze, è da considerare un presupposto per una buona qualità nell’erogazione dei servizi, il concorrente può proporre elementi migliorativi rispetto a quelli minimi sopra elencati. Tali elementi saranno oggetto di valutazione nell’ambito dell’assegnazione del punteggio relativo all’OffertaTecnica.

Di seguito gli elementi considerati migliorativi per la composizione del Gruppo di Lavoro.

6.4.1 Miglioramento del Titolo di Istruzione delle risorse

Le risorse proposte dovranno necessariamente avere i Livelli di Istruzione minimi indicati nei paragrafi precedenti in termini di titolo di studio conseguito. Il concorrente può proporre risorse con Livelli di Istruzione migliorativi rispetto a quelli minimi.

Definendo la seguente gerarchia di titoli di studio:

1 - diploma di scuola media superiore (tecnico o scientifico)

2 - laurea breve (triennale) in informatica, ingegneria, matematica, statistica o fisica.

3 - laurea magistrale o ad ordinamento unico in: informatica, ingegneria, matematica, statistica o fisica (ogni ulteriore livello universitario o corso di specializzazione non verrà considerato)

la proposta sarà valutata in base alla dimostrazione del possesso di titoli di studio superiore a quelli minimi.

6.4.2 Certificazioni individuali delle risorse

Le risorse proposte dovranno obbligatoriamente avere le competenze necessarie indicate nei paragrafi precedenti. Il concorrente può proporre risorse con skill tecnici migliorativi rispetto a quelli minimi.

La proposta sarà valutata in base alla dimostrazione del possesso delle seguenti certificazioni individuali:

• Certificazione SAP Business Objects Business Intelligence Platform

• Certificazione SAP BusinessObjects Web Intelligence

• Certificazione Talend Data Integration Developer

• Certificazione IBM SPSS Modeler

• Certificazione IBM Big Data.

6.4.3 Esperienza specifica della Società Concorrente

Il concorrente può dichiarare nell’offerta tecnica il valore aggiunto che potrà impiegare nella fornitura, derivante dall’utilizzo del know how acquisito in esperienze precedenti nell’erogazione di servizi analoghi a quanto richiesto nel capitolato tecnico nel settore autostradale.

La proposta sarà valutata in base alla fascia di fatturato del concorrente nell’ambito dei sistemi di Data Warehouse e Business Intelligence nel settore autostradale nel periodo 2015-2017.

6.5 Sostituzione di una risorsa

Poiché la stabilità nel tempo del Gruppo di Lavoro è da considerare un presupposto per una buona qualità nell’erogazione dei servizi, il Concorrente si impegna, in caso di aggiudicazione, a non sostituire le persone di cui abbia inviato il CV (eccettuate le situazioni dovute a cause di forza maggiore).

Il numero massimo ammissibile di sostituzioni annue (non richieste da ASPI) di componenti del Gruppo di Lavoro è definito come SLA al punto 9.4.1 del Presente Capitolato.

Lo SLA può essere migliorato dal Fornitore in sede di offerta tecnica. Tale offerta migliorativa sarà valutata con l’attribuzione di un punteggio e diventerà vincolante in fase di esecuzione del contratto. Ogni sostituzione eccedente gli SLA stabiliti sarà oggetto di applicazione di una penale (vedi Cap. 11).

Qualora, durante la validità del contratto, a causa di dimissioni o di esigenze del Fornitore, si presenti la necessità di sostituire una delle suddette persone, il Fornitore dovrà comunicare ad ASPI tale esigenza con un anticipo di almeno 20 gg lavorativi rispetto alla data di uscita della risorsa. Il non rispetto della tempistica di preavviso sarà oggetto di applicazione di una penale progressivamente crescente (eccettuate le situazioni dovute a cause di forza maggiore).

Il Fornitore dovrà inoltre immediatamente attivarsi per individuare il sostituto della risorsa in uscita, con competenze e caratteristiche non inferiori a quelle minime e necessarie. Il Fornitore dovrà presentare il prima possibile il CV del sostituto, completo di nominativo per esteso per sottoporlo a valutazione ed eventuale accettazione da parte di Autostrade per l’Italia. In particolare ASPI si riserva di verificare la rispondenza della risorsa proposta ai requisiti minimi per la figura professionale da ricoprire, alle conoscenze necessarie e a quelle migliorative eventualmente dichiarate dal Fornitore nell’offerta tecnica.

In caso di accettazione da parte di Autostrade per l’Italia, il sostituto dovrà essere disponibile per l’inserimento nel Gruppo di Lavoro entro la data di uscita del sostituendo. Questo evento sarà sancito dalla sottoscrizione da entrambe le parti dell’apposito modello che formalizzerà la nuova composizione del Gruppo di Lavoro.

Il non rispetto della tempistica di sostituzione sarà oggetto di applicazione di una penale progressivamente crescente (eccettuate le situazioni dovute a cause di forza maggiore).

Il sostituto dovrà essere formato tramite affiancamento a spese della contraente per almeno 20 gg lavorativi senza alcun onere aggiuntivo per Autostrade per l’Italia.

Autostrade per l’Italia, inoltre, si riserva la facoltà, a fronte di valide motivazioni, di richiedere anche in corso di fornitura la sostituzione di risorse operanti sul progetto, senza che ciò comporti alcun aggravio di costi per ASPI.

7. Erogazione dei servizi

7.1 Sede di lavoro e strumenti

L’unità organizzativa ADW di ASPI svolge le proprie mansioni presso la sede della Direzione Generale di Firenze di Autostrade per l’Italia, Limite di Campi Bisenzio (FI).

I Servizi oggetto del presente Capitolato verranno erogati, per tutta la durata del contratto, o presso la sede ASPI di Firenze o con dislocazione di parte o tutte le risorse del gruppo di lavoro presso la sede del Fornitore.

Il luogo di esecuzione del servizio è pertanto la sede ASPI di Firenze fino ad un massimo del 70% delle giornate erogate, e per la rimanente parte la sede del Fornitore.

Qualora attività di analisi o di approfondimento richiedano la presenza di personale del Fornitore presso una delle altre sedi di Autostrade, le stesse verranno concordate tra il Direttore dell’Esecuzione di ASPI ed il Referente tecnico del Fornitore. Il numero delle giornate di trasferta presso altra sede di Autostrade per L’Italia sarà in misura non superiore al 10% del totale delle giornate richieste.

Il Fornitore dovrà provvedere in proprio alle postazioni di lavoro necessarie allo svolgimento delle attività previste, rispettanti le

policy di sicurezza di ASPI.

ASPI renderà disponibile, tramite una soluzione di virtualizzazione delle postazioni di lavoro, l’accesso alle proprie postazioni in cui sia installato sw licenziato ad ASPI.

7.2 Orario di servizio

Il Fornitore erogherà i Servizi di norma secondo il seguente orario:

Orario base del Servizio

Note

Lunedì-Venerdì (*)

09:00-18:00

Comprensivo dell’intervallo mensa

(*) Sono escluse, salvo richieste specifiche, le festività nazionali di legge (es: 1° gennaio, 6 gennaio, Pasqua, 25 aprile, 1° maggio, 2 giugno, 15 agosto, 8 dicembre, 25-26 dicembre).

Il Concorrente potrà proporre, a titolo migliorativo, un orario di copertura più ampio, secondo le fasce indicate nel Disciplinare di Gara. In questo caso gli SLA che si basano sui tempi di lavoro faranno riferimento a tale orario lavorativo e non a quello base.

A fronte di specifiche esigenze e nell’ottica di garantire la continuità del Servizio, ASPI potrà richiedere con debito preavviso attività al di fuori del normale orario di Servizio per specifici interventi, senza che questo comporti ulteriori costi per Autostrade per l’Italia.

In aggiunta a quanto sopra, il Concorrente potrà garantire, a titolo migliorativo, la reperibilità H24 7/7 di una delle persone facenti parte del GdL. La persona di riferimento fornirà un contatto telefonico, da utilizzare per la gestione delle emergenze al di fuori del normale orario di lavoro. A seguito della comunicazione il Fornitore si impegna ad effettuare la presa in carico dell’evento e a garantire tutto il supporto necessario alla soluzione del problema.

Tali interventi saranno consuntivati in modo analogo a quanto previsto nel normale orario del Servizio.

7.3 Tabella dei servizi

Viene di seguito esposta la matrice relativa alle modalità di Gestione economica, di Attivazione e di Rendicontazione per le diverse tipologie di servizi previsti nel capitolato:

Servizi	Modalità di Gestione Economica	Modalità di Attivazione	Modalità di Rendicontazione
Coordinamento della Fornitura	A consumo	Continuativa a ticket (Service Request)	Mensilmente, in base all’effort sulle figure
Nuovi Sviluppi e Manutenzione Evolutiva	A consumo	Con ordinativo di lavoro a partire da ticket (RFC)	In base all’effort sulle figure; in un’unica soluzione alla conclusione dell’attività oppure in più tranche alla conclusione delle fasi dell’attività.
Supporto Applicativo	A consumo	Continuativa a ticket (Service Request/ Technical Request)	Mensilmente, in base all’effort sulle figure
Supporto utente	A consumo	Continuativa a ticket (Service Request)	Mensilmente, in base all’effort sulle figure
Manutenzione Correttiva	A consumo	Continuativa a ticket (Incident)	Mensilmente, in base all’effort sulle figure
Presa in carico del servizio	Nessuna	Automatica all’inizio del rapporto	Nessuna
Rilascio del servizio	A consumo	Alla fine del rapporto, mediante ticket (Service Request)	Una tantum, alla conclusione della Fase di Rilascio

I successivi paragrafi illustrano in dettaglio il processo di erogazione relativo a ciascun servizio

7.4 Presa in carico del servizio (Start Up)

Questa attività riguarda la fase iniziale del rapporto di collaborazione tra Committente e Fornitore, durante la quale quest’ultimo dovrà acquisire e/o consolidare la conoscenza del parco applicativo e le modalità operative di gestione dello stesso.

Con anticipo sufficiente rispetto alla data di avvio del contratto, ASPI e il Fornitore si incontreranno per mettere a punto il calendario delle iniziative da mettere in atto per effettuare il passaggio di consegne. In questa occasione il Fornitore presenterà le risorse da inserire nel Gruppo di Lavoro, fornendone i CV ed eventuale documentazione necessaria a comprovarne caratteristiche, esperienza e competenze.

La fase di Presa in carico del servizio (Start-Up) ha inizio con la data di avvio del contratto ed ha una durata fissa di 60 gg solari. In questa fase, in cui il sistema è ancora pienamente in carico al Fornitore uscente, il Fornitore entrante deve acquisire dal Fornitore uscente tutte le conoscenze ritenute necessarie per l’avvio del servizio.

Il Programma di Start-Up sarà definito in modo tale da:

• Minimizzare l'impatto sul Fornitore uscente e sulla struttura interna ASPI di riferimento durante la fase di Presa in carico; il Fornitore entrante deve ridurre al minimo la turbativa dovuta al passaggio di conoscenze, allo scopo di consentire il normale svolgimento delle attività operative anche nel periodo di Presa in carico.

• Garantire la continuità del servizio dal momento dell’inizio dell’erogazione dei servizi oggetto della fornitura, al termine della fase di Presa in carico.

• Concordare una metodologia a supporto del consolidamento della documentazione e del know-how rispetto alla documentazione presente.

• Concordare la tipologia e il numero di risorse dedicate.

• Tenere conto della soluzione proposta dal Fornitore uscente per la sua fase di Hand-Over del parco applicativo gestionale e dei servizi in ambito.

Il Programma di Start-Up deve essere predisposto, sottoscritto da Committente e Fornitore, e comunicato al Fornitore uscente entro 10 gg solari dall’avvio effettivo della fase di Start-Up.

Le eventuali modifiche in corso d’opera al Programma di Start-Up dovranno essere concordate da Committente e Fornitore e comunicate al Fornitore uscente con adeguato anticipo.

Durante la fase di Presa in Carico Committente e Fornitore lavoreranno alla definizione di un processo di governo dell’intera fornitura.

Durante la fase di Presa in Carico inoltre, il Fornitore dovrà presentare alla Committente la composizione definitiva del Gruppo di Lavoro che intende proporre in vista della fase di erogazione dei servizi. Il Fornitore è strettamente tenuto a proporre risorse che posseggano almeno i requisiti minimi e le competenze necessarie richieste per ricoprire le figure professionali richieste, descritti nel Capitolo 6. Qualora una risorsa proposta non abbia i requisiti minimi, non sarà ammessa a far parte del Gruppo di Lavoro.

Il Gruppo di Lavoro può essere formalizzato (con la sottoscrizione da entrambe le parti dell’apposito modello) solo se tutte le risorse proposte verificano i requisiti minimi. Se una (o più) risorsa non corrisponde ai requisiti minimi, non sarà ammessa a far parte del Gruppo di Lavoro e pertanto il Gruppo non sarà formalizzato.

La formalizzazione del Gruppo di Lavoro è a sua volta indispensabile per la sottoscrizione del Verbale di Presa in Carico del Servizio, che dà avvio alla fase di erogazione dei servizi oggetto della fornitura. Da quel momento il Fornitore entrante sarà responsabile a pieno titolo dei servizi erogati, avrà avvio la normale rendicontazione e saranno effettivi SLA e relative Penali.

Qualunque anomalia comportamentale rivolta nei confronti del personale del Fornitore uscente sarà oggetto di immediato intervento e potrà, se reiterata, comportare applicazione di penale nonché l’immediata esclusione e cancellazione dall’albo fornitori della Committente.

Qualora, viceversa, il personale del Fornitore uscente creasse ostacolo alla regolare esecuzione delle attività, il fatto dovrà essere immediatamente segnalato ai responsabili della Committente che avranno facoltà di intervenire disciplinando l’affiancamento.

7.5 Coordinamento della fornitura

Il coordinamento della fornitura è un servizio trasversale a tutte le attività e alle varie fasi dei servizi ed è erogato dalla persona del Referente Tecnico del Fornitore. La gestione del coordinamento della fornitura si traduce operativamente nei seguenti punti:

• L’aggiornamento costante del documento di Sintesi delle attività (cfr Modello n. 5) in cui sono sintetizzate tutte le attività a consumo. Una sezione è dedicata a tutti gli interventi relativi a nuovi sviluppi e manutenzione evolutiva con indicazione dello stato di avanzamento (da iniziare, in corso, terminato, sospeso), della data prevista di inizio e fine, e dell’effort previsto in termini di giorni per figura professionale. In un’altra sezione (foglio) del documento sono riportate invece tutte le attività non preventivabili come il coordinamento della fornitura, il supporto applicativo ecc.

• La tempestiva segnalazione al DEC di qualsiasi variazione al piano suddetto per qualsiasi turbativa/ variazione sopraggiunta: a titolo indicativo e non esaustivo:

o sovrapposizione di attività e conseguente ridefinizione delle priorità

o sospensione delle attività per mancanza di condizioni al contorno (componenti sistemistiche/database ecc.)

o interruzione dell’attività per revisione specifiche

o ri-organizzazioni del team del fornitore per sostituzioni ecc.

• Il supporto per la stesura dei documenti di prefattibilità e di analisi-requisiti per ogni intervento di nuovo sviluppo o di manutenzione evolutiva.

• Il controllo e la supervisione di ogni Ordinativo di lavoro, condiviso tra ASPI e il Fornitore e redatto secondo il Modello n. 3.

• La condivisione con ASPI di tutte le attività non preventivabili e consuntivabili a consumo con l’indicazione di giorni per figura professionale (coordinamento della fornitura, supporto applicativo, manutenzione correttiva ecc..).

• Supporto per l’aggiornamento di ogni Verbale di collaudo relativo al corrispondente ordinativo di lavoro (Modello n. 3).

• La redazione della Consuntivazione Mensile riportante l’elenco delle attività terminate con le relative figure professionali, i relativi giorni impiegati e l’importo risultante. Il linea generale tale documento deve essere redatto entro il quinto giorno lavorativo del mese successivo a quello di riferimento. In dettaglio questo documento prevede:

o una sezione in cui si riportano tutti gli interventi conclusi nel mese relativi al piano delle attività (nuovi sviluppi e manutenzione evolutiva) in cui si indicano i corrispondenti ordinativi di lavoro - verbali di collaudo.

o una sezione di consuntivazione per tutte le attività non preventivabili (coordinamento della fornitura, supporto applicativo)

• Redazione mensile del Piano di Qualità (vedi Modello n.6) entro il quinto giorno lavorativo del mese successivo a quello di riferimento secondo gli indicatori illustrati nel capitolo 9.

Al fine di garantire un servizio ottimale, ASPI (con la partecipazione del Direttore dell’Esecuzione del Contratto e dei responsabili informatici della U.O. ITS/STW/ADW direttamente interessati nella gestione e nel coordinamento dei servizi) ed il Fornitore (con la partecipazione del Referente del Contratto), effettueranno delle riunioni con periodicità mensile per verificare i risultati conseguiti, consuntivare le attività del mese precedente e pianificare al meglio interventi e attività futuri.

7.6 Nuovi Sviluppi e Manutenzione evolutiva

ASPI, a fronte di attività di change management, per richieste di manutenzione evolutiva (compresa manutenzione adattativa, preventiva, migliorativa) e nuovi sviluppi, attiva il processo sulla base della corrispondente procedura aziendale.

Questa prevede che, nei casi di change significativi (in genere con un effort superiore a 5 giorni/uomo) venga prodotto inizialmente lo studio di prefattibilità (vedi Modello n.4), per la cui stesura ASPI può richiedere supporto al Fornitore.

L’iter interno prevede a questo punto una fase di verifica e di autorizzazione a proseguire nell’intervento. In caso affermativo e i in tutti i casi in cui questa fase preliminare non sia necessaria, inizia il vero e proprio processo di change che coinvolge il Fornitore negli step descritti di seguito:

• Il Fornitore produce insieme ad ASPI il documento di analisi/requisiti.

• Nel caso di nuovi sviluppi è necessario che il Fornitore supporti ASPI negli incontri con i gestori interni dell’esercizio

(sistemisti, DBA) per la condivisione di architetture, banche date, problematiche relative alla sicurezza.

• ASPI con il supporto del Fornitore produce l’ordinativo di lavoro che rappresenta il documento formale attraverso il quale XXXX condivide con il Fornitore l’effort per l’intervento e le scadenze. L’ordinativo di lavoro riporta in dettaglio le attività previste, il relativo effort in giorni/uomo per ciascuna figura professionale individuata e la data prevista per il rilascio/collaudo e può essere eventualmente suddiviso per le varie fasi progettuali in caso di lavori di grande entità.

• Qualora ASPI e il Fornitore NON concordino con le modalità, i tempi o gli effort di realizzazione costituenti l’ordinativo di lavoro e con gli eventuali vincoli realizzativi indicati verrà attivata la procedura di escalation prevista al punto 7.6.1 di tale Capitolato Tecnico. Deve essere infine aggiornato il documento relativo alla sintesi delle attività.

• Il Fornitore definisce le specifiche di dettaglio (eventualmente con il supporto del personale ASPI), sviluppa il codice in autonomia e provvede ad effettuare Unit Test.

• Una volta completato il Fornitore rilascia il change per effettuare le varie fasi di collaudo previste. In caso di esito negativo si ripete lo step precedente.

• ASPI effettua il deploy con il supporto del Fornitore.

• In tutti quei casi in cui subentrino cause che possano impattare sulla data di rilascio prevista (condizioni al contorno, conflitto con altre attività, ecc), Fornitore e ASPI concordano una ripianificazione con conseguente aggiornamento dell’ordinativo di lavoro e della sintesi delle attività.

• Nel momento in cui le funzionalità e/o prodotti previsti nell’ambito dell’ordinativo di lavoro sono disponibili per il Collaudo, ASPI darà il via alle attività di collaudo e verifica funzionale e di sicurezza. Per i criteri di accettazione vale quanto previsto al punto 7.6.2 del presente Capitolato Tecnico. In caso di esito negativo si riparte dallo step di definizione delle specifiche di dettaglio.

• In caso di positiva conclusione dei collaudi sarà redatto e firmato da entrambe le Parti il relativo Verbale di Xxxxxxxx e il Fornitore dovrà aggiornare il documento riportante la sintesi delle attività.

• La consuntivazione delle attività per la fase di corresponsione avviene con cadenza mensile posticipata a fronte della compilazione del documento di Consuntivazione Mensile relativamente alle attività completamente evase.

7.6.1 Procedura di escalation

La seguente procedura viene seguita se è necessario definire una controversia tra le Parti in relazione a discordanze nelle valutazioni circa le modalità, i tempi o i costi di realizzazione richiesti al Fornitore attraverso l’ordinativo di lavoro.

In tal caso i componenti il gruppo di lavoro di entrambe le Parti, prima di ogni altra azione, si adoperano, per risolvere il problema internamente. Successivamente vengono effettuati i seguenti passi:

1. se il gruppo di lavoro di entrambe le Parti non è in grado di definire la controversia, Autostrade per l’Italia ed il Fornitore si incontrano per risolvere la controversia definendo le azioni che ciascuna Parte deve intraprendere;

2. diversamente si scalerà nell’organizzazione aziendale di ASPI e del Fornitore, al fine di individuare una soluzione di reciproca soddisfazione, definendo le ulteriori azioni che ciascuna Parte deve intraprendere.

7.6.2 Criteri di accettazione

Ciascun rilascio di software o di prodotti si intenderà correttamente ultimato solo se entro i termini al riguardo previsti nei singoli ordinativi di lavoro sarà stato consegnato ad quanto specificatamente richiesto compresa la relativa documentazione.

Nel caso di rilascio software, oggetto di consegna saranno i programmi (sorgenti ed eseguibili) richiesti nell’ordinativo nonché:

• la documentazione dei casi di prova cui il prodotto software è stato sottoposto dal Fornitore, con l’indicazione dei risultati ottenuti.

• la documentazione necessaria ad esercire il prodotto software.

Il software o i prodotti oggetto degli ordinativi di lavoro saranno sottoposti da parte di ASPI ad apposite verifiche:

• alla verifica della correttezza e completezza dei casi di prova consegnati dal Fornitore;

• alla eventuale individuazione di ulteriori casi di prova da parte di ASPI ed alla loro approvazione da parte del Fornitore con inserimento nel relativo piano di verifica, a meno che lo stesso Fornitore rilevi (documentando a ASPI le motivazioni) che i casi di prova individuati da ASPI risultino non applicabili;

• all’approvazione da parte di ASPI dei casi di prova così elaborati.

Successivamente al rilascio di funzionalità si procederà quindi con le attività di collaudo e più precisamente:

• alla esecuzione da parte di ASPI dei casi di prova dalla stessa approvati;

• alla effettuazione da parte di ASPI di apposite prove libere di stress funzionale e/o prestazionale del software rilasciato.

• alla conseguente eventuale individuazione di ulteriori casi di prova da parte di ASPI – a fronte di rilevanti errori emersi in sede di prove libere di stress – ed alla loro approvazione da parte del Fornitore con inserimento nel relativo piano di verifica, a meno che lo stesso Fornitore rilevi (documentando a ASPI le motivazioni) che i casi di prova individuati di ASPI risultino non applicabili;

• alla correzione da parte del Fornitore di tutti gli errori eventualmente rilevati ed alla conseguente tempestiva verifica degli stessi da parte di Autostrade per l’Italia.

Le verifiche di cui sopra termineranno positivamente con la decisione da parte di ASPI di mettere in esercizio le funzionalità rilasciate o di considerare comunque terminate le relative verifiche. Al riguardo resta inteso che tali decisioni dovranno essere assunte e notificate per iscritto da ASPI al Fornitore.

XXXX è responsabile della tempestiva esecuzione della procedura di accettazione e comunque entro i tempi di collaudo specificati nell’ordinativo di lavoro.

Il documento che comprova il positivo superamento dei Collaudi è il Verbale di Xxxxxxxx che sarà firmato da ASPI e controfirmato dal Fornitore.

7.7 Supporto Applicativo e Supporto all’utente

Le due categorie di servizi denominate Supporto Applicativo e Supporto all’utente sono erogate mediante processi e modalità tra loro analoghi.

Rientrano in queste categorie le attività di supporto e di consulenza che il Fornitore eroga a fronte di richieste e segnalazioni provenienti da personale di ASPI e altre Società Clienti. Di norma tutti gli interventi rientranti in tali categorie non implicano alcuna modifica o correzione al codice applicativo.

L’attivazione del servizio avverrà tramite lo strumento di ticketing in uso presso ASPI (Service request, Technical request) o con i dispositivi e le procedure che i Sistemi Informativi rendono disponibili per effettuare le richieste di supporto e di assistenza, tra cui posta elettronica e telefono.

Il Fornitore adotterà un Sistema di Gestione per il servizio così articolato :

• Riceve la richiesta di assistenza o supporto (ne registra richiedente, tipologia della richiesta e relativa descrizione, data e ora di attivazione se telefonica).

• Analizza la richiesta ed innesca il processo relativo, interagisce con ASPI fornendo informazioni sulla pianificazione delle attività, con particolare riferimento al tempo di soluzione previsto, e sullo stato di avanzamento della richiesta.

• Fornisce i risultati o prodotti della richiesta.

• Informa ASPI della chiusura del Ticket.

• Gestisce il tracking delle richieste di supporto e assistenza, in particolare curandone gli stati di avanzamento fino alla chiusura e aggiornando una base dati di soluzioni adatte a seguito della specifica tipologia di richiesta.

Il Fornitore è tenuto a riportare ogni attività relativa a questo servizio nel documento Sintesi delle Attività nella sezione dedicata agli interventi a consuntivo.

La consuntivazione delle attività per la fase di corresponsione avviene con cadenza mensile posticipata compilando le relative sezioni del documento di Consuntivazione Mensile

7.8 Manutenzione Correttiva

Le richieste di manutenzione correttiva nascono di norma attraverso l’acquisizione da parte dell’Help Desk di primo livello di ASPI delle segnalazioni/chiamate per malfunzionamenti o errori di funzionalità dei sistemi/applicazioni da parte degli utenti finali e inserite in un sistema di gestione delle chiamate per anomalie (Incident Ticket con lo strumento di ticketing in uso presso ASPI). Tali segnalazioni vengono successivamente prese in carico dal Service Desk Applicativo ed instradate verso l’unità organizzativa competente. E’ così assicurato il tracciamento e l’assegnazione dell’intervento ai vari livelli di competenza.

Ogni richiesta di intervento sarà qualificata da parte di ASPI con tutti i dettagli utili alla caratterizzazione e individuazione dell’errore, malfunzionamenti e/o problemi/ostacoli di usabilità:

 Data e ora segnalazione anomalia e quindi richiesta di intervento

 Livello di Severità dell’errore attribuito da XXXX (si veda punto 9.1.1. del presente Capitolato Tecnico)

 Informazioni utili per determinare le attività da effettuare, in termini di:

o area applicativa, procedura e funzionalità oggetto del problema

o descrizione dell’errore e delle modalità operative per cui si verifica l’errore

o risultato atteso verso risultato ottenuto

o tutte le informazioni necessarie per riprodurre il caso di errore nell’ambiente di test ed accelerare il processo di risoluzione (anche tramite l’esempio di caso errato)

Autostrade per l’Italia, per garantire la massima tempestività nell’attivazione degli interventi a fronte di errori o malfunzionamenti, potrà avvalersi di ulteriori canali di comunicazione oltre lo strumento di Ticketing, quali:

• una casella di posta elettronica a cui gli utenti dei sistemi/applicazioni possono destinare richieste o evidenze di vario tipo,

• richieste di intervento direttamente da parte dei referenti di ASPI al Fornitore.

Il Fornitore dovrà farsi parte diligente nel consultare costantemente gli ambienti messi a disposizione per verificare presenze di segnalazioni di anomalie o malfunzionamenti: accedere allo strumento di ticketing in uso presso ASPI, consultare la posta elettronica. In tali casi, così come in quelli con richiesta diretta di intervento da parte di Autostrade per l’Italia, il Fornitore dovrà attivarsi immediatamente per individuare gli interventi per la correzione dell’errore sulla base della Severità ad esso assegnata, dovrà condividere le soluzioni da apportare con ASPI e poi attuare gli interventi per la rimozione dell’anomalia, determinando l'effort occorrente e valutando il livello di servizio corrispondente da assicurare.

Il Fornitore adotterà un Sistema di Gestione per il servizio così articolato :

• La presa in carico da parte del Fornitore avviene alla ricezione della segnalazione ad opera di Autostrade per l’Italia, attraverso i meccanismi o procedure di comunicazione previsti.

• La segnalazione dell’errore porta anche l’indicazione della sua Severità assegnata da Autostrade per l’Italia. Tale Xxxxxxxx potrà comunque essere oggetto di contraddittorio e quindi di modifica nel corso dell’iter dell’intervento.

• Il Fornitore provvederà all’identificazione del problema (“problem determination”), eventualmente ricontattando l’utente di ASPI (o Società del Gruppo) che ha riscontrato l’inconveniente e prodotto la segnalazione.

• Il Fornitore definirà la soluzione dell’inconveniente segnalato e la condividerà con i Referenti di Autostrade per l’Italia; nel caso in cui non sia individuabile alcuna soluzione, causa non completezza della segnalazione e/o impossibilità di riprodurre l’errore, anche a seguito di un esame approfondito del problema, all’errore verrà assegnato lo stato di “sospeso” (quindi archiviato) e l’effort profuso sarà riconosciuto nell’ambito della rendicontazione del periodo di pertinenza per i servizi di Manutenzione Correttiva.

• Qualora, a seguito dell’analisi, risulti che il presunto errore non è tale e che la segnalazione richiede più che altro un’evoluzione/adeguamento delle funzionalità oggetto di segnalazione, l’intervento sul codice dei programmi software verrà

riclassificato come richiesta di Manutenzione Evolutiva. In tal caso, il tempo impiegato dal Fornitore per effettuare la “problem determination” sarà riconosciuto nell’ambito della rendicontazione del periodo di pertinenza per la Manutenzione Correttiva, mentre quello necessario alla realizzazione sarà oggetto di ordinativo di lavoro per il servizio di Manutenzione Evolutiva.

• Qualora, a seguito dell’analisi, risulti che il presunto errore è causato da situazioni incongrue nell’ambito delle

applicazioni sorgente (ad esempio dati incongruenti all’origine, che quindi impediscono il completamento della procedura di alimentazione del DW), verranno prese le misure opportune per smistare il problema al gruppo applicativo che ha in carico il sistema sorgente e per gestire la situazione minimizzando il disservizio che ne può derivare, eventualmente ricorrendo a workaround in attesa che il problema sia risolto in modo definitivo.

• La soluzione dell’inconveniente da parte del Fornitore deve consentire il ripristino delle normali funzionalità

dell’applicazione in errore. Può in alternativa, concordandolo con ASPI, definire una “Fix” temporanea o di un “Workaround”

che permetta di riattivare nei tempi previsti le funzionalità dell’applicazione, demandando la realizzazione della soluzione definitiva a tempi successivi.

• Il Fornitore procede alla correzione e al test e comunica ad ASPI la disponibilità al test per l’accettazione.

• XXXX effettua il test di accettazione e fornisce autorizzazione formale al Fornitore per procedere al rilascio nell’ambiente “target”. In casi straordinari ASPI potrà richiedere al Fornitore il rilascio in esercizio anche in mancanza del test di accettazione; in tal caso l’intervento di manutenzione correttiva sarà considerato approvato da Autostrade per l’Italia.

• Il Fornitore rilascerà ad ASPI tutte le librerie contenenti il formato sorgente della soluzione sviluppata, le versioni aggiornate della documentazione, compresa una sintetica descrizione della soluzione adottata, eventuali nuovi kit per la distribuzione.

• Qualora gli interventi eseguiti richiedano revisione della documentazione di sistema, architettura o altro, queste revisioni saranno a carico del Fornitore.

• Il Fornitore procede alla chiusura dell’errore (stato di “chiuso”) apponendo sulla segnalazione la data e l’ora di completamento dell’intervento e una sintetica descrizione della soluzione adottata.

• Alla risoluzione dell’inconveniente in ambiente di esercizio, o comunque, al momento della chiusura della chiamata, il Fornitore ne darà comunicazione ai Referenti di Autostrade per l’Italia.

• Il Fornitore mantiene traccia dei problemi aperti; l’elenco dei problemi aperti con relativa Severità sarà a continua disposizione di Autostrade per l’Italia.

• Con cadenza mensile il Fornitore produce l’elenco degli interventi effettuati (col documento di Consuntivazione Mensile) a fronte di tutte le segnalazioni ricevute, in cui vengono dettagliate per ogni intervento:

o Data e ora della segnalazione

o Data e ora di presa in carico

o Data e ora di chiusura

o Severità dell’errore

o Eventuali eventi che abbiano causato ritardi nella gestione/risoluzione

o Figure professionali utilizzate e tempo impiegato

• Redazione mensile del Piano di Qualità entro il quinto giorno lavorativo del mese successivo a quello di riferimento secondo gli indicatori illustrati nel capitolo 9.

• ASPI e il Fornitore procedono quindi ad una verifica congiunta del suddetto elenco per:

o Consuntivare gli interventi (loro valorizzazione economica) e valutare il rispetto o meno dei tempi previsti nei livelli di servizio

o Analizzare in dettaglio eventuali casi di ritardo nella presa in carico e/o nella risoluzione delle anomalie

Nei casi in cui i malfunzionamenti riscontrati nel software applicativo procurino errori, incongruenze o perdite di dati, il Fornitore si adopererà per ripristinare i dati corretti a proprio carico, senza ulteriore onere per ASPI. A tale scopo ASPI fornirà, dietro richiesta del Fornitore, le specifiche autorizzazioni ad operare sui dati e, ove si renda necessario, il supporto dei settori tecnici competenti.

Le verifiche di cui sopra termineranno positivamente con l’accettazione formale da parte di ASPI o la messa in esercizio delle funzionalità rilasciate. La consuntivazione delle attività per la fase di corresponsione avviene con cadenza mensile posticipata

7.9 Rilascio del servizio (Hand Over)

Questa attività si riferisce al passaggio di consegne verso un altro fornitore (Società subentrante) durante la fase conclusiva del rapporto contrattuale tra Committente e Fornitore.

Il Fornitore, a partire da 60 gg prima della scadenza del Contratto, dovrà garantire la massima disponibilità alle attività di passaggio e trasferimento informazioni e documentazione ad ASPI e/o ad altro Fornitore, in particolare tutte quelle conoscenze relative alle peculiarità delle applicazioni, con particolare riferimento a quelle maturate nel periodo di erogazione dei servizi.

Prima dell’avvio della fase di Hand Over verrà condiviso e redatto un Piano di Rilascio che specifichi le modalità con cui verrà svolta questa fase. Il Programma sarà predisposto e sottoscritto da Committente e Società subentrante, e comunicato al Fornitore entro 10 gg solari dall’avvio effettivo della fase di Hand Over.

Le attività di trasferimento di conoscenze e documentazione verranno svolte mediante opportune sessioni di lavoro condivise con Autostrade per l’Italia, in modo da rispettare i termini relativi al passaggio di consegna.

Durante la fase di Hand-over, la responsabilità della conduzione e gestione del Contratto rimarrà a carico del Fornitore; esso dovrà continuare a garantire i livelli di servizio previsti dal contratto; inoltre sarà compito e responsabilità del Fornitore rendere disponibile personale qualificato facente parte del Gruppo di Lavoro in essere per le attività di passaggio di consegne, indicando il proprio Responsabile di riferimento per queste attività.

E’ inoltre compito e responsabilità del Fornitore organizzare ed integrare la documentazione funzionale e tecnica messa a disposizione da ASPI al fine di agevolare la fase di transizione verso la Società subentrante.

Il Programma di Hand Over sarà definito in modo tale da:

• Minimizzare l'impatto sul Fornitore e sulla struttura interna ASPI di riferimento.

• Garantire la continuità del servizio dal momento dell’inizio dell’erogazione dei servizi oggetto della nuova fornitura, al termine della fase di Hand Over.

• Concordare una metodologia a supporto del consolidamento della documentazione e del know-how rispetto alla documentazione presente.

• Concordare la tipologia e il numero di risorse dedicate da parte del Fornitore.

Le eventuali modifiche in corso d’opera al Programma di Hand Over dovranno essere concordate da Committente e Società subentrante e comunicate al Fornitore con adeguato anticipo.

La fase di Hand Over deve completarsi prima dell’inizio dell’erogazione dei servizi da parte della Società subentrante. La conclusione della fase di Hand Over sarà sancita dalla redazione e sottoscrizione di un Verbale di presa in consegna e carico da parte della Società subentrante per ogni processo/applicazione in ambito di gara.

Da quel momento il Fornitore sarà sollevato da qualsivoglia responsabilità sui servizi erogati, e terminerà la rendicontazione e l’efficacia di SLA e relative Penali nei suoi confronti.

Qualunque anomalia comportamentale rivolta nei confronti del personale della Società subentrante sarà oggetto di immediato intervento e potrà, se reiterata, comportare applicazione di penale nonché l’immediata esclusione e cancellazione dall’albo fornitori della Committente.

Qualora, viceversa, il personale della Società subentrante creasse ostacolo alla regolare esecuzione delle attività, il fatto dovrà essere immediatamente segnalato ai responsabili della Committente che avranno facoltà di intervenire disciplinando l’affiancamento.

8. Modello di governance e matrice delle responsabilità

Il modello di Governance è la struttura organizzativa, finalizzata alla gestione delle relazioni tra ASPI e il Fornitore.

Come previsto dal Codice degli Appalti, ASPI nominerà una figura che sarà indicata come Direttore dell’Esecuzione del Contratto (DEC) che coadiuverà il RUP nel coordinamento, direzione e controllo tecnico-contabile dell’esecuzione del contratto, in modo da assicurarne la regolare esecuzione. In particolare, il DEC ha la funzione di coordinare il team dei Responsabili Informatici delle Applicazioni (RIA) interni.

Il Fornitore, a sua volta, metterà a disposizione una figura di Referente Tecnico (RT), unico per l’intera fornitura, a coordinamento di tutte le attività erogate, del team di specialisti esterni e chiamato a svolgere tutti gli adempimenti amministrativi.

DEC e RT si interfacceranno in maniera periodica e ogniqualvolta se ne presenti la necessità per supervisionare lo stato di avanzamento delle varie attività, per effettuare i consuntivi mensili, per risolvere problematiche emerse nell’erogazione dei servizi, ecc. come è descritto in dettaglio nel paragrafo relativo all’erogazione del coordinamento della fornitura.

8.1 Ruoli lato Autostrade per l’Italia

Di seguito sono descritte le figure con i relativi ruoli e responsabilità di Autostrade per l’Italia.

Struttura di

riferimento

Figura

Ruolo e responsabilità

ASPI ITS/STW/ADW

Direttore dell’Esecuzione del Contratto (DEC)

E’ la risorsa di ASPI cui compete il controllo, il coordinamento e l’attivazione dei servizi oggetto di fornitura.

E’ responsabile di:

• coordinare il team interno dei RIA

• supervisionare l’andamento del contratto verificando il rispetto delle clausole

• partecipare agli stati di avanzamento periodici pianificati con il Fornitore

• gestire le priorità in caso di conflitto di attività

• Condividere insieme al Fornitore le consuntivazioni mensili

• verificare il raggiungimento dei Livelli di Servizio previsti e definire, controllare e concordare con il Fornitore eventuali azioni in caso di Livelli di Servizio non in linea con quanto definito.

• gestire le escalation di primo livello.

ASPI ITS/STW/ADW

Responsabile Informatico delle Applicazioni (RIA)

Risorse di ASPI, con il ruolo di supervisionare lo sviluppo, la manutenzione e l’evoluzione di una o più applicazioni informatiche. Anche Responsabile Applicativo. Fungono inoltre da interfaccia verso gli Utenti o Clienti per la raccolta dei requisiti. Sono responsabili di:

• fornire/indicare i requisiti per lo svolgimento delle attività di Nuovi Sviluppi, e Manutenzione evolutiva, concordarne la pianificazione col Fornitore e definire i criteri di accettazione

• concordare col Fornitore ed emettere gli ordinativi di lavoro per i servizi di Nuovi Sviluppi e Manutenzione Evolutiva.

• validare i prodotti rilasciati dal Fornitore, richiesti negli ordinativi di lavoro, entro la data prevista di effettuazione collaudo

• disegnare ed eseguire i casi di test di accettazione

• supportare il Fornitore nella risoluzione degli errori applicativi in ambiente di produzione e condividere con esso la soluzione da approntare.

ASPI ITS/ SISTEMI INFORMATIVI

Personale di Esercizio Sistemi

Sono tutte le figure tecniche che gestiscono il sw di base (sistemi operativi, database, rete, storage ecc..) che costituisce l’ambiente in cui i sistemi/applicazioni ambito di gara si devono integrare

Struttura di

riferimento

Figura

Ruolo e responsabilità

ASPI – Altre Società Clienti

Utenti

Sono tutti gli Utenti di ASPI e Società Clienti che utilizzano i sistemi/applicazioni e che possono richiedere un’attività di supporto e assistenza nonché essere coinvolti dai Referenti di ASPI nelle diverse fasi dei processi di erogazione dei servizi.

8.2 Ruoli lato Fornitore

Di seguito sono descritte le figure con i relativi ruoli e responsabilità del Fornitore.

Figura

Ruolo e responsabilità

Referente Tecnico (RT)

E’ la figura del Fornitore chiamata a partecipare alle riunioni periodiche (mensili) con il DEC di ASPI per la verifica dei risultati conseguiti e la pianificazione degli interventi e attività future.

E’ inoltre responsabile di gestire:

• l’efficacia dei servizi, ossia controllare i Livelli di Servizio, misurare documentare ed informare ASPI sul servizio reso, essere il primo punto di riferimento per i problemi e le controversie sul servizio;

• il rispetto dei Livelli di Servizio

• l’escalation di primo livello

• le risorse assegnate ai servizi

• il rispetto delle regole contrattuali

Il Referente Tecnico (RT) svolge anche funzioni di Referente applicativo, pertanto è responsabile di:

• attivare e svolgere i servizi in base agli ordinativi di lavoro, producendo i prodotti in esso richiesti (studi di fattibilità, analisi funzionale e tecnica, sviluppo programmi, ecc..)

• gestire e controllare tutte le fasi del processo di delivery di tutte le attività di sviluppo applicativo e di assistenza erogate nell’ambito del servizio.

Team Operativo

E’ il gruppo di lavoro che segue e realizza le attività operative, è responsabile dei singoli interventi di manutenzione e di sviluppo che vengono commissionati da Autostrade sotto la forma di ticket o ordinativi di lavoro.

8.3 Matrice delle responsabilità

La tabella sotto riportata costituisce una macro suddivisione delle responsabilità tra ASPI e il Fornitore nell’ambito dei servizi oggetto di fornitura.

Attività	Ruoli		Principali rilasci	Servizi
Attività	Fornitore	Autostrade per l’Italia	Principali rilasci	Man Ev. e Nuovi Svil.	Man Corr.
Segnalazioni di malfunzionamenti e Richieste di Manutenzione Evolutiva e Nuovi sviluppi
Segnalazione malfunzionamenti e informazioni che li caratterizzano		Responsabile			
Assegnazione della severità al malfunzionamento		Responsabile			
Presa in carico delle segnalazioni di malfunzionamento	Responsabile				
Individuazione e definizione requisiti richieste utente	Responsabile		Documento dei Requisiti	
Prioritizzazione degli interventi dimanutenz. evolutiva e nuovi sviluppi e relativo Piano	Supporto	Responsabile	Piano di Man Evol. e Nuovi Svil.	
Analisi e stima della soluzione i (effort risorse)	Responsabile	Approva	Stima per Ordinativo di lavoro	
Stesura requisiti di dettaglio	Responsabile	Approva	Documento dei requisiti
Emissione ordinativo di lavoro	Approva	Responsabile	Ordinativo di lavoro	
Analisi e disegno
Analisi di dettaglio e identificazione dei malfunzionamenti	Responsabile	Approva	Documento di analisi		
Analisi e disegno di dettaglio degli interventi di man. evol. e nuovi sviluppi	Responsabile	Approva	Documento di analisi	
Implementazione
Sviluppo/manutenzione/correzione del codice applicativo	Responsabile		Documentaz. del codice		
Sviluppo dei casi di test per il system test nell’ambiente di sviluppo/test	Responsabile		Casi di test		
Documentazione in linea con standard e specifiche	Responsabile	Approva	Manuali previsti	
Test
Produzione del piano di test	Responsabile	Approva	Piano di test	
Esecuzione di unit e integration test	Responsabile		Risultati del Test		
Esecuzione del system test	Responsabile		Risultati del Test		
Segnalazione Disponibilita’ al Test di Accettazione	Responsabile				
Esecuzione del test di accettazione	Supporto	Responsabile	Verbale di Xxxxxxxx		
Delivery
Segnalazione Disponibilità alla Distribuzione/Installazione	Responsabile				
Autorizzazione alla migrazione del software in ambiente di produzione		Responsabile	Richiesta in produzione		
Rilascio nell’ambiente di produzione		Responsabile			
Produzione Reportistica / Consuntivi	Responsabile		Reportistica aggiornata		

Legenda:

• Responsabile: la parte identificata è responsabile dell’attività

• Approva: la parte identificata deve essere d’accordo e approvare i risultati dell’attività

• Supporto: la parte identificata deve fornire assistenza per il raggiungimento dei risultati dell’attività.

8.4 Responsabilità nel Trattamento dei dati personali

In considerazione del fatto che la formalizzazione del contratto comporterà per l’Appaltatore la visualizzare e il trattamento di dati personali di cui la Committente è Titolare, la stessa provvederà a nominare, con separata lettera l’Appaltatore quale “Responsabile” del Trattamento ai sensi dell’art. 29 del D.Lgs 196/03.

Del pari l’Appaltatore, e per Xxxx il nominato Responsabile del Trattamento si dovrà impegnare a nominare gli addetti allo svolgimento delle attività connesse con l’esecuzione del contratto “Incaricati” del Trattamento ai sensi e per gli effetti dell’art. 30 del D.Lgs 196/03.

9. Livelli di Servizio

I livelli di servizio (Service Level Agreement - SLA) sono misure concordate tra le Parti (relative ai processi di erogazione dei Servizi che saranno adottati e alla gestione del gruppo di lavoro) che consentono di quantificare e qualificare i Servizi erogati ad Autostrade per l’Italia.

Per i servizi oggetto della presente fornitura sono stati individuati SLA afferenti alle seguenti categorie:

• Manutenzione correttiva. Per questa sono state definite delle misure in relazione alla tempestività di risoluzione delle anomalie e del grado di correttezza della risoluzione.

• Manutenzione evolutiva e nuovi sviluppi. Per questa si adottano delle misure sul rispetto dei tempi stabiliti per la consegna sia degli studi di analisi che dei prodotti finiti.

• Adeguatezza del Gruppo di Lavoro: Criteri per garantire l’aderenza delle risorse facenti parte del Gruppo di Lavoro ai livelli di competenza ed esperienza migliorativi dichiarati dal Fornitore in sede di offerta tecnica.

• Stabilità del Gruppo di Lavoro. Criteri per garantire la stabilità del Gruppo di Lavoro durante tutta la durata dell’esecuzione del Contratto e per la gestione di eventuali sostituzioni di una risorsa.

I livelli di servizio (SLA) di seguito definiti sono quelli minimi che il Fornitore è tenuto a rispettare nell’esecuzione delle attività.

Per alcuni Servizi il Fornitore potrà impegnarsi con la presentazione della propria Offerta Tecnica al rispetto di livelli di servizio migliorativi rispetto a quelli definiti da ASPI; in questi casi la committente farà riferimento agli SLA migliorativi indicati dal fornitore aggiudicatario che assumeranno valore contrattuale e di riferimento per la misurazione della performance e l’applicazione delle relative penali.

9.1 SLA per Manutenzione Correttiva

9.1.1 Severità degli errori

ASPI classifica le anomalie secondo una scala di severità crescente che va da 1 a 5:

Severità 1: Molto Bassa

Severità 2: Bassa

Severità 3: Normale

Severità 4: Alta

Severità 5: Molto Alta

sulla base di una serie di elementi quali: l’area applicativa interessata, la sua rilevanza aziendale, l’impatto che provocano, l’urgenza dichiarata dall’utente che ha aperto l’incident, il personale coinvolto, i tempi di risoluzione necessari, ecc..

Ai fini della determinazione dei livelli di servizio per la Manutenzione Correttiva dei sistemi nell’ambito della presente fornitura, la scala di severità verrà ridotta a tre sole fasce:

 Severità 1-2: errore/malfunzionamento e/o problemi di usabilità che causano un degrado di prestazione su una funzionalità con un degrado di prestazione tollerabile per periodi limitati. Non necessitano di intervento urgente.

 Severità 3: errore/malfunzionamento che limita l’utilizzo di almeno una “funzionalità critica” per l’azienda, ma consente comunque di proseguire le operazioni, seppure con serie limitazioni;

 Severità 4-5: errore/malfunzionamento grave che impedisce l’utilizzo di almeno una “funzionalità critica” per l’azienda, o per le aziende che usufruiscono dei servizi erogati da Autostrade per l’Italia, con impatto grave o paralizzante su tutte le operazioni utente; non è possibile giungere al risultato finale utilizzando funzionalità alternative.

Il Fornitore fornirà a Autostrade per l’Italia con frequenza mensile un consuntivo degli interventi di Manutenzione Correttiva per la relativa misurazione dei Livelli di Servizio.

In caso di mancato raggiungimento degli obiettivi, verrà indetta immediatamente una revisione straordinaria tra il Fornitore e ASPI per esaminare le cause del mancato rispetto dei tempi ed attuare un piano di recupero.

In caso di mancato raggiungimento degli obiettivi, Autostrade potrà applicare le penali previste.

Il Fornitore sarà sollevato dall’obbligo di soddisfare qualsiasi Livello di Servizio qualora si rilevi che il malfunzionamento sia causato da azioni o mancate azioni da parte di ASPI o inadempienze da parte di Terze Parti sotto diretto controllo di Autostrade per l’Italia, o circostanze di situazioni di emergenze, o eventi di forza maggiore.

Nell’ambito delle attività di Xxxxxxxxxxxx Xxxxxxxxxx, i Livelli di Servizio minimi richiesti al Fornitore (SLA) sono descritti di seguito.

9.1.2 SLA_01_MC – Tempestività nella risoluzione delle anomalie

Il fornitore dovrà garantire un servizio tempestivo, definito tale se inferiore o uguale al tempo massimo previsto per la risoluzione dei malfunzionamenti in base alla priorità. Sono di seguito indicati i dettagli relativi allo SLA minimo:

Ambito		Manutenzione Correttiva
KPI		SLA_01_MC
Descrizione KPI		% risoluzione degli incident segnalati nei tempi richiesti
Obiettivo KPI		Misurare la performance del fornitore per quanto riguarda le tempestività di risoluzione delle anomalie.
Perimetro di applicazione		Tutte le applicazioni DW e BI
Algoritmo		N. Incident risolti nei tempi richiesti (mensile) SLA_01_MC = 100 N. Incident mensili
Sorgente informativa		Sistema di monitoraggio Autostrade
Periodo di rilevazione		Misurazione e rilevazione mensile. Si fa riferimento a tutti e soli i malfunzionamenti chiusi dal Fornitore nel periodo di osservazione e all’intero ambito per il quale si svolge il servizio.
Livello di Servizio Xxxxxxxxx	Xxx. 4-5	8 ore lavorative	SLA_01_MC_4-5 > 95%
	Sev. 3	20 ore lavorative	SLA_01_MC_3 > 94%
	Sev. 1-2	32 ore lavorative	SLA_01_MC_1-2 > 90%

Il Tempo di Risoluzione è il tempo, espresso in ore lavorative, che intercorre tra il momento della segnalazione dell’anomalia da parte di Autostrade e quello in cui il Fornitore individua e segnala la soluzione del problema.

Qualora l’intervento di manutenzione correttiva risulti così oneroso/complesso da richiedere maggiore tempo per la risoluzione, il Fornitore, entro la metà dei tempi stabiliti in tabella, può richiedere al DEC la deroga agli SLA fissati proponendo a puro titolo indicativo un differente tempo di risoluzione. Il DEC di Autostrade a suo insindacabile giudizio, valuterà la richiesta e comunicherà al Fornitore l’eventuale nuovo tempo limite per la chiusura dell’anomalia.

Tale deroga e il relativo tempo di risoluzione dovrà essere riportata nella reportistica di monitoraggio mensile.

Lo SLA può essere migliorato dal Fornitore in sede di offerta. Tale offerta migliorativa sarà valutata con l’attribuzione di un punteggio tecnico e diventerà vincolante in fase di esecuzione del contratto.

Tutti i tempi sopra indicati sono da intendersi validi all’interno della finestra di orario standard giornaliero del servizio (vedi paragrafo 7.2), al netto della disponibilità di accesso al sistema, ove necessario e applicabile a malfunzionamenti delle applicazioni riproducibili nell’ambiente di sviluppo/test da parte del Fornitore.

Qualora, in sede di offerta, il Fornitore abbia indicato, a titolo migliorativo, un orario di copertura più ampio, lo SLA farà riferimento a tale orario lavorativo e non a quello base.

Qualora il Fornitore abbia garantito anche la disponibilità di una persona facente parte del Gruppo di Lavoro, reperibile H24 7/7 tramite contatto telefonico, essa sarà utilizzata per la gestione delle emergenze al di fuori dell’orario di lavoro dichiarato dal partecipante nell’offerta. A seguito della comunicazione il Fornitore si impegna ad effettuare la presa in carico dell’evento e a garantire tutto il supporto necessario alla soluzione del problema.

Le sospensioni delle attività dovute a fattori esterni al team del Fornitore verranno annotate e detratte dal computo del tempo utilizzato per la risoluzione.

Per le anomalie di Severità 4-5, il Fornitore dovrà garantire l’immediata soluzione del problema, ovvero, in accordo con Autostrade per l’Italia, la predisposizione di soluzioni provvisorie che permettano almeno il ripristino delle funzionalità degradate.

9.1.3 SLA_02_MC – Correttezza delle soluzioni di malfunzionamenti

Il Fornitore dovrà garantire la correttezza delle soluzioni realizzate, definita fissando una misura minima di soluzioni rilasciate al primo collaudo funzionanti rispetto a quelle gestite nel periodo di riferimento (mese solare). Per soluzione funzionante si intende una soluzione che risolva, in via definitiva la richiesta o l’anomalia (la stessa anomalia non si deve ripresentare nell’arco di quindici giorni dalla risoluzione proposta) senza generare altre anomalie correlate. Sono di seguito indicati i dettagli relativi allo SLA:

Ambito	Manutenzione Correttiva
KPI	SLA_02_MC
Descrizione KPI	% Adeguatezza degli interventi effettuati
Obiettivo KPI	Misurare la performance del fornitore per quanto riguarda la correttezza delle soluzioni di malfunzionamenti realizzate.
Perimetro di applicazione	Tutte le applicazioni DW e BI
Algoritmo	N. soluzioni funzionanti senza rework SLA_02_MC = 100 N. Soluzioni rilasciate nel mese
Sorgente informativa	Sistema di monitoraggio Autostrade
Periodo di rilevazione	Misurazione e rilevazione mensile differita di un mese. Si fa riferimento a tutti e soli i malfunzionamenti chiusi dal Fornitore nel periodo di osservazione e all’intero ambito per il quale si svolge il servizio.
Livello di Servizio Richiesto	SLA_02_MC >= 90%

9.2 SLA per Manutenzione Evolutiva e Nuovi Sviluppi

Nell’ambito delle attività di Manutenzione Evolutiva e Nuovi Sviluppi, i Livelli di Servizio minimi richiesti al Fornitore (SLA) sono descritti di seguito.

9.2.1 SLA_03_EV – Tempestività nella consegna dei Documenti di Fattibilità

Il Fornitore dovrà garantire una tempestiva formalizzazione del Documento di Fattibilità (DdF) contenente la stima dei tempi e dei costi, definita tale se presentata entro un tempo massimo previsto in relazione alla complessità della richiesta.

Sono di seguito indicati i dettagli relativi allo SLA:

Ambito	Attività Evolutive
KPI	SLA_03_EV
Descrizione KPI	% di consegna del documento di fattibilità (inclusa stima effort) nei tempi
Obiettivo KPI	Misurare la performance del fornitore per quanto riguarda la tempestività nella fase di analisi di fattibilità di una evolutiva o di un nuovo sviluppo.
Perimetro di applicazione	Tutte le applicazioni DW e BI
Algoritmo	N. evolutive con DdF consegnato nei tempi SLA_03_EV = 100 N. evolutive nel mese
Sorgente informativa	Sistema di monitoraggio Autostrade
Periodo di rilevazione	Misurazione e rilevazione mensile differita di un mese. Si fa riferimento a tutte e sole le richieste evolutive inoltrate al Fornitore nel mese per avere uno studio di fattibilità.
Livello di Servizio Richiesto	48 ore lavorative	SLA_03_EV > 85%

Il Tempo di Consegna del documento fattibilità è il tempo, espresso in ore lavorative, che intercorre tra il momento dell’inoltro della RFC da parte di Autostrade e quello in cui il Fornitore consegna il DdF.

Qualora l’intervento di redazione del documento sia così oneroso o complesso da richiedere un periodo di tempo più ampio, il Fornitore, entro la metà dei tempi stabiliti in tabella, può richiedere al DEC applicativo la deroga agli SLA fissati proponendo a puro titolo indicativo un differente tempo di redazione. Il DEC Autostrade a suo insindacabile giudizio, valuterà la richiesta e comunicherà al Fornitore l’eventuale nuovo tempo limite per la redazione del documento.

Tale deroga e il relativo tempo di redazione dovrà essere riportata nella reportistica di monitoraggio mensile.

Tutti i tempi sopra indicati sono da intendersi validi all’interno della finestra di orario standard giornaliero del servizio (vedi paragrafo 7.2) al netto della disponibilità di accesso al sistema, ove necessario e applicabile a malfunzionamenti delle applicazioni riproducibili nell’ambiente di sviluppo/test da parte del Fornitore.

Qualora, in sede di offerta, il Fornitore abbia indicato, a titolo migliorativo, un orario di copertura più ampio, lo SLA farà riferimento a tale orario lavorativo e non a quello base.

9.2.2 SLA_04_EV – Rispetto dei tempi di completamento attività

Il Fornitore dovrà garantire il rispetto dei tempi di consegna concordati con Autostrade per lo svolgimento delle attività necessarie a completare gli interventi evolutivi, in coerenza con le specifiche. I tempi di consegna sono definiti e concordati in fase di stesura dell’Ordinativo di Lavoro.

Sono di seguito indicati i dettagli relativi allo SLA:

Ambito

Attività Evolutive

KPI

SLA_04_EV

Descrizione KPI

% di rispetto della pianificazione degli interventi effettuati e della coerenza con le specifiche.

Obiettivo KPI

Misurare la performance del fornitore per quanto riguarda il rispetto dei tempi pianificati nel completamento degli interventi evolutivi (manutenzione evolutiva o nuovi sviluppi).

Perimetro di applicazione

Tutte le applicazioni DW e BI

Algoritmo

N. interventi chiusi nei tempi

SLA_04_EV = 100

N. di interventi chiusi

Sorgente informativa

Sistema di monitoraggio Autostrade

Periodo di rilevazione

Misurazione e rilevazione mensile differita di un mese. Si fa riferimento a tutte e sole le richieste evolutive completate dal Fornitore nel mese di analisi.

Livello di Servizio Richiesto

SLA_04_EV >= 90%

9.3 SLA per l’Adeguatezza del gruppo di lavoro

Nella composizione del Gruppo di Lavoro, sia nella fase iniziale, sia qualora si dovessero rendere necessarie sostituzioni di personale, il Fornitore è strettamente tenuto a proporre risorse che posseggano sia i requisiti necessari minimi delle figure professionali richieste, sia quelli aggiuntivi proposti come elemento migliorativo in fase di offerta tecnica.

Quanto dichiarato dal Fornitore nell’offerta tecnica sarà quindi considerato vincolante per il Fornitore stesso e assumerà valore contrattuale e di riferimento per la misurazione della performance e l’applicazione delle relative penali.

Se le risorse non verificano i requisiti aggiuntivi dichiarati dal Fornitore nell’offerta tecnica, verranno applicate penali per

Inadeguatezza del gruppo di lavoro come indicato al capitolo 11.

Per quanto riguarda l’adeguatezza del Gruppo di Lavoro, i criteri vincolanti richiesti al Fornitore sono descritti di seguito.

9.3.1 Titolo di Studio delle risorse

Nell’offerta tecnica il concorrente può proporre una composizione migliorativa del Gruppo di Lavoro garantendo di fornire risorse aventi Titolo di Studio superiore a quello minimo.

In questo caso, definendo la seguente gerarchia di titoli di studio: 1 - diploma di scuola media superiore (tecnico o scientifico);

2 - laurea breve (triennale) in informatica, ingegneria, matematica, statistica o fisica;

3 - laurea magistrale o ad ordinamento unico in informatica, ingegneria, matematica, statistica o fisica.

NOTA: ogni ulteriore livello universitario o corso di specializzazione non verrà considerato come valore aggiunto.

Il Fornitore dovrà garantire la presenza, all’interno del GdL, di risorse in possesso di un Titolo di Studio corrispondente al livello di istruzione dichiarato nell’offerta tecnica.

In caso di erogazione di giornate da parte di risorse con un Titolo di Studio < del livello dichiarato, verrà applicata una penale come indicato al capitolo 11.

9.3.2 Certificazioni Individuali

Nell’offerta tecnica il concorrente può proporre una composizione migliorativa del Gruppo di Lavoro garantendo di fornire risorse in possesso delle seguenti Certificazioni individuali:

• Certificazione SAP Business Objects Business Intelligence Platform

• Certificazione SAP Business Objects Web Intelligence

• Certificazione Talend Data Integration Developer

• Certificazione IBM SPSS Modeler

• Certificazione IBM Big Data

Il Fornitore dovrà garantire la presenza, all’interno del GdL, di un numero di risorse in possesso di tali Certificazioni corrispondentemente a quanto dichiarato nell’offerta tecnica.

In caso di erogazione di giornate da parte di risorse senza certificazione rispetto a quanto dichiarato, verrà applicata una penale come indicato al capitolo 11.

9.3.3 Esperienza su DW e BI nel settore autostradale

Nell’offerta tecnica il concorrente può proporre una composizione migliorativa del Gruppo di Lavoro garantendo di fornire risorse in possesso di una esperienza di almeno due anni (successivamente al 01/01/2012) su attività di DW e BI nel settore autostradale.

Il Fornitore dovrà garantire la presenza, all’interno del GdL, di risorse in possesso di tale esperienza, corrispondentemente a quanto dichiarato nell’offerta tecnica.

In caso di erogazione di giornate da parte di risorse con esperienza non conforme rispetto a quanto dichiarato, verrà applicata una penale come indicato al capitolo 11.

9.4 SLA per la Stabilità del gruppo di lavoro

E’ di grande importanza che il Gruppo di Lavoro si mantenga stabile durante tutta la durata dell’esecuzione del Contratto. Il Fornitore dovrà pertanto garantire un livello di turn-over delle risorse il più basso possibile, a meno che l’eventuale sostituzione di una risorsa non sia stata preventivamente richiesta da Autostrade per l’Italia.

Qualora si dovessero rendere necessarie sostituzioni di personale, il Fornitore dovrà (escludendo le situazioni di cause di forza maggiore) garantire il rispetto di alcuni SLA descritti qui di seguito.

9.4.1 SLA_05_GL – Limitazione del Turn-over delle risorse

Il Fornitore deve garantire il più possibile la stabilità del Gruppo di Lavoro formalizzato inizialmente. Sono di seguito indicati i dettagli relativi allo SLA:

Ambito	Composizione del Gruppo di Lavoro
KPI	SLA_05_GL
Descrizione KPI	Numero annuo di sostituzioni (non richieste da ASPI) di risorse facenti parte del GdL
Obiettivo KPI	Misurare la performance del fornitore per quanto riguarda la stabilità nel tempo del GdL.
Perimetro di applicazione	Tutte le risorse facenti parte del GdL
Algoritmo	SLA_05_GL = N. sostituzioni non richieste da ASPI in un anno
Sorgente informativa	Sistema di monitoraggio Autostrade
Periodo di rilevazione	Misurazione e rilevazione mensile. L’indicatore verrà misurato ogni mese a partire dalla data di avvio del Contratto. Il numero di sostituzioni effettuate in ciascun mese sarà cumulato fino allo scadere di ogni anno, poi verrà azzerato per iniziare nuovamente il conteggio sull’anno successivo.
Livello di Servizio Richiesto	SLA_05_GL < 3

9.4.2 SLA_06_GL – Rispetto dei tempi di preavviso per la sostituzione di una risorsa

Qualora, durante l’esecuzione del contratto, si presenti l’esigenza di sostituire una delle persone facenti parte del Gruppo di Lavoro, il Fornitore dovrà comunicare ad ASPI tale esigenza con un adeguato anticipo rispetto alla data di uscita della risorsa.

Sono di seguito indicati i dettagli relativi allo SLA:

Ambito

Composizione del Gruppo di Lavoro

KPI

SLA_06_GL

Descrizione KPI

Numero di giorni lavorativi che intercorrono tra la Data di comunicazione di uscita di una risorsa facente parte del GdL e la Data di uscita della risorsa stessa.

Obiettivo KPI	Misurare la performance del fornitore per quanto riguarda la tempistica di comunicazione di uscita di una risorsa dal GdL. Sono esclusi casi di forza maggiore (es. morte).
Perimetro di applicazione	Tutte le risorse facenti parte del GdL
Algoritmo	SLA_06_GL = N. gg lavorativi tra Data Comunicazione e Data Uscita
Sorgente informativa	Sistema di monitoraggio Autostrade
Periodo di rilevazione	Misurazione e rilevazione in occasione di eventuale uscita di una risorsa da Gruppo di Lavoro.
Livello di Servizio Richiesto	SLA_06_GL > 20 gg lavorativi

9.4.3 SLA_07_GL – Rispetto dei tempi di sostituzione di una risorsa

Qualora, durante l’esecuzione del contratto, si presenti l’esigenza di sostituire una delle persone facenti parte del Gruppo di Lavoro, il sostituto sia stato individuato dal Fornitore, proposto ad ASPI e da questa accettato, il Fornitore deve adoperarsi per fare entrare il prima possibile la nuova risorsa nel Gruppo di Lavoro. Questo evento sarà sancito dalla sottoscrizione da entrambe le parti dell’apposito modello che formalizzerà la nuova composizione del Gruppo di Lavoro.

Sono di seguito indicati i dettagli relativi allo SLA:

Ambito	Composizione del Gruppo di Lavoro
KPI	SLA_07_GL
Descrizione KPI	Numero di giorni lavorativi che intercorrono tra la Data di Inserimento del sostituto e la Data di uscita dal Gruppo di Lavoro della risorsa da sostituire.
Obiettivo KPI	Misurare la performance del fornitore per quanto riguarda la tempistica di inserimento del sostituto di una risorsa nel GdL: il sostituto deve essere inserito prima dell’uscita della risorsa da sostituire.
Perimetro di applicazione	Tutte le risorse facenti parte del GdL
Algoritmo	SLA_07_GL = N. gg lavorativi tra Data di Inserimento del sostituto e Data di Uscita del sostituendo.
Sorgente informativa	Sistema di monitoraggio Autostrade
Periodo di rilevazione	Misurazione e rilevazione in occasione di eventuale uscita di una risorsa dal Gruppo di Lavoro.
Livello di Servizio Richiesto	SLA_07_GL > 1 g lavorativo

10. Garanzia

Gli interventi a seguito di attività di nuovi sviluppi e di manutenzione evolutiva, sulla base degli ordinativi di lavoro, saranno considerati operativi alla data di accettazione dei relativi prodotti, o in alternativa il loro uso produttivo, ed è previsto un periodo di 12 (dodici) mesi di garanzia a partire da tale data.

In detto periodo il Fornitore correggerà tempestivamente ed a sua cura e spese tutte quelle parti per le quali si dovessero riscontrare vizi e/o errori delle attività compiute, fatti salvi i casi in cui gli stessi derivino da cause a lui non imputabili.

Il collaudo per gli interventi pianificati e formalizzati attraverso “Ordinativi di Lavoro” (OdL) per i servizi di Nuovi Sviluppi e Manutenzione Evolutiva (comprese adattativa, preventiva e migliorativa) viene effettuato al termine delle attività previste; alla consegna dei relativi prodotti finiti si provvederà a redigere un apposito Verbale di Collaudo (VdC) per ogni Ordinativo di Lavoro.

Il Verbale di Xxxxxxxx non verrà emesso in caso di difetti o mancanze tali da rendere il servizio assolutamente inaccettabile. Qualora, invece, i difetti rilevati siano di lieve entità o risolubili in breve tempo, il Committente prescriverà specificatamente le soluzioni da adottare subordinando l’emissione del certificato alla regolare esecuzione delle soluzioni prescritte al Fornitore.

La manutenzione correttiva a fronte della garanzia delle implementazioni per nuovi sviluppi o manutenzione evolutiva comprende gli interventi che dovessero essere necessari per rimuovere non conformità o malfunzionamenti dovuti ad errori all’interno della codifica delle implementazioni e viene prestata sulla base di adeguata documentazione di errore e delle informazioni sul malfunzionamento che saranno fornite da Autostrade per l’Italia. Inoltre sarà cura del personale di ASPI permettere al Fornitore di riprodurre l’errore in ambiente di test.

Anche per tali interventi è previsto un periodo di garanzia di 12 (dodici) mesi a partire dalla data di accettazione dei relativi prodotti.

La garanzia decade :

• qualora si rilevi che il malfunzionamento sia causato da azioni o mancate azioni da parte di ASPI o inadempienze da parte di Terze Parti sotto il controllo di Autostrade per l’Italia, o circostanze di situazioni di emergenze, o eventi di forza maggiore.

• sui programmi o parte degli stessi modificati da ASPI e da Terze Parti sotto il controllo di Autostrade per l’Italia, senza coinvolgimento ed accordo con il Fornitore.

• sui programmi o parte degli stessi eseguiti su piattaforme hardware/software diverse da quelle prescelte per la realizzazione dei programmi.

11. Penali

In questo capitolo vengono riportate le penali applicate per il mancato rispetto dei livelli di servizio.

In caso di mancato rispetto di elementi qualitativi, verranno applicate penali secondo lo schema riportato nella seguente tabella:

Ambito	Valore Penale	Periodicità di addebito
Ritardo nella sottoscrizione del Verbale di Presa in Carico del Servizio	2.000 (duemila) € per ogni giorno di ritardo oltre il termine dei 60 giorni corrispondenti alla fase di Start Up.	Mensile
Inadeguatezza del gruppo di lavoro con riferimento al Titolo di Studio delle risorse	Decurtazione del 5% sulla tariffa giornaliera per ogni risorsa e per ogni livello inferiore rispetto a quanto dichiarato nell’Offerta Tecnica.
Inadeguatezza del gruppo di lavoro con riferimento alle certificazioni tecniche: • Certificazione SAP BO Business Intelligence Platform • Certificazione SAP Business Objects Web Intelligence • Certificazione Talend Data Integration Developer • Certificazione IBM SPSS Modeler • Certificazione IBM Big Data	Decurtazione del 5% sulla tariffa giornaliera per ogni risorsa e per ogni requisito non rispondente a quanto dichiarato nell’Offerta Tecnica.
Inadeguatezza del gruppo di lavoro con riferimento all’esperienza su DW e BI nel settore autostradale	• Analista Senior: decurtazione del 12% sulla tariffa giornaliera se la risorsa non è rispondente a quanto dichiarato nell’Offerta Tecnica. • Programmatore Senior: decurtazione del 4% sulla tariffa giornaliera per ogni risorsa non rispondente a quanto dichiarato nell’Offerta Tecnica. • Programmatore Junior: decurtazione del 2% sulla tariffa giornaliera per ogni risorsa non rispondente a quanto dichiarato nell’Offerta Tecnica.

In caso di mancato rispetto di SLA quantitativi, monitorabili con la misura di KPI, verranno applicate penali secondo lo schema riportato nella seguente tabella:

Ambito	KPI	Valore Penale	Periodicità di addebito
Manutenzione correttiva	SLA_01_MC – Tempestività nella risoluzione dei malfunzionamenti	Per ogni anomalia fuori target oltre gli SLA stabiliti al punto 9.1.2 o quanto dichiarato nell’offerta tecnica se migliorativo: 100 (cento) € per anomalia per ogni 8h di ritardo	Mensile
Manutenzione correttiva	SLA_02_MC – Correttezza delle soluzioni di malfunzionamenti	Per ogni anomalia con rework fuori target oltre gli SLA stabiliti in 9.1.3 o quanto dichiarato nell’offerta tecnica se migliorativo: 100 (cento) € per anomalia per ogni rework
Nuovi Sviluppi e Manutenzione Evolutiva	SLA_03_EV – Tempestività nella consegna dei Documenti di Fattibilità	100 (cento) € per ogni evolutiva con DdF fuori target oltre gli SLA stabiliti in 9.2.1 o quanto dichiarato nell’offerta tecnica se migliorativo.
Nuovi Sviluppi e Manutenzione Evolutiva	SLA_04_EV – Rispetto dei tempi di completamento attività	Decurtazione del 10% del valore dell’intervento per ogni evolutiva con completamento fuori target oltre gli SLA stabiliti in 9.2.2 o quanto dichiarato nell’offerta tecnica se migliorativo.
Composizione del Gruppo di Lavoro	SLA_05_GL – Limitazione del Turn-over delle risorse	3.000 (tremila) € per ogni sostituzione eccedente gli SLA stabiliti in 9.4.1
	SLA_06_GL – Rispetto dei tempi di preavviso per l’uscita di una risorsa dal GdL.	100 (cento) € per ogni giorno lavorativo in meno rispetto allo SLA stabilito in 9.4.2
	SLA_07_GL – Rispetto dei tempi di sostituzione di una risorsa	100 (cento) € per ogni giorno lavorativo in meno rispetto allo SLA stabilito in 9.4.3

Il Fornitore avrà la piena responsabilità del rispetto degli elementi qualitativi e dei livelli di servizio concordati. Al fine della verifica dell’osservanza dei medesimi esso dovrà fornire, su base mensile, il report relativo ai livelli di servizio raggiunti.

La valutazione dell’osservanza dei prescritti SLA ed il calcolo delle eventuali penali, avverrà a partire dal momento della sottoscrizione del Verbale di Presa in Carico.

L’ammontare delle penali non potrà superare la somma complessiva pari al 10% dell’importo massimo contrattuale.

Nel caso in cui le penali raggiungano il valore massimo di cui al precedente punto, ASPI si riserva la facoltà di richiedere la risoluzione del contratto.

12. Riferimento Autostrade per l’Italia

Per chiarimenti in merito al presente Capitolato tecnico e relativi requisiti fare riferimento a:

Xxxxxx Xxxxxxxx

Autostrade // per l’Italia Email: xxxxxxxxx@xxxxxxxxxx.xx Tel: 000 0000000

Mobile: x00 0000000000

in qualità di RUP.

13. Modelli standard

Di seguito alcuni modelli da compilare nelle varie fasi di avvio ed esecuzione del contatto: Modello 1 – Formalizzazione del Gruppo di Lavoro

Modello 2 – Verbale di Presa in Carico del Servizio Modello 3 – Ordinativo di Lavoro / Verbale di Collaudo Modello 4 – Documento di Prefattibilità

Modello 5 – Sintesi delle attività Modello 6 – Piano di Qualità

13.1 Modello 1 – Formalizzazione del Gruppo di Lavoro

FORNITORE: CONTRATTO n.

FORMALIZZAZIONE DEL GRUPPO DI LAVORO n.

 Termine della presa in carico (barrare solo una delle opzioni indicate)

 Sostituzione risorsa/e

La composizione del team del Fornitore, a valere dalla data , è sintetizzata nella tabella seguente.

Figura	Nominativo
Analista Senior
Programmatore Senior 1
Programmatore Senior 2
Programmatore Junior 1
Programmatore Junior 2

La mancata rispondenza ai requisiti dichiarati in fase di offerta (sia minimi che preferenziali) comporta l’applicazione delle azioni e delle penali come indicato nel Capitolato Tecnico.

La figura di riferimento per la gestione delle emergenze è:

Nominativo	Telefono

Data:

Firma DEC ASPI Firma Fornitore

13.2 Modello 2 – Verbale di Presa in Carico del Servizio

FORNITORE: CONTRATTO n.

VERBALE DI PRESA IN CARICO DELLA FORNITURA

Si verbalizza che ha avuto termine la fase di presa in carico per la fornitura dei

“Servizi informatici di progettazione sviluppo e gestione software per ambiente Data Warehouse e sistemi di Business Intelligence”.

Di conseguenza, dalla data inizierà l’erogazione di tutti i servizi previsti dalla fornitura, secondo le modalità indicate nel Capitolato Tecnico. Dalla stessa data saranno quindi attivi tutti gli SLA, e l’applicazione delle relative penali in caso di mancato raggiungimento dei livelli minimi previsti.

Data:

Firma DEC ASPI Firma Fornitore

13.3 Modello 3 – Ordinativo di Lavoro / Verbale di Collaudo

FORNITORE: CONTRATTO n.

Applicazione

ORDINATIVO DI LAVORO N. aaaa-nnn

a preventivo 

RFC n. a consuntivo 

ATTIVITA’:

Impegno previsto:

Figura Professionale	N° giorni	Importo unitario	Euro



TOTALE:

Data inizio prevista: Data rilascio prevista:

Data:

Firma Responsabile Applicativo ASPI Firma Fornitore

VERBALE DI COLLAUDO

Esito positivo  negativo 

Data rilascio effettiva:

Data:

Firma Responsabile Applicativo ASPI Firma Fornitore

13.4 Modello 4 – Documento di Prefattibilità

Documento di Prefattibilità

1. Scopo documento

Il presente documento costituisce una valutazione tecnico-economica delle attività relative a ….

2. Riferimenti RFC:

Autore:

Data di creazione:

Applicazione:

Tipologia intervento (Nuovo Sviluppo, Manut., Evolutiva): Utente Responsabile dell’Applicazione:

Utente Richiedente:

3. Descrizione generale

3.1 Obiettivi dell’intervento:

3.2 Contesto di riferimento:

3.3 Vincoli di realizzazione:

3.4 Requisiti da soddisfare:

3.5 Intervento su applicazione critica:

3.5.1 Descrizione eventuale criticità **

Si No 

3.6 Richiesta di tipo major (impatto rilevante sui servizi IT/Sw sensibile):

Si No 

4. Soluzione proposta e alternative

4.1 Descrizione della soluzione proposta:

4.2 Impatti della soluzione proposta (sul SW preesistente, sui sistemi, sulle BD):

4.3 Descrizione delle eventuali soluzioni alternative (anche se di tipo procedurale e organizzativo):

5. Valutazione costi-benefici :

6. Accettazione della Proposta Gestore della Richiesta:

Accettazione: Si No  Motivazioni del rifiuto:

Utente Responsabile dell’Applicazione:

Responsabile Intervento (in caso di modifiche Tecnologiche):

Accettazione: Si No  Motivazioni del rifiuto:

Direttore Responsabile dell’Applicazione (solo per richieste Major):

Accettazione : Si No  Motivazioni del rifiuto :

Legenda :

** opzionale

13.5 Modello 5 – Sintesi delle attività

Foglio 1: Sintesi Attività di Manutenzione Evolutiva e Nuovi Sviluppi

Foglio 2: Sintesi Attività di Manutenzione Correttiva, Supporto Applicativo, Supporto all’utente, Coordinamento Fornitura, Attività di Hand Over

13.6 Modello 6 – Piano Qualità

Document Metadata

Table of Contents

ALLEGATO A – Capitolato Tecnico

Document Metadata