Autorità per l'energia elettrica e il gas

Transcript

1 PROCEDURA DI GARA RISTRETTA ACCELERATA, IN AMBITO COMUNITARIO, PER L AFFIDAMENTO DELL APPALTO AVENTE AD OGGETTO LO SVOLGIMENTO DI SERVIZI APPLICATIVI E INFRASTRUTTURALI RELATIVI AI SISTEMI WEB-BASED DELL AUTORITÀ PER L ENERGIA ELETTRICA E IL GAS PROCEDURA DI GARA RISTRETTA ACCELERATA RIF. 474/2012/A CIG FB4 SECONDA FASE SUBPROCEDIMENTALE AD INVITI - RIF. 36/DAGR/2013 Chiarimenti n. 5 del 18 giugno 2013 Come previsto all art. 2 del Disciplinare di gara seconda fase ad inviti, con la presente nota si rappresentano alcune richieste di chiarimento pervenuta da varie imprese e le risposte inviate dall Autorità per l energia elettrica e il gas, al fine di garantire la massima trasparenza e nel rispetto del principio generale di par condicio tra i concorrenti. # Domande Risposte 1. Relativamente al criterio di valutazione "1.4.3 specifiche misure per la protezione degli applicativi su web" viene premiato con eccellente il "tracciamento degli accessi in lettura/scrittura;...", si chiede conferma che il tracciamento in lettura/scrittura finalizzato alla protezione degli applicativi su web è da garantire solo sulle nuove funzionalità che verranno sviluppate dal fornitore Non si conferma. Le funzionalità esistenti sono in generale sviluppate con tracciamento, laddove si manutenesse un'applicazione sprovvista, si commissionerebbe al fornitore l'adeguamento secondo le regole contrattuali. *.*.*.* 1

2 2. Relativamente al sistema di valutazione " Indicazione delle locazioni principali ed alternative di esercizio" si chiede di confermare le seguenti interpretazioni: 1. se la descrizione (a meno di eventuali refusi) "3 locazioni di cui almeno una a > 25 km dalla principale di DR; dotazioni di sicurezza pari al sito primario (vigilanza 24/7; antiallagamento)" associata al giudizio Eccellente (5) rappresenti un architettura basata su 1 sito primario e 2 siti di DR; 2. a meno di eventuali refusi) "3 locazioni; dotazioni di sicurezza pari al sito primario (vigilanza 24/7; antiallagamento)" associata al giudizio Ottimo (4) rappresenti un architettura senza vincoli di distanza fra il sito primario e il sito di DR, apparentemente vulnerabile complessivamente in caso di evento catastrofico; 3. se può considerarsi eccellente una soluzione basata su un sito primario, un sito di DR a > 25 km di distanza dal primario e la disponibilità ad impegnare in caso di necessità un terzo sito già in possesso del fornitore. 1. si conferma 2. Si tratta un refuso; al livello 4, in luogo di 3 locazioni; dotazioni di sicurezza pari al sito primario (vigilanza 24/7; antiallagamento) si legga 3 locazioni; di cui almeno una a distanza > 10 km dalla principale, di DR; dotazioni di sicurezza pari al sito primario (vigilanza 24/7; antiallagamento). 3. Sì, purchè il terzo sito sia immediatamente pienamente funzionale alla necessità. 3 Capitolato tecnico. Si richiede di dettagliare la copertura oraria di tutti i servizi richiesti Gli orari di servizio sono indicati nel capitolati tecnico in relazione al possibile impatto sugli utenti dei sistemi. Pertanto, è indicato l orario del servizio Service Desk ed è indicato che gli interventi di manutenzione programmata devono essere svolti in orario tale da minimizzare l indisponibilità dei sistemi (Cap.tecnico par ). La disponibilità dei sistemi è oggetto di specifico SLA (allegato 3, indicatore IQ-14). Per il resto è compito del fornitore organizzarsi nella maniera migliore per meglio soddisfare le esigenze. 4 Capitolato tecnico. Quali sono gli attuali tempi medi di lavorazione degli incident e dei change? In particolare, per quanto riguarda i change, sarebbe necessario averli suddivisi tra le diverse tipologie (Applicativi, Sistemistici e Database) e per rilevanza (distinguendo tra i major e gli altri). Per quanto riguarda gli incident, si rinvia ai dati relativi alla numerosità dei ticket aperti su richiesta dell utenza e alle note di chiarimento del 13.6 u.s. cui è allegato un pdf riportante i numeri di ticket statisticamente trattati. Per quanto riguarda le change, negli ultimi 12 mesi sono state tracciate sul sistema di track change attualmente in uso (TRAC) n. 401 richieste di change trattate con intervento applicativo o sui database a cui corrisponde una evoluzione funzionale (inclusi i nuovi sviluppi). Non sono disponibili al momento ulteriori informazioni qualitative, ma una parte rilevante di queste change request richiede interventi applicativi di tipo major. Si veda per esempio la tabella del par dell Allegato 1, dove è indicata la variazione della misura funzionale in FP delle raccolte dati che sono la principale area applicativa attualmente misurata in FP. 2

3 5 Capitolato tecnico. In ottica di migrazione dei ticket in essere sul nuovo sistema di TTM, si richiedono informazioni sulla tecnologia dell attuale sistema TTM I dati relativi ai TT sono contenuti in un normale database relazionale MySQL pertanto interrogabile in SQL. I dati sono quindi esportabili con strumenti standard. 6 Capitolato tecnico. Si richiedono gli attuali volumi di backup ed il trend di crescita (mensile, annuale) 7 Capitolato tecnico. Le attività di rilascio legate a change (adeguativi/correttivi, MEV o nuovi sviluppi) sono da intendersi incluse nei servizi a canone infrastrutturale o nelle giornate a consumo di supporto sistemistico infrastrutturale? 8 Capitolato Tecnico, Pag.62 L ipotesi di giornate di supporto specialistico da erogare è di 300 GP annue (e quindi di 1500 GP complessive nei 5 anni di contratto) o di 900 GP complessive come indicato a pag.62 del capitolato tecnico? Si rimanda ai dati dimensionali delle applicazioni disponibili sull Allegato 1 Le attività di rilascio software (Sviluppo e MEV) sono remunerate a FP (salvo i siti navigazionali per i quali le attività sono remunerate a giornate-persona). Per quanto riguarda i riflessi infrastrutturali dei rilasci software (sviluppo/mev), si rimanda a quanto previsto in tema di scalabilità dell infrastruttura (si veda in particolare: Capitolato tecnico par ; Schema di valutazione dell offerta, par ). Entro i limiti di scalabilità, gli impatti dei rilasci software sono ricompresi nel canone. Si rimanda alla nota di chiarimento n. 2 del 7 giugno u.s. pubblicata sul sito dell Autorità nella corrispondente sezione della gara ( 9 Capitolato Tecnico Allegato 1 E possibile avere una stima di massima del totale dei UFP delle applicazioni da prendere in carico? Non per tutte le applicazioni è indicato il valore nell Allegato Schema di Valutazione II fase Paragrafo Si richiedono chiarimenti in merito a cosa si intende per dalla principale di DR riportato nello Schema di Valutazione II fase Paragrafo Si intende locazione principale (sede da dove normalmente verranno erogati i servizi)? Tutti i dati disponibili sulle applicazioni attualmente conteggiate in FP sono stati forniti. Il completamento del conteggio FP per le applicazioni attualmente esterne al perimetro di misura a FP è un attività espressamente inclusa nel servizio di Presa in carico applicativa [Capitolato tecnico, par. 4.1, in particolare tabella 2, riga completam.conteggi FP (ove da fare) ]. Si conferma l interpretazione: la locazione principale è quella cui vengono erogati i servizi in condizioni ordinarie. 3

4 11 Nello Schema di Valutazione II fase Paragrafo si fa riferimento a 3 locazioni. Non ci è chiaro il fine. Serve una terza locazione oltre la principale e il sito di DR? Per quale motivo? 12 Nello Schema di Valutazione II fase Paragrafo 1.3, il Data Center a cui si fa riferimento è quello che sarà utilizzato come sede principale (sede da dove normalmente verranno erogati i servizi)? La terza locazione non è un requisito obbligatorio. Essa è stata indicata nello schema di valutazione solo per distinguere una soluzione di DR di livello ottimo o eccellente rispetto ai livelli inferiori Si conferma. Il punteggio di cui al paragrafo 1.3 tiene conto del Data center principale 13 Schema di Valutazione II fase Paragrafo 1.3. Si richiede quale valutazione ci aspettiamo dalla seguente casistica: Azienda con certificazione aziendale ISO con data center (inteso come esclusivamente affitto degli spazi) di proprietà di terzi con certificazione ISO Una soluzione del genere verrebbe valutata come Livello 2, dal momento che il livello 4 richiede che la certificazione aziendale ISO includa il DataCenter di proprietà destinato ai servizi infrastrutturali, mentre nella domanda il datacenter certificato è di terzi, casistica che corrisponde appunto al livello Schema di Valutazione II fase Paragrafo 1.3. Il caso di uno spazio affittato presso un Data Center di proprietà di terzi ma con: infrastruttura tecnologica di base (intesa come LAN, firewall, back-up e cabling) di proprietà e in gestione diretta hardware (inteso come server e storage) necessari per l erogazione del progetto di proprietà e in gestione diretta può essere assimilato al caso con Data Center di proprietà? Non può essere assimilato. Infatti, in un caso del genere servizi essenziali per la sicurezza (vigilanza, anticendio, etc.) sono demandati a terzi. 15 Capitolato Tecnico, Pag.76 Viene indicato che il link (nuovo o trasloco dell esistente) tra il sito principale e la sede dell Autorità rimane a carico dell Autorità stessa. Non è specificato alcunché riguardo il link tra il sito di DR e la sede dell Autorità? E da considerarsi escluso come quelle verso il sito principale? Si intende che in caso di attivazione del sito di DR i servizi saranno tutti erogati attraverso internet? La connettività MPLS tra AEEG e sito principale è relativa solo ai servizi interni di cui al par. 5.1 del Cap. tecnico. In caso di disastro, è ammissibile una connettività con il sito di DR non altrettanto performante ma che comunque rispetti i requisiti di sicurezza. 4

5 16 Capitolato Tecnico Sono disponibili delle statistiche di utilizzo dei server (sia fisici che virtuali) in termini di CPU, RAM, I/O, occupazione disco? Si ribadisce che l infrastruttura nuova non può essere una replica di quella attuale, dal momento che risponde a requisiti diversi (ad esempio: il TrovaOfferte è attualmente gestito con un blocco funzionale separato e questa separazione non è strettamente necessaria). Pertanto si invita a partire dalle informazioni contenute nell Allegato 1 per formulare la proposta di nuova infrastruttura. Le informazioni dell Allegato 2 sono fornite a scopo di trasparenza ma non costituiscono una specifica del nuovo sistema come chiaramente indicati al par del Capitolato tecnico. 17 Capitolato Tecnico, Pag.75 E esplicitamente indicato che le licenze Oracle sono da considerarsi facenti parte dell infrastruttura. A tal proposito, per una corretta valutazione dei costi delle licenze e della relativa manutenzione, è possibile avere il dettaglio delle versioni, tipo di edition e di tutte le componenti che necessitano di un licenza aggiuntiva per ognuno dei sistemi dove è presente Oracle? Le versioni di Oracle attualmente utilizzate sono puntualmente indicate nell Allegato 1. Si rimanda alle informazioni pubblicate; non si ritiene necessario fornire maggiori dettagli in quanto l ammodernamento delle versioni del DB Oracle costituisce un naturale effetto del rinnovamento dell infrastruttura 18 Schema di Valutazione II fase Paragrafo 1.12 Si richiede di specificare cosa si intende con per oggetti applicativi oltre ai file, dove sono memorizzati i dati oltre che nei file e file system? Nello specifico contesto si fa riferimento alla capacità di effettuare il restore di tutti i componenti applicativi (ovvero tutte le entità necessarie al funzionamento di un applicazione; a titolo esemplificativo e non esaustivo i profili utente, le alberature, le regole, il codice eseguibile, etc.) in maniera che i sistemi risultino funzionanti, ad esempio per effettuare rollback di rilasci in produzione falliti. E richiesta la possibilità che dati e applicazioni siano, dopo il restore, sincronizzati, cioè che l ambiente (applicazioni e dati) sottoposto a restore sia coerentemente riportato alla data del backup e integralmente funzionante. 5

6 19 In merito al documento di offerta qualitativa "Metodologia e organizzazione per l usabilità del software sviluppato - Relazione a supporto elemento a.5" da presentare in Busta n. 2 (come da Disciplinare di Gara, art. 11), si chiede di confermare che l'approccio alla usabilità (da impiegare lungo tutto il ciclo di vita del SW) da presentare sia da riferirsi al solo software sviluppato dal Fornitore entrante e non per il software rientrante nel perimetro di presa in carico Si conferma 20 In merito allo "Schema di valutazione II fase servizi web based rev aprile 2013", si chiede se, al paragrafo relativo alla valutazione della "metodologia e organizzazione per l usabilità del software sviluppato" - aspetto facilità, flessibilità e comprensibilità del software applicativo da parte dell utente finale, nella frase La proposta si presenta di un eccellente livello in termini di facilità d uso e di apprendimento, flessibilità, comprensibilità e chiarezza, mostrando diverse applicazioni degli strumenti di sviluppo a seconda degli output richiesti si chiede di chiarire cosa si intende per proposta : ci si riferisce ad una metodologia o a un software specifico? Nel caso in cui si tratti della metodologia richiesta per l usabilità, si chiede di chiarire cosa si intende per facilità d uso e di apprendimento : è richiesto che la metodologia sia trasferita al personale dell'autorità? Cosa si intende, quindi, per flessibilità del software applicativo, con riferimento alla metodologia di valutazione dell usabilità? 21 In merito al servizio di Service Desk e rispetto a quanto indicato al paragrafo bullet n.2, si chiede di conoscere quali siano le desiderate modalità di interazione con i referenti dell'autorità: assegnazione di ticket su inbox specifica in carico a personale dell Autorità ovvero tramite altra forma di comunicazione (fax, , telefono) Per "proposta" si intende la metodologia utilizzata dal Fornitore per garantire elevata usabilità del software. La "facilità d'uso e di apprendimento", nonché la flessibilità, comprensibilità e chiarezza si riferiscono al software da sviluppare. Le "diverse applicazioni" si riferiscono a casi di esempio che il Fornitore può fornire nella relazione tecnica per mostrare come la metodologia si adatta a diversi casi. La metodologia non deve essere trasferita al personale dell'autorità: garantire l'usabilità del software sviluppato e manutenuto è compito del Fornitore. E' richiesto che il personale dell'autorità referente per il Service Desk acceda al sistema di gestione ticket. Questo non esclude altre forme di comunicazione aggiuntive 22 In merito all'allegato n. 2 al Capitolato Tecnico, paragrafo n. 8 "Sistema Robin Hood Tax", si chiede maggior dettaglio circa l'infrastruttura a supporto dell'ambiente. In particolare: la banda adoperata dall'ambiente, lo spazio di storage necessario in SAN e le policy di backup Si veda il documento allegato alla nota di chiarimenti n. 4 (cfr. risposta alla domanda n. 25) pubblicata sul sito dell Autorità, che costituisce riferimento ritenuto sufficiente per la formulazione dell'offerta. Si rammenta sempre che la descrizione dell'esistente non costituisce specifica per la progettazione originale di quanto richiesto in Capitolato tecnico, ma solo riferimento orientativo. 6

7 23 In merito all'allegato n. 2 al Capitolato Tecnico, paragrafo n. 4 "Portale Internet e sistema informativo", si chiede maggior dettaglio circa la banda effettiva impiegata attualmente sul collegamento dedicato tra sito primario e sito di Disaster Recovery, rispetto alla banda totale dichiarata di 10 Mb/sec La banda è dedicata ed è di 10 Mb/sec, per l'appunto totalmente dedicati; i riferimento sono in Allegato 2 par Si ribadisce che quanto riportato in Allegato 2 è a puro titolo di riferimento 24 In merito all'allegato n. 2 al Capitolato Tecnico, paragrafo n. 4 "Portale Internet e sistema informativo", si chiede maggior dettaglio circa la banda globale necessaria per tutti gli ambienti applicativi, nonché le previsioni di crescita della stessa banda per il supporto di nuove funzionalità (social network, chat, web conference, servizi mobile, etc ) nel breve termine 25 In merito all'allegato n. 2 al Capitolato Tecnico, paragrafo n "Le Storage Area Network (SAN)" e n. 11 "Mappatura applicazioni su server fisici", si chiede se, relativamente allo spazio storage attualmente allocato/ adoperato, la capacità allocata di 12TB su 13.5TB (tabella di 11) includa anche i 5.9TB citati al Le citate nuove funzionalità non sono previste al momento come facenti parte dell'oggetto della gara. I dati attuali che rilevano in merito alla connettività sono riportati in Allegato 2. La banda necessaria deve essere pertanto valutata e proposta nell'ambito dell'offerta sulla base degli elementi progettuali impostati dal concorrente. A titolo di riferimento, attualmente la banda applicativa si aggira su 4 Mb/sec con tendenza a crescere, a parità di applicazioni (cioè senza aggiunte di nuove tipologie o sistemi) 'Portale internet e sistema informativo = 5.9 Tb; totale capacità allocata per applicazioni = 12 Tb; totale spazio = 13.5 Tb (cioè 1.5 Tb liberi) 26 In merito all'allegato n. 2 al Capitolato Tecnico, paragrafo n. 6 "Unbundling Contabile", si chiede se, relativamente alla connessione internet per Unbundling, i due router dedicati siano necessari per esigenze di interfacciamento personalizzate ovvero per altro motivo; in tal caso si chiede di conoscerne l'impiego 27 In merito al Capitolato Tecnico, paragrafo n "System monitoring", si chiede di conoscere quale sia l'attuale livello di integrazione tra il sistema di monitoraggio e i processi di notifica al personale di supporto 'L'architettura attuale descritta nell'alleg, 2 non costituisce requisito. Attualmente l'infrastruttura per il sistema Unbundling è separata da quella degli altri blocchi funzionali. La nuova infrastruttura deve rispettare i vincoli dei livelli di servizio definiti nell'all.3 sulla base delle caratteristiche delle applicazioni indicate nell'alleg.1 ma non deve necessariamente riprodurre l'architettura attuale indicata nell'alleg.2 a scopi di trasparenza e orientamento. L'integrazione si esplica nell'invio automatico di mail di notifica ad eventi specifici. Si ribadisce che la proposta non deve necessariamente riprodurre l'architettura attuale indicata nell'alleg.2 a scopi di trasparenza e orientamento. 28 In merito all'allegato n. 2 al Capitolato Tecnico, paragrafi n , n e n denominati tutti "Backup", si chiede di conoscere quali siano i requisti inerenti le policy di backup laddove non esplicitamente dichiarate Le specifiche per il backup sono, come tutte le altre specifiche, contenute nel Capitolato Tecnico, al par , e a seguire al per il disaster recovery 7

8 29 In merito al Capitolato Tecnico, paragrafo n. 2.5 "Approccio alla sicurezza e integrità dei dati", si chiede se sia possibile offire, per i sistemi di autenticazione, un unico meccanismo centralizzato di tipo Open Source 30 In merito all'allegato n. 2 al Capitolato Tecnico, paragrafo n. 11 "Mappatura applicazioni su server fisici", si chiede di conoscere se il mail server "aeeg-prod-mail00" citato sia dedicato alla gestione di domini locali ovvero opera in modalità di relay verso internet Il sistema di autenticazione attuale utilizzato per la maggior parte delle aree applicative di tipo extranet (CAS - Central Authentication Service) è già di tipo Open Source. Si veda Allegato 1 al Cap.tecnico, pagina 20 e Capitolato tecnico pag. 13. Ogni modifica della principale piattaforma esistente di autenticazione deve rispettare i requisiti e le procedure di cui al punto del Capitolato tecnico. Trattasi in effetti di un relay verso internet, che viene usato per tutte le operazioni di notifica di tutte le aree applicative, internet / intranet / extranet. 31 In merito all'allegato n. 2 al Capitolato Tecnico, paragrafo n. 4.1 "Descrizione generale" del Portale internet e sistema informativo, si chiede di conoscere, relativamente ai tool di sincronizzazione storage tra Sito Primario e sito di Disaster Recovery, quali siano gli strumenti di replica EMC attualmente adoperati La soluzione attualmente operativa gestisce le repliche in modalità storage based e queste avvengono su di link 10MB. Si ribadisce che quanto contenuto nell'allegato 2 è riportato solo a titolo di trasparenza e non costituisce specifica, espressa nel capitolato tecnico e in particolare al capitolo 5 32 In merito al Capitolato Tecnico, paragrafo n. 4.6 "Service desk applicativo", si chiede di conoscere se le applicazioni dispongano attualmente di tool di amministrazione utilizzabili dal Service Desk applicativo e dall'expert Service Desk infrastrutturale 33 In merito all'offerta qualitativa, si chiede di confermare che non sia necessario fornire i curricula di ogni componente del team, ma che sia sufficiente dare un'overview del livello di inquadramento e delle esperienze pregresse di ciascun profilo professionale e di ciascuna figura di cui al paragrafo 3.3 del Captolato Tecnico Si veda la risposta alla domanda 21 per quanto riguarda il Service desk applicativo. L'Expert Service Desk infrastrutturale deve avere tutti gli strumenti tipici di un service desk di questo tipo; è pertanto inevitabile che abbia accesso, per esempio, ai sistemi di monitoring delle infrastrutture (vd Capitolato tecnico, par ). Si conferma 34 In merito alla certificazione IFPUG (almeno v.2) di cui il referente per il conteggio dei function point (FP) deve essere in possesso (paragrafo 3.3 del Capitolato Tecnico), si chiede di chiarire se è necessario essere in possesso della versione CFTS o se sia sufficiente la versione CFTP Siamo a conoscenza della certificazione CFPS - Certified Function Point Specialist IFPUG e tale certificazione è sicuramente adeguata. Possiamo accettare anche la certificazione CFPP (Certified Function Point Practitioner). Non siamo a conoscenza delle versioni CFTS e CFTP citate nella domanda. Si veda Milano, 18 giugno 2013 Autorità per l energia elettrica e il gas Direzione Affari Generali e Risorse Unità Gare e Contratti Il Responsabile (firmato: Massimo Donghi) 8