Procedura aperta. Tel.: / Fax: AlmavivA - The Italian Innovation Company s.p.a.

(1)

UIRNet S.p.A.

Gara a procedura aperta per l'affidamento del servizio di realizzazione, sperimentazione, formazione, comunicazione e diffusione del sistema Drive Belt a supporto della catena logistica digitale

Informazioni sulla gara

ID 52

Tipologia di gara: Procedura aperta

Criterio di aggiudicazione: Economicamente più vantaggiosa

CPV: 72240000-9

CIG: 85682496C0

CUP: G59J17000100006

Tipo di fornitura: Servizi

Atto di riferimento: 2020

RUP: Rodolfo De Dominicis

Per richiedere informazioni:

E-mail: [email protected]

Tel.: +39 0654221337/ +39 0669922148 Fax: +39 0654281133

Stato: In svolgimento

Soggetto aggiudicatore: UIRNet S.p.A.

Centro di costo:

Destinatario fornitura/servizio:

Aggiudicatario: AlmavivA - The Italian Innovation Company s.p.a.

Importi e oneri Importo complessivo a base d'asta: € 1.257.838,00 Importo, al netto di oneri di sicurezza da

interferenze e iva, soggetto a ribasso: € 1.104.958,00 Oneri Sicurezza (Iva esclusa): € 152.880,00

Criterio di valutazione dell'offerta economica Formula per calcolo del punteggio dell'offerta

economica 1.2 Proporzionalità inversa sul ribasso

Punteggio massimo da attribuire all'offerta

economica 20

Date pubblicazione e scadenza

Data inizio partecipazione: 30 dicembre 2020 18:00 Termine ultimo per la presentazione di quesiti: 29 gennaio 2021 12:00

Data scadenza: 12 febbraio 2021 18:00

(2)

Documenti richiesti ai partecipanti - Documentazione amministrativa DGUE

Domanda di partecipazione Documento di Identità

Garanzia provvisoria, dichiarazione di impegno di un fideiussore e dichiarazione poteri del fideiussore Eventuali documenti integrativi

Modello F23 pagamento bollo Dichiarazione integrativa PassOE

Visura camerale storica Procura

Informativa sul trattamento dei dati personali

Copia certificazione ex art. 93, comma 7, D.Lgs. n. 50/2016 Documentazione e dichiarazioni ulteriori per i soggetti associati Dichiarazione di subappalto

Documenti richiesti ai partecipanti - Offerta economica Offerta economica

Eventuali documenti integrativi

Documentazione gara Bando di gara pubblicato in GUUE

Disciplinare di gara All. 1 - Capitolato Tecnico

All. 1-bis - Documentazione di Progetto All. 2 - Schema di Contratto

All. 3 - Fac simile Dichiarazione di subappalto All. 4 - Fac simile Domanda di partecipazione All. 5 - Fac simile Dichiarazioni integrative All. 6 - Griglia di valutazione

All. 7 - Fac simile Offerta Economica

All. 8 - Fac simile Dichiarazione familiari e conviventi All. 9 - Informativa sul trattamento dei dati personali Bando di gara pubblicato in GURI

(3)

FAQ

Domanda Risposta

In relazione al Disciplinare di

gara cap. 14 –

CONTENUTO DELLA

BUSTE B – OFFERTA TECNICA, si chiede di confermare che l’oﬀerta tecnica dovrà essere composta dai seguenti ﬁles separati e denominati: 1.

Proposta Metodologica 2.

Relazione descrittiva delle soluzioni realizzate 3.

Curricula vitae 4. Proposte Migliorative e non dovrà essere formattata in un unico ﬁle di Oﬀerta Tecnica.

Si chiede inoltre se dal computo delle pagine dei singoli ﬁles sono esclusi eventuale copertina e indice.

Come specificato nell’art. 14 del Disciplinare, al quale integralmente si rimanda, l’Offerta Tecnica dovrà essere composta dai seguenti files, che dovranno essere caricati separatamente negli appositi slot messi a disposizione nella piattaforma telematica per la gestione delle gare in relazione alla Busta Tecnica: 1) proposta metodologica relativa alla realizzazione del Sistema Drive Belt; 2) proposta

metodologica relativa ai servizi di Sperimentazione; 3) proposta metodologica relativa alla Formazione, Comunicazione e Diffusione; 4) Relazione descrittiva delle soluzioni realizzate; 5) curricula vitae, in formato europeo, dei soggetti che compongono il Team professionale e dai medesimi sottoscritti; 6) Relazione descrittiva di eventuali proposte migliorative sui servizi di Realizzazione e Sperimentazione.

Si precisa che copertina ed indice non sono compresi nel computo delle pagine indicate nel Disciplinare di gara in relazione a ciascuno dei suddetti documenti.

In riferimento al Disciplinare di gara cap. 6.3 REQUISITI DI CAPACITÀ TECNICA E

PROFESSIONALE, è

riportato: La comprova dei suddetti requisiti è resa mediante una delle seguenti modalità: in caso di servizi prestati a favore di pubbliche amministrazioni o enti pubblici - copia conforme all’originale dei certiﬁcati rilasciati

dall’amministrazione/ente contraente, con l’indicazione dell’oggetto, dell’importo e del periodo di esecuzione; in caso di servizi prestati a favore di committenti privati - copia conforme all’originale delle attestazioni rilasciate dal committente privato, con l’indicazione dell’oggetto, dell’importo e del periodo di esecuzione. Si chiede, nel caso in cui non sia possibile esibire le attestazioni Cliente, la possibilità di esibire, ai ﬁni della comprova, referral prodotti da un revisore, o presidente collegio sindacale, oppure copia di contratti e fatture.

Ai ﬁni della comprova sarà possibile produrre copia dei contratti accompagnata da documentazione idonea a dimostrare la regolare esecuzione del servizio.

Il professionista di business non è una ﬁgura professionale prevista nella fornitura ma è uno degli utenti del sistema.

Per mero refuso materiale non è stata riportata la ﬁgura del System Administrator le cui

caratteristiche sono:

(4)

Con riferimento al Disciplinare, paragrafo 2.4 OGGETTO DELL’APPALTO, IMPORTO A BASE D’ASTA E TEAM PROFESSIONALE DA DEDICARE

ALL’APPALTO, si prega di fornire i requisiti minimi della figura Professionista di Business e della figura del System Administrator previste negli altri documenti di gara.

Profilo Descrizione

System

Administrator

Almeno 5 anni di esperienza professionale di amministrazione, configurazione ed ottimizzazione di sistemi IT/ICT complessi, in ambito di Big Data/Business Intelligence & Analytics.

In particolare, il profilo professionale prevede esperienze maturate nell’ambito delle seguenti aree tematiche:

Amministrazione di piattaforme in ambito Big Data/

Business Intelligence &Analytics (es. Cloudera, Apache Hadoop HDFS, Talend, Apache NiFi, Apache Spark, Kafka, Hadoop, Impala, ecc.);

Amministrazione in ambito Networking;

Amministrazione, configurazione e monitoraggio di RDBMS (es. PostgreSQL, Oracle, ecc);

Shell scripting e Python scripting

Amministrazione di ambienti virtualizzati e/o containerizzati (Docker e Kubernetes)

Configurazione, ingegnerizzazione e rilascio in esercizio di modelli di analytics/advanced analytics su soluzioni BigData e di acquisizione/processamento dati (es. Cloudera, Apache Hadoop, Talend, Apache NiFi);

Configurazione, ingegnerizzazione e rilascio in esercizio di dashboard/report su soluzioni di Business Intelligence (es. Qlik Sense, Tableau, MS PowerBI);

Con riferimento al Disciplinare, paragrafo 2.4 OGGETTO DELL’APPALTO, IMPORTO A BASE D’ASTA E TEAM PROFESSIONALE DA DEDICARE

ALL’APPALTO, si prega di fornire la Tariffa

professionale g/uomo per la figura del Professionista di Business.

Vedere risposta al quesito 3)

Con riferimento al Disciplinare, paragrafo 14.

CONTENUTO DELLA BUSTA B – OFFERTA TECNICA, considerando che devono essere sottoscritti dalla risorse presentate nel team, si prega di chiarire se i CV allegati all’Offerta Tecnica debbano essere nominativi.

Si, i CV devono essere nominativi.

Con riferimento al Capitolato Tecnico, paragrafo 11.6 SLA06 - Rispetto dei tempi

(5)

di apertura issue su GitLab, si prega di chiarire se per data e ora effettiva di apertura issue si intende l’ora della presa in carico della issue intesa come registrazione e la

classificazione della richiesta e se per data e ora prevista di apertura issue si intende l’arco temporale di 3 ore entro il quale la

segnalazione deve essere registrata e classificata.

Si, si intende che la registrazione e la classiﬁcazione delle richieste su GitLab deve avvenire entro 3 ore dall’arrivo della segnalazione

Con riferimento agli strumenti per la fornitura, si prega di chiarire se UIRNet mette a disposizione del Fornitore le utenze della piattaforma GitLab Enterprise con accesso ai moduli GitLab Service Desk e GitLab Plan.

Si al fornitore sarà fornita un’utenza per accedere al tenant di UIRNet della GitLab Enterprise, i due moduli citati sono disponibili.

Con riferimento al Capitolato Tecnico, paragrafo 5.2.4 Servizio di assistenza (Help- desk), si prega di

confermare che le richieste di supporto degli utenti avverrà tramite l’invio di mail al Team dell’Help Desk o tramite apertura issue su GitLab.

Gli utenti potranno utilizzare entrambe le modalità, le segnalazioni via mail devono essere riportate dall’Help-Desk su GitLab, mentre nel caso di imputazione diretta su GitLab, la segnalazione dovrà essere presa in carico e classificata nei tempi previsti dal Fornitore.

Per quanto riguarda i requisiti di capacità tecnica e professionale di cui al par.

6.3 del disciplinare, e in particolare relativamente alle indicazioni per i

raggruppamenti temporanei, si prega di confermare che la locuzione "fermo restando che la mandataria deve possedere i requisiti in misura maggioritaria" sia da intendersi nel senso che la mandataria deve possedere la maggior parte dei requisiti considerati nel loro

complesso, ossia almeno il requisito n. 1 e

alternativamente uno dei due requisiti di cui ai n. 2 e 3, per una somma totale che superi i requisiti dichiarati dalle mandanti.

Si conferma.

Con riferimento all’Allegato E - Dimensionamento del sistema – AnnessoE1,

(6)

paragrafo 4.3.2 Giorni uomo, si prega di chiarire la discrepanza tra la somma dei gg/u riportata nella tabella degli UC funzionali classificati secondo

complessità pari a 1246 gg/u con quella dei gg/u dei profili riportata nella tabella sottostante pari invece a 1294 gg/u.

L’effort corretto è pari a 1294 gg/u.

Con riferimento al

Capitolato_All.1 - Capitolato Tecnico-1_Capitolato- Tecnico e all’Allegato E - Dimensionamento del sistema – AnnessoE1 si prega di chiarire se i KPI sui quali viene stimato l’effort siano 82 come da Capitolato Tecnico, oppure 81 come da Allegato E.

Il numero corretto di KPI è 82.

Con riferimento alle figure professionali riportate nel Disciplinare, paragrafo 2.4 OGGETTO DELL’APPALTO, IMPORTO A BASE D’ASTA E TEAM PROFESSIONALE DA DEDICARE

ALL’APPALTO e a quelle riportate nell’Allegato - C - Architettura della soluzione a pag. 30, si prega di

confermare che per Sistemista si intende la figura del System Developer.

No, si intende un proﬁlo equivalente alla ﬁgura del System Administrator, vedere risposta al quesito 3).

Con riferimento all’Allegato - C - Architettura della, paragrafo 7. Figure professionali architettura target, si prega di chiarire se con fase di esercizio pari a 12 mesi si intende la fase di sperimentazione, al netto del mese di setup.

Nel documento Allegato - C - Architettura della soluzione, al paragrafo 7, il progettista fa riferimento ad un periodo di esercizio di 12 mesi con il sistema a regime, che è da considerarsi non assimilabile alla fase di sperimentazione annoverata nel documento All.1 - Capitolato Tecnico-1_Capitolato-Tecnico. La durata prevista della fase di sperimentazione è di 13 mesi, ivi compreso un mese dedicato alla configurazione dell’ambiente di sperimentazione.

Si prega di chiarire se gli Use Case Funzionali sono 82 come riportato

nell’allegato_Allegato - B - Modello della soluzione - Annesso B2 - UseCase Funzionali oppure 81 come riportato nell’Allegato E - Dimensionamento del sistema – AnnessoE1.

Il numero corretto di Use Case è 82.

Con riferimento

(7)

all’allegato_Allegato - B - Modello della soluzione - Annesso B2, si prega di chiarire se gli Use Case riportati (82) sono esaustivi di tutte le funzionalità necessarie per la fase di sperimentazione. In secondo luogo, si prega di chiarire se gli Use Case riportati nel suddetto documento includono anche gli Use Case riportati negli allegati G.

Gli Use Case riportati nel documento Allegato - B - Modello della soluzione - Annesso B2 non sono esaustivi in quanto devono essere considerati anche gli Use Case di cui al documento Allegato - G - Scenari di riferimento - Annesso G1 - Use Case Funzionali.

Con riferimento

all’allegato_Allegato - B - Modello della soluzione, pag. 6 a pag. 21 RF-WBH- 09 Analisi di what-if, si prega di chiarire se le analisi di tipo what-if prodotte tramite workbench devono poi essere riportate sul Cruscotto Strategico in ambiente di Visualization.

Sì, si conferma.

Con riferimento al

capitolato_All. 1 - Capitolato Tecnico -1_Capitolato- Tecnico, pag. 57, viene riportata una durata della sperimentazione pari a 12 mesi mentre in altri punti dello stesso documento si parla di 13 mesi. Si prega di chiarire se nei 13 mesi è compreso un mese necessario per il setup. In secondo luogo, si prega di confermare che il supporto sistemistico vada

considerato per 12 mesi in totale su tutto il progetto.

Vedere la riposta al quesito 13.

Si prega di confermare che la percentuale massima subappaltabile sia il 40%, come previsto dalla normativa vigente.

Con riferimento al limite della percentuale massima subappaltabile si è tenuto conto di quanto stabilito nelle sentenze C-63/18, della Corte di Giustizia Europea del 26 settembre 2019 e C-402/18 del 27 novembre 2019. In mancanza di espressa indicazione in sede di oﬀerta delle parti del servizio che intende subappaltare l’aﬃdatario non potrà ricorrere al subappalto. Gli operatori economici indicano, in ogni caso, nell’apposita sezione del DGUE e nell’Allegato 3 al Disciplinare di gara, la quota che intendono subappaltare.

Per quanto riguarda la documentazione da produrre per l'ausiliaria, si prega di chiarire se oltre ai documenti elencati a pag. 23 del disciplinare, vada prototta anche la dichiarazione integrativa.

No, non è necessaria la dichiarazione integrativa.

(8)

si prega di confermare che in caso di RTI la marca da bollo vada presentata solo da parte della mandataria

Si conferma.

si prega di chiarire se anche le imprese mandanti debbano essere iscritte al portale UIRNET, o per la partecipazione sia sufficiente che sia iscritta la sola mandataria.

Per la partecipazione alla gara di un RTI è suﬃciente che la sola mandataria sia iscritta alla Piattaforma telematica di gestione delle gare in uso a UIRNet, fermo restando il rispetto delle disposizioni contenute nel Disciplinare di gara in relazione a tale forma di partecipazione.

Con riferimento all’Allegato E Dimensionamento del Sistema – Annesso E1 (par.

4.3.2) viene indicato l’effort complessivo per gli UC raggruppati per complessità, ma i totali presenti sulla riga non corrispondono a quelli effettivamente calcolati. Si richiedono dunque i corretti numeri di gg/p e di UC.

Per il numero di Use Case vedere risposta quesito 14.

Per l’effort gg/u vedere risposta quesito 10.

4.3.1.1) ove si indica che “da benchmark BIP l’indice di produttività per attività simili (quota di sviluppo legata al calcolo dei KPI)) è pari a 5 CFP/gg” trattandosi di indice di produttività non

verificabile o confrontabile sul mercato, si richiede maggiore dettaglio su come tale indice è stato ottenuto .

L’indice di produttività è stato identiﬁcato, sia in base all’esperienza del progettista nella realizzazione di soluzioni similari, sia considerando la capacità di supporto all’automazione della gestione dei flussi fornita dalla soluzione tecnologica proposta.

Vedere anche risposta al quesito 85.

Con riferimento al Capitolato Tecnico (par. 6.1.2) si indica che “Sono state ricomprese nella stima in CFP le attività connesse all’acquisizione dei flussi funzionali e al computo dei KPI di analisi e, in particolare, sono state previste nell’ambito del conteggio in CFP le seguenti attività: • Analisi di dettaglio dei requisiti • Definizione di dettaglio degli scenari e delle modalità di test • Sviluppo • Esecuzione test • Documentazione prevista dal presente capitolato • Manutenzione correttiva Mentre nell’Allegato E – Annesso E1 par. 4.3.1.1 si indica che “la stima dei CFP comprende le seguenti

Si, per “Supporto baby-sitting post go-live” si intende la Manutenzione correttiva per

eventuali anomalie da prestarsi secondo legge per 12 mesi.

(9)

attività: • Analisi requisito • Definizione scenari e modalità di test • Sviluppo • Esecuzione test •

Documentazione • Supporto baby-sitting post go-live richiediamo di specificare se per Supporto baby-sitting post go-live si intende la Manutenzione correttiva per eventuali anomalie

riscontrabili nella fase di post go-live. Si chiede inoltre di specificare la durata di questa fase di Post Go-Live

Con riferimento al paragrafo 7 del Capitolato Tecnico, ove si descrive il piano di progetto, considerato il parallelismo richiesto fra Sviluppo della Release 2 e MEV Fase A, richiediamo maggiori chiarimenti in merito all’ambiente in cui si prevede siano sviluppate, testate e collaudate le MEV;

chiediamo inoltre se l’ambiente di collaudo citato a pag.60 del capitolato è lo stesso di sviluppo,

sperimentazione o un terzo da dover predisporre

Le MEV vanno sviluppate, testate e collaudate nell’ambiente di sviluppo. Si, l’ambiente di sviluppo e collaudo citato alla pagina 60 sono lo stesso ambiente.

Con riferimento all’Allegato E Dimensionamento del Sistema – Annesso E1, ove si indica che “Per il calcolo dei CFP è stato utilizzato il metodo di early estimation Avarage, basato sul flusso vettori per l’acquisizione dei dati dal sistema Port Community System (PCS), ritenuto rappresentativo per questo insieme. Nella stima è stato considerato l’utilizzo della tecnologia sottostante che, tramite connettori dedicati e già sviluppati, non richiede attività di sviluppo per la parte di connessione e integrazione con la fonte dati, se non la parte più alta di lettura e scrittura del dato da remoto in locale”, si chiede di confermare che tutti i 28 flussi stimati con l’utilizzo dei CFP siano riportabili alla stessa situazione, e quindi che non richiedano attività di sviluppo per la parte di connessione e integrazione con la fonte dati, se non la parte più alta di lettura e scrittura del dato da remoto in locale, in quanto tali attività non sono

Le parti di connessione e integrazione sono state dimensionate nel progetto all’interno degli

ETL (considerati negli Use Case di acquisizione).

(10)

state dimensionate nel progetto.

4.3.2) ove si classifica l’effort stimato per ogni UC

funzionale secondo complessità (Bassa, Media, Alta), si prega di avere visibilità sui criteri utilizzati per classificare gli UC.

Il criterio di classificazione è stato determinato in fase di progettazione sulla base di valutazioni inerenti alla speciﬁcità degli UC stessi, agli obiettivi e alle tipologie di analisi, ai dati necessari al suo funzionamento e alla complessità della visualizzazione delle analisi svolte (se graﬁche o meno).

Con riferimento all’Allegato E Dimensionamento del Sistema – Annesso E1 ove si indica che “da benchmark BIP l’indice di produttività (per gli use case di acquisizione) è pari a 6 CFP/gg”, trattandosi di indice di produttività non verificabile né confrontabile sul mercato a causa della scarsità di banche dati di riferimento pubbliche rispetto a quelle relative al metodo IFPUG FP, si richiede maggiore dettaglio su come tale indice è stato ottenuto .

Vedere risposta ai quesiti numero 23 e 83.

In riferimento a quanto indicato nel paragrafo 4.3 del Capitolato Tecnico, chiediamo conferma che il perimetro del progetto sia interamente descritto dagli Use Case presentati.

Si, ad eccezione delle attività previste come manutenzioni evolutive che saranno qualiﬁcate nel corso del Progetto.

Con riferimento all’allegato D paragrafo 6.1.1 nella parte relativa al caricamento delle anagrafiche, si chiede di chiarire se si tratta di tabelle statiche oppure occorre definire una schedulazione automatica per gestire aggiornamenti/storicizzazioni del dato

Relativamente all’Allegato D – Componenti di sistema – paragrafo 6.1, la schedulazione automatica per gestire gli aggiornamenti dei dati va prevista solo per i riferimenti geograﬁci di cui al paragrafo 6.1.1.5 del documento medesimo.

4.3.2) ove si classifica l’effort stimato per ogni UC

funzionale secondo complessità (Bassa, Media, Alta), la somma dei UC case classificati risulta 81. Si

Si veda la risposta al quesito 14.

(11)

chiede quindi di confermare tale numero, o dichiarare diverso numero di UC.

4.3.1.2) ove si indica che il totale di CFP per gli use case funzionali rispetto agli 81 KPI è pari a 410. Ma 5 CFP x 81 KPI = 405. si chiede dunque di confermare se i KPI in ambito sono 81 o 82.

Si veda la risposta al quesito 11.

In riferimento alle Tematiche di georeferenziazione, richiediamo un chiarimento su chi fornisca i modelli cartografici della rete ferroviaria e autostradale per la componente geografica. Si prega di confermare, inoltre, che non siano necessarie funzionalità avanzate proprie di un sistema GIS per il trattamento di tali informazioni

I modelli cartograﬁci, come tipologia e caratteristiche funzionali, saranno oggetto di approfondimento in sede di esecuzione del servizio. Si conferma che non sono necessarie funzionalità avanzate proprie di un sistema GIS.

Con riferimento al Capitolato Tecnico (par. 6.1.2) ove si indica che “Per il calcolo dei CFP è stato utilizzato il metodo di early estimation Average, basato sul flusso vettori per l’acquisizione dei dati dal sistema Port Community System (PCS), ritenuto rappresentativo per i casi d’uso di acquisizione, e quello di “Flussi di traffico ferroviario O-D”, ritenuto rappresentativo per i casi d’uso funzionali”, non è presente in alcun documento la descrizione dei “Flussi di traffico ferroviario O-D”. si prega di fornire tale descrizione.

Il ﬂusso denominato “Flussi di traﬃco ferroviario O-D” è corrispondente al KPI 3.4.21 equivalente allo Use Case 24, 25 e 79. La descrizione è riportata nel documento Allegato – B – Modello della soluzione al paragrafo 7.4.

Con riferimento a quanto indicato nell’allegato D paragrafo 5.3 i flat file forniti da enti esterni (nel numero di 28) e a quanto indicato nel paragrafo 6.1.1. si richiede se le anagrafiche fornite (nel numero di 11) saranno corredati da opportuna documentazione tecnica e di business, e se i

Le anagrafiche fornite saranno corredate da opportuna documentazione tecnica. I flat file

forniti da enti esterni non esauriscono le fonti di alimentazione del sistema.

(12)

flat file forniti da enti esterni esauriscono le fonti di alimentazione del sistema

CAP TECNICO 4.3.2 Si chiede conferma che le fonti dati "no core" (o secondarie) non sono oggetto di

integrazione nel perimetro dell'offerta.

Si conferma che le fonti dati “no core” non sono oggetto di integrazione. Potranno essere oggetto di eventuale evolutive.

Allegato B Annex B4 Si chiede conferma che i KPI da trattare nel perimetro dell'offerta sono soltanto quelli riportati nell'allegato

"Allegato B - Modello della soluzione - Annesso B4 - Lista KPI"

Si, sono quelli indicati nel documento citato.

CAP TECNICO 4.3.2 Si richiede conferma della disponibilità tecnica ed organizzativa di tutte le fonti dati core citate e che non sono richiesti interventi ad hoc sui sistemi sorgenti da parte dell'appaltatore.

Tra le fonti dati core vi sono fonti pubblicamente accessibili, per le fonti non accessibili pubblicamente sarà compito della Stazione Appaltante concordare e organizzare le modalità di accesso. Si conferma che non sono richiesti interventi ad hoc sui sistemi sorgente da parte dell’appaltatore.

CAP TECNICO Pag. 10 Si chiede conferma che i dati da elaborare ricevuti dalle fonti dati "core" siano comunque limitati alle sole regioni PON.

No, i flussi non riguardano solo fonti dati "core" delle sole regioni PON, ma in ragione della valenza nazionale del Progetto, sono estesi a tutto il territorio anche per consentire analisi in relazione ai flussi nord-sud.

CAP TECNICO Pag. 10 e par. 4.3.2 Nel caso in cui si confermi la domanda precedente si richiede se i sistemi territoriali da

interfacciare siano solo quelli riferiti alle regioni PON e se per i sistemi nazionali il flusso dati da trattare sia solo quello relativo alle regioni PON.

No, i ﬂussi riguardano tutto il territorio nazionale; tra questi sarà data particolare attenzione ai flussi pertinenti alle regioni del PON.

CAP TECNICO 4.3.2 Si richiede la lista completa dei PCS e dei Freight Village da interfacciare.

È previsto un connettore standard per ogni tipo di comunicazione previsto dal PCS e dai Freight Village.

Annex B4 Si chiede di chiarire se la fonte dati RSRD citata nell'allegato

(13)

"Allegato B - Modello della soluzione - Annesso B4 - Lista KPI" è da intendersi come fonte dati "core"

Si conferma che la fonte dati RSRD è da considerarsi come “core”.

Allegato B Annex B4 I flussi di dati indicati nel

documento sono riferiti a flussi dati realizzabili in modalità nativa con il sistema sorgente (quindi con un interfaccia dedicata per l'invio dello stesso modello dati) o sono da realizzare mediante l'elaborazione di più flussi dati provenienti dal sistema sorgente?

I flussi di dati indicati nel documento possono essere riferiti a entrambi i casi esposti.

CAP TECNICO 4.3.2 Si chiede conferma che il protocollo di

interfacciamento per tutti i PCS sia unico.

È previsto un connettore standard per ogni tipo di flusso dati con i PCS ed i Freight Village.

CAP TECNICO 4.3.2 Si chiede conferma che il protocollo di

interfacciamento per tutti i freight Village sia unico.

È previsto un connettore standard per ogni tipo di flusso dati con i PCS ed i Freight Village.

CAP TECNICO Pagg.30-32 Quali sono le modalità di integrazione e i relativi protocolli di comunicazione con le fonti dati principali (ad es. disponibilità API, possibilità di accesso diretto alle basi informative, necessità di protocolli CDC - Change Data Capture)

Le modalità di integrazione con le fonti dati principali sono quelle normalmente alla base dei processi ETL sulla base della disponibilità di API e/o altre soluzioni di interscambio

informativo, anche in ragione delle funzionalità rese disponibili dalla soluzione tecnologica indicata.

CAP TECNICO Pagg.30-32 Si chiede di chiarire quale sia la periodicità di acquisizione dei dati dalle fonti dati principali e se sarà necessario acquisire anche dati storicizzati in fase di inizializzazione del sistema

La periodicità di acquisizione deve essere conﬁgurabile, si conferma che non è prevista l’elaborazione di ﬂussi real-time, sebbene alcune sorgenti informative possano fornire dati in modalità continuativa. Si, si conferma che sarà necessario acquisire anche dati storicizzati in fase di inizializzazione del sistema.

CAP TECNICO 5.1.4 Si chiede di chiarire se rispetto l'Architettura target sia possibile identificare soluzioni alternative rispetto alle componenti

tecnologiche selezionate per i diversi layer

Non sarà possibile proporre soluzioni tecnologiche alternative alle componenti individuate,

salvo per quanto previsto nelle proposte migliorative indicate nella documentazione di gara, se

non per comprovati e sostanziati motivi (quali soluzioni tecnologiche innovative non esistenti

al momento della progettazione o nuove tecnologie che determinano signiﬁcativi

miglioramenti della qualità dell’opera o sue parti, senza alterare l’impostazione progettuale e

senza comportare aumento del costo).

(14)

CAP TECNICO Sub criterio 1.2 Si richiede se le soluzioni indicate nel criterio sono riferite al processo di gestione progetto o alla soluzione complessiva stessa

Le soluzioni indicate nel criterio sono riferite alla soluzione complessiva.

CAP TECNICO 5.1.3.2 La progettazione ha prodotto un’ipotesi di schema di rete dei nodi che compongono Drive Belt, come specificato in Figura 4 - Componenti fisiche Drive Belt. In tale diagramma, sono presenti 2 nodi master del cluster Cloudera e non sono presenti nodi Kafka. Nel dimensionamento di cui alla Tabella 9 –

Dimensionamento ambiente di sperimentazione del successivo paragrafo 5.1.6.2, i nodi master indicati sono 3 ed è presente 1 nodo dedicato per il componente Kafka. Si richiede conferma che il dimensionamento dell'infrastruttura in termini di quntità di VM richieste debba fare riferimento alla succitata tabella 9 del paragrafo 5.1.6.2 e non al diagramma di rete illustrato in Figura 4 - Componenti fisiche Drive Belt del paragrafo 5.1.3.2

La Figura 4 fornisce una rappresentazione esemplificativa della struttura delle componenti fisiche, per il dimensionamento effettivo della soluzione si deve fare riferimento alla tabella 9 del paragrafo 5.1.6.2

CAP TECNICO 5.1.4.5 Non essendo specificata la versione di PostgreSQL richiesta si richiede conferma che si debba intendere l'utilizzo dell'ultima versione stabile disponibile.

Per PostgreSQL occorre utilizzare la versione compatibile con le speciﬁche degli altri prodotti della soluzione target, come criterio generale l’ultima versione stabile disponibile è corretto.

CAP TECNICO 7.3.1 Si richiede di specificare il formato target richiesto relativo alle immagini VM dell'ambiente di sviluppo

Il formato delle immagini delle VM da considerare è quello di interscambio OVA.

CAP TECNICO 7.4.1 Si richiede di confermare che, a differenza dell'ambiente di sviluppo, non è prevista, tra i deliverable, la fornitura delle immagini VM dell'ambiente di sperimentazione

No, anche per l’ambiente di sperimentazione è richiesta la fornitura delle immagini VM.

(15)

CAP TECNICO 5.1.3.2 Al fine di garantire l'accesso in modalità protetta all'interno della rete privata non esposta tramite Reverse Proxy, si richiede la

possibilità di configurare una o più VPN IPSec Site-to-Site over internet dalla sede UIRNet presso cui sono attestate le postazioni di lavoro UIRNet che eventualmente richiedano l'accesso verso i sistemi ospitati nel Cloud Service Provider, oggetto di fornitura.

Le modalità di accesso all’infrastruttura saranno definite nel corso della fornitura. La modalità di accesso indicata è una delle soluzioni tecniche applicabili, ma potrebbe essere necessario affiancare la stessa con soluzioni Client-to-Site anche in ragione delle modalità di lavoro agile.

DOMANDA1 : Disciplinare di gara Par.. 6.2 REQUISITI DI CAPACITÀ ECONOMIA E FINANZIARIA Si chiede a questa Committente se, in sede di comprova del requisito in argomento, sia possibile in alternativa alla polizza, presentare un certificato firmato digitalmente dalla

compagnia assicurativa che attesti l’esistenza della copertura assicurativa contro i rischi professionali con espresso almeno il massimale specificato nei documenti di gara.

DOMANDA 2 Disciplinare di gara Par. 21

AGGIUDICAZIONE

DELL’APPALTO E STIPULA DEL CONTRATTO lettera d) Si chiede conferma che il riferimento al par. 7.2 sia un refuso e che si deve fare riferimento invece al par. 6.2 DOMANDA 3 Schema di contratto art. 16 –

RESPONSABILITA’ comma 16.2 a) Si chiede conferma che la polizza assicurativa, che dovrà essere presentata in sede contrattuale, si riferisca alla copertura assicurativa contro i rischi professionali di cui all’art. 6.2 del Disciplinare. b) Si chiede conferma che sarà possibile in alternativa alla polizza consegnare un certificato firmato digitalmente dalla compagnia assicurativa che attesti l’esistenza della copertura assicurativa

Si conferma che il riferimento all’art. 7.2 contenuto nell’art. 21 del Disciplinare di gara (p. 40, lett. d) p. è un refuso e che il riferimento corretto è all’art. 6.2 del medesimo Disciplinare. Si conferma che la polizza assicurativa cui si fa riferimento nell’art. 16.2 dello Schema di Contratto è la medesima polizza contro i rischi professionali richiesta nell’art. 6.2 del Disciplinare di gara. In sede di comprova di detta polizza sarà necessario produrre copia conforme all’originale della stessa.

Nell’Allegato E

(16)

Dimensionamento del Sistema – Annesso E1 si dichiara che: “Per il calcolo dei CFP è stato utilizzato il metodo di early estimation Avarage, basato sul flusso vettori per l’acquisizione dei dati dal sistema Port Community System (PCS), ritenuto rappresentativo per questo insieme. Nella stima è stato considerato l’utilizzo della tecnologia sottostante che, tramite connettori dedicati e già sviluppati, non richiede attività di sviluppo per la parte di connessione e integrazione con la fonte dati, se non la parte più alta di lettura e scrittura del dato da remoto in locale”. Si chiede conferma che tutti i 28 flussi stimati con l’utilizzo dei CFP siano effettivamente riportabili alla stessa

situazione, ovvero che non richiedano attività di sviluppo per la parte di connessione e integrazione con la fonte dati, se non la parte più alta di lettura e scrittura del dato da remoto in locale, in quanto tali attività non sono state dimensionate nel progetto.

Si veda la risposta al quesito 26).

Nell’Allegato E Dimensionamento del Sistema – Annesso E1 si dichiara che: “da benchmark BIP l’indice di produttività (per gli use case di acquisizione) è pari a 6 CFP/gg” Dal momento che tale indice di produttività non è verificabile, né

confrontabile sul mercato a causa della scarsità di banche dati di riferimento pubbliche rispetto a quelle relative al metodo IFPUG FP, si chiede di avere un dettaglio maggiore su come tale indice è stato ottenuto (es. fonte dati del

benchmarking BIP o altre fonti presenti in letteratura ed accessibili).

Si veda la risposta al quesito numero 23).

Nell’Allegato E Dimensionamento del Sistema – Annesso E1 (par.

4.3.1.1) si dichiara che: “da benchmark BIP l’indice di produttività per attività simili (quota di sviluppo legata al calcolo dei KPI)) è pari a 5 CFP/gg” Dal momento che

(17)

tale indice di produttività non è verificabile, né

confrontabile sul mercato a causa della scarsità di banche dati di riferimento pubbliche rispetto a quelle relative al metodo IFPUG FP, si chiede di avere un dettaglio maggiore su come tale indice è stato ottenuto (es. fonte dati del

benchmarking BIP o altre fonti presenti in letteratura ed accessibili).

Si veda la risposta al quesito 23).

4.3.1.2) si dichiara che il totale di CFP per gli use case funzionali rispetto agli 81 KPI è pari a 410. Ma 5 CFP x 81 KPI = 405. Si chiede di confermare quindi quanti sono i KPI in ambito.

81 o 82?

Si veda la risposta al quesito 11).

4.3.2) si dichiara l’effort stimato per ogni UC funzionale classificato secondo complessità (Bassa, Media, Alta). La somma dei UC case classificati risulta di nuovo pari a 81. Si chiede quindi di confermare tale numero o dichiarare il numero definitivo di UC.

Si veda la risposta al quesito 14).

4.3.2) si dichiara l’effort stimato per ogni UC funzionale classificato secondo complessità (Bassa, Media, Alta). Si chiede di avere visibilità sui criteri utilizzati per

classificare gli UC di complessità Bassa, Media o Alta.

Si veda la risposta al quesito 27).

4.3.2) si riporta l’effort complessivo per gli UC raggruppati per complessità.

I totali presenti sulla riga non

Per l’effort in gg/u si veda la risposta al quesito 10).

Per gli UC si veda la risposta al quesito 22).

(18)

corrispondono a quelli effettivamente calcolati. Si chiede di avere conferma dei corretti numeri di gg/p e di UC.

Per gli UC si veda la risposta al quesito 22).

Nel Capitolato Tecnico (par.

6.1.2) si dichiara che “Per il calcolo dei CFP è stato utilizzato il metodo di early estimation Average, basato sul flusso vettori per l’acquisizione dei dati dal sistema Port Community System (PCS), ritenuto rappresentativo per i casi d’uso di acquisizione, e quello di “Flussi di traffico ferroviario O-D”, ritenuto rappresentativo per i casi d’uso funzionali”. Dove sono descritti i “Flussi di traffico ferroviario O-D”? Non si ritrovano nei documenti.

Si veda la risposta al quesito 34).

Nel Capitolato Tecnico (par.

6.1.2) si dichiara che “Sono state ricomprese nella stima in CFP le attività connesse all’acquisizione dei flussi funzionali e al computo dei KPI di analisi e, in

particolare, sono state previste nell’ambito del conteggio in CFP le seguenti attività: • Analisi di dettaglio dei requisiti • Definizione di dettaglio degli scenari e delle modalità di test • Sviluppo • Esecuzione test • Documentazione prevista dal presente capitolato • Manutenzione correttiva Nell’Allegato E – Annesso E1 par. 4.3.1.1 si dichiara invece che “la stima dei CFP comprende le seguenti attività: • Analisi requisito • Definizione scenari e modalità di test • Sviluppo • Esecuzione test •

Documentazione • Supporto baby-sitting post go-live Si chiede di specificare se per Supporto baby-sitting post go-live si intende quindi la Manutenzione correttiva per eventuali anomalie

riscontrabili nella fase di post go-live. Si chiede inoltre di specificare la durata di questa fase di Post Go-Live

Si veda la risposta al quesito 24).

Con riferimento a quanto indicato nell’allegato D paragrafo 6.1.1

(19)

relativamente al caricamento delle anagrafiche, si prega di chiarire se si tratta di tabelle statiche oppure occorre definire una schedulazione automatica per gestire aggiornamenti/storicizzazioni del dato

Si veda la risposta al quesito 30).

Con riferimento a quanto indicato nell’allegato D paragrafo 5.3 i flat file forniti da enti esterni (nel numero di 28) ed in riferimento a quanto indicato nel paragrafo 6.1.1. le anagrafiche fornite (nel numero di 11) saranno corredati da opportuna documentazione tecnica e di business? I flat file forniti da enti esterni esauriscono le fonti di alimentazione del sistema?

Si veda la risposta al quesito 35).

Con riferimento a quanto indicato nel piano di progetto descritto nel paragrafo 7 del Capitolato Tecnico,

considerato il parallelismo richiesto fra Sviluppo della Release 2 e MEV Fase A, si richiede un chiarimento relativo all’ambiente in cui si prevede siano sviluppate, testate e collaudate le MEV;

inoltre si richiede se l’ambiente di collaudo citato a pag.60 del capitolato è lo stesso di sviluppo,

sperimentazione o un terzo da dover predisporre?

L’ambiente per le MEV è quello di sviluppo. Si, l’ambiente citato è quello di sviluppo.

In riferimento alle Tematiche di georeferenziazione si chiedono chiarimenti su chi fornisca i modelli cartografici della rete ferroviaria e autostradale per la componente geografica; si chiede inoltre conferma che non siano necessarie funzionalità avanzate proprie di un sistema GIS per il trattamento di tali informazioni

Si veda la risposta al quesito 33).

In riferimento a quanto indicato nel paragrafo 4.3 del Capitolato Tecnico si chiede conferma se il perimetro del progetto sia interamente descritto dagli

Si veda la risposta al quesito 29).

(20)

Use Case presentati.

In riferimento al documento

“capitolato tecnico” al paragrafo 5.1.6.3 “Licenze”

si chiede di confermare la possibilità di proporre licenze open source ove possibile

Sì, si conferma la possibilità.

si chiede di confermare la possibilità di proporre un sistema operativo alternativo a Red Hat Linux, nel rispetto della compatibilità con lo stack software di cui la soluzione richiesta si compone secondo quanto dichiarato dai vendor nelle relative specifiche tecniche.

Si è possibile proporre un sistema operativo alternativo, purché basato su kernel Unix/Linux.

2) In riferimento al documento “capitolato tecnico” al paragrafo 5.1.4.6

“architetture hardware” ed in merito all’affermazione in esso contenuta

“L’Appaltatore dovrà indicare quale piattaforma cloud intende adottare, la stessa deve essere qualificata da AgID secondo quanto disposto dalle circolari AgID n.2 e n. 3 del 9 aprile 2018”, si chiede conferma che l’appaltatore potrà utilizzare un cloud provider pubblico a sua scelta purché sia certificato AgID anche laddove i servizi cloud offerti siano certificati su AgID attraverso moduli separati.

Si, si conferma che si può utilizzare un cloud provider pubblico a sua scelta purché sia certificato AgID anche laddove i servizi cloud offerti siano certificati su AgID attraverso moduli separati.

si chiede di confermare la possibilità di proporre la fornitura di licenze open source per tutte le componenti software che dovessero prevederne l'opzione e anche per le componenti software che eventualmente i vendor dovessero segnalare come

“End of Life” e che quindi necessitano di essere sostituite con prodotti di nuova generazione.

No, è possibile proporre la fornitura di licenze open source per le componenti software che

prevedono l'opzione nel capitolato, nel caso di componenti software che i vendor dovessero

segnalare come “End of Life” è possibile indicare la nuova versione supportata degli stessi.

(21)

In merito ai requisiti di capacità tecnica e professionale del Disciplinare di gara, in particolare in merito al par.

6.3 punto c) -2), si chiede di confermare che sono ammissibili, e considerati equipollenti, anche servizi aventi ad oggetto la progettazione e lo sviluppo di sistemi per la gestione e l’analisi di dati eterogenei strutturati e/o non strutturati.

Non sono considerati né ammissibili né equipollenti ai requisiti di gara i servizi di progettazione e/o sviluppo di sistemi per la gestione e l’analisi di dati eterogenei strutturati e/o non strutturati.

In merito alla griglia di valutazione del progetto tecnico, in particolare in merito al criterio n. 4

“Qualità delle soluzioni realizzate” dell’Allegato 6 – Griglia di valutazione al Disciplinare di gara, si chiede di confermare che, relativamente alle esperienze pregresse saranno valutate positivamente anche le esperienze in merito alla realizzazione e gestione di piattaforme per l’analisi di dati eterogenei strutturati e/o non strutturati, con

particolare riferimento alla metodologia e agli strumenti, nonchè alla qualità delle soluzioni implementate.

Si conferma che saranno valutate anche le esperienze in merito alla realizzazione e gestione di piattaforme per l’analisi di dati eterogenei strutturati e/o non strutturati.

Rif.to Disciplinare pag. 30 - Curricula vitae “5) i curricula vitae, in formato europeo, dei soggetti che

compongono il Team professionale e dai medesimi sottoscritti (cfr.

criterio n. 5 e relativi sub criteri 5.1 “Qualità delle figure professionali” e 5.2

“Organizzazione delle figure professionali” della Griglia di Valutazione), con annessa dichiarazione (resa ai sensi del D.P.R. n. 445 del 2000 dal legale rappresentante dell’Operatore Economico) attestante la disponibilità delle predette risorse professionali per l’intera durata del contratto d’appalto.” Si chiede alla codesta stazione appaltante se è possibile: a) presentare CV di figure professionali appartenenti a società subappaltatrici con accordo

Con riferimento al quesito sub a), si conferma; con riferimento al quesito sub b), si conferma, purché i

contratti di collaborazione siano stati sottoscritti in epoca anteriore alla pubblicazione del Bando di

gara. I predetti contratti dovranno essere prodotti alla Stazione Appaltante prima o contestualmente

alla sottoscrizione del contratto.

(22)

tale da garantire la

continuità per l’intera durata del contratto d’appalto, l’impegno in via esclusiva con l’Operatore Economico pertanto non potendo dette risorse essere indicate da altri concorrenti. b) presentare CV di figure professionali legate all’offerente da contratti di collaborazione che coprono l'intera durata contrattuale.

Rif.to Disciplinare pag. 7 – Team Professionale “Il team professionale dedicato all’appalto dovrà

comprendere tutte le figure sottoindicate che dovranno essere in possesso dei seguenti requisiti minimi:

[…]” Trattandosi di requisito minimo, si chiede se è possibile ricorrere all’istituto dell’avvalimento per soddisfare tale requisito minimo. Si chiede inoltre se eventuali CV dell’ausiliaria concorrono alla valutazione del criterio n. 5 e relativi sub criteri 5.1 “Qualità delle figure professionali” e 5.2

“Organizzazione delle figure professionali” della Griglia di Valutazione dell’Offerta Tecnica.

Il ricorso all’avvalimento è consentito con riferimento ai requisiti di capacità tecnica e professionale di cui all’art. 6.3. del Disciplinare di gara, secondo quanto previsto nell’art. 7 del Disciplinare medesimo e nell’art. 89 del D.Lgs. n. 50/2016.

Tenendo conto delle difficoltà di lavoro in presenza legate al perdurare dell’emergenza sanitaria COVID19, si chiede di specificare più

precisamente il luogo o i luoghi di svolgimento dei servizi previsti, e di confermare che per tutte le attività che lo consentono sia possibile operare da remoto, eccezion fatta per

l’erogazione della Formazione on site per la quale sono previsti massimo 10 giorni complessivi (rif. CT pag 53).

Lo svolgimento dei servizi richiesti potrà essere operato in remoto per tutte le attività che lo consentono. Sarà comunque diritto della Stazione Appaltante convocare incontri de visu presso la propria sede. Resta ovviamente esclusa da dette modalità di erogazione la Formazione on site.

2. In riferimento al

Disciplinare di gara cap. 6.3 REQUISITI DI CAPACITÀ TECNICA E

PROFESSIONALE, Si chiede di confermare che sia possibile comprovare i requisiti di capacità tecnica e

professionale, in caso di

Come già precisato nella FAQ n. 2 ai ﬁni della comprova dei requisiti di capacità tecnica e

(23)

professionale, in caso di impossibilità ad esibire attestazioni del Cliente, anche con specifica dichiarazione del Collegio Sindacale riportante l’oggetto del servizio svolto, le date di esecuzione, il corrispettivo ed i committenti.

professionale sarà possibile produrre copia dei contratti accompagnata da documentazione idonea a dimostrare la regolare esecuzione del servizio.

Si chiede conferma che il documento corrispondente al punto 5) Curricula vitae non abbia limite massimo di pagine.

Si conferma.

Tenendo conto delle difficoltà di lavoro in presenza e degli

spostamenti del personale legati al perdurare dell’emergenza sanitaria COVID19, si chiede se sia possibile allegare Curricula di soggetti che compongono il Team professionale di cui al documento 5 dell’Offerta Tecnica anche senza la sottoscrizione dei medesimi, purché sottoscritti dal legale rappresentante.

Come previsto dal Disciplinare di Gara (art. 14, pag. 30), ciascun CV prodotto deve essere sottoscritto – con ﬁrma autografa o con ﬁrma digitale - dal soggetto, al quale il CV si riferisce, componente il Team professionale.

In riferimento alla richiesta di produrre come deliverable della fase di realizzazione “le immagini delle VM

dell’ambiente” (Capitolato Tecnico, pag.61, punto 7.3.1), e in considerazione che fra le proposte migliorative è richiesta nel Disciplinare (pag.30, punto 6.2) una “Proposta di sistema Drive Belt nativamente

containerizzata”, si richiede conferma che come deliverable della fase di Realizzazione l’immagine di un container equivalga all’immagine di una VM.

Si, i due tipi di immagini sono equivalenti e quindi nel caso di “Proposta di sistema Drive Belt nativamente containerizzata” le immagini dei container sostituiscono le immagini delle VM.

Si richiede di chiarire se la fase di Sperimentazione sia da considerarsi di durata 13 mesi (come indicato a pag.

48 del Capitolato Tecnico) o di 12 mesi (come indicato a pag. 57 dello stesso Capitolato)

Si veda la risposta al quesito 13).

(24)

In relazione al par 2.4 OGGETTO DELL’APPALTO, IMPORTO A BASE D’ASTA E TEAM PROFESSIONALE DA DEDICARE

ALL’APPALTO a pag. 7 del disciplinare di gara, si richiedono chiarimenti circa la definizione del modello di costo relativo ai CFP. Infatti si ritiene che il combinato disposto fra costo medio degli skill previsti e produttività media nei functional CFP comporti un valore medio di costo medio più alto rispetto ai valori unitari previsti.

La fornitura dei servizi di sviluppo è a corpo, il computo metrico realizzato in sede di progettazione è stato utilizzato nella determinazione della base d’asta. Il costo dei CFP, calcolato secondo uno schema di ripartizione percentuale dell’impegno delle ﬁgure per l’individuazione del costo medio giornaliero delle attività di sviluppo e del fattore di produttività, è funzionale esclusivamente alle realizzazioni in ambito di MEV.

Schema di Contratto recita all’ART. 19 - RECESSO 19.1 Fermo restando quanto previsto in materia di recesso dagli artt. 88, comma 4-ter, e 92, comma 4, del D.Lgs. n. 159/2011, (antimafia) la Committente nei casi di i) giusta causa e ii) reiterati inadempimenti dell’Appaltatore, anche se singolarmente non gravi, ha diritto di recedere

unilateralmente dal Contratto in tutto o in parte, in qualsiasi momento, dandone comunicazione scritta all’Appaltatore senza preavviso. In tal caso, l’Appaltatore ha diritto al pagamento di quanto correttamente eseguito a regola d’arte secondo i corrispettivi e le condizioni di contratto e rinuncia, ora per allora, a qualsiasi pretesa risarcitoria, ad ogni ulteriore compenso o indennizzo e/o rimborso delle spese anche in deroga a quanto previsto all’art. 1671 c.c. Si chiede a codesto Ente di

regolamentare l’ipotesi di reiterati inadempimenti come ipotesi di risoluzione e non come ipotesi di recesso unilaterale. Pertanto, si chiede a codesto Ente di considerare la previsione sotto citata. Inserendo l’ipotesi de qua nell’art 18.

ART. 18 – RISOLUZIONE 18.1 (…omissis) nei seguenti casi: “Ferma restando l’applicazione delle penali previste nei

precedenti articoli, la Committente si riserva di richiedere la risoluzione del presente contratto

nell’ipotesi di grave e

Si conferma l’art. 19 dello Schema di Contratto allegato al Disciplinare di Gara.

(25)

reiterato inadempimento”.

Schema di contratto: 12.5 Resta espressamente convenuto che tutti gli obblighi ed oneri, nessuno escluso od eccettuato, comunque derivanti dall’osservanza di norme di legge e regolamentari, condizioni e patti applicabili alle prestazioni oggetto del presente Contratto si intendono compresi e compensati dal corrispettivo del Contratto e restano ad esclusivo carico

dell’Appaltatore. Per l’effetto, l’Appaltatore non potrà avanzare pretesa o richiesta di compensi, risarcimenti o indennizzi nei confronti della Committente, impegnandosi espressamente a manlevare e tenere indenne la

Committente stessa da tutte le conseguenze derivanti dall’eventuale inosservanza delle predette norme e prescrizioni. Si chiede a codesto Ente di considerare la previsione suggerita sotto citata. 12.5 Resta

espressamente convenuto che tutti gli obblighi ed oneri, nessuno escluso od

eccettuato, comunque derivanti dall’osservanza di norme di legge,

regolamentari e dalle condizioni e dai patti ivi contenuti del presente Contratto, si intendono compresi e compensati dal corrispettivo del Contratto e restano ad esclusivo carico dell’Appaltatore. Per l’effetto, l’Appaltatore non potrà avanzare pretesa o richiesta di compensi, risarcimenti o indennizzi nei confronti della Committente, impegnandosi espressamente a manlevare e tenere indenne la

Committente stessa da tutte le conseguenze derivanti dall’eventuale inosservanza delle predette norme e prescrizioni.

Si conferma l’art. 12.5 dello Schema di Contratto allegato al Disciplinare di Gara.

Rif. CT par. 6.1.2 pag. 55

“La stima delle attività è stata elaborata con il metodo dei Cosmic Function Point (CFP) per le attività riconducibili allo sviluppo applicativo e attraverso una stima dell’effort in

(26)

giorni/uomo per le attività non misurabili” Se nel corso dell’implementazione del sistema dovessero emergere differenze significative della stima in CFP e/o dell’effort in gg/p si richiede alla codesta stazione appaltante se è previsto un range di tolleranza (es. ±10%) e se l’eventuale superamento di tale soglia sarà gestito individuando e definendo rilasci successivi attraverso MEV, così come delineato nel paragrafo 5.2.3 del CT (Manutenzione correttiva, adeguativa ed evolutiva durante la

sperimentazione”).

La fornitura dei servizi di sviluppo è da intendersi a corpo, il computo metrico realizzato in

sede di progettazione è stato utilizzato nella determinazione della base d’asta.

(27)

Criteri punteggio documentazione tecnica

Nome criterio/sub-criterio Punteggio massimo attribuibile 1. Proposta metodologica relativa alla realizzazione del Sistema Drive Belt

1.1 Qualità della proposta metodologica

complessivamente intesa 5.00

1.2 Qualità delle soluzioni e degli strumenti di

gestione del progetto 5.00

1.3 Integrazione GitLab 3.00

Totale criterio 13.00

2. Proposta metodologica relativa ai servizi di Sperimentazione 2.1 Assistenza ed Help desk di 1 e 2 livello 3.00

2.2 Gestione di servizi in cloud 3.00

3. Proposta metodologica relativa alla Formazione, Comunicazione e Diffusione 3.1 Qualità della proposta relativa alla formazione 6.00

3.2 Qualità della proposta relativa al piano per

follow up 4.00

3.3 Qualità della proposta relativa al piano per la

comunicazione e diffusione 4.00

4. Qualità delle soluzioni realizzate 4.1 Soluzioni di realizzazione e gestione di

piattaforme Big Data in cloud 5.00

5. Adeguatezza del team professionale

5.1 Qualità delle figure professionali 10.00 5.2 Organizzazione delle figure professionali 5.00

6. Proposte Migliorative sui servizi di Realizzazione e Sperimentazione 6.1 Consistenza e vantaggi di eventuali proposte

migliorative nell'ambito della realizzazione 3.00 6.2 Proposta di sistema Drive Belt nativamente

containereizzata 7.00

6.3 Implementazione della componente Kafka 3.00 6.4 Fornitura di supporto professionale per i prodotti open source adottati da Drive Belt 3.00

6.5 Automazione dei Test 5.00

6.6 Fornitura di soluzioni di monitoraggio integrato 3.00 6.7 Consistenza e vantaggi di eventuali proposte

migliorative nell'ambito della sperimentazione 3.00

Totale 80.00

(28)

Documenti richiesti ai partecipanti - Offerta tecnica 1) Proposta metodologica relativa alla realizzazione del Sistema Drive Belt 2) proposta metodologica relativa ai servizi di Sperimentazione

3) proposta metodologica relativa alla Formazione, Comunicazione e Diffusione 4) Relazione descrittiva delle soluzioni realizzate

5) Curricula vitae con annessa dichiarazione attestante la disponibilità delle risorse professionali 6) Relazione descrittiva di eventuali proposte migliorative sui servizi di Realizzazione e Sperimentazione Eventuali documenti integrativi