SOMMARIO
CAPITOLATO TECNICO
Progetto “112 NUE 2009 Integrato”:
Fornitura di un sistema hardware, software e servizi per l’aggiornamento tecnologico nei centri di risposta della Polizia di Stato
SOMMARIO
1 PREMESSA 4
2 OGGETTTO DELLA GARA 6
2.1 Durata della fornitura 7
2.2 Componenti della fornitura a carico dell’Amministrazione 7
3 SITUAZIONE ATTUALE 9
3.1 Organizzazione del contesto operativo 9
3.2 L’attuale sistema SCT 9
3.2.1 L’architettura attuale del sistema SCT 9
3.2.2 Software applicativo 10
4 LA SOLUZIONE RICHIESTA: “NUOVO SCT” 14
4.1 Premessa 14
4.2 Sistema di gestione utenze 16
4.2.1 La gestione degli utenti 17
4.2.2 I requisiti del sistema di repository degli utenti 18
4.2.3 I requisiti del sistema di gestione delle identità utenti 18
4.3 Sistema Hardware Centrale presso CEN di Napoli 19
4.3.1 Server Centrale di Tipo A 20
4.3.2 Storage Centrale 21
4.3.3 Switch 22
4.3.4 Armadi rack 22
4.4 Sistema Hardware presso le Questure 23
4.4.1 Server di Questura di I Fascia 23
4.4.2 Server di Questura di II Fascia 25
4.4.3 Storage condiviso per cluster 27
4.4.4 Postazioni Operatore 28
4.5 Software di system management 29
4.6 Software di base e d’ambiente 29
4.7 Software Backup 29
4.8 Software Virtualizzazione 30
4.9 Provisioning automatico del software 31
4.9.1 Descrizione del servizio 31
4.9.2 Requisiti 31
5 SERVIZI TECNICI 32
5.1 Manutenzione hw e assistenza sistemistica sul sistema SCT attuale e SLA 32
5.1.1 Livelli di criticità e SLA 32
5.1.2 Figure professionali 33
5.1.3 Dimensionamento 33
5.1.4 Penali 34
5.2 Migrazione e conversione delle applicazioni 35
5.2.1 Dimensionamento 38
5.3 Recupero dati storici 38
5.4 Installazione e messa in funzione “nuovo SCT” 38
5.4.1 Penali 39
5.5 Manutenzione e gestione “nuovo SCT” e SLA 39
5.5.1 Requisiti di qualità livelli di servizio 40
5.5.2 Assistenza 41
5.5.3 Assistenza e manutenzione applicativa 43
5.5.4 Penali 44
5.6 Manutenzione Evolutiva a consumo 47
5.6.1 Livelli di servizio e penali 47
5.7 Formazione alla conduzione sistemistica ed operativa a livello centrale 50
5.7.1 Soddisfazione dei Requisiti 50
5.8 Figure professionali 51
6 ATTIVITÀ DI COORDINAMENTO E DIREZIONE DI PROGETTO 54
7 PIANO DI PROGETTO 55
8 MONITORAGGIO 55
9 ULTERIORI RACCOMANDAZIONI E NORMATIVE 55
10 COLLAUDO 56
11 MODALITA’ COMPILAZIONE DELLE OFFERTE 57
11.1 Offerta Economica 57
11.2 Offerta Tecnica 59
12 CRITERI DI AGGIUDICAZIONE 59
1 PREMESSA
A seguito dell’istituzione del Numero Unico di Emergenza Europeo 112, il Dipartimento della Pubblica Sicurezza del Ministero dell’Interno ha elaborato, d’intesa con l’Arma dei carabinieri, i Vigili del fuoco e l’Emergenza sanitaria, il progetto “112 NUE Integrato” che prevede che tutte le chiamate di emergenza con selezione 113 (Polizia di Stato) o 112 (Arma dei Carabinieri) originate sia dalla rete fissa, sia dalla rete mobile, vengano instradate verso le Sale/Centrali Operative dell’Arma dei Carabinieri e della Polizia di Stato (Public Safety Answering Point di 1° livello) competenti per territorio. E’ previsto l’inoltro delle chiamate di emergenza, agli Enti (CO 115 e CO 118) PSAP di 2° livello con il contestuale invio, dei dati di identificazione e localizzazione del chiamante.
Il progetto “112 NUE Integrato” fonda i suoi presupposti sullo scenario normativo di seguito indicato:
▪ Decisione europea 91/396/CEE sull’introduzione di un numero unico europeo per le chiamate di emergenza.
▪ Raccomandazione della Commissione delle Comunità Europee del 25 luglio 2003 (2003/558/CE) [notificata con il numero C(2003) 2657].
▪ Decreto legislativo del 1° agosto 2003, n.259 (c.d. Codice delle Comunicazioni Elettroniche), art. 76 “numeri di emergenza nazionali e numero di emergenza unico europeo”.
▪ Decreto 27 aprile 2006 del Ministero delle Comunicazioni “Servizio 112 numero unico europeo d’emergenza” (Gazzetta Ufficiale n. 191 del 18-8-2006).
▪ Decreto 22 gennaio 2008 del Ministero delle Comunicazioni “Numero unico europeo di emergenza 112” (Gazzetta Ufficiale n. 59 del 10-3-2008).
▪ Decreto 12 novembre 2009 del Ministero dello Sviluppo Economico “Disposizioni relativamente al servizio del numero telefonico unico di emergenza europeo 112” (Gazzetta Ufficiale n. 30 del 6-2-2010).
Per consentire agli operatori dei centri di risposta della Polizia di Stato di gestire con efficacia ed efficienza le chiamate di emergenze e gli eventi ad essa relativi, i dati di localizzazione del chiamante ed il loro trattamento, il coordinamento operativo con gli altri centri di risposta nel caso di intervento congiunto, si rende necessario l’aggiornamento tecnologico del sistema informatico delle Sale Operative delle Questure “Sistema per il Controllo del Territorio – SCT “.
Il progetto SCT ha informatizzato le Sale Operative delle Questure della Polizia di Stato ed ha fornito la tecnologia alle proprie unità operative per la gestione degli eventi segnalati dai cittadini, permettendo agli operatori la gestione ottimale delle emergenze.
Il software applicativo SCT di proprietà dell’Amministrazione è stato realizzato nel 2000, basato su un’architettura client/server distribuita su ogni Questura, si compone di diversi moduli funzionali. Si rende ora necessaria una nuova architettura applicativa centrale che tenga conto delle mutate esigenze applicative indotte dal progetto NUE 112, dalla disponibilità delle rete IP di comunicazione tra gli uffici centrali e Periferici della Polizia di Stato, dai nuovi paradigmi di sviluppo e programmazione del software.
L’obiettivo è di arrivare ad un nuovo sistema SCT con le seguenti caratteristiche:
Caratteristiche tecniche
• Nuova Architettura informatica centralizzata a più livelli che separi l’interfaccia utente e applicativa dal livello di business logic e dal livello dati. Il modulo “Sala Operativa” e il relativo DBMS sarà l’unico ad essere distribuito su server specifici di Questura come specificato nel capitolo 4.
• Disponibilità di una soluzione modulare per facilitare l’interoperabilità con le altre applicazioni dell’Amministrazione e di altri Enti.
• Possibilità di governare in modalità automatica e centralizzata presso il CEN di Napoli la distribuzione e gli eventuali aggiornamenti del software di base e applicativo sui sistemi di ciascuna Questura sia client che server.
• Utilizzo dove possibile, di tecnologia “Open Source”, sia a livello di software di base che d’ambiente.
• Modularità spinta delle soluzioni software per consentire un avvio graduale dell’intero sistema.
• Elevato livello di continuità dei servizi informatici.
• Scalabilità.
Caratteristiche funzionali
• Devono essere garantite le stesse funzionalità attualmente disponibili.
• L’interfaccia deve essere il più possibile simile nei colori e nella disposizione delle form e dei tasti d’interazione all’attuale, in modo che gli operatori di sala possano continuare a svolgere le proprie funzioni riducendo al minimo gli impatti sull'utilizzo del nuovo software applicativo.
• Il sistema informativo dovrà consentire l’archiviazione e la consultazione dei dati garantendo adeguati livelli di riservatezza e sicurezza rispettando l’attuale profilazione degli utenti.
• Fornitura di un punto unico di gestione e di analisi dei dati.
• Adozione di un sistema di autenticazione e profilazione con utenza e password conforme allo standard LDAP come specificato nel paragrafo 4.2.
2 OGGETTTO DELLA GARA
L’appalto si concretizzerà, attraverso la fornitura di tutte le componenti tecnologiche sia hardware che software necessarie e di tutti i servizi occorrenti per la realizzazione ed il completo avviamento del sistema informativo “nuovo SCT” e per la sua gestione e manutenzione nei tempi di seguito richiesti.
Sono oggetto di fornitura della presente gara:
▪ Tutto l’hardware necessario al funzionamento del nuovo sistema, sia periferico (postazioni operatore, server in alta affidabilità, storage) presso 104 Questure, sia centrale (sistemi server in alta affidabilità, storage) presso il CEN di Napoli. Non è previsto il riuso dell’hardware esistente.
▪ Tutto il sw di base, di ambiente, di system management, e di virtualizzazione necessario sia a livello centrale che periferico come specificato nel presente capitolato.
▪ Armadi rack per il sito centrale e per le Questure.
▪ Due switch FC con almeno 24 porte a 8 Gbps ciascuno, di cui almeno 8 ciascuno gia' attive, comprensive di connettori SFP+ e cavi per connettere tutti i server e lo storage solo per la sede Centrale.
▪ Ritiro e smaltimento a norma di legge delle attuali apparecchiature (postazioni operatore, server, storage)
La fornitura dovrà essere corredata da specifici servizi tecnici e precisamente:
• Assistenza sistemistica e manutenzione hardware della piattaforma attuale (esclusa quindi l’assistenza applicativa) presso tutte le Questure e supporto del sistema di certification authority nella sede di Spinaceto (RM) fino alla migrazione sulla nuova architettura.
• Centralizzazione di tutti i moduli su piattaforma x86 con relativo DBMS ad esclusione del modulo “Sala Operativa”.
• Porting del modulo “Sala Operativa” su piattaforma x86 di Questura e del relativo DBMS per la gestione in real time di tale funzionalità.
Le due attività sopracitate devo essere realizzate:
o mantenendo tutte le funzionalità e l’interfaccia il più possibile simile nei colori e nella disposizione delle form e dei tasti d’interazione all’attuale;
o permettendo la gestione remota del client e della componente server di Questura in modalità smart client;
o implementando funzioni di “help” e di documentazione on-line;
o documentando tutto il nuovo software secondo lo standard ISO/IEC 90003:2004 “Software engineering – Guidelines for the application of ISO 9001:2000 to computer software”.
▪ Recupero dei dati di esercizio e storici e porting degli stessi dai database di Questura ai nuovi DBMS distribuiti e centralizzato.
▪ Servizi necessari per l’installazione e messa in funzione delle tecnologie offerte su tutte le Questure e la sede centrale.
▪ Manutenzione, conduzione tecnica, funzionale e gestione dell’applicativo sulla nuova architettura per minimo 12 mesi.
▪ Manutenzione evolutiva a consumo di 2000 punti funzione .
▪ Formazione per la conduzione sistemistica ed operativa a livello centrale del personale dell’Amministrazione.
Le Imprese partecipanti, avuto riguardo alle esigenze rappresentate nella documentazione di gara, dovranno pertanto produrre apposita offerta che, tenuto conto del relativo contesto operativo e normativo, illustri i servizi, le tecnologie, i criteri organizzativi ed operativi che si intendono adottare per l’effettuazione dell’intervento di che trattasi nel dettaglio richiesto per la sua valutazione.
Per quanto riguarda il sistema di autenticazione e profilazione, l’attuale sistema SCT utilizza smart card base su un modello di Certification Authority sviluppato utilizzando software IBM Lotus Notes ed installato presso la sede di Spinaceto (RM).
E’ richiesto l’adozione di un nuovo sistema di autenticazione e profilazione con utenza e password senza l’utilizzo di smart card basato su un registro utenti locale in ciascuna Questura, conforme allo standard LDAP, che dovrà essere allineato con un registro utenti centralizzato presente presso il CEN di Napoli anch’esso basato su standard LDAP.
2.1 Durata della fornitura
La durata contrattuale minima è di 36 (trentasei) mesi a decorrere dalla “Data di inizio attività” che sarà comunicata dall’Amministrazione all’Impresa.
L'avviamento dell'intero sistema dovrà essere completato su tutte le Questure ed a livello centrale
entro 24 mesi dalla data di inizio attività.
A decorrere dal collaudo positivo dell’intero sistema, dovrà essere erogato il servizio di manutenzione e gestione “nuovo SCT”, come specificato nel paragrafo 5.5, che avrà una durata minima di 12 mesi ed il servizio di MEV a consumo di 2000 punti funzione.
E’ criterio premiante l’erogazione di ulteriori trimestri del servizio di manutenzione e gestione “nuovo SCT”, come specificato nel paragrafo 5.5. oltre quelli minimi richiesti.
Le apparecchiature si intenderanno acquisite in proprietà al patrimonio del Dipartimento della Pubblica Sicurezza ed i prodotti software si intenderanno concessi in licenza d’uso illimitata alla data positiva del collaudo.
L’Amministrazione sarà proprietaria del codice sorgente dell’applicativo “nuovo SCT” e di ogni sviluppo si realizzi nell’ambito della vigenza contrattuale.
2.2 Componenti della fornitura a carico dell’Amministrazione
Nell’ambito del progetto l’Amministrazione renderà disponibile quanto segue:
❑ i codici sorgente, la progettazione di dettaglio, i manuali utente della attuale versione SCT;
❑ un gruppo di governo con competenze amministrative e tecniche afferenti la materia oggetto di fornitura e che fornirà tutte le indicazioni, i requisiti, le specifiche e verificherà lo stato avanzamento dei lavori;
❑ un responsabile di progetto con il compito di condurre, con l’impresa la realizzazione della fornitura e di sottoscrivere ed accettare tutti i deliverable di fornitura finali ed intermedi per conto dell’Amministrazione;
❑ il software antivirus;
❑ il motore cartografico e le mappe cartografiche;
❑ la configurazione degli apparati di rete periferici e centrali per la connettività sulla rete VPN dell’Amministrazione;
❑ una sede specchio di Questura (non operativa) per l’attività di sviluppo e test.
La fornitura dovrà conformarsi ai requisiti di seguito indicati:
1. tutte le Apparecchiature e le componenti software dovranno presentare caratteristiche tecniche superiori o uguali a quelle minime riportate nel presente documento;
2. dovranno essere forniti i quantitativi di apparecchiature, componenti software e servizi indicati nel presente capitolato;
3. per ciascuna apparecchiatura e componente software dovrà essere fornita una copia della manualistica tecnica completa, edita dal produttore; la documentazione dovrà essere in lingua italiana oppure, se non prevista, in lingua inglese sia in formato elettronico che cartaceo;
4. eventuali elementi accessori, necessari per il corretto funzionamento delle componenti fornite, dovranno essere fornite senza costi aggiuntivi.
L’impresa dovrà garantire la conformità delle apparecchiature alle normative CEI o ad altre disposizioni internazionali riconosciute e, in generale, alle vigenti norme legislative, regolamentari e tecniche disciplinanti i componenti e le modalità di impiego delle apparecchiature medesime ai fini della sicurezza degli utilizzatori.
Tutti i materiali ed i componenti oggetto della Fornitura dovranno essere nuovi di fabbrica e completi di quanto necessario per il loro perfetto funzionamento (per esempio cavi di connessione, adattatori e cavi di alimentazione).
3 SITUAZIONE ATTUALE
Ogni Provincia è sede della Questura, un ufficio della Polizia di Stato con competenza provinciale, alle dipendenze del Ministero dell’Interno. Suo compito primario è assicurare il mantenimento dell'ordine e della sicurezza pubblica nell'ambito del territorio di competenza. Per il conseguimento di tale fine viene svolta una costante attività di prevenzione e repressione dei reati.
Il 113 è sia il numero che la denominazione del servizio preposto a rispondere alle chiamate d’emergenza dei cittadini alla Polizia di Stato che sarà nell’ambito del progetto 112 NUE integrato sostituito dal numero unico di emergenza 112.
Il servizio è istituito presso la Questura d'appartenenza, precisamente nella Sala Operativa dove si trova anche la Sala Radio che raccoglie le segnalazioni inoltrate al Numero di emergenza dai cittadini, predisponendo gli interventi (e/o segnalazioni) cui andranno a prestare il dovuto soccorso o ausilio le Autoradio "operative" (ovvero che non siano già impegnate in precedenti interventi assegnati loro sempre dalla Sala Operativa).
La sala del 113 è quindi, con le dovute eccezioni, una sorta di "centrale telefonica" gestita da personale appartenente alla Polizia di Stato; nelle grandi e medie questure, a livello pratico, si tratta di un ambiente con varie postazioni operatore consistenti in un sistema di terminali collegati alle linee telefoniche e di workstation con l’applicativo SCT per la gestione informatica degli interventi. Nelle questure più piccole invece possiamo trovare centralino 113 e Sala Radio riuniti in un unica stanza.
3.1 Organizzazione del contesto operativo
Il contesto organizzativo in cui si svolgerà l’intervento è rappresentato da tutte le Sale Operative delle Questure e dal CEN di Napoli per l’installazione del “nuovo SCT” e sua conduzione e manutenzione.
Da tutte le Sale Operative delle Questure e dalla sede di Spinaceto (RM) per l’assistenza sistemistica e manutenzione hardware della piattaforma attuale.
3.2 L’attuale sistema SCT
3.2.1 L’architettura attuale del sistema SCT
L’architettura applicativa dell’attuale sistema SCT è di tipo client-server su ogni Questura con un proprio DBMS (IBM DB2) senza scambi di dati tra le Questure stesse. Presso la sede di Spinaceto è installta la CA autority per l’abilitazione delle smart card per gli operatori.
L’architettura di SCT prevede l’utilizzo di alcune applicazioni (Demoni) installati sul server, le quali una volta invocate eseguono delle elaborazioni e notificano i client; tali client però non si servono di alcuna applicazione per eseguire operazioni di lettura/scrittura/cancellazione dei dati, infatti tutti i moduli client C/C++ accedono direttamente ( tramite driver ODBC ) alla Base di Dati. La gestione di accessi concorrenti ai dati viene gestita direttamente dal DB Server e non da un gestore di servizi separato installato sul server .
3.2.2 Software applicativo
Un primo schema a macroblocchi funzionali del sistema SCT, riportato nel diagramma che segue, evidenzia le varie componenti dello stesso.
La progettazione ed i manuali utente, sono parte del presente capitolato e si possono scaricare dal sito xxx.xxxxxxxxxxxxxx.xx nella sezione “Bandi di gara”. E’ possibile richiedere di visionare l’applicativo SCT presso la sede di Spinaceto (RM).
I codici sorgenti saranno forniti all’impresa aggiudicataria.
Segue una breve descrizione funzionale dei vari moduli.
Sala Operativa
La Sala Operativa gestisce il controllo ordinario del Territorio, Emergenze, Servizi di Ordine Pubblico, Servizio pianificati in genere e attività estemporanee nel Controllo del territorio.
E’ il centro di accettazione e trattamento di tutte le informazioni che saranno il patrimonio dati del sistema nel suo complesso.
E’ un modulo funzionale che consente:
• la visualizzazione della storia, cronaca, fabbisogno e previsioni per territorio, dispositivo ed evento;
• l’attivazione di funzioni di sevizio indispensabili durante la gestione operativa (appello volanti, accesso banca dati SDI, registrazione telefonate, ecc.);
• la presa in carico di attività pianificate;
• la gestione delle richieste ed interventi;
• la consultazione dei dati necessari durante le attività di Sala Operativa;
• la consultazione guidata dei risultati dei pacchetti di analisi richieste;
• l’elaborazione automatica e contestuale alla gestione delle emergenze:
o informazioni rilevanti (locali o remote);
o vie di fuga;
o configurazione dinamica dei piani di intervento;
•rappresentazione cartografica di tutte le informazioni preesistenti, gestite ed elaborate automaticamente dal sistema;
•servizi di analisi spaziale su richiesta dell’operatore:
o volante più vicina;
o calcolo percorso ottimale;
o visualizzazioni eventi correlati ed obbiettivi sensibili.
Consultazione e Reportistica
La sua funzionalità consiste nel fornire un sistema di navigazione tra i dati elementari presenti del sistema di Provincia e produzione di rapporti.
Questa funzione è costituita da componenti applicative accessibili da:
• Sala Operativa;
• Documentale.
Terminale di Bordo
Il terminale di Bordo rappresenta già un compente hardware specifico, ma dal punto di vista funzionale costituisce l’appendice del sistema SCT per gli equipaggi delle unità operative attrezzate. Il terminale di bordo ha le seguenti funzioni:
• Interrogazione SDI.
• Funzioni di navigazione cartografica.
• Trasmissione dei dati di locazione del veicolo.
• Trasmissione messaggi con informazioni di contesto da Sala Operativa e viceversa.
Segreteria
Questa funzionalità si ripercuote su tutte le altre funzioni, è un insieme logico di servizi necessari per la corretta configurazione funzionale di SCT. Le diverse componenti integrate nell’applicazione di Segreteria sono:
• Gestione degli utenti
• Gestione dei turni di servizio
• Gestione del parco mezzi
• Gestione dei dati di base (Tipologiche, Rubriche ecc.)
• Configurazione dei segnali e servizi video
• Un sistema che consenta visualizzazione della storia, cronaca, fabbisogno e previsioni per territorio, dispositivo ed evento (Giornale).
Documentale e Relazioni Servizio
Applicazione destinata alla raccolta e alla gestione di informazioni relative a denuncie informative e relazioni di servizio. Il documentale fornisce le seguenti funzionalità:
• Interrogazione SDI
• Acquisizione denuncie
• Invio denuncie a SDI
• Acquisizione automatica dati rilevanti denuncie
• Acquisizione relazioni di servizio
• Consultazione relazioni e denuncie
Pianificazione
Questa funzionalità fornisce i servizi utili alla corretta pianificazione delle attività di controllo ordinarie del territorio. Tra le principali funzioni:
• Pianificazione strategico tattica e servizi di ordine pubblico
• Impostazione piani preordinati di intervento
• Attivazione delle funzioni di ottimizzazione dei piani impostati
• Consultazione guidata dei risultati dei pacchetti di analisi.
Simulatore
Il simulatore è lo strumento destinato alla formazione del personale che utilizza SCT. Rispecchia nel modo più fedele possibile tutte le funzioni del Sistema di Controllo del Territorio. Dal punto di vista funzionale, oltre a tutte le componenti SCT, è dotato di:
• Un sistema per la produzione e riproduzione di scenari accadimento.
• Un sistema che gestisce la simulazione dei scenari con possibilità di intervento in tempo reale.
• Un sistema per gestire il percorso formativo dei discenti.
• Un sistema per l’Interazione fra formatori e discenti durante la riproduzione di scenari.
Funzioni specifiche Sala Crisi
La sala crisi utilizza tutte le applicazioni di sala operativa, introducendo inoltre tutte le funzionalità e componenti necessarie alla gestione di particolari situazioni che richiedono un gruppo di utenti eterogenei.
Analisi e Previsioni
Questa funzionalità permette agli operatori un’analisi dei dati (centralizzati) che descrivono il Territorio, le attività del Dispositivo di Polizia e gli eventi e fatti che accadono nel Territorio di competenza della Provincia.
Dal punto di vista delle applicazioni questa funzionalità è realizzata da una componente applicativa, con l’integrazione di moduli specifici nelle altre componenti preesistenti che utilizzano il Giornale.
Sicurezza & Servizi di sistema
Sono tutte le componenti necessarie alla conduzione e gestione del sistema sotto tutti gli aspetti tecnologici/operativi, si fa esplicito riferimento a:
• Servizi di profilazione utenza
• Cifrautre tramite Certification Autority
• Backup automatici e manuali
• Firewall e intrusion detection
• Gestione centralizzata degli allarmi ricavati da log di sistema.
I moduli applicativi server sono sviluppati in C/C++, Java e sono eseguiti su HW IBM Risc con sistema operativo AIX. I client, sviluppati anch’essi in linguaggio C/C++, Java sono ospitati su workstation Intel/Windows.
Contesto Tecnologico
Analizzando globalmente il codice sorgente con la tecnologia CAST AIP, sono stati rilevati i seguenti dati dimensionali:
Figura –Tecnologie utilizzate in SCT
Tabella – Tecnologie utilizzate in SCT
Files | Linguaggio | Linee vuote | Linee di Commento | Linee di codice |
1439 | C++ | 191217 | 126195 | 731942 |
1544 | Java | 90987 | 77827 | 482870 |
1959 | C/C++ Header | 50137 | 46895 | 205292 |
294 | C | 39603 | 40153 | 144853 |
33 | SQL | 13478 | 6447 | 41694 |
150 | PHP | 6437 | 6761 | 34764 |
15 | XML | 000 | 00 | 0000 |
89 | JSP | 0000 | 000 | 0000 |
24 | Javascript | 000 | 000 | 0000 |
25 | CSS | 000 | 000 | 0000 |
58 | DOS Batch | 000 | 00 | 0000 |
18 | C# | 000 | 000 | 0000 |
12 | IDL | 330 | 0 | 1581 |
19 | HTML | 000 | 000 | 0000 |
30 | make | 386 | 315 | 920 |
16 | ASP,Net | 100 | 0 | 872 |
60 | Teamcenter def | 135 | 0 | 392 |
24 | Korn Shell | 117 | 12 | 336 |
3 | Visual Basic | 46 | 63 | 103 |
3 | Bourne Shell | 1 | 0 | 17 |
A titolo semplificativo e non esaustivo si ritiene il dimensionamento dell’applicativo di circa 14.000 Function Point stimati in parte secondo il metodo Backfired definito dall’International Function Points User Group (IFPUG) in parte come somma degli FP relativi ad alcune funzionalità integrate nel corso degli ultimi due anni.
4 LA SOLUZIONE RICHIESTA: “NUOVO SCT”
4.1 Premessa
E’ richiesta la conversione dell’applicazione e la migrazione dei dati del modulo “Sala Operativa” da piattaforma IBM Risc 6K a piattaforma x86 di Questura; la conversione, la migrazione dei dati e la centralizzazione, presso il CEN della Polizia di Stato di Napoli, delle altre componenti applicative del sistema SCT su piattaforma x86.
Il sistema deve essere realizzato in modo tale che il modulo “Sala Operativa” sia operativo ed eseguito al CEN di Napoli in caso di guasto “bloccante” del server di Questura.
Il processo deve lasciare inalterati i requisiti di carattere funzionale dell’applicativo e l’interfaccia utente in modo che gli operatori di sala possano continuare a svolgere le proprie funzioni riducendo al minimo gli impatti sull'utilizzo del sistema.
L’Amministrazione ha una propria rete VPN per la connessione di tutte le Questure alla sede del CEN di Napoli. La configurazione della stessa per le esigenze del presente progetto, saranno a carico di qualificato personale dell’Amministrazione.
Schema logico dell’architettura applicativa
L’architettura modulare dell’applicazione SCT permette la distribuzione dei moduli parte sul sistema locale della Questura e parte al Centro presso il CEN di Napoli. In particolare il modulo “Sala Operativa” dovrà continuare ad operare in Questura a servizio degli utenti per le loro attività operative, con possibilità di lavorare in modalità disconnessa dal Centro, mentre tutti gli altri moduli dovranno essere portati al Centro presso il CEN di Napoli e accessibili dagli operatori di tutte le Questure se autorizzati.
Il modulo “Sala Operativa” è particolarmente critico pertanto deve essere garantita sempre la sua disponibilità. Il server che lo ospita deve essere pertanto in alta affidabilità e le risorse che utilizza devono essere ridondate. La base dati applicativa su cui opera, presso ogni Questura, deve essere replicata, sincronizzando periodicamente i dati, al Centro presso il CEN di Napoli.
E' richiesto inoltre che si possa governare in modalità automatica e centralizzata presso il CEN di Napoli la distribuzione e gli eventuali aggiornamenti del software di base e applicativo sui sistemi di ciascuna Questura sia client che server.
In considerazione dei requisiti precedenti, deve essere possibile ricostruire l’applicazione sala operativa, comprensiva dei dati, utilizzando le immagini e le repliche dei dati presenti presso il CEN di Napoli.
4.2 Sistema di gestione utenze
Relativamente alla gestione delle utenze il sistema di ”user repository” deve essere basato sul protocollo LDAP. Nel seguito del Capitolato esso sarà definito come “LDAP repository”.
Su di esso si definiscono gli utenti e i relativi attributi che saranno utilizzati dalle applicazioni in fase di identificazione ed autenticazione. Gli attributi di ciascun utente saranno impiegati anche per costruirne il relativo profilo e ricavarne l’eventuale appartenenza a gruppo/i. I dati contenuti nel profilo di un utente sono utilizzati dalle applicazioni, per assumere le decisioni autorizzative.
L’LDAP repository deve permettere di creare almeno gli attuali ruoli e profili. Deve essere altresì garantita la possibilità di stabilire dei nuovi ruoli o profili, qualora ciò dovesse emergere in fase d’analisi, durante la progettazione esecutiva.
Presso la Sede Centrale sarà installato l’”LDAP repository centralizzato”, su di esso saranno definiti tutti gli utenti che dovranno utilizzare le applicazioni. L’albero di questo LDAP dovrà essere definito per tenere conto di tutte le sale operative presenti nelle questure. Gli utenti dovranno avere un attributo che ne qualifichi l’appartenenza ad una determinata sala operativa.
Oltre all’LDAP repository centralizzato, per permettere il massimo grado di operatività e flessibilità si dovrà utilizzare un’architettura di ”LDAP repository” distribuita sul territorio. In particolare ciascuna sala operativa dovrà essere dotato di un proprio “LDAP repository locale” sul quale saranno definiti solo gli utenti di pertinenza della sala operativa in questione.
La necessità di avere anche un “LDAP repositoty locale” presso ciascuna sala operativa nasce dall’esigenza di garantire il funzionamento dell’applicazione Modulo Sala Operativa, e quindi l’operatività degli utenti, anche nel caso in cui non sia possibile, a causa di malfunzionamenti di rete, stabilire una connessione con l’LDAP repository centralizzato. In generale l’applicazione Modulo Sala Operativa eseguirà le relative query per identificare/autenticare/autorizzare un utente verso il proprio LDAP repository locale, mentre le altre applicazioni centralizzate eseguiranno le query per identificare/autenticare/autorizzare un utente verso ”LDAP repository centralizzato”.
figura 1 use case dell’autenticazione degli utenti
4.2.1 La gestione degli utenti
L’ LDAP repository dovrà essere dotato di un sistema per la gestione del ciclo di vita degli utenti tale da permettere la creazione, modifica e cancellazione di un utente e l’attribuzione dei relativi attributi, nonché la gestione e l’eventuale reset delle password (sistema di gestione delle identità).
Le informazioni relative al ciclo di vita di un utente saranno immesse mediante l’applicazione gestione delle identità che avrà un’interfaccia di tipo web based disponibile presso la Sede Centrale. Mediante tale applicazione il responsabile di ciascuna sala operativa inserirà e/o modificherà le informazioni relative agli utenti della propria sala sull’LDAP repository centrale, da questo le informazioni saranno poi allineate verso l’ LDAP repository locale di pertinenza.
Nella figura sotto riportata si evidenzia, a titolo esemplificativo, lo use case relativo alla gestione delle utenze da parte dei responsabili delle sale operative. Nella normale operatività essi si collegano all’applicazione per la gestione delle identità per fare le opportune operazioni, sarà quindi cura di detta applicazione allineare le modifiche sull’ LDAP repository locale di pertinenza.
figura 2 Lo use case del reset della password in condizioni di normale operatività
Nel caso in cui non sia disponibile la connettività di rete tra la Sede Centrale ed una sala operativa, e il responsabile debba resettare la password di un utente locale, il responsabile opererà il reset della password collegandosi con le proprie credenziali di amministratore all’LDAP repository locale ed eseguendo le relative operazioni di reset, permettendo così di operare sull’applicazione Modulo Sala Operativa. L’utente in seguito, utilizzando le funzioni di self care reset fornite dal Sistema di Gestione delle Identità, potrà resettare la propria password per avere la piena operatività anche sulle altre applicazioni.
4.2.2 I requisiti del sistema di repository degli utenti
Il sistema di repository degli utenti sia a livello centrale che locale deve rispettare i seguenti requisiti:
1. Devono essere supportati gli standard LDAP.
2. L’LDAP repository centralizzato deve essere installato in maniera da garantire l’alta affidabilità. E’ ammissibile sia una soluzione di tipo active/passive che active/active con relativo bilanciamento del carico.
3. L’LDAP repository locale deve essere installato in maniera da garantire l’alta affidabilità. E’ ammissibile sia una soluzione di tipo active/passive che active/active con relativo bilanciamento del carico.
4. Devono essere disponibili algoritmi di cifratura AES (Advanced Encryption Standard) e SHA (Salted Secure Hash Algorithm) per la conservazione sicura di attributi all'interno del repository.
5. Deve essere possibile proteggere i canali di comunicazione tra gli LDAP e il sistema di gestione delle identità attraverso la crittografia tramite l’utilizzo protocollo SSL o TSL.
6. L'LDAP repository deve essere conforme allo standard di sicurezza Common Criteria e all' Evaluation Assurance Level 4 (EAL4).
7. Gli LDAP repository devono essere multi piattaforma, ovvero girare almeno sui seguenti sistemi operativi: Windows, Linux, UNIX.
8. Deve essere possibile definire delle policy sulla qualità della password sia a livello globale che per gruppi di utenti o singoli individui (es. lunghezza minima, scadenza, minimo numero di caratteri speciali o numeri etc.).
4.2.3 I requisiti del sistema di gestione delle identità utenti
Il sistema per la gestione delle identità deve rispettare i seguenti requisiti:
1. Deve permettere una granularità di autorizzazione per consentire la gestione di un sottoinsieme di utenti o funzioni (xx.xx Ruolo Amministratore di Sala Operativa può gestire solo gli utenti della propria sala, mentre un amministratore regionale potrebbe gestire gli utenti delle sale di una regione).
2. Deve fornire interfaccia Web per la registrazione di nuove persone con la flessibilità di modifiche degli attributi di anagrafica che devono essere gestiti.
3. Deve avere una funzione di “self-care della password” attraverso la quale un utente che abbia dimenticato la propria password, rispondendo positivamente alle domande di challenge possa resettarla.
4. Deve possedere un sistema di workflow autorizzativo, configurabile attraverso interfaccia di tipo grafico.
5. Deve fornire funzionalità di ricertificazione delle utenze e delle persone gestite dal sistema configurabile con notifiche automatiche inviate ai responsabili regionali.
4.3 Sistema Hardware Centrale presso CEN di Napoli
Il sottosistema informatico deve prevedere soluzioni tecnologiche ed organizzative finalizzate a garantire un elevato livello di affidabilità e disponibilità.
L’architettura dei sistemi dovrà essere modulare, scalabile, affidabile e con livelli di sicurezza adeguati a supportare il sistema informativo di tutte le Questure. Per ciascuno dei requisiti di tale componente si riassumono le principali caratteristiche:
• Modularità – tutti i servizi implementati dovranno essere organizzati in blocchi funzionali che possano risiedere su un solo sistema oppure su sistemi diversi per aderire a specifiche esigenze architetturali nell’ambito della sicurezza e delle prestazioni. L’approccio modulare assicurerà all’Amministrazione ed all’impresa un’ampia scelta in termini di configurazione dei sistemi, ottemperando linee guida generali richieste.
• Scalabilità – condizione essenziale per i servizi implementati è che siano in grado di poter scalare sia in maniera verticale incrementando la potenza elaborativa, sia in modo orizzontale inserendo più sistemi.
• Affidabilità – i sistemi ed i servizi implementati dovranno far uso di meccanismi di alta affidabilità come le soluzioni in cluster.
• Sicurezza – l’architettura dovrà essere organizzata per livelli concentrici, suddivisi per sensibilità d’accesso in relazione alle diverse caratteristiche dei sistemi che ospita. Dovranno essere definiti almeno tre livelli: presentation, application logic, resource managment.
L' architettura HW da fornire presso il CEN di Napoli è costituita da:
• due server di Tipo A;
• sei server di fascia I (sottoparagrafo 4.4.1) adibiti all’ambiente di test/sviluppo e per la gestione del provisioning, monitoraggio e back-up;
• uno storage condiviso;
• due switch;
• armadi rack.
4.3.1 Server Centrale di Tipo A
Dovranno essere forniti due server in configurazione Cluster.
La seguente tabella riporta i requisiti HW minimali del singolo Server. Per ogni caratteristica è obbligatorio descrivere il valore offerto:
CARATTERISTICHE | VALORE RICHIESTO | VALORE OFFERTO |
Marca/Modello | Dichiarare il valore | |
ARCHITETTURA | ||
Struttura: | Rack Standard | |
Occupazione | 4 U | |
Sistema di raffreddamento | Il server dovrà essere dotato di ventole ridondate con funzionalità hot swap | |
Rack Unit occupate | Dichiarare il valore | |
ALIMENTAZIONE | ||
Alimentazione | Ciascun server dovrà essere dotato di stadio di alimentazione ridondato con funzionalità hot swap e dimensionato comunque per garantire i fabbisogni di potenza del server in condizioni di massima espansione. | |
Processore | ||
Tipo CPU | Dichiarare il valore | |
SMP processor Installati/core | 4 CPU/8 core | |
RAS | La CPU deve implementare una funzione di Machine Check Architecture (MCA) che sia in grado di gestire errori di sistema che altrimenti causerebbero il fermo del sistema. | |
Prestazioni | ||
SPECint_rate2006 BASE | ≥ 700 | |
SPECfp_rate2006 BASE | ≥ 540 | |
Memoria | ||
Memoria (RAM) Installata | ≥ 256 GB | |
Memoria (RAM) Max | 3 TB | |
Slot totali di RAM | Dichiarare il valore | |
Slot disponibili di RAM | Dichiarare il valore | |
Velocità RAM | Dichiarare il valore | |
Tipo RAM | Dichiarare il valore | |
ECC | Dichiarare il valore | |
Controller | ||
Interfacce di rete | 10 porte 1Gbps + 2 porte 10Gbps upgradabile a CNA | |
HBA | 2 schede 8Gbps dual port | |
Grafica | Dichiarare il valore | |
Sottosistema I/O – Slot | 7 slot totali | |
Disco Fisso | ||
Numero di dischi fissi installati | ≥ 2 | |
Capacità dischi fissi | ≥ 600 GB (ciascuno) | |
Scalabilità | ≥ 8 dischi |
CARATTERISTICHE | VALORE RICHIESTO | VALORE OFFERTO |
Tipo disco fisso installato | SAS hot swap | |
Controller disco fisso | Dichiarare il valore | |
Tipo RAID supportati | RAID 0,1 | |
Tipologia dischi supportati | Dichiarare il valore | |
Velocità rotazione hard disk | ≥ 10k rpm | |
Dispositivo ottico | ||
Tecnologia: | DVD-RW | |
Velocità: | Min 8x | |
Caricamento: | Dichiarare il valore | |
Monitoring e Management | ||
Funzioni di gestione | Monitoraggio e configurazione del sottosistema indipendentemente dallo stato acceso / spento del server; inclusi nella fornitura tutti i software, i driver e le utility necessarie. Il server deve poter essere gestito remotamente out- of-band tramite interfaccia 10/100Mbps dedicata. | |
Certificazioni | ||
Compatibilità certificata | VMware-Virtual Infrastructure | |
Sistemi Operativi supportati | VMWare ESX 4.x o successivo RedHat 5.x (incluso RHEV) o successivo Microsoft Windows 2008R2 (incluso Hyper-V) o successivo |
4.3.2 Storage Centrale
La seguente tabella riporta i requisiti HW minimali dello storage per il sito Centrale. Per ogni caratteristica è obbligatorio descrivere il valore offerto:
CARATTERISTICHE | VALORE RICHIESTO | VALORE OFFERTO |
Marca/Modello | Dichiarare il valore | |
Formato | Rack standard | |
Processore | ||
Numero processori | Dichiarare il valore | |
Dischi | ||
Spare Disk | Dichiarare il valore | |
Capacità singolo disco | 300 GB SAS oppure FC o superiori | |
Capacità totola richiesta lorda | 28 TB | |
Numero dischi | Dichiarare il valore | |
Min capacità supportata dalla Storage Area Network | 50 TB | |
Sottosistema I/O | ||
Connettività | FC | |
Nr. Host Collegabili | 32 |
CARATTERISTICHE | VALORE RICHIESTO | VALORE OFFERTO |
Memoria | ||
Cache | 4 GB | |
Alimentazione/Raffreddamento | ||
Alimentazione | Stadio di alimentazione ridondato con funzionalità hot swap e dimensionato comunque per garantire i fabbisogni di potenza in condizioni di massima espansione. Batteria tampone per alimentazione. | |
Sistema di raffreddamento | Il sistema dovrà essere dotato di ventole ridondate con funzionalità hot swap | |
Software | ||
Supporto ai seguenti Sistemi Operativi | Windows Server, Linux | |
Caratteristiche del sistema | ||
Caratteristiche | ||
Compatibilità certificata | VMware-Virtual Infrastructure |
4.3.3 Switch
Dovranno inoltre essere forniti due switch FC con almeno 24 porte a 8 Gbps ciascuno, di cui almeno 8 ciascuno già attive, comprensive di connettori SFP+ e cavi per connettere tutti i server e lo storage.
4.3.4 Armadi rack
Dovranno essere forniti appositi armadi rack da 19” con altezza massima 42U per le esigenze della fonitura (server, sistemi storage) presso il CEN di Napoli. Vengono di seguito riportate le caratteristiche tecniche minime richieste. Per ogni caratteristica è obbligatorio descrivere il valore offerto:
CARATTERISTICHE | VALORE RICHIESTO | VALORE OFFERTO | |||
Rack totali forniti | Numero necessario per l’intera fornitura | ||||
Caratteristiche generali | Intelaiatura interna atta a supportare pannelli e chassis normalizzati standard, con dimensioni di 482,5 mm (19”) di larghezza, e multipli di 44,5 mm (U – unit) in altezza | ||||
Dovrà essere dotato di parete posteriore asportabile, nonché di un ingresso posteriore passacavi o di una opportuna apertura posteriore con piastra di chiusura); dovranno inoltre essere forniti tutti i pannelli ciechi per le apparecchiature non presenti | |||||
Dovrà essere dotato di parete rimovibile, con serratura e chiave | anteriore | apribile | e | ||
Dovrà essere dotato di opportuni dispositivi per la messa a livello della struttura | |||||
Rack Unit disponibili | Almeno 42 RU | ||||
Console | kit estraibile (da rack) per alloggiamento tastiera e monitor LCD 17” o maggiore, ripiegabile a scomparsa comprensivo di tastiera e dispositivo di puntamento | ||||
Switch KVM | Si | ||||
Cavi di collegamento cablaggio | PDU e | Si |
4.4 Sistema Hardware presso le Questure
L' architettura HW da fornire presso le questure è composta da:
• 14 coppie di server di I fascia
• 91 coppie di server di II fascia
• 105 sistemi di storage
• armadi rack
• 1500 postazioni di lavoro.
4.4.1 Server di Questura di I Fascia
Dovranno essere forniti due server in configurazione Cluster.
La seguente tabella riporta i requisiti HW minimali del singolo Server. Per ogni caratteristica è obbligatorio descrivere il valore offerto:
CARATTERISTICHE | VALORE RICHIESTO | VALORE OFFERTO |
Marca/Modello | Dichiarare il valore | |
ARCHITETTURA | ||
Struttura: | Chassis 19” blade | |
Numero di server ospitabili | Almeno 6 | |
Sistema di raffreddamento | Lo chassis dovrà essere fornito di ventole ridondate con funzionalità hot swap in configurazione massima. | |
Rack Unit occupate | Dichiarare il valore | |
ALIMENTAZIONE | ||
Alimentazione | Ciascuno chassis dovrà essere dotato di alimentazione ridondata con funzionalità hot swap e dimensionato comunque per garantire i fabbisogni di potenza del server in condizioni di massima espansione. | |
Dispositivo ottico | ||
Tecnologia: | DVD-RW | |
Velocità: | Min 8x | |
Caricamento: | Dichiarare il valore | |
Server Blade | ||
Tipo CPU | Dichiarare il valore | |
SMP processor Installati/Core | 2 CPU/6 Core per ciascuna CPU | |
SMP processor MAX | 2 CPU | |
Prestazioni | ||
SPECint_rate2006 BASE | ≥ 315 | |
SPECfp_rate2006 BASE | ≥ 230 | |
Memoria | ||
Memoria (RAM) Installata | ≥ 24 GB | |
Memoria (RAM) Max | 192 GB | |
Slot totali di RAM | Dichiarare il valore |
CARATTERISTICHE | VALORE RICHIESTO | VALORE OFFERTO |
Slot disponibili di RAM | Dichiarare il valore | |
Velocità RAM | Dichiarare il valore | |
Tipo RAM | Dichiarare il valore | |
ECC | Dichiarare il valore | |
Controller | ||
Interfacce di rete | 4 porte 1Gbps | |
HBA | 2 porte da almeno 3Gbps | |
Grafica | Dichiarare il valore | |
Sottosistema I/O – Slot | 2 slot totali | |
Disco Fisso | ||
Numero di dischi fissi installati | 2 dischi SAS da 146GB 10K rpm in RAID1 | |
Capacità dischi fissi | dischi SAS da 146GB in RAID1 | |
Tipo disco fisso installato | SAS hot swap | |
Controller disco fisso | Dichiarare il valore | |
Tipo RAID supportati | RAID 0,1 | |
Tipologia dischi supportati | Dichiarare il valore | |
Velocità rotazione hard disk | ≥ 10K rpm | |
Monitoring e Management | ||
Funzioni di gestione | Il server deve poter esere gestito remotamente out- of-band tramite interfaccia 10/100Mbps dedicata, e Console grafica remota | |
Eco sostenibilità | ||
Consumo del server | Dichiarare il consumo energetico annuo in KW/h | |
Certificazioni | ||
Compatibilità certificata | VMware-Virtual Infrastructure | |
Sistemi Operativi supportati | VMWare ESX 4.x o successivo RedHat 5.x (incluso RHEV) o successivo Microsoft Windows 2008R2 (incluso Hyper-V) o successivo |
4.4.2 Server di Questura di II Fascia
Dovranno essere forniti due server in configurazione Cluster.
La seguente tabella riporta i requisiti HW minimali del singolo Server. Per ogni caratteristica è obbligatorio descrivere il valore offerto:
CARATTERISTICHE | VALORE RICHIESTO | VALORE OFFERTO |
Marca/Modello | Dichiarare il valore | |
ARCHITETTURA | ||
Struttura: | Chassis 19” blade | |
Numero di server ospitabili | Almeno 6 | |
Sistema di raffreddamento | Lo chassis dovrà essere fornito di ventole ridondate con funzionalità hot swap in configurazione massima. | |
Rack Unit occupate | Dichiarare il valore | |
ALIMENTAZIONE | ||
Alimentazione | Ciascuno chassis dovrà essere dotato di alimentazione ridondata con funzionalità hot swap e dimensionato comunque per garantire i fabbisogni di potenza dello chassis in condizioni di massima espansione. | |
Dispositivo ottico | ||
Tecnologia: | DVD-RW | |
Velocità: | Min 8x | |
Caricamento: | Dichiarare il valore | |
Server Blade | ||
Tipo CPU | Dichiarare il valore | |
SMP processor Installati/Core | 1 CPU/6 Core per ciascuna CPU | |
SMP processor MAX | 2 CPU | |
Prestazioni | ||
SPECint_rate2006 BASE | ≥ 155 | |
SPECfp_rate2006 BASE | ≥ 113 | |
Memoria | ||
Memoria (RAM) Installata | ≥ 12 GB | |
Memoria (RAM) Max | 192 GB totali con 2 CPU installate | |
Slot totali di RAM | Dichiarare il valore | |
Slot disponibili di RAM | Dichiarare il valore | |
Velocità RAM | Dichiarare il valore | |
Tipo RAM | Dichiarare il valore | |
ECC | Dichiarare il valore | |
Controller | ||
Interfacce di rete | 4 porte 1Gbps | |
HBA | 2 porte da almeno 3Gbps | |
Grafica | Dichiarare il valore | |
Sottosistema I/O – Slot | 2 slot totali | |
Disco Fisso | ||
Numero di dischi fissi installati | 2 dischi SAS da 146GB 10K rpm in RAID1 |
CARATTERISTICHE | VALORE RICHIESTO | VALORE OFFERTO |
Capacità dischi fissi | dischi SAS da 146GB in RAID1 | |
Tipo disco fisso installato | SAS hot swap | |
Controller disco fisso | Dichiarare il valore | |
Tipo RAID supportati | RAID 0,1 | |
Tipologia dischi supportati | Dichiarare il valore | |
Velocità rotazione hard disk | ≥ 10K rpm | |
Monitoring e Management | ||
Funzioni di gestione | Il server deve poter esere gestito remotamente out- of-band tramite interfaccia 10/100Mbps dedicata, e Console grafica remota. | |
Eco sostenibilità | ||
Consumo del server | Dichiarare il consumo energetico annuo in KW/h | |
Certificazioni | ||
Compatibilità certificata | VMware-Virtual Infrastructure | |
Sistemi Operativi supportati | VMWare ESX 4.x o successivo RedHat 5.x (incluso RHEV) o successivo Microsoft Windows 2008R2 (incluso Hyper-V) o successivo |
Si precisa che:
• devono essere forniti anche tutti i dispositivi switch nello chassis per accedere alla LAN in maniera ridondata;
• devono essere forniti anche tutti i dispositivi necessari all'accesso alla SAN in maniera ridondata;
• devono essere forniti anche i rack atti ad ospitare la soluzione proposta e tutti i dispositivi per il corretto funzionamento/controllo della soluzione proposta (KVM, PDU, cavi di collegamento elettrico, ecc.). Saranno oggetto di valutazione migliorativa quelle soluzioni rack che ottimizzino gli ingombri complessivi della soluzione proposta;
• è possibile fornire la SAN integrata nello chassis Blade;
• il CD/DVD può essere parte dello chassis blade;
• la gestione remota può appartenere all'intero chassis;
• l’alimentazione e raffreddamento può essere centralizzato a livello di chassis.
4.4.3 Storage condiviso per cluster
La seguente tabella riporta i requisiti HW minimali dello storage per il server distribuito.
CARATTERISTICHE | VALORE RICHIESTO | VALORE OFFERTO |
Marca/Modello | Dichiarare il valore | |
Formato | Rack standard | |
Controller interni hot swap | ||
Numero controller | 2 | |
Dischi | ||
Spare Disk | 1 | |
Capacità singolo disco | 300 GB SAS oppure FC | |
Nr. Dischi | 4 configurabili raid 5 | |
Min capacità supportata dalla Storage Area Network | 12 TB | |
Sottosistema I/O | ||
Connettività | SAS oppure FC | |
Nr. Host Collegabili | ≥ 6 | |
Memoria | ||
Cache | 2GB totali | |
Alimentazione/Raffreddamento | ||
Alimentazione | Stadio di alimentazione ridondato con funzionalità hot swap e dimensionato comunque per garantire i fabbisogni di potenza in condizioni di massima espansione. Batteria tampone per alimentazione cache. Nel caso la SAN sia integrata allo chassis , fare riferimento alla sezione chassis. | |
Sistema di raffreddamento | Il sistema dovrà essere dotato di ventole ridondate con funzionalità hot swap. Nel caso la SAN sia integrata allo chassis , fare riferimento alla sezione chassis. | |
Software | ||
Supporto ai seguenti Sistemi Operativi | Windows Server, Linux, VMware | |
Caratteristiche del sistema | ||
Compatibilità certificata | VMware-Virtual Infrastructure |
4.4.4 Postazioni Operatore
Dovranno essere fornite postazioni operatore con le seguenti caratteristiche minime:
CARATTERISTICHE | VALORE RICHIESTO MINIMO | VALORE OFFERTO |
MARCA/ MODELLO | Dichiarare il valore | |
PRESTAZIONI | ||
PROCESSORE | multi-Core, 8 MB di cache L2 | |
Benchmark BAPCO SysMark 2007 Preview Rating | >= 170 | |
MEMORIA | ||
Memoria installata | 8 GB | |
Tipo RAM | Dichiarare il valore | |
Memoria Max | 24 GB | |
HD | ||
Capacità disco fìsso | 250 GB SATA 7200 rpm | |
SOTTOSISTEMA GRAFICO | ||
Scheda grafica doppia uscita | 1 GB dedicato | |
MONITOR (DUE PER CIASCUNA WORKSTATION) | ||
MARCA/ MODELLO | Dichiarare il valore | |
Tipo | Display LCD | |
Dimensione | 21" diagonale | |
Tipo risoluzione | Dichiarare il valore | |
Pixel pitch | 0,27 mm | |
rapporto di contrasto standard | 1000:1 | |
Luminosità | 250 cd/m2 | |
I/O | ||
Tastiera | USB Standard | |
Dispositivo puntamento | Mouse a scorrimento laser USB | |
Unità Ottica | DVD R | |
Audio | Integrata High Definition (HD) Audio, Analog Devices AD1988A codec | |
Scheda di rete | LAN PCIe Broadcom /intel 10/100/1000, | |
Porte esterne | Non richieste | |
Slot espansione | Non Richieste | |
SOFTWARE | ||
Sistema operativo | Windows 7 |
4.5 Software di system management
Al CEN di Napoli è utilizzato il prodotto HP Open View. L’impresa deve fornire le licenze di questo prodotto per il monitoraggio dei sistemi proposti sia periferici che centrali.
Tale SW deve essere in grado di:
• gestire server fisici e virtuali da una unica console tramite browser;
• gestire di dispositivi storage e di rete;
• integrarsi con VMWare vCenter;
• gestire dispositivi via SNMP;
• gestire server virtuali;
• monitorare i consumi elettrici ;
• gestire in modalità centralizzata gli aggiornamenti del SW.
Sarà cura del fornitore individuare i moduli necessari e quantificare il numero delle licenze sulla base dell’infrastruttura proposta.
4.6 Software di base e d’ambiente
Dovrà essere fornito il software di base e d'ambiente necessario al corretto funzionamento dei sistemi e degli applicativi. Rientrano in tale tipologia di prodotti il sistema operativo, il Data Base Management System, il software di virtualizzazione ed ogni altro software ritenuto necessario dall’Impresa per il corretto funzionamento del sistema informativo ad eccezione del software antivirus.
I prodotti offerti dovranno essere conformi agli standard, di ampia e consolidata diffusione ed in particolare il sistema operativo utilizzato dovrà essere dotato di caratteristiche di multitasking, multiutenza, journaling, mentre il sistema di gestione di base di dati (DBMS), dovrà essere di tipo relazionale e conforme allo standard ANSI DATABASE SQL per l’accesso ai dati.
Il database Centrale dovrà essere di tipo Oracle Database, IBM DB2 o Microsoft SQL Server mentre è lasciata libera la scelta del DBMS da installare nei server di Questura purché l’impresa produca dettagliata documentazione sulla modalità dell’allineamento/replica con il Database centrale.
Le licenze d’uso dei prodotti software di base e d’ambiente devono intendersi illimitate in termini di tempo e per un numero di utenti sufficiente a coprire le esigenze dell’Amministrazione.
4.7 Software Backup
Dovrà essere integrato in termini di licenze l’attuale piattaforma di Backup presente al CEN di Napoli e pertanto dovrà essere fornita la piattaforma di Symantec NetBackup.
Nella tabella seguente sono riportati i prodotti e la modalità di licensing:
DESCRIZIONE | VERSIONE | CODICE |
SYMC NETBACKUP PLATFORM BASE 7.1 XPLAT 1 FRONT END TBYTE STD LIC GOV BAND S | 7.1 | 08CMXZF0-ZZZGS |
SYMC NETBACKUP PLATFORM BASE 7.1 XPLAT 1 FRONT END TBYTE INITIAL ESSENTIAL 12 MONTHS GOV BAND S | 7.1 | 08CMXZZ0-EI1GS |
Il dimensionamento dovrà essere basato sulla disponibilità di 1.2 TB row per ciascuna delle 105 sedi periferiche dedicati ai cluster di database da sottoporre a backup, e quantificabile in circa 106 TeraByte totali.
4.8 Software Virtualizzazione
Dovrà essere fornito il prodotto VMware, per le 14 Questure di Fascia I con le seguenti configurazioni:
Configurazione singola Questura Fascia I | ||
Part number | Description | Q.ty |
VCS5-FND-C | VMware vCenter Server 5 Foundation for vSphere up to 3 hosts (Per Instance) | 1 |
VCS5-FND-P-SSS-C | Production Support/Subscription for vCenter Server 5 Foundation for vSphere 5 | 2 |
VS5-ENT-PL-C | VMware vSphere 5 Enterprise Plus for 1 processor (with 96 GB vRAM entitlement per processor) | 4 |
VS5-ENT-PL-P-SSS-C | Production Support/Subscription for VMware vSphere 5 Enterprise Plus for 1 processor for 1 year | 8 |
VC-OENT-VM-C | VMware vCenter Operations Enterprise Standalone License per Managed Virtual Machine | 2 |
VC-OENT-VM-P-SSS- C | Production Support/Subscription for VMware vCenter Operations Enterprise Pack Standalone License per Managed Virtual Machine | 4 |
Dovrà essere fornito il prodotto VMware, per le 91 Questure di Fascia II con le seguenti configurazioni:
Configurazione singola Questura Fascia II | ||
Part number | Description | Q.ty |
VCS5-FND-C | VMware vCenter Server 5 Foundation for vSphere up to 3 hosts (Per Instance) | 1 |
VCS5-FND-P-SSS-C | Production Support/Subscription for vCenter Server 5 Foundation for vSphere 5 | 2 |
VS5-ENT-PL-C | VMware vSphere 5 Enterprise Plus for 1 processor (with 96 GB vRAM entitlement per processor) | 2 |
VS5-ENT-PL-P-SSS-C | Production Support/Subscription for VMware vSphere 5 Enterprise Plus for 1 processor for 1 year | 4 |
VC-OENT-VM-C | VMware vCenter Operations Enterprise Standalone License per Managed Virtual Machine | 2 |
VC-OENT-VM-P-SSS- C | Production Support/Subscription for VMware vCenter Operations Enterprise Pack Standalone License per Managed Virtual Machine | 4 |
4.9 Provisioning automatico del software
4.9.1 Descrizione del servizio
Per servizio di provisioning automatico del software s’intende la distribuzione remota applicata ad ogni tipologia di software, sia esso di sistema che applicativo, che appartenga o meno alla configurazione standard delle apparecchiature definita nel presente capitolato. In questo servizio ricadono sia le attività di applicazione di una “fix” risolutiva di un malfunzionamento, sia il rilascio di nuove versioni del software, conseguenti ad un aggiornamento tecnologico generalizzato o specifico di una classe funzionale. Il servizio potrà anche essere necessario per la distribuzione di dati nel caso, ad esempio, di file di configurazione, di file utente o di file per prodotti antivirus.
4.9.2 Requisiti
Per tale servizio, è responsabilità del fornitore la realizzazione di un sistema di provisioning automatico del software che garantisca almeno le seguenti caratteristiche:
• consentire di aggiornare remotamente il software di tutti i sistemi periferici del sistema “nuovo SCT”, sia server che workstation, secondo piani di distribuzione definibili dall'Amministrazione;
• che preveda sia la modalità di provisioning forzata dal centro (modalità “push”) sia offrire agli amministratori del sistema la possibilità di autorizzare gli utenti a installare e rimuovere determinati applicativi e pacchetti software (modalità di aggiornamento “pull”);
• consentire la gestione automatica delle patch di sistema operativo sia dei server che delle workstation (patch management);
• fornire un immediato aggiornamento dei dati di inventario relativo alla configurazione software delle apparecchiature aggiornate mediante le distribuzioni;
• fornire la funzionalità di reportistica in tempo reale sullo stato delle distribuzioni del software, siano esse patch di sistema oppure software applicativo;
• consentire la funzione di rollback in caso di aggiornamento non andato a buon fine. La funzione di rollback dovrà essere selettiva, ovvero riguardare solo quei sistemi per cui la distribuzione sia effettivamente fallita.
Il sistema di provisioning automatico dovrà garantire la possibilità di distribuzione "Fan-Out/Multi- Hop" che permette ai server remoti di agire come punti di distribuzione per le loro reti locali, migliorando l'efficacia del processo di distribuzione. Più specificatamente il pacchetto destinato a più workstation attestati al nodo di Fan-Out (es. server ubicato in una Questura) dovrà essere mandato una volta sola dal server di provisioning automatico centralizzato al nodo di Fan-Out, il quale a sua volta lo indirizzerà a tutte le stazioni destinatarie (workstation collegati alla LAN della Questura). Saranno considerati elementi qualificanti della soluzione la disponibilità di meccanismi nativi che minimizzino problemi causati dalla latenza elevata e dalla scarsa larghezza di banda delle reti e la disponibilità della funzione di checkpoint/restart delle distribuzioni. Inoltre, altro elemento qualificante della soluzione è la disponibilità di meccanismi di alta disponibilità del provisioning automatico (quale hot failover).
5 SERVIZI TECNICI
Oltre alla fornitura delle tecnologie devono essere espressamente previsti i servizi tecnici per:
1. Assistenza sistemistica e manutenzione hardware della piattaforma attuale presso tutte le Questure e supporto del sistema di certification authority nella sede di Spinaceto fino alla migrazione sulla nuova architettura.
2. Migrazione, conversione e centralizzazione (presso il CEN di Napoli) di tutti i moduli “as is” su piattaforma x86 ad esclusione del modulo “Sala Operativa”; porting del modulo “Sala Operativa” su piattaforma x86 di Questura per la gestione in real time di tale funzionalità come richiesto nel capitolo 4.
3. Recupero dei dati di esercizio e storici e porting degli stessi dai database di Questura ai nuovi DBMS Centrale e periferici.
4. Servizi necessari per l’installazione e messa in funzione delle tecnologie offerte e delle procedure applicative su tutte le Questure e la sede centrale di Napoli.
5. Manutenzione e gestione dell’applicativo “nuovo SCT” sulla nuova architettura per minimo 12 mesi.
6. Manutenzione evolutiva a consumo di 2000 punti funzione.
7. Formazione per la conduzione sistemistica ed operativa a livello centrale del personale dell’Amministrazione.
Nei successivi paragrafi le specifiche dei servizi richiesti.
5.1 Manutenzione hw e assistenza sistemistica sul sistema SCT attuale e SLA
Per assicurare la corretta migrazione al nuovo sistema SCT è necessario, in parallelo, tutelare il corretto funzionamento delle attuali componenti tecnologiche, tramite la realizzazione delle seguenti attività per una durata massima di 24 mesi:
▪ Assistenza sistemistica a supporto dell’attuale utenza del sistema SCT;
▪ Assistenza sistemistica sull’attuale Database;
▪ Assistenza sulla Certification Autority di Xxxxxxxxx (RM);
▪ Manutenzione attuali Server Aix e relativo storage.
E’ ovviamente esclusa l’assistenza applicativa dell’attuale sistema SCT.
5.1.1 Livelli di criticità e SLA
Vengono di seguito definiti i seguenti stati di criticità relativamente alla funzionalità del sistema:
1. Guasto Bloccante malfunzione sia hardware che software (di base e d’ambiente) che rende non utilizzabili una o più funzionalità disponibili all’operatore di Sala Operativa;
2. Guasto non bloccante malfunzione che, pur impedendo l’uso delle funzioni software, non inibisce l’operatività da parte dell’utente; l’utente può cioè ugualmente pervenire ai risultati attesi mediante l’utilizzo di altre funzionalità comunque offerte dal sistema.
Livelli di servizio (SLA)
Le chiamate dalle sedi periferiche verranno ricevute dal personale dell’Amministrazione ed inoltrate al personale del Committente attraverso notifica telefonica, e-mail e/o fax.
Il servizio (su server, dischi, DB) deve essere dimensionato per risolvere la criticità secondo quanto indicato e riferito alla presa in carico del problema segnalato dall’Amministrazione e rilevati su base bimestrale, con i seguenti tempi di ripristino calcolati dal momento di richiesta d’intervento:
1. disservizi di tipo “bloccante”:
12h lavorative nel 90% dei casi 24h lavorative nel 10% dei casi
2. disservizi di tipo “non bloccante”:
10gg solari nel 95% dei casi 14gg solari nel 5% dei casi
Per quanto concerne l’assistenza sistemistica e database, la sede di erogazione del servizio sarà in prevalenza il CMT di Spinaceto ma, in caso di necessità per garantire la funzionalità del sistema dovranno essere effettuati interventi on-site presso le sale macchine delle Questure.
Per quanto concerne le manutenzioni hardware, il servizio verrà prestato on-site.
L’Amministrazione attiverà il servizio di help-desk di I livello. L’impresa deve attivare il servizio di Help-desk di II livello tramite un numero telefonico ed uno di fax per la ricezione delle richieste (numero/i Verde gratuito/i per il chiamante) con copertura oraria dalle ore 08.00 alle ore 18:00 esclusi sabati e festivi che dovrà:
• raccogliere le segnalazioni di guasti hardware, problematiche sistemistiche, DB;
• risolvere le segnalazioni di guasto (mediante tele-assistenza ove possibile dalla sede di Spinaceto);
• pianificare la logistica degli interventi;
• verificare la risoluzione degli interventi;
• gestire un apposito software di tracciamento delle richieste, degli interventi e delle chiusure consultabile on-line anche da personale dell’Amministrazione;
• fornire i report di attività al Responsabile dell’Amministrazione al fine di verificare i livelli di servizio.
5.1.2 Figure professionali
La proposta prevede il supporto sistemistico alla Sale Operative mediante le figure professionali di seguito descritte:
▪ Sistemista AIX senior per le tematiche degli attuali Server;
▪ Esperto Lotus Notes;
▪ Consulente specialista senior – DB2 per le tematiche di tuning e supporto DB per le attuali Sale Operative.
5.1.3 Dimensionamento
Nel corso dell’ultimo anno sono state gestite:
▪ 500 richieste per guasti non bloccanti;
▪ 150 ticket per guasti bloccanti la cui risoluzione ha richiesto l’intervento di un sistemista/DBA specializzato.
Si richiede l’erogazione del servizio per la manutenzione dei server UNIX e dei dischi, la cui tipologia è riportata nello schema seguente:
Apparato | Tipo macchina | Modello | Qtà |
SERVER | 7026 | 6H1 | 100 |
7026 | H70 | 32 | |
7026 | H80 | 36 | |
9113 | 550 | 20 | |
9131 | 52A | 2 | |
8203 | E4A | 16 | |
Totale | 206 | ||
DISCHI | 7133 | X00 | 00 |
0000 | X00 | 18 | |
Totale | 103 |
Tali server e dischi sono installati nelle 103 sale apparati dislocate presso le Questure.
L’impresa dovrà fornire dettagliate informazioni sull’organizzazione del servizio, sulle figure professionali impiegate, sulle modalità di gestione.
5.1.4 Penali
Le penali applicabili in caso di ritardata esecuzione delle attività relativamente agli SLA definiti nei sottoparagrafi 6.1.1:
a) disservizi bloccanti
penale di €. 250,00 per ogni ora lavorativa di ritardo
b) disservizi non bloccanti
penale di €. 500,00 per ogni giorno lavorativo di ritardo
5.2 Migrazione e conversione delle applicazioni
La classe di fornitura “migrazione e conversione delle applicazioni software” (come definita da DigitPA nella relativa classe di fornitura) si compone dei seguenti elementi:
• servizio di migrazione dei dati dal DBMS attuale al DBMS proposto;
• servizio di conversione delle applicazioni che consiste nella trasformazione di prodotti software completi (costituiti cioè dal software applicativo SCT e da tutte le componenti ad esso correlato) dalla piattaforma tecnologica attuale a quella richiesta basata su un’architettura x86, lasciando inalterate tutte le funzionalità dell’applicazione di partenza nel rispetto di quanto richiesto nel capitolo 4.
Si devono lasciare inalterati i requisiti di carattere funzionale del sistema. Fanno eccezione a questa regola i requisiti funzionali che si riferiscono a caratteristiche prestazionali che, a fronte del processo di migrazione / conversione, potrebbero risultare migliorati. E’ richiesta la realizzazione di funzioni di “help” e di documentazione on-line per l’assistenza agli operatori.
Nelle successive tabelle “Matrice di Responsabilità Attività – Profilo di competenza” è indicata per ciascun profilo di competenza, responsabile (R) o contributore tipico (Ct), un’ipotesi di massima del suo impegno (quantità di lavoro, “effort” ) nell’attività. Tale impegno è espresso come percentuale, fatto 100 l’impegno totale richiesto dall’attività, ed è quindi una stima del “peso” relativo del profilo di competenza nell’esecuzione dell’attività.
L’impresa dovrà proporre le proprie tabelle indicando anche l’eventuale utilizzo di strumenti automatici di conversione, e analogamente l’eventuale scelta di sviluppare/adottare strumenti automatici per ridurre gli interventi manuali, che modificano il peso relativo dei diversi profili professionali.
L’impresa deve esporre come si intendono effettuare le attività richieste ed in particolare si richiede di descrivere dettagliatamente i seguenti punti:
• Architettura applicativa proposta per la migrazione e conversione in particolare:
o la tecnologia proposta per il livello di GUI (“presentation logic”)
o la tecnologia proposta per il livello di “logica di business” centralizzata
o Il modello di interazione proposto tra Xxxxxxxx e Centro
o Soluzione proposta per la gestione del modulo” Sala Operativa” dal CEN di Napoli in casi di indisponibilità del server di Questura
o Affidabilità e scalabilità.
• Eventuale riuso delle applicazioni esistenti, evidenziando le modalità con cui avviene tale riuso.
• Soluzione proposta per effettuare il rollout presso le Questure indicando in particolare:
o Soluzione proposta per la migrazione/sincronizzazione dati
o Gli impatti logistici e organizzativi.
• Il sistema di profilazione e gestione utenze proposto.
• Sistema di provisioning automatico del software proposto.
.
TABELLA MATRICE DI RESPONSABILITA’ ATTIVITA’ – PROFILO DI COMPETENZA CONVERSIONE APPLICAZIONI
Profilo competenza | di | Analisi dei requisiti | Progett. tecnica conversione | Progett. applicativa conversione | Progett. Test e Collaudo | Realizzazione conversione | Predisp. del sistema | Produzione della document. | Qualific. finale | Xxxxxxxx | Xxxxxx. | |
Consulente per Vendita l’Applicazione Tecnologie Informatiche | la e di | Ct 10% | ||||||||||
Analista Programmatore | Ct | 70% | Ct | 10% | ||||||||
Tecnico di Collaudo e Integrazione di Sistemi | R 100% | R 100% | R 100% | R 100% | R 90% | |||||||
Progettista di Sistemi Informatici | R 90% | R 80% | R 80 % | R 15% | Ct | 10% | ||||||
Responsabile della Configurazione e del Centro Dati | R 80% | |||||||||||
Sistemista | Ct 20% | Ct 20% | Ct 15% | Ct | 10% | |||||||
% di effort - totale | 100% | 100% | 100% | 100% | 100% | 100% | 100% | 100% | 100% | 100% |
TABELLA MATRICE DI RESPONSABILITA’ ATTIVITA’ – PROFILO DI COMPETENZA MIGRAZIONE DEI DATI
Profilo competenza | di | Analisi requisiti | dei | Progettazione tecnica migrazione | Progettazione applicativa migrazione | Progettazione Test e Collaudo | Realizzazione migrazione | Predisposizione del sistema | Qualificazione finale | Collaudo | |
Consulente per Vendita l’Applicazione Tecnologie Informatiche | la e di | Ct | 10% | ||||||||
Analista Programmatore | Ct | 20% | |||||||||
Tecnico Collaudo Integrazione Sistemi | di e di | R 100% | R 100% | R 100% | R 90% | ||||||
Responsabile Basi di Dati | di | R 90% | R 100% | R 100% | R 80% | Ct | 10% | ||||
% di effort - totale | 100% | 100% | 100% | 100% | 100% | 100% | 100% | 100% |
5.2.1 Dimensionamento
Sarà cura del fornitore effettuare il conteggio dei function point alla fine dell’attività di conversione e centralizzazione che costituiranno la base line del “nuovo SCT”.
Il conteggio delle dimensioni in Punti Funzione dovrà essere effettuata da persona certificata IFPUG secondo le modalità di conteggio definite dal IFPUG secondo l’ultima versione rilasciata. L’impresa dovrà fornire tutta la documentazione tecnica di riferimento.
5.3 Recupero dati storici
Tali servizi comprendono tutte le attività tecniche necessarie ad effettuare il recupero dei dati dagli attuali DBMS delle Questure ai nuovi DBMS Centrale e periferici.
I servizi di migrazione si articolano nelle seguenti macro attività:
❑ presa in carico tecnica delle basi dati esistenti;
❑ definizione del modello di migrazione;
❑ migrazione dei dati sul nuovo ambiente, con conseguente eliminazione di errori/ridondanze;
❑ certificazione equivalenza dei dati migrati sul nuovo DBMS.
5.4 Installazione e messa in funzione “nuovo SCT”
I servizi per l’installazione delle tecnologie offerte comprendono tutte le attività necessarie per installare le tecnologie (server, storage, postazioni lavoro, software di base e d’ambiente, dispositivi, ecc..) e per l’installazione e messa in esercizio delle procedure applicative offerte.
L’attivazione dell’intero sistema deve essere completata, presso la sede centrale e presso tutte le Questure in ogni sua componente, entro il limite non derogabile di 24 mesi solari dalla data di inizio attività.
L’impresa deve valutare la compatibilità del predetto valore (24) mesi con la propria capacità organizzativa proponendo il valore richiesto o migliorativo. In quest’ultimo caso, in cui la messa in esercizio sia completata prima del massimo richiesto di 24 mesi, il servizio di conduzione, assistenza e manutenzione del “nuovo SCT”, come specificato nel successivo paragrafo 5.5, deve essere erogato fino al raggiungimento del termine contrattuale nel rispetto degli SLA offerti.
Le attività di installazione e messa in funzione del sistema “nuovo SCT”, sono comprensive di ogni onere relativo ad imballaggio, trasporto, facchinaggio, consegna “al piano”, posa in opera, installazione delle apparecchiature e delle opzioni, verifica della funzionalità delle apparecchiature, asporto dell’imballaggio e qualsiasi altra attività ad esse strumentale.
Sono ivi comprese le attività necessarie per installare e configurare tutti i programmi, effettuare la relativa parametrizzazione con l’introduzione delle codifiche di base, delle strutture operative, degli utenti, la definizione dei profili utente per l’applicazione delle politiche degli accessi, l’installazione delle postazioni lavoro, l’apporto di eventuali personalizzazioni sulla base delle esigenze dell’ Amministrazione, ed in generale ogni altra attività necessaria per mettere in linea il sistema e renderlo fruibile dagli utenti nei tempi richiesti nel presente capitolato di gara.
Le attività relative sono, in via indicativa ma non esaustiva, le seguenti:
• Popolamento dei dati relativi alle utenze presso LDAP di Questura
• Migrazione completa dei dati relativi all’attuale applicazione SCT in uso sui nuovi DBMS centrale e periferici
• Un adeguato periodo di funzionamento dell’applicazione attuale in modalità operativa e di quella migrata in modalità test
• Minimizzazione dell’impatto in termini di tempo e aspetti logistici.
E’ richiesta una descrizione dettagliata delle modalità con cui vengono garantite le caratteristiche sopra elencate, i tempi necessari, le fasi e gli impatti logistici ed eventuali soluzioni per ridurre al minimo la perdita di dati riattivando l’applicazione attuale e la relativa banca dati qualora ci fossero problemi con quella migrata. Si evidenzia che per le attività di cui sopra in nessuna Questura è assicurata la possibilità di installare i nuovi sistemi in parallelo a quelli attuali.
E’ a carico del fornitore il ritiro e lo smaltimento a norma di legge delle apparecchiature delle Questure (postazioni operatore, server, storage).
5.4.1 Penali
Ogni giorno di ritardo rispetto a quanto definito nell’offerta per l’approntamento al collaudo del sistema funzionante relativamente alla prima Questura ed al sistema Centrale, così come ogni giorno di ritardo rispetto a quanto definito nell’offerta per il completamento dell’installazione presso tutte le Questure, comporterà l’applicazione di una penale corrispondente all’1 per 1000 del valore dell’offerta economica complessiva, per ogni Questura di cui non è stata dichiarato l’approntamento al collaudo.
5.5 Manutenzione e gestione “nuovo SCT” e SLA
Per la gestione di tutti i servizi tecnici relativi alla manutenzione delle apparecchiature ed applicativi ed in generale di tutte le chiamate di assistenza deve essere previsto un unico punto di accesso al quale tutti gli utenti si rivolgeranno per le segnalazioni degli eventuali malfunzionamenti di qualunque natura (apparecchiature, applicativi, ecc..).
Il servizio di gestione, assistenza e manutenzione del sistema “nuovo SCT” decorrerà dal collaudo positivo del sistema e si concluderà al raggiungimento del termine contrattuale.
Sarà premiante la fornitura del servizio di manutenzione, così come definito in tutte le sue componenti nel presente paragrafo, oltre il minimo richiesto.(Rif. tabella: valutazione della qualità della soluzione, voce E).
Le apparecchiature oggetto dell’appalto devono essere garantite con gli SLA di intervento richiesti per la durata del contratto e comprendono le attività tecniche che l’Impresa, attraverso le proprie risorse tecnologiche e le proprie risorse umane, si obbliga ad effettuare allo scopo di garantire il regolare funzionamento di tutte le apparecchiature fornite e costituenti il nuovo sistema SCT offerto (server, dispositivi, ..) e relativo ripristino delle funzionalità in caso di segnalati malfunzionamenti.
Tutte le richieste di intervento devono essere opportunamente monitorate e rendicontate mediante appositi strumenti informatizzati forniti dall’Impresa che prevedano la gestione di tutti i dati necessari a consentire all’Amministrazione la verifica diretta del rispetto delle clausole contrattuali.
E’ necessario illustrare dettagliatamente le competenze e l’organizzazione del gruppo tecnico che verrà preposto alla gestione del “nuovo SCT”, descrivendo nel dettaglio l’organizzazione, le procedure e le risorse impiegate.
Nei successivi paragrafi sono dettagliate, in via indicativa ma non esaustiva, le modalità di erogazione dei singoli servizi con le prescrizioni minime richieste.
5.5.1 Requisiti di qualità livelli di servizio
Vengono di seguito definiti i seguenti stati di criticità relativamente alla funzionalità del sistema:
1. Guasto Bloccante: malfunzione sia hardware che software che rende non utilizzabili le funzionalità disponibili all’operatore di Sala Operativa.
2. Guasto non bloccante: malfunzione che, pur impedendo l’uso delle funzioni software, non inibisce l’operatività da parte dell’utente; l’utente può cioè ugualmente pervenire ai risultati attesi mediante l’utilizzo di altre funzionalità comunque offerte dal sistema.
3. Anomalia: una o più funzioni non operano correttamente.
Livelli di servizio (SLA)
L’offerente deve attivare il servizio di Help-desk (I e II livello) con proprie risorse umane e tecnologiche con copertura oraria H24, 7 giorni su 7 per almeno 12 mesi solari che dovrà operare in ottica Customer Satisfaction svolgendo:
• Un’informazione corretta e tempestiva;
• Il supporto immediato al primo contatto sui problemi segnalati;
• La fornitura di indicazioni dei tempi previsti per la risoluzione;
• La verifica puntuale della soddisfazione degli utenti sulle modalità di intervento e di risoluzione.
Il servizio di Help Desk di I livello dovrà perseguire i seguenti obiettivi:
• assicurare la comunicazione tempestiva ed efficace tra l’utenza e le strutture di supporto e viceversa;
• provvedere alla raccolta delle segnalazioni di guasti hardware e software;
• provvedere alla raccolta e registrazione delle richieste di assistenza;
• garantire il monitoraggio per la prevenzione di problemi, supportare le operazioni di complessità non elevata;
• smistare alle strutture di assistenza specifiche la risoluzione dei problemi non risolvibili nell’ambito di questo servizio;
• scalare le segnalazioni e le richieste al secondo livello d’intervento gestendone tutto l’iter fino alla chiusura mediante verifica finale;
• nel caso di guasti bloccanti, oltre ad attivare il tecnico specializzato nell’orario di reperibilità telefonica, deve avvisare anche il responsabile dell’Amministrazione;
• pianificare la logistica degli interventi;
• verificare la risoluzione degli interventi;
• gestire un apposito software di tracciamento delle richieste, degli interventi, delle chiusure consultabile on-line anche da personale dell’Amministrazione;
• fornire i report di attività al Responsabile dell’Amministrazione al fine di verificare i livelli di servizio.
Dovranno essere garantiti i seguenti livelli minimi di servizio:
1) Risposta entro 30”, per l’80% delle chiamate ricevute.
2) Percentuale di chiamate perdute non superiore al 4%.
Le Richieste devono poter essere inoltrate con le seguenti modalità:
• Numeri Telefonici (numeri gratuiti)
• Fax (numeri gratuiti)
Dovranno essere espressamente esplicitate le modalità di erogazione del servizio relativo al supporto tecnico agli utenti, tramite help desk telefonico e sistemi di teleassistenza e le modalità di erogazione di tutti i servizi tecnici previsti con la descrizione del modello organizzativo, delle professionalità impiegate, delle procedure e del software di tracciamento proposto.
I tempi di risoluzione delle criticità sono riferiti all’orario di segnalazione all’Help-desk di I livello e sono di seguito indicati su base bimestrale:
1) disservizi di tipo “bloccante”:
16h solari nel 95% dei casi; 24h solari nel 5% dei casi;
2) disservizi di tipo “non bloccante”:
4gg solari nel 95% dei casi; 6gg solari nel 5% dei casi;
3) disservizi di tipo “anomalia”:
10gg solari nel 100% dei casi.
Esclusivamente per le postazioni operatore, nel caso di disservizio di tipo bloccante, è consentito un tempo di ripristino di tipo NBD ( Next Business Day) solo se almeno il 60% delle restanti postazioni operative della Questura che ha richiesto l’intervento sono funzionanti.
5.5.2 Assistenza
Presidio Data Center
Gli specialisti dedicati alla gestione del Data Center dovranno essere in possesso del titolo di studio di scuola media superiore o laurea, di comprovata esperienza almeno triennale, acquisita nelle specifiche problematiche del rispettivo ruolo.
Attraverso le risorse del gruppo tecnico di gestione, si dovrà garantire il presidio del Data Center secondo le fasce orarie riportate di seguito:
• Lunedì al Venerdì dalle ore 08.00 alle ore 18.00;
Il servizio di Gestione del Sistema Informativo decorrerà dal collaudo positivo del sistema centrale e della prima Questura per tutta la durata del contratto.
Assistenza Sistemistica per Sistemi Server
Il servizio dovrà garantire la continuità di funzionamento dei sistemi sia centrale che periferico e l’ottimale uso delle risorse. Dovrà essere prestato da personale dotato di idonea formazione ed esperienza relativamente ai sistemi operativi presenti.
Le prestazioni richieste in via indicativa ma non esaustiva, sono:
• installazione e parametrizzazione di sistemi operativi;
• predisposizione e gestione delle procedure atte a garantire la riduzione del rischio informatico (sistemi anti-intrusione, sistemi di autenticazione, back-up, antivirus, log di sistema, etc.);
• gestione sistemi di account e autorizzazione;
• documentazione delle procedure operative;
• aggiornamento S.O. mediante applicazioni di patches;
• preparazione ambiente per istallazioni hardware e software;
• diagnosi ed eliminazione guasti (sia software che hardware) anche mediante allertamento dei fornitori di manutenzione;
• gestione esperte nel sistema di virtualizzazione VMware;
• impostazioni e interpretazione di report e log di sistema ad uso della diagnosi e dell’upgrade dei sistemi e tuning.
Assistenza Sistemistica per il DBMS
Il servizio dovrà garantire la continuità di funzionamento dei sistemi DBMS centrale e periferico e l’ottimale uso delle risorse da questi messe a disposizione. Il personale addetto dovrà essere dotato di idonea formazione ed esperienza relativa ai DBMS installati.
Le prestazioni richieste in via indicativa ma non esaustiva, sono:
• installazione e parametrizzazione di sistemi DBMS;
• predisposizione e aggiornamento costante delle procedure atte a garantire la riduzione del rischio informatico (autenticazione, backup, crittografia, log di sistema, etc.);
• gestione account;
• documentazione delle procedure operative;
• aggiornamento DBMS mediante applicazioni di patches;
• preparazione e dimensionamento ambiente per nuove istallazioni software;
• diagnosi ed eliminazione anomalie;
• tuning attraverso l’adozione dei sistemi di monitor dei DBMS e interpretazione della reportistica.
Assistenza Tecnico Operativa di Base
Per assistenza tecnica operativa di base s’intendono tutte le attività tecniche di base atte a garantire la normale operatività di sistemi informatici semplici (postazioni, periferiche in rete, ecc.); in particolare sono richieste in via indicativa ma non esaustiva le seguenti prestazioni:
• interventi tecnici finalizzati alla diagnosi di anomalie hardware o software relative al parco hardware periferico;
• interventi tecnici finalizzati alla risoluzione di semplici problemi hardware quali ad esempio sostituzione di periferiche o componenti;
• esecuzione e verifica dei backup e dei relativi log;
• interventi tecnici di installazione da remoto del software applicativo, middleware;
• interventi tecnici quali l’installazione, la configurazione di base e tutto quanto necessario alla messa in esercizio delle Questure;
• movimentazione di un posto di lavoro;
• aggiunta ad un posto di lavoro;
• cambiamenti del posto di lavoro;
• gestione operativa della schedulazione;
• software distribution.
Assistenza Tecnica Specialistica Applicativa
Per assistenza tecnica specialistica applicativa s’intendono tutte le attività tecniche atte a garantire la corretta conduzione del software applicativo “nuovo SCT”, in particolare sono richieste in via indicativa ma non esaustiva, le seguenti prestazioni:
• parametrizzazione del software;
• individuazione delle anomalie dei software applicativi e rimozione degli stessi;
• installazione e testing del software applicativo e relativo aggiornamento;
• gestione user/account/authorization;
• redazione e aggiornamento della documentazione tecnica;
• produzione/aggiornamento della documentazione utente (manuali utente, tutorial, help on- line, wizard, ecc.). La documentazione utente sarà predisposta secondo standard e requisiti fissati nel processo di progettazione e deve essere oggetto di verifiche da parte dell’Amministrazione per accertarne l’accuratezza, la comprensibilità e più in generale l’usabilità.
Il personale addetto a queste funzioni dovrà avere una formazione di base di programmatore e specifica esperienza nella conduzione di software applicativi.
5.5.3 Assistenza e manutenzione applicativa
I servizi di manutenzione del software applicativo comprendono le attività tecniche che l’Impresa si obbliga ad effettuare per tutto il periodo contrattuale allo scopo di garantire il regolare funzionamento dei programmi facenti parte il “nuovo SCT” (procedure applicative, software di base, d’ambiente, ecc..) ed il supporto agli utenti.
Tali servizi comprendono la gestione degli aggiornamenti e/o delle nuove versioni delle procedure applicative e si articoleranno attraverso le seguenti principali attività:
• la manutenzione correttiva per la rimozione di cause ed effetti di malfunzionamenti;
• la manutenzione adeguativa per la verifica ed adeguamento del sistema informativo alla dinamica della tecnologia (hardware, software di base e d’ambiente) ed al cambiamento dei requisiti organizzativi e normativi;
• il supporto tecnico degli utenti per l’utilizzo del sistema, anche tramite help desk telefonico di I livello e sistemi di teleassistenza.
MAC
Gli obiettivi di una fornitura MAC sono così definiti:
❑ mantenere operativa la soluzione (software) attraverso attività che assicurino in via continuativa la rimozione delle malfunzioni;
❑ assicurare il miglioramento tempestivo delle funzionalità e delle prestazioni, per esempio quando un programma non ha prestazioni adeguate al livello di servizio richiesto e ciò viene percepito come una malfunzione, richiedendo un intervento di correzione;
❑ garantire l’evoluzione tecnico funzionale della soluzione software (in questo contesto definita come manutenzione adeguativa);
❑ fornire servizi di supporto per risolvere tempestivamente problemi relativi a malfunzioni ed errori;
❑ assicurare l’aggiornamento periodico della soluzione, attraverso il miglioramento della funzionalità, dell’affidabilità e dell’efficienza dei prodotti. L'aggiornamento presuppone il rilascio di nuove versioni e/o correzioni dei prodotti da parte del relativo fornitore.
La tabella che segue riporta le attività previste, ed i relativi prodotti oggetto di consegna (deliverable), per l’elemento della classe di fornitura.
Attività | Input | Output |
Analisi dei requisiti | Capitolato tecnico della fornitura e ulteriori specifiche fornite dall’Amministrazione | Specifica dei requisiti, Piano di gestione dlle comunicazioni |
Progettazione tecnica | Specifiche dei requisiti | Specifica tecnica |
Realizzazione del servizio | Specifica dei requisiti, Specifica tecnica | Piano del servizio, Sistema di erogazione del servizio, verifica degli SLA |
Gestione degli interventi di manutenzione | Segnalazione di malfunzioni | Verbale di rilevazione del problema |
Analisi dei problemi e delle modifiche | Verbale di rilevazione del problema. | Analisi delle modifiche |
Attuazione delle modifiche | Analisi delle modifiche | Prodotto software modificato |
Rendicontazione | Analisi delle modifiche | Rapporto di manutenzione |
5.5.4 Penali
Le penali applicabili in caso di ritardata esecuzione delle attività relativamente agli SLA definiti nel sottoparagrafi 5.5.1:
a) disservizi bloccanti
penale di €. 400,00 per ogni ora solare di ritardo
b) disservizi non bloccanti
penale di €. 250,00 per ogni giorno solare di ritardo
c) disservizi anomalie
penale di €. 100,00 per ogni giorno solare di ritardo
Servizio di Help Desk
Valori di Soglia | Penali Causale Importi | ||
Tempo Max Attesa | 30 sec. nel 80% dei casi 60 sec nel 20% dei casi | Per ogni punto o frazione percentuale in meno rispetto ai valori di soglia | 0,5%-1% del valore contrattuale del servizio nel periodo di osservazione |
Chiamate Entranti perdute | 1% - 5% | Per ogni punto o frazione percentuale in meno rispetto ai valori di soglia | 0,5%-1% del valore contrattuale del servizio nel periodo di osservazione |
Le penali applicabili in caso di ritardata esecuzione delle altre attività non riconducibili a quanto sopra riportato, sono definiti nelle successiva “tabella servizi”. I questionari di rilevazione per la verifica dei livelli di servizio dovranno essere proposti dal fornitore, in accordo alle frequenze ed ai parametri richiesti, ed approvati dal responsabile di progetto dell’Amministrazione.
Tabella Servizi
Classe di fornitura | Sviluppo sistemi |
Caratteristica /Sottocaratteristica | Affidabilità/ Tolleranza ai guasti |
Indicatore/Misura | Disponibilità del sistema – DIS1 |
Sistema di gestione delle misure | La disponibilità viene misurata contando il numero dei fermi non programmati di sistema e la loro durata, nell’arco della finestra di erogazione del servizio. L’indicatore relativo alla disponibilità dei sistemi riguarda la disponibilità dell’intera infrastruttura hardware e software necessaria all’erogazione di una applicazione verso l’utente finale e non quindi la disponibilità di un singolo elemento del sistema. L’indicatore relativo alla disponibilità dei sottosistemi ( DB,…) e prodotti del middleware (Web Server, Application Server, ecc.) in questo contesto riguarda la disponibilità delle prestazioni o la fruizione dell’applicazione nella sua interezza. La finestra di erogazione da considerare è quella definita contrattualmente |
Unità di misura | Percentuale |
Dati elementari da rilevare | • Data e ora di fermo (al minuto) • Data e ora di riattivazione (al minuto) |
Periodo di riferimento | 2 mesi |
Frequenza esecuzione misure | 6 volte l’anno |
Regole di campionamento | Vanno considerati i fermi non programmati, non dovuti all’applicazione, rilevabili dal log di sistema e/o dai registri di conduzione operativa. • Xxxxx occorsi e risolti nel periodo di osservazione corrente • Xxxxx occorsi nel periodo di osservazione precedente e risolti in quello corrente. |
Formula di calcolo | Dati necessari • durata del fermo • tempo totale = tempo contrattuale di erogazione del servizio nel periodo di riferimento (esclusi i fermi programmati) La disponibilità si rappresenta come DIS1 = Tempo _ totale − ∑ Durata _ fermo ×100 Tempo _ totale |
Regole di arrotondamento | La percentuale va arrotondata alla frazione decimale di punto percentuale sulla base del secondo decimale - per difetto se la parte decimale è ≤ 0,05 - per eccesso se la parte decimale è > 0,05 |
Obiettivi (valori soglia) | Obiettivi DIS1 ≥ 99,6% (sistema di Questura –modulo sala operativa- ad alta disponibilità ) DIS1 ≥ 98,5% (sistema centrale) |
Azioni contrattuali | Per ogni 0,1% di disponibilità inferiore all’obiettivo si applica una penale di importo dell’0,05% del costo della fornitura per il modulo sala operativa e 0,02 % per gli altri |
Eccezioni | L’applicazione delle regole contrattuali inizia dopo un periodo di avviamento di due mesi della sede centrale e della prima Questura. Per le altre Questure l’applicazione delle regole contrattuali inizia alla data del collaudo positivo |
Caratteristica /Sottocaratteristica | Funzionalità / Accuratezza |
Indicatore/Misura | Completezza dei back-up effettuati – CBKE |
Sistema di gestione delle misure | Strumenti per la raccolta dei dati elementari dei back-up effettuati (nome back-up, repository, data e ora). |
Unità di misura | Numero di elementi mancanti |
Dati elementari da rilevare | • numero di back-up richiesti per applicazione • numero di back-up realmente effettuati per applicazione |
Periodo di riferimento | 4 mesi |
Frequenza esecuzione misure | 3 volte l’anno |
Regole di campionamento | Vanno considerati tutti tutti i backup effettuati |
Formula di calcolo | Dati necessari • numero di back-up richiesti per applicazione (NBR) • numero di back-up realmente effettuati per applicazione (NBE) CBKE= NBR− NBE La quantità CBKE indica il numero di elementi (back-up) mancanti |
Regole di arrotondamento | NA |
Obiettivi (valori soglia) | Obiettivi • CBKE = 0 |
Azioni contrattuali | Per ogni elemento mancante rispetto al numero stabilito contrattualmente per applicazione si applica una penale dello 0.5% del corrispettivo. |
Caratteristica / Sottocaratteristica | Soddisfazione help desk |
Indicatore/Misura | Soddisfazione dell’utente sul servizio di help desk - SOD |
Sistema di gestione delle misure | I questionari di rilevazione della soddisfazione degli utenti, proposto dal Fornitore ed approvato dall’Amministrazione, devono proporre domande che indaghino sul grado di soddisfazione nei confronti dei servizi di help desk di I livello |
Metodi e strumenti di misura | Misura manuale |
Unità di misura | Percentuale |
Dati elementari da rilevare | Valori (da 1 a 6) forniti in risposta alle domande specifiche |
Periodo di riferimento | Tre mesi |
Frequenza esecuzione misure | 4 volte l’anno |
Regole di campionamento | NA |
Formula di calcolo | SOD = (x * 100) / y dove: x = N° delle risposte positive (per risposta positiva si intende una risposta con valore > 3) y = N° delle domande |
Regole di arrotondamento | La percentuale ottenuta dovrà essere arrotondata all’intero superiore se la parte decimale è maggiore di 0,50 o all’intero inferiore se la parte decimale è minore o uguale a 0,50. |
Obiettivi (valori soglia) | SOD ≥80% |
Azioni contrattuali | Penale: Per ogni punto percentuale di scostamento in diminuzione si applica una penale di importo pari allo 0,01% del valore del servizio di assistenza |
Eccezioni | NA |
5.6 Manutenzione Evolutiva a consumo
La manutenzione evolutiva sarà effettuata su richiesta dell’Amministrazione per la messa in esercizio di funzionalità non ancora individuate, da valutare in punti funzione secondo le modalità di conteggio definite dal IFPUG secondo lo standard vigente. Tale attività sarà erogata per complessivi 2000 function point.
5.6.1 Livelli di servizio e penali
Classe di fornitura | Manutenzione Evolutiva |
Caratteristica / Sottocaratteristica | Affidabilità/ Maturità |
Indicatore/Misura | Difettosità – NDIF |
Sistema di gestione delle misure | L’impresa dovrà prevedere un sistema in grado di raccogliere ed elaborare i dati elementari in particolare nelle fasi di test, collaudo e nell’arco temporale relativo all’ avviamento/diffusione. Il sistema di rilevazione deve prevedere una classificazione delle malfunzioni ad esempio in base alle seguenti tipologie: − non bloccante: malfunzione che, pur impedendo l’uso delle funzioni software, non inibisce l’operatività da parte dell’utente; l’utente può cioè ugualmente pervenire ai risultati attesi mediante l’utilizzo di altre funzionalità comunque offerte dal sistema; − bloccante: malfunzione che rende totalmente o parzialmente non utilizzabili le funzionalità disponibili all’utente. I fermi dell’applicazione sono provocati da errori bloccanti. La rilevazione può essere fatta automaticamente con appositi tool di defects tracking o con modalità mista. Ogni malfunzione rilevata deve essere analizzata e classificata per rilevarne la causa. Malfunzioni derivanti dalla medesima causa devono essere conteggiate una sola volta. |
Unità di misura | Percentuale |
Dati elementari da rilevare | • Dimensioni in FP delle applicazioni a inizio del periodo di osservazione. • Nr malfunzioni per tipo. • Fase di rilevazione (test, collaudo, avviamento / diffusione). |
Periodo di riferimento | Nei 12 mesi di esercizio dall’ avviamento dell’intervento di MEV. |
Frequenza esecuzione misure | NA |
Regole di campionamento | NA |
Formula di calcolo | Dati necessari NDIFB = MBTOT / FP NDIFNB = MNBTOT / FP |
MBTOT = numero totale di Malfunzioni Bloccanti rilevate nel periodo di riferimento; MNBTOT = numero totale di Malfunzioni Non Bloccanti rilevate nel periodo di riferimento; Il valore va espresso come percentuale. | |||||
Regole di arrotondamento | La percentuale va arrotondata al decimale successivo dell’ultimo decimale significativo del valore di soglia. (es. per valore di soglia = 0,01 l’arrotondamento è al terzo decimale). | ||||
Obiettivi (valori soglia) | Obiettivi L’obiettivo è quello di tenere sotto controllo l’affidabilità dell’applicazione, monitorando il tasso degli errori applicativi che provocano il fermo dell’applicazione. Valori soglia sono illustrati di seguito: | ||||
Classe di criticità | Descrizione | Valore soglia errori bloccanti | Valore soglia errori non bloccanti | ||
1 | L’intera applicazione è indisponibile agli utenti | 0,01% | NA | ||
2 | Funzionalità critiche dell’applicazione sono indisponibili agli utenti | 0,1% | NA | ||
3 | Funzionalità non critiche dell’applicazione sono indisponibili agli utenti | NA | 2% | ||
4 | Funzionalità non critiche dell’applicazione sono indisponibili agli utenti e non c’è immediato impatto sull’operatività degli utenti | NA | 5% | ||
Azioni contrattuali | Il superamento dei valori di soglia comporta l’applicazione di una penale determinata come % del corrispettivo dell’intervento di MEV ed è illustrato in tabella | ||||
Classe di criticità | Importo per errori bloccanti | Importo per errori non bloccanti | |||
1 | 2 % | NA | |||
2 | 1 % | NA | |||
3 | NA | 0,5 % | |||
4 | NA | 0,4 % | |||
Caratteristica /Sottocaratteristica | Affidabilità / ripristinabilità | ||||
Indicatore/Misura | Efficienza di rimozione errori – RERR | ||||
Sistema di gestione delle misure | Sistema di gestione della rilevazione dei difetti con la componente aggiuntiva di registrazione degli interventi di rimozione, dei tempi impegnati e relativo esito. Il sistema dovrà essere in grado di raccogliere ed elaborare i dati elementari in particolare nell’arco temporale relativo all’avviamento / diffusione / garanzia. La rilevazione può essere fatta in modalità mista con appositi tool di defects tracking e trouble ticketing1. | ||||
Unità di misura | RERRBL, RERRNBL = percentuale. |
T = ora | |||||
Dati elementari da rilevare | • Nr malfunzioni rilevate per Tipo; • Nr interventi di rimozione effettuati con esito positivo; • Tempo di rimozione e ripristino. | ||||
Periodo di riferimento | Nel corso dell’avviamento / diffusione. | ||||
Frequenza esecuzione misure | In base alle caratteristiche dell’applicazione può essere stabilita la frequenza di misura nell’arco temporale dell’avviamento / diffusione. | ||||
Regole di campionamento | NA | ||||
Formula di calcolo | Malfunzioni rimosse nel tempo limite (valori espressi come percentuale): RERRBL= MBLrimossi/ MBLrilevati RERRNBL= MNBLrimossi/MNBLrilevati dove: MBLrimossi/rilevati = numero totale delle Malfunzioni Bloccanti rimosse nel tempo limite / rilevate nel periodo di osservazione; MNBLrimossi/rilevati = numero totale delle Malfunzioni Non Bloccanti rimosse nel tempo limite / rilevate nel periodo di osservazione; Tempo di rimozione e ripristino T = D-fi - D-in D-in= data/ora inizio intervento eseguito nel tempo limite D-fi= data/ora fine intervento eseguito nel tempo limite Gli indicatori esposti possono essere misurati distintamente per ciascuna “Classe di criticità”, come individuata ai fini dell’indicatore DIFETTOSITA’ – NDIF. | ||||
Regole di arrotondamento | La percentuale va arrotondata al primo decimale. | ||||
Obiettivi (valori soglia) | L’obiettivo è quello di tenere sotto controllo l’efficienza e l’efficacia del periodo di avviamento / diffusione monitorando la tempestività di intervento a fronte di malfunzionamenti. Valori soglia: RERRBL ≥ 95% con tempo limite = 16 ore solari per classe di criticità 1 e 2. Il restante 5% dei casi deve essere risolto nel tempo limite = 24 ore per classe di criticità 1e 2. RERRNBL ≥ 95% con tempo limite = 4 gg solari per classe di criticità 3; 10 gg solari per classe di criticità 4; il restante 5% dei casi deve essere risolto nel tempo limite = 6 gg solari per classe di criticità 3; 10 gg solari per classe di criticità 4. | ||||
Azioni contrattuali | Il superamento dei valori di soglia comporta l’applicazione di una penale determinata come % del corrispettivo dell’intervento di MEV ed è illustrato in tabella | ||||
Classe di criticità | Importo per errori bloccanti | Importo per errori non bloccanti | |||
1 | 1% | NA | |||
2 | 0,8% | NA | |||
3 | NA | 0,5% | |||
4 | NA | 0,4% |
5.7 Formazione alla conduzione sistemistica ed operativa a livello centrale
L’impresa dovrà provvedere ad erogare moduli formativi allo scopo di addestrare il personale dell’Amministrazione del CEN di Napoli sui sistemi hw e sw forniti. L’attività didattica avrà lo scopo di fornire al personale addetto (fino alla specializzazione conseguita) la piena conoscenza e capacità di intervenire con competenze almeno di primo livello, in termini operativi, di manutenzione e supporto ai sistemi forniti.
Xxxxxxx in generale, le seguenti assunzioni:
⮚ la formazione in aula, avverrà frontalmente;
⮚ gli insegnanti dovranno essere qualificati e specializzati sugli argomenti trattati;
⮚ il corso dovrà essere in lingua italiana.
Le date d’inizio e le modalità di svolgimento dei moduli dovranno essere concordati con l’Amministrazione. In particolare l’impresa dovrà programmare e svolgere una adeguata formazione teorica e pratica per il personale tecnico dell’Amministrazione in modo da fornire tutti gli elementi basilari per comprendere le fasi di installazione, messa in esercizio, personalizzazione e manutenzione del sistema complessivo.
Il piano di Formazione deve prevedere un numero di partecipanti che verrà definito dall’Amministrazione e comunque non superiore ad un numero complessivo di 10 quale personale dedicato alla gestione del sistema e personalizzazione dei moduli.
Per la stima dell’attività didattica si devono considerare 6 moduli di 5 giorni (di 6h) che verranno erogati secondo il piano che verrà definito dall’Amministrazione.
Al termine del corso dovrà essere erogata un’attività formativa di tipo on-the-job di almeno 60 giorni lavorativi.
L’impresa dovrà fornire un piano di formazione complessivo dei moduli con l’indicazione delle diverse sessioni di formazione ed il tempo dedicato ad ogni sezione del programma. Ai partecipanti ai corsi la società rilascerà un attestato per ogni tipologia di modulo.
Per ogni modulo l’impresa dovrà indicare gli skill minimi necessari alla partecipazione del modulo di formazione, di background tecnico e di responsabilità rispetto al sistema, del personale partecipante.
A ciascun allievo frequentatore dovrà essere fornita la documentazione tecnica (manuali anche in formato elettronico “ipertestuale”, web, dispense illustrate di particolari argomenti di carattere propedeudico e/o tecnologico la cui conoscenza sia necessaria per acquisire quanto esposto nei manuali delle apparecchiature in fornitura). La documentazione tecnica di supporto sarà costituita da manuali aventi lo scopo di consentire al personale di effettuare:
⮚ una corretta utilizzazione dei sistemi;
⮚ gli interventi correttivi di primo livello necessari per l’eliminazione di malfunzionamenti dei sistemi;
⮚ la gestione delle configurazioni e delle personalizzazioni;
⮚ la gestione degli interventi di manutenzione preventiva e/o correttiva.
5.7.1 Soddisfazione dei Requisiti
La formazione dovrà essere erogata presso le strutture messe a disposizione dall’Amministrazione, allestite per l’erogazione della formazione. Tale allestimento comprenderà:
❑ infrastrutture didattiche e informatiche adeguate allo svolgimento dei corsi;
❑ postazioni di lavoro, in numero adeguato ai discenti previsti per ciascuna edizione del corso.
L’impresa dovrà essere in possesso di una certificazione UNI EN ISO 9001:2000, valida al momento di presentazione dell’offerta da parte della stessa (oppure da parte di uno dei soggetti costituenti il raggruppamento o l’associazione temporanea d’impresa) .
L’erogazione della formazione deve essere conforme ai requisiti della norma UNI ISO 10015:2001.
5.8 Figure professionali
Le figure professionali proposte per lo sviluppo dei servizi oggetto della fornitura, tranne che per i servizi di assistenza sistemistica degli attuali sistemi, dovranno far riferimento almeno ai profili di seguito descritti.
Questi hanno un valore indicativo e non prescrittivo, in quanto l’impresa potrà proporre ulteriori figure professionali.
Per quanto riguarda la voce “Xxxxxx, Certificazioni ed Abilitazioni”, saranno ritenuti validi quelli rilasciati da organismi Nazionali/Internazionali ufficialmente riconosciuti nell’ambito ICT e Università, Consorzi, Produttori di beni ICT, ed ottenuti tramite il superamento di un esame finale ed attinenti all’incarico nell’ambito della fornitura.
CAPO PROGETTO | |
Titolo di Studio | Laurea in discipline tecniche o cultura equivalente |
Certificazioni/Xxxxxx/ Abilitazioni | • Certificazione PMI |
Anzianità lavorativa | • Minimo 10 anni, di cui almeno 5 anni di provata esperienza nella gestione di progetti di grandi dimensioni con più team cross-functional richiedenti definizione e applicazione di processi organizzativi complessi |
Esperienze Lavorative | • Esperienze e competenze rilevanti per la definizione di strategie IT - con focalizzazione su obiettivi strategici e di disegno – e di un percorso di informatizzazione innovativo e ad alto valore aggiunto • Uso di tecniche e prodotti software per project management e risk management • Controllo realizzazione procedure • Stima di risorse per la realizzazione di progetto • Redazione di documentazione di progetto • Stima di tempi e pianificazione attività • Analisi e progettazione di sistemi informativi, package, procedure complesse • Responsabilità su gruppi di progetto • E’ titolo preferenziale l’esperienza con tale qualifica in progetti di sale operative complesse |
Conoscenze | • Metodologie di misura progetti • Metodologie di sviluppo • Redazione di specifiche di progetto • Analisi di processi • Conoscenze di tecniche e prodotti SW per project management e risk management • Ottime capacità relazionali |
ANALISTA FUNZIONALE | |
Titolo di Studio | Laurea in discipline tecniche/economiche o cultura equivalente |
Anzianità lavorativa | Minimo 8 anni, di cui almeno 3 nella funzione |
Esperienze Lavorative | • Redazione di specifiche di progetto • Redazione di modelli dei processi • Controllo realizzazione procedure • Stima di risorse per realizzazione di progetto • Stima di tempi • Coordinamento di gruppi di lavoro • Disegno e progettazione di test |
Conoscenze | • Metodologie di analisi dei processi • Metodologie di analisi e disegno di prodotti SW • Metodologie di analisi e disegno dati • Tecniche di controllo di progetto e di programmazione strutturata • sistema di virtualizzazione VmWare • DBMS Relazionali e in particolare del DBMS offerto • Tecniche di programmazione in ambiente Java • Conoscenza di strumenti di work-flow management |
ANALISTA PROGRAMMATORE | |
Titolo di Studio | Diploma di perito informatico o equivalente |
Anzianità lavorativa | Minimo 5 anni, di cui almeno 2 nella funzione |
Esperienze Lavorative | • Verifica della corretta applicazione di metodi e standard • Sviluppo di analisi tecnica di media complessità • Documentazione procedure • Programmazione e test (preparazione di casi di test ed esecuzione di test) • Partecipazione a gruppi di progetto di medie/grandi dimensioni • Installazione e personalizzazione di sistemi anche complessi • Progettazione ed integrazione di sistemi |
Conoscenze | • Tecnologie emergenti • Metodologie di analisi e disegno di prodotti SW • sistema di virtualizzazione VmWare • Tecniche di programmazione Object oriented • Ottima conoscenza dei linguaggi di programmazione: ASP, HTML/XTML/XML/javascript • Tecniche di programmazione in ambiente Java • DBMS Relazionali e in particolare del DBMS offerto, DBA • Strumenti di modellazione dati • Strumenti per il cleaning e la qualità dei dati |
PROGRAMMATORE | |
Titolo di Studio | Diploma di perito informatico o equivalente |
Anzianità lavorativa | Minimo 3 nella funzione |
Esperienze Lavorative | • Preparazione ed esecuzione di casi di test • Preparazione di documentazione di programmi • Partecipazione alla stesura di specifiche tecniche • Partecipazione a gruppi di progetto di medie dimensioni • Installazione e personalizzazione di sistemi anche complessi • Progettazione ed integrazione di sistemi |
Conoscenze | • Metodologie di analisi, disegno di prodotti SW • linguaggi di programmazione • Strumenti per la codifica dei programmi • Tecniche di programmazione strutturata e in ambiente java • Ottima conoscenza dei linguaggi di programmazione: ASP, HTML/XTML/XML/javascript |
PROGETTISTA DI SISTEMI INFORMATICI | |
Titolo di Studio | Laurea in discipline tecniche o cultura equivalente |
Certificazioni/Xxxxxx/ Abilitazioni | Da dichiarare a cura dell’impresa |
Anzianità lavorativa | Minimo 10 anni, di cui almeno 4 nella funzione |
Esperienze Lavorative | • Redazione di specifiche di progetto • Valutazione costi e soluzioni tecniche • Stima di risorse per la realizzazione di progetto • Definizione di scopi, obiettivi, approcci e strategie per la realizzazione del progetto • Analisi e progettazione di sistemi informativi, package e procedure complesse • Definizione delle componenti della soluzione • Stima di tempi • Controllo prestazioni • Responsabilità su gruppi di progetto • sistema di virtualizzazione VmWare |
Conoscenze | • Tecniche e prodotti SW per Project Management e Risk Management • Architetture di sistemi complessi e tecnologie • Problematiche architetturali • Integrità, riservatezza ed affidabilità dei sistemi informativi • Impatti organizzativi e system reingeneering • Tecniche di assessment di processi • Assicurazione qualità, benchmarking e capacity planning • E’ titolo preferenziale l’esperienza con tale qualifica in progetti di sale operative complesse |
SISTEMISTA | |
Titolo di Studio | Laurea in discipline tecniche o cultura equivalente |
Certificazioni/Xxxxxx/ Abilitazioni | Da dichiarare a cura dell’impresa |
Anzianità lavorativa | Minimo 8 anni, di cui 4 nel ruolo |
Esperienze Lavorative | • Installazione, personalizzazione, tuning e troubleshooting di server e client in ambienti Microsoft e Linux • Esperienza specialistica su tecnologie e prodotti di SAN e back-up • Attività di installazione, configurazione ed update del software, sia di S.O. che di altri prodotti presenti in fornitura • Tuning ed ottimizzazione della configurazione del sistema per garantirne la massima efficienza (utilizzo della cpu, memoria,I/O dischi e spazio) • Configurazione/ gestione di sottosistema dischi ed integrazione in ambiente SAN • Stesura di documenti tecnici ed operativi • Progettazione test integrati • E’ titolo preferenziale l’esperienza con tale qualifica in progetti di sale operative complesse |
Conoscenze | • Specifiche competenze: o configurazioni cluster Windows e Linux o configurazioni dei DBMS Relazionali, DBA o Configurazione di infrastruttura di Storage e sistemi di back-up • Conoscenza Sistemi Operativi Linux e Windows, • Linguaggi : C - C++ - • sistema di virtualizzazione VmWare • Conoscenze specialistiche delle applicazioni enterprise conformi agli standard Java • Conoscenza della piattaforma HP Open View • Conoscenza del sw di Backup Symantec • Skill specifico nella gestione, configurazione e tuning di Application Server |
6 ATTIVITÀ DI COORDINAMENTO E DIREZIONE DI PROGETTO
Per le attività di coordinamento e direzione di progetto, in riferimento in particolare alle risorse impiegate nel progetto stesso, l’Impresa dovrà garantire l’impiego per l’intero periodo contrattuale, di un Capo Progetto.
Tale figura professionale dovrà avere un’ approfondita conoscenza delle problematiche oggetto della presente gara come indicato nel paragrafo 5.8 (figure professionali).
I compiti del capo progetto saranno, tra gli altri:
• assumere il ruolo di interfaccia unica con l’Amministrazione;
• coordinare le risorse costituenti i vari gruppi tecnici;
• armonizzare le attività progettuali con le direttive dell’Amministrazione;
• rendicontare, con periodicità bimestrale, le presenze e le attività di tutte le risorse umane utilizzate nel progetto.
Nell’esecuzione ordinaria del Servizio il suddetto Capo Progetto avrà il compito di coordinare e dirigere tutte le prestazioni appresso descritte:
• Coordinamento generale di progetto
• Assistenza sistemistica per tutti i sistemi server
• Assistenza sistemistica per tutti i RDBMS
• Assistenza tecnico operativa di base
• Servizio di help desk
• Assistenza tecnica specialistica applicativa
• Manutenzione ordinaria hardware centrale e periferico
• Fornitura software applicativo
• Forniture e servizi complementari necessari all’espletamento dell’intero servizio
• Formazione e addestramento del personale nel CEN di Napoli (training on the job).
Tutte le attività di gestione operativa, coordinate dal Capo progetto, dovranno essere coerenti con il piano generale di attività che verrà predisposto dall’impresa ed accettato dall’Amministrazione, con cadenza almeno trimestrale. Per ogni piano di attività, al termine del periodo, dovrà essere fornito dal Capo progetto un report dettagliato che illustri, in relazione agli obiettivi prefissati, i risultati raggiunti e le eventuali criticità riscontrate.
7 PIANO DI PROGETTO
L’impresa dovrà predisporre un Piano di progetto relativo a tutte le attività previste dal rapporto contrattuale. Il Piano di progetto dovrà contenere almeno i seguenti elementi:
• l’organizzazione delle risorse necessarie allo svolgimento delle attività previste dal contratto, inclusi struttura dei gruppi di lavoro, responsabilità, carichi di lavoro, risorse materiali;
• le fasi del progetto, i flussi in ingresso ed uscita dalle attività e quanto previsto in termini di controllo ed assicurazione qualità;
• il piano temporale del progetto, con l’individuazione delle attività, delle loro relazioni e per ciascuna di esse, delle risorse dei tempi necessari per completarle con particolare riferimento al gant del collaudo dell’intera fornitura;
• l’analisi dei rischi e dei problemi associati alle varie fasi.
Il Piano di progetto dovrà essere presentato in fase di offerta e revisionato a valle dell’aggiudicazione e firma del contratto, per riflettere le eventuali variazioni intervenute.
Nel corso della esecuzione del contratto, il Piano di progetto sarà utilizzato dall’impresa come Piano del servizio, ovvero per regolare tempi e modi di esecuzione delle attività proprie di quei servizi. Ciascuna edizione del Piano di progetto dovrà essere sottoposta all’approvazione dell’Amministrazione.
Si specifica che:
• L’attivazione del sistema deve essere completa in opera, presso la sede centrale e presso tutte le Questure in ogni sua componente entro il limite non derogabile di 24 mesi solari dalla data di inizio attività.
• L’impresa deve valutare la compatibilità del predetto valore richiesto con l’obiettivo della realizzazione proponendo il valore richiesto o migliorativo. In quest’ultimo caso in cui la messa in esercizio sia completa prima del massimo richiesto di 24 mesi, il servizio di conduzione, assistenza e manutenzione del “nuovo SCT” deve essere erogato fino al raggiungimento del termine contrattuale nel rispetto degli SLA offerti.
8 MONITORAGGIO
Entro i 30 gg successivi all’approvazione del contratto si devono definire le modalità di Monitoraggio del Progetto. Le stesse devono essere proposte dall’impresa ed accettate dall’Amministrazione.
9 ULTERIORI RACCOMANDAZIONI E NORMATIVE
Il Sistema deve essere progettato e realizzato nel rispetto di tutte le normative vigenti nazionali e locali relative alla tutela ambientale, alla sicurezza sugli ambienti di lavoro ed in generale a tutte quelle connesse alle opere da realizzare a perfetta regola d’arte, con particolare riferimento a:
- prevenzione della salute e sicurezza
- radiazioni ionizzanti
- sostanze nocive
- dispositivi di protezione
- tutela dell’ambiente
- compatibilità elettromagnetica
- scariche elettrostatiche
L’impresa è pienamente responsabile delle attività realizzate e deve fornire qualora richiesto tutte le certificazioni, attestanti il rispetto delle normative suddette.
10 COLLAUDO
Il collaudo viene eseguito da Commissioni istituite con apposito decreto dell’Amministrazione. Le operazioni di collaudo vengono svolte con le seguenti modalità:
• Collaudo inventariale entro novanta giorni presso un locale messo a disposizione dall’impresa.
• Collaudo in opera del sistema funzionante relativamente alla prima Questura ed al sistema Centrale.
• Collaudo in opera a seguire di tutte le Questure.
Segue una lista delle principali requisiti da verificare:
• Completamento della migrazione dati
• Funzionamento del sistema di provisioning centralizzato
• Funzionamento del sistema di monitoring centralizzato
• Funzionamento del sistema di gestione utenze
• Funzionamento del modulo di “Sala Operativa”
• Accessibilità e funzionalità dei moduli centralizzati
• Funzionamento del sistema di replica dati dalla Questura verso il CEN di Napoli
• Funzionamento del modulo “Sala Operativa” dal CEN in caso di blocco dei server di Questura.
L’impresa deve presentare un “Piano dei Collaudi” con l’indicazione di un efficiente programma di test e dettagliate procedure per controllare la perfetta funzionalità di tutte le parti del sistema (hardware, software, ecc).
L’impresa deve garantire tutta l’assistenza necessaria alle Commissioni di Collaudo per l’effettuazioni delle verifiche.
I collaudi vengono eseguiti con le modalità previste nel piano di collaudo, fatta salva la facoltà della Commissione di richiedere ulteriori motivate verifiche.
Nota
Si specifica che per le operazioni di collaudo saranno nominate 17 commissioni con competenza regionale (alcune commissioni con competenza su due regioni). Considerato un tempo di collaudo di circa 5 gg lavorativi a Questura, considerate le necessità delle regioni con un elevato numero di provincie, il tempo minimo per completare il collaudo per tutte le Questure con una pianificazione parallela delle attività, non può essere inferiore a tre mesi.
11 MODALITA’ COMPILAZIONE DELLE OFFERTE
11.1 Offerta Economica
Nell’offerta oltre al costo globale della fornitura, dovranno essere forniti i costi distinti per le singole voci ed attività come di seguito indicato. Si precisa che devono essere inserite tutte le righe relative alle singole voci di costo non esplicitamente indicate ma che concorrono al valore complessivo della fornitura.
Componente fornitura | Qtà | Prezzo Unitario | Prezzo complessivo | |
HARDWARE | ||||
Hardware Centrale | Armadi Rack | |||
Server Tipo A | ||||
Server fascia I | ||||
Sistema storage | ||||
Switch | ||||
Hardware Periferico | Server fascia I | |||
Server fascia II | ||||
Sistema storage | ||||
Postazioni lavoro | ||||
Armadi Rack | ||||
SOFTWARE | ||||
Sistemi operativi | Inserire una riga per il costo di ogni componente centrale e periferico | |||
Software di System Management – HP open view ( sia centrale che periferico) | Inserire una riga per il costo di ogni componente | |||
DBMS Centrale | Inserire una riga per il costo di ogni componente | |||
DBMS Periferico | Inserire una riga per il costo di ogni componente | |||
Software di backup Symantec | Inserire una riga per il costo di ogni componente | |||
Sistema di Provisioning | Inserire una riga per il costo di ogni componente software | |||
Inserire una riga per ogni figura professionale | ||||
Software di virtualizzazione VmWare | Inserire una riga per il costo di ogni componente centrale e |
periferico | ||||
Altri eventuali software | Inserire una riga per il costo di ogni componente centrale e periferico | |||
MANUTENZIONE SISTEMI ESISTENTI | ||||
Manutenzione Hw sistemi esistenti | Canone mensile – inserire una riga per ogni tipologia di apparato | |||
Assistenza sistemistica sistemi esistenti | Inserire una riga per ogni figura professionale | |||
SERVIZI | ||||
Conversione e centralizzazione di tutti i moduli “as is” su piattaforma x86 Centrale | Function Point | |||
Inserire una riga per ogni figura professionale | ||||
Porting del modulo “Sala Operativa” su piattaforma x86 di Questura | Function Point | |||
Inserire una riga per ogni figura professionale | ||||
Recupero dati di esercizio e storici ,migrazione ai nuovi DB periferici e centralizzato. | Function Point | |||
Inserire una riga per ogni figura professionale | ||||
Inserire una riga per ogni figura professionale | ||||
Help Desk | inserire una riga per ogni figura professionale) | |||
Costo Globale (inserire una riga per ogni tipologia di fornitura) | ||||
MANUTENZIONE “NUOVO SCT” | ||||
Manutenzione HW | Canone mensile – inserire una riga per ogni apparato | |||
MEV – | Function Point | |||
MAC – | Canone mensile | |||
Manutenzione SW | Canone mensile – inserire una riga per ogni software fornito | |||
ALTRI COSTI | ||||
Altri costi | Inserire una riga per ogni eventuale altro costo previsto | |||
TOTALE |
11.2 Offerta Tecnica
La busta “B” dovrà contenere un indice completo di quanto in essa contenuto, nonché la Relazione Tecnica in lingua italiana priva di qualsivoglia indicazione (diretta o indiretta) di carattere economico dalla quale si evinca in modo completo e dettagliato, ed in conformità ai requisiti indicati nel presente Capitolato Tecnico, la descrizione dei beni e servizi offerti oggetto di gara.
Deve essere evidente il confronto tra le caratteristiche tecniche minime richieste e quelle offerte, le modalità di fornitura e di prestazione dei servizi oggetto di fornitura, con riferimento ai requisiti indicati nel capitolato tecnico stesso.
Alla Relazione in originale, dovrà essere aggiunta una copia in formato elettronico non modificabile (x.xx. in formato “.pdf “ con la possibilità di eseguire ricerche sul testo).
La Relazione Tecnica dovrà necessariamente contenere le caratteristiche dei beni e servizi offerti, le modalità di fornitura e di prestazione dei servizi, con riferimento ai requisiti indicati nel presente Capitolato tecnico.
La suddetta Relazione Tecnica:
• dovrà essere presentata su fogli singoli di formato DIN A4, non in bollo, con una numerazione progressiva ed univoca delle pagine e dovrà essere fascicolata con rilegatura non rimovibile;
• dovrà essere contenuta entro le 100 (cento) pagine;
• dovrà rispettare lo “Schema di risposta” riportato nell’allegato 1.
Si rappresenta che la Commissione procederà alla valutazione della sola Relazione Tecnica. Nel caso in cui, pertanto, il Concorrente produca documentazione aggiuntiva, quest’ultima non sarà sottoposta a valutazione.
Si sottolinea che, pena l’esclusione dalla gara, la Relazione Tecnica deve descrivere le modalità di erogazione di ciascun servizio anche in assenza di miglioramento dei requisiti minimi indicati nel presente capitolato.
Si precisa che tutte le soluzioni proposte devono essere nella piena disponibilità dell’impresa e senza oneri aggiuntivi per l’Amministrazione. Si precisa inoltre che quanto descritto nella Relazione Tecnica costituisce di per sé dichiarazione di impegno dell’impresa all’esecuzione nei tempi e modi descritti nella relazione stessa. Per tutte le proposte indicate nella Relazione Tecnica dovranno essere forniti gli elementi oggettivi di verifica o misurazione.
12 CRITERI DI AGGIUDICAZIONE
La gara verrà aggiudicata, a favore del concorrente che avrà presentato l’offerta economicamente più vantaggiosa, ai sensi dell’art. 83 del D.lgs. 163/2006, e s.m.i., da individuare sulla base dei parametri e con i pesi di seguito elencati:
CRITERIO | PUNTEGGIO MASSIMO |
Punteggio tecnico | 60 |
Punteggio economico | 40 |
TOTALE | 100 |
Il punteggio totale sarà quindi determinato dalla somma algebrica del punteggio tecnico e del punteggio dell’offerta economica calcolato applicando la seguente formula:
Y = PT + PE
La Commissione procederà alla valutazione delle offerte tecniche e all’attribuzione del punteggio tecnico PT con riguardo alle caratteristiche tecniche migliorative rispetto a quanto previsto da Capitolato tecnico, in base ai criteri della seguente tabella.
PARAMETRI DI VALUTAZIONE DELLA QUALITÀ DELLA SOLUZIONE | PESI | |
A. CAPACITA' ORGANIZZATIVE DEL SOGGETTO PROPONENTE | ||
A1 | Adeguatezza e completezza dell’organizzazione Proposta dei razionali sottesi alla ripartizione dei servizi/attività oggetto di fornitura tra le unità operative dell’azienda concorrente ovvero tra le aziende raggruppande/consorziande/subappaltatrici/ausiliarie e le loro unità operative, in caso di RTI, consorzio, subappalto o avvalimento, descrivendo in modo chiaro gli elementi caratterizzanti ciascuna unità operativa/azienda raggruppanda/consorzianda/subappaltatrice/ausiliaria nel massimizzare l’efficacia di tale distribuzione nell’erogazione della fornitura stessa. | 3 |
A2 | Capacità di operare molteplici interventi in parallelo sul territorio nazionale garantendo un elevato livello di qualità. Soluzione organizzativa, in termini di sedi sul territorio, risorse, strumenti e modalità operative per fronteggiare picchi di attività dovuti a situazioni quali ad esempio il passaggio in esercizio di uno o più obiettivi progettuali. | 3 |
A3 | Soluzione organizzativa proposta Adeguatezza e completezza dell'organizzazione (ruoli, risorse, mix di figure professionali) al fine di garantire la massima produttività ed il rispetto dei requisiti di qualità richiesti. | 3 |
A4 | Gestione rischio e cambiamenti Soluzione organizzativa che l’impresa s’impegna a mettere in atto per garantire un adeguato grado di flessibilità per tutti i servizi. In particolare per fronteggiare situazioni determinate dalla instabilità e mutevolezza dei requisiti, da eventi imprevisti o da picchi di lavoro, anche tramite l'utilizzo di metodologie e strumenti di gestione del rischio. | 3 |
SUBTOTALE | 12 | |
B. SOLUZIONE | ||
B1 | Adeguatezza e completezza dell’Offerta Tecnica | 1 |
B2 | La soluzione architetturale e l'architettura tecnica • 2 punto:Riduzione ingombri apparati hw per le Questure • 2 Punti: Riuso delle applicazioni esistenti • 6 Punti: Qualità dell’architettura applicativa in termini di o conformità della GUI rispetto a quella attuale o completezza del modello di interazione proposto tra Questura e Centro o Scalabilità/Affidabilità o Gestione modulo “Sala Operativa” dal Centro • 3 Punti: Minimizzazione degli impatti logistici e organizzativi durante il rollout • 2 Punti: Completezza del sistema di profilazione e gestione utenze proposto in termini di o Presenza di workflow autorizzativo, configurabile o Presenza di funzione di “self-care della password” o Livello di granularità di autorizzazione | 15 |
B3 | Livello di automazione garantito dalla piattaforma software offerta | 2 |
B4 | Soluzione che l’impresa offre per il recupero dati storici e la migrazione/sincronizzazione dati nella fase di rollout e di esercizio | 3 |
B5 | Figure professionali Capo progetto max pt. 2 Progettista sistemi informatici max pt. 1 Sistemista max pt. 1 | 4 |
SUBTOTALE | 25 | |
C | ASSISTENZA | |
C1 | Soluzione progettuale proposta per l’automazione delle rilevazioni di Customer Satisfaction La soluzione, che rimarrà di proprietà dell'Amministrazione a fine contratto, deve prevedere l’utilizzo di uno strumento Open Source, un'estrema flessibilità nella costruzione di questionari, in funzione delle funzionalità e delle tipologie di utenti destinatari. La valutazione della soluzione terrà conto: - delle metodologie, strumenti, tecniche di rilevazione e di copertura dei campioni; - delle modalità di raccolta, di elaborazione e di fruizione dei dati; - degli interventi proposti a fronte dei risultati delle rilevazioni effettuate al fine di migliorare continuamente il rapporto con l'utenza. | 1,5 |
C2 | Modalità di erogazione del servizio di Manutenzione evolutiva soprattutto relativamente a strumenti, risorse e/o modalità organizzative adottate per: - la gestione dei cicli di vita degli obiettivi; - garantire la qualità del software da rilasciare e una bassa difettosità in esercizio; - l'ottimizzazione del processo di risoluzione dei malfunzionamenti sul sw rilasciato (correttive in garanzia): fino a 0,75 punti; - gestire tempestivamente le interazioni necessarie con l'Amministrazione per problematiche riscontrate in collaudo e/o con | 1,5 |
gli altri team sia in fase di avvio in esercizio sia in esercizio, al fine di evitare/limitare le interruzioni nella disponibilità del sistema: fino a 0,75 punti. | ||
SUBTOTALE | 3 | |
D. PIANO DI PROGETTO | ||
D1 | Piano di progetto Chiarezza esposistiva, tempistica delle attività, integrazioni delle fasi | 5 |
D2 | Messa in esercizio delle 104 Questure e del sistema centrale max 24 mesi (1 pt. per ogni mese in meno) | 5 |
D3 | Miglioramento SLA e Qualità del servizio “nuovo SCT” | 2 |
SUBTOTALE | 12 | |
E. DURATA DELLA MANUTENZIONE | ||
Dopo i 36 mesi a partire dall’inizio del contratto, per ogni tre mesi in più 2 punti (dovrà essere fornito il servizio di manutenzione e gestione “nuovo SCT” come specificato nel par. 5.5) | 8 | |
TOTALE | 60 |
I punti relativi all’offerta economica (PE) sarà calcolato sulla base della seguente formula:
Scn∗k+1)
PE=40 * [1-( 1 * (1-Sc) ]
Legenda:
Y = punteggio totale ottenuto;
PE = punteggio economico attribuito all’impresa
PT = punteggio ottenuto a seguito della valutazione tecnica del progetto; Pbase = è il prezzo a base d’asta;
Pofferto = è il prezzo dell’offerta in esame;
Sc=(Pbase-Pofferto)/Pbase è lo sconto espresso in centesimi; n=3,5;
k=800.
saranno considerate le prime due cifre dopo la virgola senza procedere a alcun arrotondamento (es. PE: 3,2345 punteggio attribuito 3,23)
I punteggi ottenuti dall’esame tecnico ed economico saranno quindi sommati al fine di ottenere la graduatoria finale, aggiudicando la gara alla Società che ha ottenuto il punteggio maggiore.
La gara sarà aggiudicata all’offerta che avrà conseguito la massima valutazione totale. Tutti i calcoli saranno arrotondati alla seconda cifra decimale. A parità di punteggio complessivo si proporrà l’aggiudicazione a favore dell’offerente che avrà ottenuto il maggiore punteggio tecnico.
Si procederà all'aggiudicazione anche in presenza di una sola offerta purché ritenuta valida dalla Commissione di gara.