Contract
Procedura volta alla realizzazione di un nuovo sistema informatico, denominato “G.U.S.-N.”, finalizzato all’automazione dei processi di raccolta, condivisione ed elaborazione dei dati nazionali concernenti la gestione degli Uffici Sanitari della Polizia di Stato |
Allegati al presente documento: Allegato A – “Sistema GUS” Allegato B – “Applicativo GUS-N – Requisiti Utente” Allegato C – “Dettaglio Fasi Progettuali” Allegato D – “Struttura dell’Offerta Tecnica” Allegato E – “Ampliamento CEN” |
SOMMARIO
1 Premessa e contesto di riferimento 6
1.1 Le strutture coinvolte nel progetto 6
2.2.1 Requisiti non funzionali 9
3.1 Descrizione della fornitura 10
3.1.1 Work Breakdown Structure (WBS) 11
3.2.1 Fase 1: Centralizzazione del Sistema GUS 11
3.2.1.1 Fase 1a: Infrastruttura HW/SW 11
3.2.1.2 Fase 1b: Sviluppo GUS-C 12
3.2.2 Fase 2: Xxxxxxxxxx XXX-X / Xxxxxxxx XXX-X 00
3.2.2.1 Fase 2a: Diffusione GUS-C 13
3.2.2.2 Fase 2b: Xxxxxxxx XXX-X 00
3.2.3 Fase 3: Sperimentazione e Collaudo Sistema GUS-N 14
4.1 Servizio di Conduzione Progetto 15
4.1.3 Modalità di erogazione del Servizio e caratteristiche del Prodotto 16
4.1.4 Contenuto dell’Offerta Tecnica 16
4.2 Allestimento Infrastruttura HW/SW 17
4.3 Allestimento Piattaforma SW 17
4.3.3 Modalità di erogazione del Servizio e caratteristiche del Prodotto 18
4.3.4 Contenuto dell’Offerta Tecnica 18
4.4 Allestimento Postazioni Remote 19
4.4.3 Modalità di erogazione del Servizio e caratteristiche del Prodotto 20
4.4.4 Contenuto dell’Offerta Tecnica 20
4.5 Servizio di Sviluppo Software 21
4.5.3 Modalità di erogazione del Servizio e caratteristiche del Prodotto 21
4.5.4.1 Modalità di conteggio in Punti Funzione 23
4.5.5 Contenuto dell’Offerta Tecnica 23
4.6 Servizio di Migrazione Dati 24
4.6.3 Modalità di erogazione del Servizio e caratteristiche del Prodotto 25
4.6.4 Contenuto dell’Offerta Tecnica 25
4.7 Servizio di Garanzia/Manutenzione – Infrastruttura HW/SW 25
4.8 Servizio di Garanzia/Manutenzione – Ambiente SW 26
4.8.3 Modalità di erogazione del Servizio e caratteristiche del Prodotto 27
4.8.3.1 Manutenzione Preventiva 27
4.8.3.2 Manutenzione Adeguativa 27
4.8.3.3 Manutenzione Correttiva 28
4.8.3.4 Manutenzione Evolutiva 29
4.8.4 Dimensionamento e compensi previsti 30
4.8.4.1 Manutenzione Preventiva 30
4.8.4.2 Manutenzione Adeguativa/Correttiva 30
4.8.4.3 Manutenzione Evolutiva 30
4.8.5 Contenuto dell’Offerta Tecnica 31
4.9.1.1 Fornitore subentrante 32
4.9.2 Modalità di erogazione del Servizio e caratteristiche del Prodotto 32
4.9.3 Contenuto dell’Offerta Tecnica 32
5 Piano Preliminare di Progetto 33
5.1 Piano Preliminare dei Tempi 33
5.2 Piano Preliminare delle Risorse Umane 34
5.2.1 Profili professionali – Infrastruttura HW/SW 34
5.2.2 Profili professionali – Ambienti SW 35
5.3 Piano Preliminare della Qualità 38
8.2 Manutenzione – Infrastruttura HW/SW 40
8.3 Manutenzione – Ambienti SW 40
9 Sicurezza delle Informazioni 41
10 Modalità di consegna dei prodotti e luogo di esecuzione delle attività 41
11 Modalità di presentazione delle Offerte Tecniche 42
11.1 Cause di esclusione dalla gara 42
12 Modalità di presentazione delle Offerte Economiche 42
12.2 Manutenzione – Infrastruttura HW/SW 43
12.3 Manutenzione – Ambienti SW 44
12.3.1 Manutenzione Preventiva 44
12.3.2 Manutenzione Adeguativa/Correttiva (MAC) 44
12.3.3 Manutenzione Evolutiva (MEV) 44
12.5 Tariffe figure professionali 45
13 Criteri di valutazione delle Offerte 46
13.1 Punteggio Tecnico (PT) 46
13.1.1 Componenti Hardware/Software 46
13.1.1.2 Certificazioni del personale 47
13.2 Punteggio Economico (PE) 50
1 Premessa e contesto di riferimento
A partire dal luglio 2010, a conclusione di un contratto di fornitura stipulato con una azienda di servizi informatici, l’Ufficio Sanitario Provinciale della Questura di Roma si è dotato in via sperimentale di un sistema informatico, denominato G.U.S. (Gestione Ufficio Sanitario), atto ad automatizzare la gestione dei dati sanitari relativi a tutti i dipendenti della Polizia di Stato in forza presso la stessa Questura.
Considerate le ottime risultanze di questa prima sperimentazione, la Direzione Centrale di Sanità e la Direzione Centrale per gli Affari Generali della Polizia di Stato del Dipartimento della Pubblica Sicurezza hanno congiuntamente deciso di estendere l’utilizzo dell’applicativo GUS ad ulteriori quattordici Uffici Sanitari presenti sul territorio, per eseguire una più ampia seconda fase di sperimentazione.
Riscontrando ulteriore unanime apprezzamento da parte degli Uffici Sanitari interessati nella seconda fase di sperimentazione, le suddette Direzioni Centrali hanno congiuntamente deciso di estendere l’uso del GUS a tutti gli Uffici Sanitari della Polizia di Stato presenti sul territorio nazionale, avviando il progetto denominato GUS-N (Gestione Ufficio Sanitario – Nazionale), nell’ambito del quale rientra la fornitura oggetto di questo Capitolato.
1.1 Le strutture coinvolte nel progetto
I soggetti coinvolti nel progetto GUS-N sono, principalmente, la Direzione Centrale di Sanità (DCS) e gli Uffici Sanitari della Polizia di Sato presenti sul territorio nazionale (circa 140), in veste di utenti finali, oltre che le strutture di seguito elencate:
▪ Direzione Centrale per gli Affari Generali della Polizia di Stato – Ufficio per l’Informatizzazione e l’Innovazione Tecnologica (UIIT);
▪ Centro Elettronico Nazionale della Polizia di Stato (CEN);
▪ Direzione Centrale dei Servizi Tecnico Logistici e della Gestione Patrimoniale – Ufficio Attività Contrattuale per l’Informatica, gli Impianti Tecnici e le Telecomunicazioni (UAT), precedentemente denominato Ufficio Impianti Tecnici, Telecomunicazione ed Informatica.
Nel seguito di questo Capitolato ci si riferirà a tutte le sopraddette strutture con il termine generico di “Amministrazione”.
Nel seguito di questo Capitolato verranno utilizzati diffusamente i seguenti acronimi:
ACRONIMO | Descrizione |
XXX | Xxxxxxxx Ufficio Sanitario |
XXX-X | XXX - Centralizzato |
GUS-N | GUS - Nazionale |
DCS | Direzione Centrale di Sanità |
CEN | Centro Elettronico Nazionale della Polizia di Stato di Napoli |
UAT | Ufficio Attività Contrattuale per l’Informatica, gli Impianti Tecnici e le Telecomunicazioni |
UIIT | Ufficio per l’Informatizzazione e |
ACRONIMO | Descrizione |
l’Innovazione Tecnologica | |
UPS | Ufficio della Polizia di Stato |
GPL | General Public License |
WBS | Work Breakdown Structure |
WP | Work Package o Insieme di attività |
DEC | Direttore di Esecuzione del Contratto |
DEC-CEN | Direttore di Esecuzione del Contratto per il Centro Elettronico Nazionale |
DEC-DCS | Direttore di Esecuzione del Contratto per la Direzione Centrale di Sanità |
Responsabile dei Servizi Applicativi | Referente, lato Fornitore, per il DEC-DCS, per le attività legate allo sviluppo del software. |
Responsabile dei Servizi CEN | Referente, lato Fornitore, per il DEC-CEN, per le attività svolte presso il CEN di Napoli. |
SAL | Stato Avanzamento Lavori |
RDBMS | |
MAC | Manutenzione Correttiva |
MEV | Manutenzione Evolutiva |
FP | Function Point |
HW | hardware |
SW | software |
FW | firmware |
SAN | Storage Area Network |
2 Finalità del progetto
Il Progetto GUS-N è un’iniziativa mirata alla reingegnerizzazione del sistema informatico denominato GUS, di proprietà della Amministrazione, per renderlo idoneo ad un uso esteso a livello nazionale, anziché locale, come avviene attualmente, ed alla parziale modifica/integrazione delle funzionalità dell’applicativo software GUS, parte integrante del suddetto sistema.
Il sistema GUS, in possesso della Amministrazione ed oggetto della originaria fornitura del 2009, consta di una virtual appliance costituita da una architettura software basata integralmente su licenze open source.
Elemento principale del sistema GUS è l’omonimo applicativo, sviluppato ad hoc dalla software house a cui è stata affidata la fornitura. Come stabilito dall’originario contratto, il codice sviluppato è oggi di esclusiva proprietà della Amministrazione.
Per i dettagli relativi al sistema GUS, ed alle funzionalità dell’omonimo applicativo, si veda l’allegato A – “Sistema GUS”.
Partendo dall’attuale sistema GUS, il progetto GUS-N mira a sviluppare e diffondere su tutto il territorio nazionale l’uso del nuovo omonimo sistema.
Per chiarezza espositiva, nel seguito di questo Capitolato ci si riferirà al Sistema GUS-N come all’insieme di tutte le componenti riportate nello schema seguente:
Come evidenziato nello schema, i due macroelementi principali costituenti il Sistema GUS-N sono l’Infrastruttura HW/SW, composta da elementi hardware a cui verrà direttamente sovrapposta la piattaforma di virtualizzazione (Hypervisor di tipo 1), e due Ambienti SW (virtual appliance), composti da una piattaforma totalmente virtualizzata su cui dovrà girare l’applicativo software GUS-N, sviluppato nel corso del progetto.
Il Sistema GUS-S dovrà essere realizzato nel rispetto dei requisiti funzionali e non funzionali di seguito descritti.
2.2.1 Requisiti non funzionali
La componente hardware e software del Sistema GUS-N dovranno essere progettate e realizzate al fine di soddisfare tutti i seguenti principali requisiti non funzionali:
• le componenti principali del Sistema dovranno essere installate ed attivate presso il Centro Elettronico Nazionale della Polizia di Stato sito in Napoli, nel pieno rispetto delle caratteristiche dell’infrastruttura HW/SW in esso presente, al fine di garantire una totale integrazione;
• la componente sw del Sistema dovrà essere accessibile in modalità web, tramite la sola rete intranet della Polizia di Stato (Ministero dell’Interno), diffusa sul territorio nazionale;
• il Sistema dovrà essere capace di garantire in esercizio la stessa fluida esperienza d’uso dell’attuale GUS, servendo circa mille utenti, di cui almeno la metà in maniera concorrente; in tale ottica, dovrà essere in grado di gestire, con tempi di risposta ragionevoli, le schede di tutti i dipendenti della Polizia di Stato in esso contenute (circa 100.000 ÷ 110.000, con un tasso di crescita annuo dell’1%), sia per le normali funzionalità di gestione che per le più evolute funzioni statistiche;
• il Sistema dovrà prevedere la simultanea esistenza di un ambiente di esercizio/produzione e di un secondo ambiente di test, di ridotte capacità rispetto al primo ma funzionalmente analogo, che, un volta ultimato il progetto, verrà utilizzato per svolgere attività di formazione; questo ambiente dovrà essere in grado di servire almeno cinquanta utenti in maniera concorrente, gestendo almeno un centinaio di schede pazienti;
• il Sistema dovrà essere sviluppato nel pieno rispetto del D.Lgs. 196/03, per quanto concerne il trattamento di dati sensibili tramite l’ausilio di strumenti elettronici;
• le Piattaforme e gli Applicativi sw del Sistema dovranno essere interamente basate su software concesso in licenza GPL (General Public License), secondo standard non proprietari;
• l’Applicativo GUS-N dovrà essere realizzato mantenendo per quanto possibile lo stesso aspetto grafico dell’applicativo GUS (interfaccia utente, UI) e riutilizzando, laddove possibile, il codice sorgente per quest’ultimo sviluppato;
• l’intero Sistema dovrà essere progettato per garantire la sua totale sostenibilità per almeno tre anni (ciclo di vita del sistema) successivi alla data di positivo collaudo finale, allo scopo di evitare alla Amministrazione di dover sostenere ulteriori spese per il suo mantenimento, a parte quelle di gestione ordinaria, oltre l’investimento associato al presente appalto.
Ulteriori requisiti non funzionali di dettaglio verranno specificati nel seguito del Capitolato, soprattutto per quanto concerne la componete hardware del Sistema.
Per i dettagli relativi ai requisiti utente dell’Applicativo GUS-N, insieme con lo schema dati, necessari per la definizione puntuale dei requisiti funzionali si veda l’allegato B – “Sistema GUS-N – Requisiti Utente”.
Oltre agli specifici requisiti suddetti, si ribadisce che dovranno essere presi in considerazione, da un punto di vista funzionale, anche i dettami imposti dal D.Lgs. 196/03, per quanto concerne il trattamento di dati sensibili tramite l’ausilio di strumenti elettronici.
3 Ambito della fornitura
Nell’Ambito del progetto GUS-N, portato avanti dalla Amministrazione, diverse attività richiedono il coinvolgimento di un Fornitore esterno: il complesso di queste attività definisce, nel suo insieme, l’Ambito della Fornitura.
3.1 Descrizione della fornitura
L’oggetto della fornitura, costituito dal complesso dei beni forniti e servizi erogati dal Fornitore nel corso del progetto, rappresenta il risultato delle attività comprese nell’Ambito delle Fornitura.
I diversi elementi costituenti l’oggetto suddetto sono quelli di seguito elencati, che verranno meglio dettagliati successivamente in questo Capitolato:
• Servizio di Conduzione Progetto: servizio professionale erogato dal fornitore finalizzato al corretto coordinamento di tutte le attività progettuali ad esso affidate, ed alla concordata gestione dei rapporti con l’Amministrazione;
• Allestimento Infrastruttura HW/SW: allestimento, presso il Centro Elettronico Nazionale (CEN) della Polizia di Stato con sede in Napoli, dell’intera architettura (hardware e software) costituente la piattaforma sopra la quale poggerà l’Ambiente SW del sistema GUS-N; tale architettura dovrà essere perfettamente integrata in quella del CEN;
• Allestimento Piattaforma SW: allestimento, presso il Centro Elettronico Nazionale (CEN) della Polizia di Stato con sede in Napoli, dell’architettura software costituente la piattaforma alla base dell’Ambiente di Test e di Esercizio (o Produzione) su cui girerà l’Applicativo GUS-N;
• Allestimento Postazioni Remote: allestimento delle postazioni remote collegate all’Ambiente SW del Sistema GUS-N presso la Direzione Centrale di Sanità (DCS) ed, eventualmente, presso una ulteriore ufficio della Polizia di Stato;
• Servizio di Sviluppo Software: servizi professionali erogati dal fornitore finalizzati allo sviluppo, test ed installazione dell’Applicativo software GUS-N;
• Servizio di Migrazione Dati: migrazione nel nuovo Sistema GUS-N dei dati presenti nelle istanze del GUS attualmente diffuse sul territorio nazionale;
• Servizio di Garanzia/Manutenzione:
o Infrastruttura HW/SW: servizi professionali erogati dal Fornitore al fine di effettuare gli opportuni interventi di manutenzione sull’Infrastruttura hardware e software del Sistema GUS-N;
o Ambiente SW: servizi professionali erogati dal Fornitore al fine di effettuare gli opportuni interventi di manutenzione, eventualmente anche correttiva, sulla Piattaforma SW e l’Applicativo GUS-N;
nell’ambito del progetto sono previste solo le attività di avvio di tali servizi, che proseguiranno oltre la sua conclusione per tutto il ciclo di vita del Sistema GUS-N;
• Trasferimento Know-How: trasferimento, al termine dell’appalto, di tutto il know-how di progetto a personale della Amministrazione o di altra società privata subentrante.
3.1.1 Work Breakdown Structure (WBS)
Di seguito viene mostrata una sintetica WBS complessiva del Progetto GUS-N, che verrà successivamente decomposta secondo le tre fasi previste per la sua realizzazione.
SISTEMA GUS-N |
1. UFFICIO AMMINISTRAZIONE GUS-N c/o DCS 2. INFRASTRUTTURA HW/SW c/o CEN 2.1 Infrastruttura HW 2.2 Infrastruttura SW 3. AMBIENTI SW 3.1 Ambiente di Esercizio 3.2 Ambiente di Test 4. POSTAZIONI REMOTE 4.1 Postazione primaria c/o DCS 4.2 Postazione secondaria 5. APPLICATIVO SOFTWARE GUS-N 6. GESTIONE CONTRATTO |
L’insieme delle attività costituenti l’Ambito della Fornitura sono contenute nelle seguenti tre fasi progettuali.
3.2.1 Fase 1: Centralizzazione del Sistema GUS
Questa fase di progetto si compone di due sottofasi che dovranno svolgersi parzialmente in parallelo, poiché correlate.
3.2.1.1 Fase 1a: Infrastruttura HW/SW
L’obiettivo di questa sottofase è quello di realizzare tutta l’Infrastruttura HW/SW del Sistema GUS-N.
3.2.1.2 Fase 1b: Sviluppo GUS-C
L’obiettivo principale di questa sottofase è quello di realizzare l’Ambiente SW del GUS-N e l’Applicativo GUS-C (GUS – Centralizzato), come risultato della reingegnerizzazione dell’attuale sistema GUS (come detto, costituito da una virtual appliance), al fine di renderlo idoneo ad una gestione centralizzata. In questa sotto fase, inoltre, dovranno essere predisposte le postazione di lavoro capaci di operare da remoto sugli ambienti sw installati al CEN (Postazioni Remote), al fine di ridurre al minimo la necessità di intervento su Napoli .
Al termine di questa fase dovrà essere complessivamente disponibile al collaudo il Sistema GUS-C, costituito dalla medesima Infrastruttura hw/sw e l’Ambiente sw del sistema finale GUS-N, su cui dovrà girare un applicativo informatico (Applicativo GUS-C) che riproduca le sole funzionalità principali dell’attuale GUS, opportunamente modificate.
Si riporta, di seguito, la WBS ed la configurazione del sistema risultante al termine di questa fase del progetto (gli insiemi di attività (WP) riportati in corsivo non sono parte dell’Ambito della Fornitura, poiché per essi non è prevista la partecipazione del Fornitore).
1. CENTRALIZZAZIONE SISTEMA GUS | DELIVERABLE DI FASE |
1.1 UFFICIO AMM. GUS-N c/o DCS 1.2 INFRASTRUTTURA HW/SW c/o CEN 1.2.1 Infrastruttura HW 1.2.2 Infrastruttura SW 1.3 AMBIENTE SW GUS-C 1.3.1 Piattaforma SW 1.3.2 Applicativo SW 1.4 POSTAZIONI REMOTE 1.4.1 Postazione Remota c/o DCS 1.4.2 Postazione Remota c/o Uff. P.S. 1.5 GESTIONE CONTRATTO 1.5.1 Piano di Progetto definitivo 1.5.2 Stato Avanzamento Lavori 1.5.3 Verifica Fornitura 1.5.4 Avvio Garanzia/Manutenzione Infrastruttura HW/SW |
Per i dettagli relativi alle attività previste in questa fase, le loro reciproche dipendenze, la loro durata ed il grado di coinvolgimento del Fornitore richiesto per ognuna di esse, si faccia riferimento all’Appendice C – “Dettaglio Fasi Progettuali”.
3.2.2 Fase 2: Diffusione GUS-C / Sviluppo GUS-N
Questa fase di progetto si compone di due sottofasi che dovranno svolgersi in parallelo, poiché correlate.
3.2.2.1 Fase 2a: Diffusione GUS-C
L’obiettivo di questa sottofase è quello di diffondere l’uso del Sistema GUS-C a tutti gli Uffici Sanitari che attualmente utilizzano localmente il sistema GUS. L’onere principale che avrà il Fornitore, nel corso di questa sottofase, sarà la migrazione e l’allineamento dei dati presenti nei diversi GUS locali, prima di rendere il GUS-C utilizzabile da ogni singolo Ufficio Sanitario.
Questa sottofase, inoltre, fungerà da sperimentazione allargata del Sistema GUS-C, nel corso della quale verranno raccolte le possibili segnalazioni di malfunzionamenti e/o richieste di modifica pervenute dai suddetti Uffici Sanitari, per la successiva analisi ed eventuale approvazione.
3.2.2.2 Fase 2b: Sviluppo GUS-N
L’obiettivo di questa sottofase è quello di sviluppare le nuove funzionalità previste per l’Applicativo GUS-N, a partire dal GUS-C realizzato nella fase precedente del progetto; tale integrazione dovrà essere resa disponibile nel solo ambiente di test.
In questa sottofase, inoltre, verranno eseguite le modifiche al GUS-C richieste ed approvate nella parallela sottofase di diffusione. Come sviluppate, tali modifiche dovranno essere sia rese disponibili immediatamente nell’ambiente di produzione, dove risiede il GUS-C, sia integrate nel nascente applicativo GUS-N.
Si riporta, di seguito, la WBS ed la configurazione del sistema risultante al termine di questa fase del progetto (gli insiemi di attività (WP) riportati in corsivo non sono parte dell’Ambito della Fornitura, poiché per essi non è prevista la partecipazione del Fornitore).
2. DIFFUSIONE GUS-C / SVILUPPO GUS-N | DELIVERABLE DI FASE |
2.1 DIFFUSIONE GUS-C 2.1.1 Attivazione GUS-C beta (Migrazione Dati GUS) 2.1.2 Modifiche GUS-C 2.2 APPLICATIVO GUS-N 2.2.1 Sviluppo GUS-N beta 2.2.2 Modifiche GUS-C 2.3 GESTIONE CONTRATTO 2.3.1 Revisione Piano di Progetto 2.3.2 Stato Avanzamento Lavori 2.3.3 Validazione Fornitura |
Per i dettagli relativi alle attività previste in questa fase, le loro reciproche dipendenze, la loro durata ed il grado di coinvolgimento del Fornitore richiesto per ognuna di esse, si faccia riferimento all’Appendice C – “Dettaglio Fasi Progettuali”.
3.2.3 Fase 3: Sperimentazione e Collaudo Sistema GUS-N
In questa fase di progetto verrà inizialmente reso disponibile il nuovo Sistema GUS-N agli Uffici Sanitari utilizzatori del GUS-C, al fine di eseguirne una più allargata sperimentazione, alla conclusione della quale verrà effettuato il collaudo finale del sistema ed il successivo avvio della capillare diffusione del GUS-N a tutti gli Uffici Sanitari nazionali. Nel corso della sperimentazione, qualora fosse rilevato qualche malfunzionamento, il Fornitore dovrà provvedere ad eseguire le necessarie modifiche correttive.
Si riporta, di seguito, la WBS ed la configurazione del sistema risultante al termine di questa fase del progetto (gli insiemi di attività (WP) riportati in corsivo non sono parte dell’Ambito della Fornitura, poiché per essi non è prevista la partecipazione del Fornitore).
3. SPERIMENTAZIONE E COLLAUDO GUS-N | DELIVERABLE DI FASE |
3.1 APPLICATIVO XXX-X 0.0.0 XXX-X beta 3.1.2 XXX-X Xxxxxx 0.0 XXXXXXXXXX XXX-X 3.2.1 Formazione Personale XX.XX. 3.2.2 Attivazione Utenze 3.3 GESTIONE CONTRATTO 3.3.1 Revisione Piano di Progetto 3.3.2 Stato Avanzamento Lavori 3.3.3 Verifica Fornitura 3.3.4 Avvio Garanzia/Manutenzione Ambienti SW |
Per i dettagli relativi alle attività previste in questa fase, le loro reciproche dipendenze, la loro durata ed il grado di coinvolgimento del Fornitore richiesto per ognuna di esse, si faccia riferimento all’Appendice C – “Dettaglio Fasi Progettuali”.
4 Oggetto della Fornitura
Come anticipato, i diversi elementi costituenti l’Oggetto della Fornitura sono quelli di seguito elencati:
- Servizio di Conduzione Progetto;
- Allestimento Infrastruttura HW/SW;
- Allestimento Piattaforma SW;
- Allestimento Postazioni Remote;
- Servizio di Sviluppo Software;
- Servizio di Migrazione Dati;
- Servizio di Garanzia/Manutenzione;
- Trasferimento Know-How.
Nel seguito di questo capitolo, ognuno dei sopra elencati servizi verrà meglio dettagliato, specificando per ognuno di essi quali siano gli specifici obiettivi, vincoli, modalità di erogazione e caratteristiche del prodotto richieste, e cosa debba essere inserito nell’Offerta per la loro valutazione ai fini della selezione del fornitore.
4.1 Servizio di Conduzione Progetto
L’obiettivo del Servizio di Conduzione Progetto è la gestione integrata di tutte le attività costituenti l’Ambito della Fornitura, definite nel contratto.
Ferma restando la forte correlazione di tutte attività contenute nell’ambito della fornitura, il Fornitore dovrà distinguere nettamente le attività di conduzione progettuale per quelle legate agli interventi da svolgere presso il CEN, finalizzate all’allestimento dell’Infrastruttura HW/SW, e per tutte quelle legate alla realizzazione degli applicativi software; in tale ottica, il Fornitore dovrà designare due distinti responsabili della Fornitura, a cui nel seguito di questo Capitolato ci si riferirà, rispettivamente, come Responsabile dei Servizi CEN e Responsabile dei Servizi Applicativi.
I due soggetti suddetti, formalmente designati dal Fornitore all’inizio della Fornitura, dovranno possedere una comprovata competenza nella conduzione di progettualità simili a quelle che cadranno sotto la propria responsabilità; tali competenze, viste come l’insieme di conoscenze ed esperienza, saranno oggetto di valutazione ai fini dell’assegnazione della gara.
Uno dei compiti principali di entrambi i Responsabili sopra indicati sarà quello di fungere da referenti unici per tutte le attività contenute nel proprio ambito di competenza, mantenendo un canale di comunicazione costantemente aperto con l’Amministrazione che, a tal fine, designerà due distinti Direttori di Esecuzione del Contratto (rispettivamente, DEC-CEN e DEC-DCS), con il compito di seguire la corretta realizzazione della Fornitura, oltre che sottoscrivere e validare tutti i deliverable finali ed intermedi (validazione deliverable).
Si precisa che, per quanto riguarda le attività di collaudo, l’Amministrazione nominerà una o più specifiche Commissioni che verificheranno la corretta esecuzione della Fornitura (Verifica Fornitura).
In generale, la gestione dell’intero progetto dovrà essere accompagnata da un dettagliato Piano di Progetto, la cui versione definitiva dovrà essere consegnata all’Amministrazione successivamente alla stipula del contratto, approfondendo quanto riportato nel Piano Preliminare di Progetto contenuto nell’Offerta Tecnica. In tale ottica, in fase esecutiva del progetto, sarà onere dei due Responsabili per la Fornitura coordinarsi reciprocamente nello svolgimento di tutte quelle attività logicamente o sequenzialmente correlate, ricadenti sotto i rispettivi ambiti di competenza.
Nella eventualità in cui il Fornitore abbia la necessità di sostituire uno dei responsabili della Fornitura, durante l’esecuzione del Progetto, questi dovrà proporre una figura professionale di pari (o superiore) livello, che sostituirà la precedente solo dopo formale accettazione da parte della Amministrazione.
Il Servizio di Conduzione del Progetto è previsto per tutta la durata del Progetto.
Relativamente al Servizio di Conduzione Progetto, l’oggetto della Fornitura si compone dei seguenti elementi:
• il Piano di Progetto, costantemente aggiornato, contenente le baseline di progetto;
• una versione elettronica del crono-programma di progetto, costantemente aggiornata, su software di Project Management;
• una licenza d’uso del software di cui al precedente punto, nel caso in cui
o questo non venga fornito con licenza freeware o GPL;
o non venga utilizzato un software di Project Management in versione Server, messo a disposizione dal Fornitore via rete Internet, per accedere al quale venga fornita una utenza alla Amministrazione, per tutta la durata del Progetto;
• un periodico resoconto sullo stato di avanzamento dei lavori (SAL), contenente i punti stabiliti congiuntamente tra le parti, all’inizio di ogni fase del Progetto.
4.1.3 Modalità di erogazione del Servizio e caratteristiche del Prodotto
Ogni responsabile della Fornitura, designato dal Fornitore, dovrà fungere da referente diretto del rispettivo DEC, per le tutte le attività costituenti l’Ambito della Fornitura, segnalando, in maniera soprattutto proattiva, eventuali scostamenti dell’effettivo andamento delle attività in esecuzione, rispetto alle ultime baseline di progetto approvate.
Particolare attenzione, da parte dei responsabili della Fornitura, dovrà essere posta sulla corretta gestione delle modifiche e sul rispetto delle modalità di comunicazione prestabilite (contenuti, destinatari, tempi, strumenti di comunicazione), soprattutto per quanto concerne i SAL.
A partire dal Piano Preliminare di Xxxxxxxx, i responsabili della Fornitura dovranno redigere congiuntamente un Piano di Progetto definitivo da consegnare ad entrambi i DEC per l’approvazione, entro dieci giorni lavorativi successivi alla stipula del contratto. I contenuti del Piano di Progetto dovranno essere concordati con i rispettivi DEC, prima che questo venga consegnato per ottenerne la formale approvazione finale.
Ogni Responsabile della Fornitura, inoltre, dovrà mantenere costantemente aggiornato, nel corso di tutto il progetto, il Piano di Progetto e le baseline (tramite un software di project management), apportando le modifiche solo dopo averle concordate con il rispettivo DEC.
Per quanto riguarda i contenuti del Piano Preliminare di Progetto, che dovrà essere inserito nell’Offerta Tecnica, si faccia riferimento al relativo capitolo contenuto in questo Capitolato.
4.1.4 Contenuto dell’Offerta Tecnica
Relativamente al Servizio di Conduzione Progetto, l’Offerta Tecnica dovrà contenere i seguenti elementi:
• una sintetica descrizione dei metodi/metodologie di project management genericamente adottati dall’Offerente per la conduzioni dei progetti;
• le indicazioni relative alle risorse umane che verranno impiegate per questo servizio (team di project management), nelle modalità specificate nel successivo paragrafo Piano Preliminare delle Risorse Umane;
• il Curriculum Vitae, in formato europeo, rigorosamente anonimo, delle figure professionali che verranno designate come Responsabile dei Servizi CEN e Responsabile dei Servizi Applicativi;
• le caratteristiche del software di project management proposto, con i dettagli relativi alla licenza;
• una proposta di report per lo stato di avanzamento lavori (SAL).
Al prodotto/servizio sopra descritto fanno riferimento i seguenti insiemi di attività (WP):
Codice | Denominazione |
1.5 | GESTIONE CONTRATTO |
2.3 | GESTIONE CONTRATTO |
3.3 | GESTIONE CONTRATTO |
4.2 Allestimento Infrastruttura HW/SW
Per i dettagli relativi a questo servizio si veda la relativa sezione contenuta nell’Allegato E – “Ampliamento CEN”
Per questo servizio fungeranno da referenti il DEC-CEN, lato Amministrazione, e il Responsabile dei Servizi CEN, lato Fornitore.
Al prodotto/servizio sopra descritto fanno riferimento i seguenti insiemi di attività (WP):
Codice | Denominazione |
1.2 | INFRASTRUTTURA HW/SW c/o CEN |
4.3 Allestimento Piattaforma SW
L’allestimento della Piattaforma SW prevede la fornitura delle componenti costituenti l’architettura proposta sia per l’Ambiente di Test che per quello di Esercizio (o Produzione), e l’esecuzione di tutte le operazioni necessarie all’allestimento di tali architetture virtualizzate sull’Infrastruttura HW/SW precedentemente predisposta presso il CEN.
Si precisa che, dopo la chiusura del Progetto, l’Ambiente di Test dovrà rimanere attivo per essere utilizzato come Ambiente di Formazione.
Le figure professionali indicate dall’Offerente per l’esecuzione delle suddette operazioni dovranno possedere una comprovata conoscenza ed esperienza nello specifico settore legato a queste attività, che saranno oggetto di valutazione ai fini dell’assegnazione della gara.
Per quanto concerne i vincoli temporali per l’esecuzione di questo insieme di attività, farà fede quanto stabilito in questo Capitolato e, successivamente, le baseline dei tempi di progetto concordate
definitivamente dopo la stipula del Contratto, a partire dai contenuti dell’Offerta Tecnica. Il mancato rispetto dei tempi concordati comporterà l’applicazioni di penali, qualora i ritardi non siano giustificati.
Si ribadisce che, oltre i costi legati al servizio di manutenzione previsto in questo Capitolato, l’Offerta dovrà prevedere la totale copertura delle spese di mantenimento delle Piattaforme SW per tutto il ciclo di vita del Sistema.
Relativamente all’allestimento delle Piattaforme SW, l’oggetto della Fornitura si compone dei seguenti elementi:
• tutto i software (sistemi operativi, web server, RDBMS, application server, etc.) necessari per il corretto allestimento di entrambe le piattaforme;
• il servizio di installazione e configurazione (tuning), da eseguirsi principalmente presso il CEN di Napoli;
• un documento che descriva l’architettura costituente la Piattaforma sw dell’Ambiente di Test e di quello di Esercizio/Produzione (questo documento verrà utilizzato anche per il Collaudo dell’Sistema GUS-N).
4.3.3 Modalità di erogazione del Servizio e caratteristiche del Prodotto
Per questo servizio fungeranno da referenti il DEC-DCS, lato Amministrazione, e il Responsabile dei Servizi Applicativi, lato Fornitore.
Le Piattaforme SW degli Ambienti di Test e di Esercizio (o Produzione) dovranno essere allestite sull’Infrastruttura HW/SW oggetto di questa Fornitura, precedentemente predisposta presso il Centro Elettronico Nazionale della Polizia di Stato di Napoli.
Le risorse virtuali (nr. CPU, memoria RAM, spazio disco, etc.) che saranno effettivamente dedicate alle Piattaforme SW saranno stabilite nel dettaglio congiuntamente tra l’Amministrazione ed il Fornitore, partendo da quanto proposto in Offerta tecnica. Discorso analogo varrà per lo spazio disco che verrà effettivamente riservato al GUS-N tramite SAN (Storage Area Network) del CEN, dedicato alla memorizzazione dei dati associati al solo Ambiente SW di Esercizio.
Le Piattaforme software del Sistema GUS-C/N dovranno prevedere le tre componenti logiche tradizionali di una applicativo web: web server, application server e RDBMS. Xxxxx restando i concetti propri dei sistemi di virtualizzazione, non sono imposti vincoli sulla separazione delle componenti logiche suddette (suddivisione in macchine virtuali distinte).
Per il dimensionamento delle componenti in termini di risorse, si consideri quanto specificato tra i requisiti in questo Capitolato (cfr. Requisiti prestazionali o non funzionali).
Si precisa che tutto il software necessario per l’allestimento di entrambe le Piattaforme degli ambienti dovrà essere fornito con licenza GPL (General Public License).
4.3.4 Contenuto dell’Offerta Tecnica
Relativamente all’Allestimento dell’Ambiente di Sistema, l’Offerta Tecnica dovrà contenere i seguenti elementi:
• una descrizione della architettura che si propone di allestire per realizzare le due piattaforme previste, specificando se verranno realizzate macchine virtuali integrate o distinte per le varie componenti logiche (web server, application server, RDBMS); tale descrizione dovrà essere comprensiva delle motivazioni che hanno portato alla scelta proposta, soprattutto nell’ottica della stabilità e delle performance attese;
• le specifiche risorse computazionali assegnate ad ognuna delle macchine virtuali che verranno generate per implementare i suddetti componenti, nei limiti dell’Infrastruttura HW/SW del Sistema;
• lo spazio di storage che si ritiene dovrà essere riservato sulla SAN utile per un utilizzo del sistema almeno decennale, facendo una stima di transazioni annuali e peso delle stesse (dato utile solo per una stima preventiva, non oggetto di valutazione da parte della Commissione di Gara);
• i software di base che verranno utilizzati per implementare i suddetti componenti, nel rispetto dei vincoli imposti (devono essere chiaramente indicati i riferimenti per verificare la compatibilità dei software forniti con l’Infrastruttura SW sottostante);
• le indicazioni relative alle risorse umane che verranno impiegate per questo servizio, nelle modalità specificate nel successivo paragrafo Piano Preliminare delle Risorse Umane;
• le indicazioni relative ai tempi di esecuzione di questo servizio, nelle modalità specificate nel successivo paragrafo Piano Preliminare dei Tempi.
Al prodotto/servizio sopra descritto fanno riferimento i seguenti insiemi di attività (WP):
Codice | Denominazione |
1.3.1 | Piattaforma SW |
4.4 Allestimento Postazioni Remote
Al fine di limitare al massimo le attività presso il CEN della Polizia di Stato, una volta allestite le Piattaforme SW presso tale struttura, dovrà essere predisposta una postazione remota ad esse collegata presso la Direzione Centrale di Sanità, sita in Xxxx (Xxxxxx Xxxxxxxx Xxxxxxxx XX, 00), attraverso la quale dovranno essere svolte tutte le attività di istallazione e configurazione dei moduli costituenti l’Applicativo GUS-C/N, che verranno sviluppati nel corso della Fornitura.
La suddetta postazione dovrà essere utilizzata per la gestione in remoto sia dell’Ambiente di Test che di quello di Esercizio/Produzione, e dovrà essere mantenuta attiva anche per lo svolgimento delle attività di manutenzione, previste a conclusione del progetto (cfr. Servizio di Garanzia/Manutenzione per gli Ambienti SW); si precisa che tramite detta postazione non sarà in alcun modo possibile intervenire da remoto sulla configurazione dell’Infrastruttura HW/SW del Sistema GUS-N.
Inoltre, qualora lo ritenga opportuno, il Fornitore sarà autorizzato ad utilizzare la postazione remota anche come ambiente di sviluppo dell’Applicativo GUS-C/N.
Oltre alla postazione remota da allocarsi presso la Direzione Centrale di Sanità, il Fornitore avrà la possibilità di allestire una ulteriore postazione remota presso un diverso ufficio della Polizia di Stato (da concordare successivamente alla stipula del Contratto), che risulti maggiormente vicino alla sede del Fornitore, al fine di rendere più agevoli e veloci gli interventi sul Sistema (soprattutto per i servizi di manutenzione). Per questa seconda postazione remota valgono le stesse prescrizioni sopra specificate per quella prevista presso la Direzione Centrale di Sanità.
Si specifica che anche le postazioni remote sono da considerarsi parte integrante del Sistema GUS-N, per cui al temine del Progetto rimarranno di proprietà della Amministrazione e dovranno essere oggetto di manutenzione per tutto il ciclo di vita per esso previsto.
Relativamente all’allestimento delle postazioni remote, l’oggetto della Fornitura si compone dei seguenti elementi:
• tutte le risorse hardware (PC, Monitor, etc.) e software (licenze del sistema operativo e degli applicativi installati) necessarie per l’allestimento delle postazioni;
• servizio di allestimento e configurazione della postazione remota presso la Direzione Centrale di Sanità;
• servizio di allestimento e configurazione della postazione remota presso un ulteriore ufficio della Polizia di Stato, se richiesto dal Fornitore;
• un documento che descriva le caratteristiche e la configurazione delle postazioni.
4.4.3 Modalità di erogazione del Servizio e caratteristiche del Prodotto
Per questo servizio fungeranno da referenti principalmente il DEC-DCS, lato Amministrazione, e il Responsabile dei Servizi Applicativi, lato Fornitore, fermo restando, qualora risultasse necessario, il supporto degli altri responsabili di progetto.
I tempi e le modalità di installazione delle postazioni remote dovranno essere concordate tra il Responsabile della Fornitura e quello di Contratto; quest’ultimo garantirà al Fornitore l’adeguato supporto per il completamento della attività (supporto logistico, parametri di configurazione di rete, etc.).
Non ci sono particolari prescrizioni relative alle risorse hardware e software delle postazioni informatiche da installare, purché esse siano nuove ed adeguate all’esecuzioni dei compiti indicati.
La posizione della seconda postazione remota, se richiesta dal Fornitore, non potrà essere garantita dall’Amministrazione in qualsiasi ufficio della Polizia di Stato (UPS) presente sul territorio, per cui dovrà essere oggetto di accordo tra le parti, successivamente alla stipula del contratto. L’orientamento, in ogni caso, è che tale seconda postazione venga installata presso la sede di un Ufficio Sanitario.
Per questa seconda postazione, si richiede che il terminale fornito sia di tipologia “portatile” (Notebook).
4.4.4 Contenuto dell’Offerta Tecnica
Relativamente alle postazioni remote, l’Offerta Tecnica dovrà contenere i seguenti elementi:
• la descrizione delle caratteristiche hardware e software delle postazioni remote fornite;
• la dichiarazione attestante la necessità di allestire la seconda postazione remota, oltre quella presso la Direzione Centrale di Sanità, con una indicazione della provincia/comune dove si vorrebbe fosse installata;
• la dichiarazione attestante l’eventuale utilizzo di una delle postazioni remote come ambiente di sviluppo software;
• le indicazioni relative alle risorse umane che verranno impiegate per questo servizio, nelle modalità specificate nel successivo paragrafo Piano Preliminare delle Risorse Umane;
• le indicazioni relative ai tempi di esecuzione di questo servizio, nelle modalità specificate nel successivo paragrafo Piano Preliminare dei Tempi.
Al prodotto/servizio sopra descritto fanno riferimento i seguenti insiemi di attività (WP):
Codice | Denominazione |
1.4 | POSTAZIONI REMOTE |
4.5 Servizio di Sviluppo Software
L’obiettivo del servizio di sviluppo software richiesto al Fornitore è la realizzazione dell’Applicativo GUS-N, secondo i requisiti descritti in precedenza in questo documento ed i relativi allegati.
Come meglio illustrato nella descrizione delle fasi progettuali, questo servizio dovrà essere erogato inizialmente per la realizzazione dell’Applicativo GUS-C e, successivamente, per il GUS-N.
La fase di sviluppo dell’applicativo dovrà prevedere una intensa attività di coordinamento tra il Responsabile dei Servizi Applicativi ed il DEC-DCS, al fine di arrivare ad un risultato finale pienamente concorde con i requisiti funzionali e prestazionali.
Relativamente al servizio di sviluppo software, l’oggetto della Fornitura si compone dei seguenti elementi:
• l’attività di sviluppo del codice, seguendo un metodo iterativo-incrementale, svolta autonomamente dal Fornitore sull’ambiente di sviluppo;
• semilavorati dell’Applicativo GUS-C/N, installati nell’Ambiente di Test ed, eventualmente,in quello di Esercizio;
• un documento che descriva le funzionalità dell’applicativo sotto forma di dettagliati test funzionali, denominato Piano dei Test Funzionali, collegato a quello sui requisiti utente fornito unitamente a questo Capitolato, redatto anch’esso in modo iterativo-incrementale parallelamente allo sviluppo del software (il Piano dei Test Funzionali verrà utilizzato anche per le attività di collaudo);
• il codice sorgente dell’Applicativo GUS-N, una volta terminato il Progetto, che diverrà di esclusiva proprietà della Amministrazione (aggiornato durante gli interventi di manutenzione);
• le risultanze della copertura del codice (code coverage) ottenuta attraverso i test specificati nel Piano dei Test Funzionali;
• le risultanze di una serie di test di carico svolti sull’Ambiente di Esercizio, che confermino la rispondenza del Sistema GUS-N ai requisiti prestazionali;
• tutta la documentazione necessaria per il conteggio dei punti funzione effettivamente sviluppati, conformemente allo standard stabilito (cfr. Modalità di conteggio in Punti Funzione).
4.5.3 Modalità di erogazione del Servizio e caratteristiche del Prodotto
Lo sviluppo software dell’Applicativo GUS-C/N, in tutte le fasi del Progetto, così come nel corso degli interventi di manutenzione correttiva (MAC) e evolutiva (MEV), dovrà seguire un metodo iterativo ed incrementale.
Alle attività di scrittura del codice, svolte autonomamente dal Fornitore, dovrà essere sempre premesso un accordo tra il Responsabile dei Servizi Applicativi ed il DEC-DCS, avente l’obiettivo di:
1. stabilire quali requisiti utente sviluppare nel corso della successiva iterazione, in base alle priorità da quest’ultimo indicate (fatti salvi eventuali vincoli di concatenazione);
2. definire dettagliatamente i requisiti funzionali, associati a quelli utente che si è stabilito di sviluppare.
Inoltre, definiti i requisiti da sviluppare, sempre in premessa alla fase di scrittura del codice, il Responsabile dei Servizi Applicativi dovrà fornire al DEC-DCS una stima dei punti funzione che verranno consumati e del tempo che verrà impiegato per produrre il semilavorato.
ATTIVITÀ PREVISTE PER SINGOLA ITERAZIONE
Al termine di ogni iterazione, il Fornitore dovrà produrre un semilavorato da istallare nell’Ambiente di Test, dove sarà oggetto di test finalizzati ad ottenere la validazione da parte del DEC-DCS. Per la validazione dei singoli semilavorati verranno eseguite una serie di prove di funzionalità basate sul documento denominato Piano dei Test Funzionali, prodotto dal Fornitore, in molteplici versioni, parallelamente allo sviluppo software.
Ogni versione del Piano dei Test Funzionali dovrà contenere anche l’aggiornata rilevazione di copertura del codice (code coverage) garantita dai test in esso previsti; il valore percentuale di copertura delle linee di codice (statement coverage) dovrà essere almeno pari all’80%, se non diversamente stabilito, in base a quanto indicato dal Fornitore in fase di Offerta Tecnica.
Il Piano dei Test Funzionali fungerà anche da registro delle diverse versioni dell’applicativo prodotte nel corso dello sviluppo.
Una volta ottenuta la validazione del semilavorato (deliverable di iterazione), il Responsabile dei Servizi Applicativi dovrà fornire al DEC-DCS l’esatto conteggio dei punti funzione effettivamente consumati nella iterazione (cfr. Modalità di conteggio in Punti Funzione). Tale conteggio consentirà al DEC-DCS di conoscere il numero complessivo di punti funzione consumati fino ad un dato momento dello sviluppo, al fine di misurare le performance del Fornitore ed anche valutare la possibilità di sviluppare ulteriori funzionalità non previste all’inizio del progetto.
Oltre al conteggio dei punti funzione consumati, al termine dell’iterazione verrà congiuntamente misurato il tempo effettivamente impiegato per produrre il semilavorato (giorni lavorativi). A tale proposito si precisa che i periodi di tempo spesi dalla Amministrazione per eseguire autonomamente i
test propedeutici alla validazione dei semilavorati, qualora non consentano al Fornitore la prosecuzione delle attività di sviluppo, non potranno essere attribuiti a questo per la contestazione di eventuali ritardi soggetti a penali.
La versione finale dell’applicativo software, insieme con l’associato Piano dei Test Funzionali, una volta validata, verrà sottoposta a Xxxxxxxx.
Il metodo sopra descritto dovrà essere utilizzato anche per lo sviluppo di modifiche correttive, per le quali, successivamente alla validazione, dovrà essere prevista dal Fornitore l’installazione nell’Ambiente di Esercizio.
Benché il processo sopra descritto abbia il principale obiettivo di implementare le funzionalità dell’applicativo successivamente alla stabile definizione dei requisiti utente e funzionali, è possibile che durante il ciclo di sviluppo software venga richiesta al Fornitore la rilavorazione di parte dell’applicativo in precedenza già realizzata, a causa di subentranti variazioni dei suddetti requisiti.
Tali rilavorazioni verranno gestite congiuntamente tra il Responsabile dei Servizi Applicativi ed il DEC-DCS, valutando attentamente ogni singolo caso nell’ottica, soprattutto, della contabilizzazione finale sia dei FP consumati sia del tempo impiegato per tali attività.
Per le attività di sviluppo svolte nel corso del progetto si è stimata la realizzazione di massimo 700 Function Point (FP).
Successivamente al Collaudo, l’Amministrazione contabilizzerà i FP effettivamente sviluppati (c.d. conteggio a consuntivo), in numero comunque non superiore al massimo fissato, per stabilire il compenso del Fornitore, il canone per la MAC ed il tetto di FP per la MEV (cfr. Servizio di Garanzia/Manutenzione –Ambiente SW).
In fase di predisposizione dell’Offerta, l’Offerente dovrà tenere presente che l’Amministrazione utilizzerà i FP come unità di misura unica di tutta l’attività di sviluppo, per cui la valorizzazione economica proposta per il singolo punto funzione dovrà prendere in considerazione l’insieme completo di tutte le attività previste ed i deliverable richiesti nell’ambito del servizio di sviluppo software sopra illustrato (scrittura codice, redazione di documenti, etc.), e non solamente quanto strettamente legato esclusivamente alla implementazione dei requisiti funzionali.
4.5.4.1 Modalità di conteggio in Punti Funzione
Il conteggio delle dimensioni in Function Point dovrà essere effettuato secondo le modalità definite dallo standard IFPUG vigente, pertanto il Fornitore dovrà fornire tutta la documentazione tecnica a tale scopo necessaria, sempre aggiornata all’ultimo intervento evolutivo eseguito, sia nel corso delle sviluppo che negli eventuali interventi di manutenzione successivi al progetto.
4.5.5 Contenuto dell’Offerta Tecnica
Relativamente al Servizio di Sviluppo Software, l’Offerta Tecnica dovrà contenere i seguenti elementi:
• una descrizione del metodo di sviluppo software adottato dal Fornitore al proprio interno, in cui vengano specificate le metodiche utilizzate per garantire la qualità del codice prodotto, facendo eventualmente riferimento a standard correlati a tale attività (es. ISO/IEC 25010:2011);
• una sommaria descrizione del modello di documento che verrà impiegato per la stesura del Piano dei Test Funzionali (in alternativa ad un unico documento, è ammessa anche la redazione
di due documenti correlati, uno dedicato alla specifica dei requisiti funzionali ed uno al piano dei test associati);
• una sintetica descrizione dei controlli che si prevede di implementare nell’applicativo software GUS-C/N per soddisfare i requisiti sulla privacy, con specifico riferimento ai vincoli imposti dal D.Lgs. 196/03, relativi al trattamento di dati sensibili tramite l’ausilio di strumenti elettronici;
• una sommaria descrizione dei test di carico che verranno svolti sul Sistema GUS-N, con l’indicazione degli eventuale strumenti software utilizzati a supporto di questa attività;
• una sommaria descrizione delle caratteristiche dell’ambiente di sviluppo, specificando se questo sarà installato presso la sede dell’Offerente o su una postazione remota prevista in fornitura;
• una sommaria descrizione dello strumento che verrà impiegato per misurare la percentuale di copertura del codice (code coverage) garantita dai test previsti nel Piano dei Test Funzionali, con l’esplicita indicazione del valore percentuale minimo di copertura (statement coverage) che verrà garantito (minimo 80%);
• le indicazioni relative alle risorse umane che verranno impiegate per questo servizio, nelle modalità specificate nel successivo paragrafo Piano Preliminare delle Risorse Umane;
• le indicazioni relative ai tempi di esecuzione di questo servizio, nelle modalità specificate nel successivo paragrafo Piano Preliminare dei Tempi.
Al prodotto/servizio sopra descritto fanno riferimento i seguenti insiemi di attività (WP):
Codice | Denominazione |
1.3.2 | Applicativo SW GUS-C |
2.1.2 | Modifiche GUS-C |
2.2 | SVILUPPO GUS-N |
3.1 | APPLICATIVO GUS-N |
4.6 Servizio di Migrazione Dati
Una volta terminato lo sviluppo del Sistema GUS-C, il Fornitore dovrà erogare un servizio di migrazione progressiva dei dati contenuti in tutte le istanze del GUS presenti sul territorio; questa operazione sarà propedeutica per l’avvio all’uso del GUS-C da parte degli Uffici Sanitari ad oggi utilizzatori del GUS.
Nell’esecuzione di queste operazioni, da parte del Fornitore dovrà essere fatta particolare attenzione a mantenere la totale riservatezza dei dati trattati, essendo di natura sensibile.
Relativamente alla migrazione dei dati presenti nei diversi sistemi GUS attivi sul territorio, l’oggetto della Fornitura si compone dei seguenti elementi:
• Migrazione progressiva nel GUS-C dei dati presenti in ogni istanza attiva del GUS (relativamente solo ai dati medici dei pazienti e non alle utenze presenti), garantendo la
compatibilità con la nuova struttura della banca dati e la deduplicazione delle possibili istanze multiple dei record che dovessero presentarsi tra i diversi GUS;
• Relazione dettagliata degli esiti di ogni singola migrazione effettuata.
4.6.3 Modalità di erogazione del Servizio e caratteristiche del Prodotto
I tempi e le modalità di migrazione dei dati dovranno essere concordate tra il Responsabile dei Servizi Applicativi ed il DEC-DCS; quest’ultimo metterà a disposizione del Fornitore copia delle banche dati da migrare, sia per effettuare dei test che l’effettiva migrazione.
Per queste attività dovrà esserci il massimo rispetto dei tempi concordati, dovendo necessariamente richiedere il fermo delle attività degli Uffici Sanitari in corso di migrazione; per tale ragione, probabilmente verrà richiesto di effettuare le operazioni sulle banche dati nei giorni festivi o in orari extra-lavorativi (tardo pomeriggio/sera).
Il Fornitore dovrà sempre prevedere una procedura di roll-back, qualora si verificassero problemi nel corso della migrazione dei dati.
Al termine di ogni migrazione, il Responsabile dei Servizi Applicativi dovrà fornire un resoconto contenente le relative risultanze (Report di Migrazione); i contenuti di tale resoconto saranno concordati tra le parti nel corso della fase esecutiva del progetto.
4.6.4 Contenuto dell’Offerta Tecnica
Relativamente al Servizio di Migrazione dei dati del GUS, l’Offerta Tecnica dovrà contenere i seguenti elementi:
• una descrizione delle modalità di esecuzione delle operazioni di migrazione, specificando procedure ed eventuali strumenti software utilizzati a supporto, soprattutto per quanto concerne la deduplicazione delle istanze multiple dei record che dovessero presentarsi tra i diversi GUS;
• una proposta di Report di Migrazione, da utilizzare come modello;
• le indicazioni relative alle risorse umane che verranno impiegate per questo servizio, nelle modalità specificate nel successivo paragrafo Piano Preliminare delle Risorse Umane;
• le indicazioni relative ai tempi di esecuzione di questo servizio, nelle modalità specificate nel successivo paragrafo Piano Preliminare dei Tempi.
Al prodotto/servizio sopra descritto fanno riferimento i seguenti insiemi di attività (WP):
Codice | Denominazione |
2.1.1 | Attivazione GUS-C beta |
4.7 Servizio di Garanzia/Manutenzione – Infrastruttura HW/SW
Per i dettagli relativi a questo servizio si veda la relativa sezione contenuta nell’Allegato E – “Ampliamento CEN”.
Al prodotto/servizio sopra descritto fanno riferimento i seguenti insiemi di attività (WP):
Codice | Denominazione |
1.5.4 | Avvio Garanzia/Manutenzione Infrastruttura HW/SW |
4.8 Servizio di Garanzia/Manutenzione – Ambiente SW
In fase di chiusura del Progetto verrà avviato il Servizio di Garanzia/Manutenzione per gli Ambienti SW, con l’obiettivo di mantenere pienamente funzionante la componente applicativa del Sistema GUS- N per tutto il ciclo di vita stabilito, pari a tre anni.
Nell’ambito di questo servizio devono essere previste le seguenti tre tipologie di intervento:
• Manutenzione Preventiva;
• Manutenzione Adeguativa;
• Manutenzione Correttiva (MAC);
• Manutenzione Evolutiva (MEV).
Per quanto riguarda la Manutenzione Preventiva, Adeguativa e Correttiva, nel corso del periodo di Garanzia, pari ai primi dodici mesi successivi al collaudo finale, non verrà corrisposto alcun compenso al Fornitore. Per i due anni successivi alla Garanzia, gli interventi di manutenzione preventiva ed adeguativa verranno contabilizzati a consumo (in gg/uomo), mentre per gli interventi di manutenzione correttiva verrà corrisposto un canone annuo.
Per quanto riguarda la Manutenzione Evolutiva, verrà corrisposto un compenso al Fornitore sulla base dei FP effettivamente sviluppati per la realizzazione delle modifiche, nei limiti di un tetto prefissato.
Per la gestione delle attività di manutenzione sugli Ambienti SW, il Fornitore dovrà nominare formalmente il nominativo di un referente con cui si relazionerà il Responsabile dell’Applicativo GUS- N, nominato dall’Amministrazione a conclusione del Progetto, per la pianificazione ed il controllo degli interventi.
Tutte le spese accessorie legate agli interventi di manutenzione (viaggio, vitto, alloggio, etc.) saranno a carico del Fornitore, siano essi nel periodo di Garanzia o nei successivi quattro anni di esercizio.
Tutto quanto necessario alla corretta erogazione dei servizi di manutenzione (nomina referenti, definizione puntuale delle procedure, etc.) dovrà essere dettagliato nel Piano di Manutenzione per l’Ambiente SW, la cui stesura è prevista in concomitanza con l’avvio dei servizi, successivamente al collaudo finale del Sistema GUS-N.
Relativamente alla Garanzia/Manutenzione per gli Ambienti SW, l’oggetto della Fornitura si compone dei seguenti servizi, da erogare per tutto il ciclo di vita del sistema:
• Manutenzione Preventiva:
o interventi di manutenzione preventiva pianificati, ripetuti periodicamente ogni tre mesi, per un totale minimo di quattro all’anno;
o interventi di manutenzione preventiva a chiamata, entro i limiti di giornate disponibili;
• Manutenzione Adeguativa:
o interventi di manutenzione adeguativa, da svolgere contestualmente a quelli di manutenzione preventiva o correttiva;
o ogni elemento software, sia per le Piattaforma SW (aggiornamenti dei sistemi operativi, patch del web server, etc.) che per l’Applicativo GUS-N, da installare durante gli interventi di manutenzione, per aggiornare gli Ambienti SW del Sistema;
o modifiche alla documentazione prodotta nel corso del progetto, legata alla configurazione degli Ambienti SW del Sistema GUS-N, se risultino necessarie successivamente agli interventi adeguativi effettuati;
• Manutenzione Correttiva (MAC):
o interventi di manutenzione correttiva a chiamata;
o ogni elemento software, sia per le Piattaforma SW (aggiornamenti dei sistemi operativi, patch del web server, etc.) che per l’Applicativo GUS-N, da installare sugli Ambienti durante gli interventi di manutenzione, per risolvere i malfunzionamenti;
o modifiche alla documentazione prodotta nel corso del Progetto, legata alla configurazione degli Ambienti SW del Sistema GUS-N, se risultino necessarie successivamente agli interventi correttivi effettuati;
• Manutenzione Evolutiva (MEV):
o interventi di manutenzione evolutiva a richiesta;
o ogni elemento software, sia per le Piattaforma SW (aggiornamenti dei sistemi operativi, patch del web server, etc.) che per l’Applicativo GUS-N, da installare sugli Ambienti durante gli interventi di manutenzione, per modificarne le funzionalità;
o modifiche alla documentazione prodotta nel corso del Progetto, legata alla configurazione degli Ambienti SW del Sistema GUS-N, se risultino necessarie successivamente agli interventi evolutivi effettuati;
• Registro della Manutenzione: registro contenente tutte le informazioni di dettaglio relative ad ogni intervento di manutenzione svolto;
• Piano della Manutenzione per l’Ambiente SW, contenente la puntuale descrizione degli accordi presi tra le parti, relativi a tutti i servizi di manutenzione sugli Ambienti SW;
Considerata la stretta correlazione, nell’ambito del Servizio di Garanzia/Manutenzione per gli Ambienti SW il Fornitore dovrà considerare anche il mantenimento di tutte le componenti hardware e software costituenti le Postazioni Remote.
4.8.3 Modalità di erogazione del Servizio e caratteristiche del Prodotto
Gli interventi di manutenzione dovranno essere svolti, a seconda delle necessità, presso il CEN di Napoli o utilizzando una delle postazioni remote allestite nel corso del progetto.
4.8.3.1 Manutenzione Preventiva
Le modalità ed i tempi di esecuzione degli interventi di manutenzione preventiva dovranno essere anticipatamente concordati tra il referente del Fornitore ed il Responsabile dell’Applicativo GUS-N, che sarà chiamato ad accertarne la corretta esecuzione.
Il Responsabile dell’Applicativo GUS-N, qualora lo ritenga necessario, potrà imporre che almeno uno dei quattro interventi di manutenzione previsti annualmente, venga svolto presso il CEN di Napoli.
4.8.3.2 Manutenzione Adeguativa
Con manutenzione adeguativa si intendono:
• adeguamenti necessari a seguito di cambiamenti di condizioni al contorno (ad esempio per variazioni al numero utenti, per migliorie di performance, per aumento delle dimensioni delle basi dati, ecc.);
• adeguamenti necessari per innalzamento di versioni del software di base;
• adeguamenti intesi all’introduzione di nuovi prodotti o modalità di gestione del sistema;
• migrazioni di piattaforma;
• modifiche, anche massive, non a carattere funzionale, alle applicazioni (ad esempio cambiamento di titoli sulle maschere, etc).
La manutenzione adeguativa tipicamente non varia la consistenza della baseline dei FP; nei casi di eccezione, il Fornitore è tenuto a fornire tutti gli elementi di misurazione necessari ad eseguirne l’aggiornamento.
4.8.3.3 Manutenzione Correttiva
Per manutenzione correttiva si intende la diagnosi e la rimozione delle cause e degli effetti, sia sulle interfacce utente che sulle basi dati, dei malfunzionamenti delle procedure e dei programmi in esercizio.
La manutenzione correttiva è innescata da una segnalazione di impedimento all’esecuzione dell’applicazione/funzione o dal riscontro di differenze fra l’effettivo funzionamento del software applicativo e quello atteso, come previsto dalla relativa documentazione o comunque determinato dai controlli che vengono svolti durante l’attività dell’utente.
I malfunzionamenti imputabili a difetti presenti nel codice sorgente, o nelle specifiche di formato o di base dati, non rilevati durante il ciclo di sviluppo o in collaudo, sono risolti dal servizio di manutenzione correttiva con la riparazione del codice sorgente.
I malfunzionamenti, le cui cause non sono imputabili a difetti presenti nel software applicativo, ma ad errori tecnici, operativi o d’integrazione con altri sistemi (ad esempio interruzione del collegamento TP, uso improprio delle funzioni, ecc.), possono comportare, da parte del servizio di manutenzione correttiva, il solo supporto all’attività diagnostica sulla causa del malfunzionamento, a fronte della segnalazione pervenuta, ma sono poi risolti da altre strutture di competenza.
La manutenzione correttiva, di norma, non comporta la modifica della baseline dei FP; nei casi di eccezione, il Fornitore è tenuto a fornire tutti gli elementi di misurazione necessari ad eseguirne l’aggiornamento.
Sono parte integrate della manutenzione correttiva anche le seguenti attività:
• partecipazione, durante il periodo di collaudo, alle attività di presa in carico dei prodotti sviluppati e da rilasciare in esercizio, al fine di acquisire il know-how necessario al corretto svolgimento del servizio;
• contributi di competenza sistemistica e specialistica di prodotto necessaria alla corretta soluzione del malfunzionamento.
Gli interventi di MAC saranno invocati dal Responsabile dell’Applicativo GUS-N, secondo una procedura che verrà dettagliatamente concordata tra le parti, successivamente al collaudo finale del Sistema (Piano di Manutenzione per l’Ambiente SW), seguendo le linee guida descritte nel seguito.
Una richiesta di manutenzione correttiva dovrà portare alla esecuzione di un intervento, ed alla successiva risoluzione dei malfunzionamenti, nei limiti temporali di seguito indicati:
Tipologia di malfunzionamento | Tempi di risoluzione (in ore lavorative* dalla segnalazione) |
Bloccante | 12 ore nell’80% dei casi; 18 ore nel restante 20% dei casi. |
Non Bloccante | 40 ore nell’80% dei casi; |
60 ore nel restante 20% dei casi. | |
* Si intendono 8 ore lavorative giornaliere, comprese tra le 9 e le 17. | |
4.8.3.3.1 Attivazione del Servizio
L’attivazione del servizio avviene tramite l’invio di una mail di segnalazione malfunzionamento alla seguente casella di posta elettronica:
(indirizzo di posta elettronica indicato dal Fornitore)
I mettenti autorizzati all’attivazione del servizio di MAC sono i seguenti indirizzi di posta elettronica, utilizzati dall’Amministrazione:
- (primo indirizzo di posta elettronica specificato dalla Amministrazione);
- (secondo indirizzo di posta elettronica specificato dalla Amministrazione);
- …
Il periodo di riferimento da adottare per la ricezione delle segnalazioni è rappresentato dall’orario 9 - 17, dal lunedì al venerdì, esclusi i festivi; l’invio di una segnalazione al di fuori del suddetto periodo presuppone la formale ricezione della stessa alle ore 9 del primo giorno lavorativo utile, successivo a quello di invio.
Considerato che il servizio di posta elettronica tradizionale è erogato in modalità best effort, all’atto di ricezione della segnalazione, il Fornitore darà seguito, senza ritardo, con una mail di notifica. Per ovviare a questa problematica, qualora disponibile da entrambe le parti, verrà utilizzato un servizio di Posta Elettronica Certificata.
A seguito dell’analisi della segnalazione da parte del Fornitore, sarà prodotta una stima delle attività per la rimozione del malfunzionamento, e saranno concordate con l’Amministrazione le modalità di intervento per il ripristino del pieno funzionamento del sistema.
4.8.3.3.2 Segnalazione malfunzionamento
La richiesta relativa alla segnalazione del malfunzionamento dovrà contenere le seguenti informazioni:
- Data e ora di invio della segnalazione (e-mail) da parte dell’Amministrazione;
- Tipologia di Malfunzionamento (BLOCCANTE / NON BLOCCANTE);
- Ambito della richiesta (Ambiente di test; Ambiente di Esercizio; Applicativo software);
- Sistematicità del malfunzionamento (SI/NO/NON APPLICABILE);
- Descrizione del malfunzionamento rilevato;
- Descrizione del comportamento atteso dal sistema, ma non riscontrato, a fronte delle operazioni svolte.
4.8.3.3.3 Elementi aggiuntivi
Se richiesto dal Fornitore, l’Amministrazione si impegna a fornire qualsiasi altro elemento possa aiutare nella comprensione del malfunzionamento e nella sua risoluzione.
4.8.3.4 Manutenzione Evolutiva
Per manutenzione evolutiva si intende la realizzazione di funzionalità volte a soddisfare esigenze utente che riguardano funzioni aggiuntive, modificate o complementari al sistema esistente. Sono riconducibili a manutenzione evolutiva anche le modifiche urgenti alle funzioni, da realizzarsi con
risorse e tempi contenuti, quali ad esempio, la modifica di una transazione o di un tabulato per una diversa prospettazione dei dati.
La manutenzione evolutiva rilascia prodotti che modificano la consistenza della baseline dei FP, che di norma si incrementa, salvo casi di cancellazione in contemporanea di funzioni obsolete e eventualmente sostituite da quelle nuove sviluppate. Al termine dell’intervento, il Fornitore è tenuto a fornire tutti gli elementi di misurazione necessari a mantenere aggiornata la baseline dei FP.
L’esecuzione degli interventi di manutenzione evolutiva (MEV) verranno richiesti dal Responsabile dell’Applicativo GUS-N, e dovranno essere svolti con le stesse modalità previste per il Servizio di Sviluppo Software. Per le modifiche svolte nell’ambito delle MEV non è prevista l’esecuzione di un Collaudo, ma la sola approvazione finale da parte del Responsabile dell’Applicativo GUS-N stesso.
Qualora necessario, ogni documento legato alle caratteristiche del Sistema GUS-N dovrà essere modificato, da parte del Fornitore, al termine degli interventi di manutenzione, e successivamente approvato nella sua nuova versione dal Responsabile dell’Applicativo GUS-N.
Ogni intervento di manutenzione svolto sul Sistema, nel corso del ciclo di vita, dovrà essere annotato nel Registro di Manutenzione, i cui contenuti verranno dettagliatamente stabiliti concordemente tra le parti, successivamente al collaudo finale del Sistema.
4.8.4 Dimensionamento e compensi previsti
4.8.4.1 Manutenzione Preventiva
Gli interventi di manutenzione preventiva sono contabilizzati in gg/uomo, per un massimo di 8 annuali, per tutti i tre anni previsti.
4.8.4.2 Manutenzione Adeguativa/Correttiva
• Primo anno (periodo di Garanzia): tutti gli interventi di manutenzione inclusi in fornitura;
• Anni successivi al primo: canone annuo pari al 7% dei FP effettivamente contabilizzati a consuntivo per la realizzazione dell’Applicativo GUS-N;
4.8.4.3 Manutenzione Evolutiva
Per gli interventi di Manutenzione Evolutiva è previsto un limite annuo del 10% dei FP effettivamente contabilizzati a consuntivo per la realizzazione dell’Applicativo GUS-N, pari complessivamente al 30% (cumulabile) per i tre anni previsti.
Il compenso previsto per ogni intervento sarà anch’esso stabilito in base ai FP effettivamente contabilizzati, una volta terminate ed approvate le modifiche. Nell’offerta economica il fornitore dovrà indicare il prezzo unitario per il Punto Funzione di tipo ADD. Si precisa che, nel corso del contratto, nel caso in cui, nell’ambito della manutenzione evolutiva sia necessario modificare (CHG) o cancellare (DEL) funzioni già esistenti, l’Amministrazione remunererà i relativi punti funzione nella misura, rispettivamente, del 50% e del 10% del prezzo unitario aggiudicato per le funzioni sviluppate (ADD).
Al termine dovrà essere aggiornata la baseline del sistema applicativo in accordo alla seguente formula: EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL*VAFB)
in cui VAFA=VAFB=1 ed in tutti gli interventi di sviluppo in cui CFP=0, la formula applicabile è
EFP = ADD + CHGA + DEL.
Gli interventi di manutenzione evolutiva saranno valutati in accordo alla metodologia IFPUG 4.3 in Punti Funzione al termine della fase di analisi di ogni singolo intervento.
Per la valorizzazione economica proposta per il singolo punto funzione di tipo ADD, vale quanto specificato nella descrizione del Servizio di Sviluppo Software.
4.8.4.3.1 Fattore di Conversione
Qualora le attività di manutenzione non possano essere valutate in FP ma in giornate uomo, il valore di conversione che verrà impiegato nel corso di tutta la Fornitura sarà di 1 gg/uomo per ogni 2 FP.
4.8.5 Contenuto dell’Offerta Tecnica
Relativamente al Servizio di Garanzia/Manutenzione, l’Offerta Tecnica dovrà contenere i seguenti elementi:
• una descrizione
- delle modalità di esecuzione,
- dei tempi stimati,
- e delle risorse tecnologiche
che verranno impiegate per gli interventi di manutenzione ordinaria ed adeguativa, specificando per quanti e quali di essi sia previsto di intervenire tramite le postazioni remote o, eventualmente, presso il CEN di Napoli;
• le indicazioni relative alle risorse umane che verranno impiegate per questo servizio, nelle modalità specificate nel successivo paragrafo Piano Preliminare delle Risorse Umane.;
• livelli di servizio proposti relativamente alla MAC, minori o uguali ai limiti temporali specificati;
• una proposta di Registro di Manutenzione, da utilizzare come modello.
Al prodotto/servizio sopra descritto fanno riferimento i seguenti insiemi di attività (WP):
Codice | Denominazione |
3.3.4 | Avvio Garanzia/Manutenzione Ambienti SW |
Preventivamente alla chiusura dell’appalto, il Fornitore dovrà trasferire tutto il know-how relativo al progetto ed al Sistema GUS-N all’Amministrazione, secondo tempi e modalità che verranno concordati (Piano di Avvicendamento).
Tra gli elementi che dovranno essere trasferiti alla Amministrazione, a titolo non esaustivo, si indica:
- ultima versione del codice sorgente dell’Applicativo GUS-N;
- ultima versione della documentazione descrivente il Sistema GUS-N;
- copia dell’ambiente di sviluppo;
- ultima versione del Piano dei Test Funzionali;
- codice sorgente dei test effettuati;
- modalità di esecuzione dei test di carico, con l’indicazione delle risorse impiegate;
- ultima versione del Registro di Manutenzione.
Nel caso in cui, al termine dell’appalto, sia previsto che la gestione del Sistema GUS-N venga affidata ad un diverso soggetto (Fornitore subentrante), il Fornitore dovrà collaborare con l’Amministrazione per trasferire a questo tutto il know-how necessario per la corretta esecuzione dei servizi.
In questa fase il Fornitore dovrà svolgere una attività di affiancamento del Fornitore subentrante, a partire da almeno un mese prima della chiusura dell’appalto, secondo modalità e tempi specifici da stabilire anch’essi nel Piano di Avvicendamento.
Questa attività non comporterà oneri aggiuntivi per l’Amministrazione ed dovrà svolgersi in parallelo ai normali servizi di manutenzione.
4.9.2 Modalità di erogazione del Servizio e caratteristiche del Prodotto
Le modalità di esecuzione di questo servizio verranno concordate tra le parti, in maniere puntuale, prima della sua esecuzione, con la stesura di un Piano di Avvicendamento definitivo a partire dagli elementi presentati dal Fornitore in Offerta.
4.9.3 Contenuto dell’Offerta Tecnica
Relativamente al Trasferimento del Know-How, nell’Offerta dovrà essere inserita una esplicita accettazione di questo sevizio, oltre che
- una sommaria descrizione delle modalità e degli elementi proposti per la sua completa esecuzione, utilizzabili come base per la stesura del Piano di Avvicendamento,
- e le indicazioni relative alle risorse umane che verranno impiegate per questo servizio, nelle modalità specificate nel successivo paragrafo Piano Preliminare delle Risorse Umane.
Questo servizio non compare in WBS poiché svolto al di fuori del progetto all’interno del cui ambito è inserita la Fornitura oggetto di questo Capitolato.
5 Piano Preliminare di Progetto
Per la redazione dell’Offerta Tecnica, il Fornitore dovrà elaborare una Piano Preliminare di Progetto, costituente un prima sintetica versione del Piano di Progetto definitivo, da fornire in forma dettagliata successivamente alla stipula del Contratto. I contenuti del Piano preliminare dovranno essere inseriti all’interno dell’Offerta Tecnica, secondo le modalità esposte in questo Capitolato (cfr. Modalità di presentazione delle Offerte Tecniche).
Gli elementi costituenti il Piano Preliminare di Progetto dovranno essere i seguenti, secondo le specifiche dettagliate successivamente:
• Piano Preliminare dei Tempi;
• Piano Preliminare delle Risorse Umane;
• Piano Preliminare della Qualità.
Il Piano di Progetto presentato successivamente alla stipula del contratto dovrà contenere i sopra elencati piani nella loro forma definitiva, ridiscussa, concordata ed approvata dalla Amministrazione. All’inizio di ogni fase del progetto sarà programmata una revisione del Piano di Progetto, per apportarvi eventuali aggiornamenti.
5.1 Piano Preliminare dei Tempi
Il Fornitore dovrà presentare un crono-programma delle attività di progetto, in cui venga riportata una sua stima dei tempi di esecuzione di tutte quelle attività per cui è espressamente richiesto (contrassegnate con la dicitura “a.c.f.” – a cura del fornitore), secondo lo schema riportato nell’Allegato C – “Dettaglio Fasi Progettuali”1.
A partire da quello presentato in Offerta, il crono-programma di progetto sarà complessivamente rivisto, congiuntamente tra l’Amministrazione ed il Fornitore, in fase di redazione del Piano di Progetto definitivo. Si precisa, comunque, che l’Amministrazione avrà la facoltà di pretendere, da parte del Fornitore, l’esecuzione di quelle specifiche attività per cui è richiesta una previsione temporale in fase di Offerta, conformemente a quanto in essa dichiarato.
I tempi di progetto, stabiliti nel Piano di Progetto definitivo, varranno come riferimento per l’eventuale applicazione delle penali. Ai fini della loro applicazione, comunque, non potrà essere imputabile l’eventuale dilatazione della durata del progetto, rispetto a quanto previsto, se dovuta a ritardi nelle attività in carico esclusivo alla Amministrazione; dovranno altresì essere svolte delle valutazioni caso per caso, per tutte quelle attività svolte congiuntamente tra le parti.
Nel corso del Progetto, la durata delle attività verrà sempre stimata e conteggiata in giornate lavorative, anche al fine di stabilire l’eventuale applicazione di penali.
Nell’elaborazione delle stime richieste all’Offerente, relative ai tempi di sviluppo del software, si consideri che le attività delegate totalmente al Fornitore e quelle di test/validazione, svolte congiuntamente, vanno complessivamente considerate come un tutt’uno, stante lo stretto legame ad esse imposto dal metodo iterativo-incrementale, in base al quale queste devono alternarsi ciclicamente.
1 Non è consentito all’Offerente modificare differentemente i tempi prestabiliti nello schema.
L’Amministrazione intende completare il Progetto GUS-N entro una durata massima di 12 (dodici) mesi2 dalla stipula del contratto con il Fornitore.
La dichiarazione presentata in Offerta di riduzione dei tempi di Progetto fino ad un massimo di 10 (dieci) mesi verrà considerata come elemento premiante.
Una eventuale dichiarazione di riduzione ulteriore dei tempi di Progetto fino ad un massimo di 9 (nove) mesi, presentata in Offerta, benché considerata comunque come valido termine di riferimento, verrà valutata come elemento premiante solo se adeguatamente motivata, al fine di evidenziare che tale riduzione non vada a discapito della qualità del prodotto finale.
Si ribadisce che l’Amministrazione avrà la facoltà di pretendere, da parte del Fornitore, l’esecuzione del Progetto secondo i tempi dichiarati in fase di Offerta, che, inoltre, verranno utilizzati come termine di confronto per l’applicazione delle eventuali penali.
5.2 Piano Preliminare delle Risorse Umane
Coerentemente con il crono-programma presentato nel Piano Preliminare dei Tempi di Progetto, l’Offerente dovrà presentare una Piano Preliminare delle Risorse Umane, in cui sia indicato l’impiego stimato di risorse umane.
Nell’Offerta Tecnica, per ogni servizio compreso in fornitura (cfr. Contenuto dell’Offerta Tecnica), dovrà essere specificato quanto segue:
• le competenze delle risorse umane che si propone di impiegare, definendo ruoli e responsabilità ;
• il numero di risorse che si propone di impiegare, differenziato per ruolo.
Inoltre, direttamente connesso al crono programma presentato nel Piano Preliminare dei Tempi, nell’Offerta dovrà essere indicata, per ogni singola attività, la percentuale di impiego delle singole risorse in precedenza specificate.
Per una più attenta valutazione delle risorse proposte, in allegato all’Offerta dovrà essere presentato il CV, secondo il modello europeo, in forma rigorosamente anonima, di almeno le due figure proposte come Responsabili della Fornitura e di tutti i componenti del gruppo di lavoro dedicato all’Allestimento dell’Infrastruttura HW/SW.
La reale associazione dei nominativi alle risorse genericamente proposte nel Piano Preliminare delle Risorse Xxxxx dovrà essere esplicitata nel Piano di Progetto definitivo, a cui, a discrezione dei due DEC, potrà essere richiesto di allegare il CV di tutte o parte di tali risorse.
Nel corso del Progetto, il Fornitore avrà la facoltà di proporre la sostituzione di alcuni dei soggetti specificati nel Piano di Progetto definitivo, purché tale sostituzione non comporti una diminuzione in termini di competenze delle figure professionali inizialmente impiegate, e sia preventivamente approvata dalla Amministrazione.
5.2.1 Profili professionali – Infrastruttura HW/SW
Per la definizione dei profili professionali relativi alle attività legate al servizio di Allestimento dell’Infrastruttura HW/SW, si faccia riferimento alla sezione relativa alle risorse umane contenuta nell’Allegato E – “Ampliamento CEN”.
2 Si consideri un mese pari a 30 (trenta) giorni solari.
5.2.2 Profili professionali – Ambienti SW
Per armonizzare la definizione delle figure professionali proposte per lo svolgimento dei servizi oggetto della fornitura relativi agli Ambienti SW, l’Offerente dovrà fare riferimento ai profili di seguito descritti. Questi hanno valore indicativo e non prescrittivo, in quanto l’Amministrazione si riserva in ogni caso di accettare o meno una risorsa per una certa qualifica sulla base delle effettive capacità, al di là del suo profilo personale.
I profili delle figure che seguono non sono da considerare esaustivi delle esigenze della fornitura (anche in termini di conoscenze), in quanto l’Amministrazione potrà richiedere in corso di esecuzione del contratto competenze specifiche in relazione ad ulteriori tematiche, prodotti, sistemi e metodologie.
CAPO PROGETTO | |
Esperienze lavorative | • Minimo 12 anni, di cui almeno 4 nella funzione • Redazione di documentazione di progetto • Controllo realizzazione procedure • Stima di risorse per realizzazione di progetto • Stima di tempi e pianificazione attività • Analisi e progettazione di sistemi informativi, package, procedure complesse • Uso di tecniche e prodotti software per project management e risk management • Responsabilità su gruppi di progetto |
Conoscenze | • Metodologie di sviluppo • Metodologie di misura progetti • Conoscenze ed uso di tecniche e prodotti software per project management e risk management • Tematiche applicative gestionali e/o data warehouse • Autorevolezza e comprovata esperienza in progetti di grandi dimensioni • Ottime capacità relazionali |
ANALISTA FUNZIONALE | |
Esperienze lavorative | • Minimo 8 anni, di cui almeno 4 come analista • Redazione di documentazione di progetto • Controllo realizzazione procedure • Stima di risorse per lo sviluppo di software • Stima di tempi e pianificazione attività • Coordinamento di gruppi di lavoro • Disegno e progettazione di test |
Conoscenze | • Metodologie di analisi di prodotti SW • Metodologie di disegno di prodotti SW • Tecniche di controllo di progetto • Tecniche di programmazione strutturata • Tecniche di modellazione e integrazione dati • Metodologie e tecniche per la gestione dei metadati • Metodologie e tecniche per il cleaning e la qualità dei dati • Metodologia di analisi e disegno Object Oriented con UML • Applicazioni OLAP, ROLAP e processi ETL • Tematiche applicative gestionali e/o data warehouse, • Ottime capacità relazionali |
ANALISTA PROGRAMMATORE | |
Esperienze lavorative | • Minimo 4 anni come programmatore e 3 nella funzione • Coordinamento di piccoli gruppi di lavoro • Verifica della corretta applicazione di metodi e standard • Sviluppo di analisi tecnica di media complessità • Documentazione procedure |
• Preparazione di casi di test • Esecuzione di test • Partecipazione a gruppi di progetto di medie/grandi dimensioni | |
Conoscenze | • Metodologie di disegno di prodotti software • Tecniche di programmazione strutturata • DBMS relazionali • Strumenti di modellazione dati • Tecniche di programmazione Object Oriented • Applicazioni OLAP, ROLAP e processi ETL • Ottime capacità relazionali |
PROGRAMMATORE | |
Esperienze lavorative | • Minimo 4 anni nella funzione • Completa autonomia nello sviluppo • Preparazione ed esecuzione di casi di test di unità • Preparazione di documentazione di programmi • Partecipazione alla stesura di specifiche tecniche • Partecipazione a gruppi di progetto di medie dimensioni |
Conoscenze | • Strumenti per la codifica dei programmi • Tecniche di programmazione strutturata • Tecniche di programmazione Object Oriented |
SPECIALISTA DI PRODOTTO | |
Esperienze lavorative | • Minimo 8 anni, di cui almeno 3 nella funzione • Analisi, progettazione e realizzazione di sistemi informativi, package, procedure complesse • Progettazione test integrati • Ottime capacità relazionali • Spiccata attitudine al problem solving |
Conoscenze | • Ottime capacità relazionali • Strumenti MS Office • Sistemi MS Windows • Sistemi Unix • Tecnologia Java in particolare lo std J2EE • Ambienti di programmazione ed utilizzo dei prodotti tecnologici: - Visual Basic - Html - Business Objects - XML - Actuate e reporting suite - Linguaggio C/C++ - Crystal Report - Java - PHP |
SPECIALISTA TECNOLOGICO | |
Esperienze lavorative | • Minimo 8 anni, di cui almeno 3 nella funzione • Redazione di specifiche di gestione e procedure • Stima di risorse per realizzazione attività • Spiccata attitudine al problem solving |
Conoscenze | Elevata conoscenza di prodotti/tecnologie: • Sistemi operativi: MS Windows, UNIX X-OPEN, Linux • RDBMS – Oracle Database, IBM DB2 for OS/390 e MS SQL Server • Piattaforma J2EE • Piattaforma Microsoft .NET • Tecniche di OLAP, ROLAP e processi ETL • Strumenti di Business Intelligence |
• Ottime capacità relazionali |
Nel corso delle fornitura, relativamente al personale impiegato, il Fornitore dovrà erogare i servizi richiesti garantendo livelli di servizio riportati di seguito:
PFI – Personale della fornitura inadeguato | |||
Caratteristica | Efficienza | Sottocaratteristica | Utilizzazione delle Risorse |
Aspetto da valutare | Numero di risorse non ritenute adeguate dall’Amministrazione | ||
Unità di misura | Risorse inadeguate | Fonte dati | Contratto, e-mail, lettere, verbali |
Periodo di riferimento | Trimestre precedente la rilevazione | Frequenza di misurazione | Trimestrale |
Dati da rilevare | Numero di risorse ritenute inadeguate dall’Amministrazione (N_Risorse_Inadeguate) | ||
Regole di campionamento | Nessuna | ||
Formula | PFI = N_Risorse_Inadeguate | ||
Regole di arrotondamento | Nessuna | ||
Valore di soglia | PFI = 0 | ||
Azioni contrattuali | Un rilievo sulla fornitura per ogni risorsa ritenuta non adeguata superiore al valore di soglia | ||
Eccezioni | Nessuna | ||
TIP – Tempestività nell’inserimento di personale | |||
Caratteristica | Efficienza | Sottocaratteristica | Utilizzazione delle Risorse |
Aspetto da valutare | Tempo trascorso tra la richiesta dell’Amministrazione e l’inserimento/sostituzione della risorsa richiesta | ||
Unità di misura | Xxxxxx lavorativi | Fonte dati | Contratto, e-mail, lettere, verbali, Consuntivo attività, presenza all’interno del gruppo di lavoro |
Periodo di riferimento | Trimestre precedente la rilevazione | Frequenza di misurazione | Ad evento (dopo ogni inserimento) |
Dati da rilevare | - Data prevista per un adempimento relativo alla richiesta/sostituzione di una risorsa come risulta dal contratto (Data_prevista_risorsa) - Data effettiva per un adempimento relativo alla richiesta/sostituzione di una risorsa (Data_effettiva_risorsa) | ||
Regole di campionamento | Nessuna | ||
Formula | TIP = Data_effettiva_risorsa - Data_prevista_risorsa | ||
Regole di arrotondamento | Nessuna | ||
Valore di soglia | PFI ≤ 0 | ||
Azioni contrattuali | Il mancato rispetto del valore di soglia comporterà un rilievo sulla fornitura per ogni ritardo di 1 giorno lavorativo rispetto al valore soglia | ||
Eccezioni | Nessuna | ||
TORS – Turn over del personale | |||
Caratteristica | Efficienza | Sottocaratteristica | Utilizzazione delle Risorse |
Aspetto da valutare | Turn over: numero delle risorse sostituite su iniziativa del fornitore | ||
Unità di misura | Risorse sostituite | Fonte dati | e-mail, lettere, verbali |
Periodo di riferimento | Semestre precedente la rilevazione | Frequenza di misurazione | Semestrale |
Dati da rilevare | Numero di risorse sostituite su iniziativa del fornitore (N_Risorse_Sostituite) | ||
Regole di campionamento | Nessuna | ||
Formula | TORS = N_Risorse_Sostituite | ||
Regole di arrotondamento | Nessuna | ||
Valore di soglia | TORS ≤ 0 | ||
Azioni contrattuali | Il mancato rispetto del valore di soglia comporterà l’applicazione di una penale | ||
Eccezioni | Nessuna | ||
5.3 Piano Preliminare della Qualità
Per quanto concerne gli aspetti legati alla qualità della fornitura, l’Offerente dovrà fornire indicazioni relative sia al generale Sistema di Gestione della Qualità utilizzato a livello aziendale, sia alle metodologie (processi, procedure, etc.) e risorse che verranno specificatamente impiegate nello svolgimento delle attività costituenti l’Ambito della Fornitura.
Coerentemente a quanto specificato in questo Capitolato per ognuno dei servizi/prodotti costituenti l’Oggetto della Fornitura (cfr. Contenuto dell’Offerta Tecnica, cfr. Modalità di erogazione del Servizio e caratteristiche del Prodotto), l’Offerente dovrà presentare un Piano Preliminare della Qualità in cui sia indicato quali metodi e risorse intenda impiegare per garantire il pieno soddisfacimento dei requisiti di progetto. In particolare, dovrà essere dato risalto agli strumenti (metriche) che verranno messi a disposizione dei DEC per svolgere il monitoraggio e controllo della Fornitura.
Per fini di assicurazione della qualità delle attività di sviluppo software, in particolare, si specifica che il DEC-DCS, nel corso dell’esecuzione del Progetto, avrà il diritto di eseguire audit di verifica dell’effettivo impiego delle metodiche dichiarate dal Fornitore (c.d. Audit di 2° parte), secondo modalità e tempi che verranno concordati tra le parti. Discorso analogo varrà per gli strumenti impiegati per garantire la sicurezza delle informazioni.
I DEC, qualora non ritengano chiari i contenuti del Piano Preliminare della Qualità, potrà richiedere al Fornitore di esplicitarli meglio nel Piano di Progetto definitivo.
6 Durata Appalto
La durata complessiva massima stimata del presente appalto è pari a 48 mesi [12 (Progetto) + 36 (manutenzione)], soggetta a possibile ribasso.
Tale tempistica comprende le prestazioni di garanzia e manutenzione previste per l’Infrastruttura HW/SW e per gli Ambienti SW, di durata non comprimibile.
7 Operazioni di collaudo
Nel corso del Progetto è programmata l’esecuzione di due collaudi, rispettivamente al temine della prima e terza fase. Le operazioni di collaudo saranno eseguite da una specifica Commissione, a tal fine designata formalmente dall’Amministrazione, che dovrà verificare la piena funzionalità del Sistema GUS-N e la sua corrispondenza ai requisiti imposti.
In generale, per dare avvio alle operazioni di collaudo, l’Amministrazione dovrà ricevere da parte del Fornitore una formale comunicazione di “approntamento al collaudo”, approvata preventivamente dai DEC, che in tal modo attesteranno la fornitura di tutto quanto necessario alla sua corretta esecuzione (Piano dei Test Funzionali, Descrizione dell’Ambiente di Sistema, Risultanze Test di carico, etc.).
Si precisa che nel corso del collaudo, la Commissione avrà la facoltà di eseguire verifiche anche differenti da quanto indicato nella documentazione fornitagli a supporto. Inoltre, per facilitare le operazioni di collaudo, la Commissione potrà richiedere la presenza dei DEC e di personale inviato dal Fornitore.
Il Collaudo previsto al temine della prima fase del Progetto avrà lo scopo principale di verificare il corretto allestimento presso il CEN di Napoli della Infrastruttura HW/SW del Sistema GUS-N.
Su detta infrastruttura dovranno essere già allestiti gli Ambienti di Esercizio e Test del GUS-C, benché questi non saranno oggetto di verifica funzionale nel corso del Collaudo, ma esclusivamente sottoposti ai test di carico in una fase precedente ad esso.
Il giorno lavorativo successivo alla data di ricezione, da parte del Fornitore, della comunicazione formale di esito positivo di questo collaudo, decoreranno i termini per l’avvio dei servizi di Garanzia/Manutenzione per l’Infrastruttura HW/SW previsti in fornitura.
Per dettagli riguardanti la verifica di conformità dell’Infrastruttura HW/SW, si veda la relativa sezione dell’Allegato E – “Ampliamento CEN”.
Il secondo ed ultimo collaudo, previsto al temine della terza fase del Progetto, avrà il principale scopo di verificare il corretto funzionamento degli Ambienti SW del Sistema GUS-N.
Alla positiva conclusione di questo collaudo, l’Amministrazione avvierà le attività di conteggio dei FP effettivamente sviluppati e verificherà l’eventuale applicazione di penali.
Il giorno lavorativo successivo alla data di ricezione, da parte del Fornitore, della comunicazione formale di esito positivo di questo collaudo finale, decoreranno i termini per l’avvio dei servizi di Garanzia/Manutenzione per gli Ambienti SW previsti in fornitura.
8 Penalità
A garanzia della corretta esecuzione della fornitura, di seguito vengono definite le penalità previste per la mancata erogazione dei servizi, rispetto a quanto contrattualizzato. Come termine di confronto per l’applicazione delle penali, laddove non diversamente indicato, verrà preso a riferimento quanto stabilito nel Piano di Progetto definitivo (anche considerati gli eventuali aggiornamenti concordati).
L’applicazione delle penali non preclude il diritto dell’Amministrazione di richiedere il risarcimento del danno ulteriore.
Le domande per disapplicazione delle penalità, motivate e documentate esaurientemente, dovranno essere presentate all'Amministrazione, pena la decadenza, entro 30 (trenta) giorni solari dalla data di ricezione della raccomandata con la quale è stata comunicata la loro applicazione.
A garanzia della corretta durata del progetto, nel corso della fornitura, utilizzando come termine di confronto i tempi di esecuzione stabiliti nel Piano di Progetto definitivo, i DEC prenderanno nota di tutti gli scostamenti rispetto ai tempi effettivi di esecuzione delle attività.
Per ogni giorno lavorativo di ritardo sul completamento del Progetto, pienamente imputabile al Fornitore, l’Amministrazione applicherà una riduzione percentuale del compenso per la fornitura, pari a:
• 0,2%, fino ad un massimo di 15 (quindici) giorni lavorativi di ritardo;
• 1%, per ogni ulteriore giorno lavorativo di ritardo rispetto al limite fissato al punto precedente.
Inoltre, si ribadisce che per fini di assicurazione della qualità del progetto, il DEC-DCS avrà il diritto di eseguire audit di verifica dell’effettivo impiego delle metodologie di sviluppo software dichiarate dal Fornitore (c.d. Audit di 2° parte), stabilite nel Piano di Progetto definitivo, secondo modalità e tempi che verranno concordati tra le parti.
8.2 Manutenzione – Infrastruttura HW/SW
Per le penalità legate al servizio di allestimento dell’infrastruttura HW/SW, si faccia riferimento alla relativa sezione contenuta nell’Allegato E – “Ampliamento CEN”.
8.3 Manutenzione – Ambienti SW
A garanzia della corretta esecuzione del servizio di manutenzione correttiva (MAC), nel xxxxx xxxxx xxxxx xx xxxx xxx Xxxxxxx XXX-X, il Responsabile di Sistema verificherà i tempi di effettiva esecuzione degli interventi, rispetto a quelli stabiliti in questo Capitolato.
Per ogni ora lavorativa di ritardo sui limiti prefissati (conteggiata dalla segnalazione alla risoluzione del malfunzionamento), pienamente imputabile al Fornitore, l’Amministrazione applicherà una riduzione percentuale sul canone annuale, secondo lo schema seguente:
• (malfunzionamenti bloccanti): riduzione del 1% del canone;
• (malfunzionamenti non bloccanti): riduzione dello 0,2% del canone.
A garanzia della corretta esecuzione del servizio di manutenzione evolutiva (MEV), verranno applicate le penali nelle stesse modalità previste per il Progetto, basandosi sul piano di attuazione degli interventi di MEV, stabilito concordemente tra le parti prima della loro esecuzione.
9 Sicurezza delle Informazioni
Considerato che il Progetto GUS-N prevede il trattamento di dati sensibili, il Fornitore dovrà adottare le misure necessarie a garantire la riservatezza dei dati di cui verrà a conoscenza nel corso della Fornitura.
La stipula del Contratto, a tale riguardo, verrà considerata la formale accettazione di un “Accordo di non divulgazione” delle informazioni da parte del Fornitore.
I soli soggetti indicati nel Piano delle Risorse Umane definitivo saranno autorizzati al trattamento dei dati sensibili trattati.
L’Amministrazione, per tramite del DEC-Applicativo o del Responsabile dell’Applicativo GUS-N, avrà il diritto di verificare l’effettiva adozione dei metodi (intesi come procedure e strumenti) dichiarati nell’Offerta Tecnica, a garanzia della riservatezza dei dati sensibili trattati (audit di 2° parte).
10 Modalità di consegna dei prodotti e luogo di esecuzione delle attività
Si segnala che le attività esecutive del progetto saranno svolte principalmente presso gli uffici della Direzione Centrale di Sanità del Dipartimento di Pubblica Sicurezza (sita in xxxxxx Xxxxxxxx Xxxxxxxx XX, 00, Xxxx) e presso il CEN di Napoli (sito in xxx Xxxxx 0, “Real Bosco di Capodimente”, Napoli)3.
Gli incontri di coordinamento, relativi alla conduzione del progetto o a questioni contrattuali, si svolgeranno principalmente presso la Sede di Xxxxxx Pretorio del Dipartimento della Pubblica Sicurezza (sita in xxx xxx Xxxxxx Xxxxxxxx 0, Xxxx).
3 Non è qui contemplato l’ufficio della Polizia di Stato dove verrà installata l’eventuale seconda postazione remota, che, come detto, sarà presumibilmente un Ufficio Sanitario.
11 Modalità di presentazione delle Offerte Tecniche
Al fine di garantire alla Commissione che verrà istituita per l’aggiudicazione della gara (nel seguito, Commissione di gara) la possibilità di svolgere una analisi agevole ed un confronto strutturato di tutte le Offerte Tecniche che perverranno, queste dovranno essere scritte in lingua italiana, prive di qualsiasi indicazione diretta o indiretta di carattere economico, e conformi allo schema presente nell’Allegato D
– “Struttura dell’Offerta Tecnica”.
Inoltre, per consentire alla Commissione di gara di assegnare agevolmente i punteggi tecnici, si raccomanda di considerare anche le voci di merito presenti nelle griglie di valutazione, durante la stesura delle Offerte Tecniche.
11.1 Cause di esclusione dalla gara
In linea generale, saranno esclusi dalla gara gli offerenti che presentino:
- offerte nelle quali fossero sollevate eccezioni e/o riserve di qualsiasi natura alle condizioni di fornitura specificate nel Capitolato Tecnico e relative appendici;
- offerte che siano sottoposte a condizione;
- offerte che sostituiscano, modifichino e/o integrino le predette condizioni di fornitura;
- offerte incomplete e/o parziali;
- offerte di servizi che non possiedano le caratteristiche minime stabilite nel Capitolato, ovvero proposte con modalità difformi, in senso peggiorativo, da quanto stabilito;
- offerte in cui venga dichiarata una durata del progetto superiore al massimo stabilito.
12 Modalità di presentazione delle Offerte Economiche
Nell’Offerta Economica, oltre al costo globale dell’appalto, 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.
Se non imposto dalla struttura delle tabelle, deve essere specificata la metrica a cui è associato il “prezzo unitario” indicato.
PROJECT MANAGEMENT | |||
Descrizione | Prezzo Unitario (€) (giornata/uomo) | Quantità | Totale (€) |
Servizio di Conduzione Progetto | |||
ALLESTIMENTO INFRASTRUTTURA HW/SW | |||
Descrizione | Prezzo Unitario (€) | Quantità | Totale parziale (€) |
Armadio RACK | 2 | ||
Cisco Nexus 5548 | 2 | ||
Cisco Nexus 2248 | 1 | ||
Enclosure | 2 | 42 / 51 | |
ALLESTIMENTO INFRASTRUTTURA HW/SW | |||
Server Blade | 6 | ||
Software di virtualizzazione | |||
Servizi di Installazione, Configurazione e Test | |||
TOTALE (€) | |||
SERVIZI PROFESSIONALI – AMBIENTI SW | |||
Descrizione | Prezzo Unitario (€) (giornata/uomo – FP) | Quantità | Totale parziale (€) |
Allestimento Ambienti SW | |||
Allestimento Postazione Remota c/o DCS | |||
Allestimento Postazione Remota c/o Ufficio PdS | |||
Servizio di Sviluppo Software (FP) | 700 FP | ||
Servizio di Migrazione Dati | |||
TOTALE (€) | |||
ALLESTIMENTO PIATTAFORMA SW E POSTAZIONI REMOTE | |||
Descrizione | Prezzo Unitario (€) | Quantità | Totale parziale (€) |
Elencare, su righe distinte, tutti gli elementi hardware e software forniti (anche con costo pari a zero), necessari per l’allestimento Piattaforma SW e delle Postazioni Remote. | |||
TOTALE (€) | |||
ALTRE VOCI DI COSTO | |||
Descrizione | Prezzo Unitario (€) | Quantità | Totale parziale (€) |
Elencare, su righe distinte, qualsiasi altro elemento compreso in fornitura, prima non menzionato. | |||
TOTALE (€) | |||
12.2 Manutenzione – Infrastruttura HW/SW
Per quanto riguarda il servizio di manutenzione per l’Infrastruttura HW/SW, sulla base delle stime proposte dall’Offerente, nell’Offerta Economica dovranno essere presentati i seguenti schemi opportunamente completati.
Descrizione | Prezzo Unitario (€) | Quantità | Totale (€) |
Servizio di Manutenzione | 36 mesi |
Il fornitore dovrà impegnarsi a garantire che il servizio di manutenzione venga fornito allo stesso prezzo proposto in offerta, in caso di rinnovo dopo la naturale scadenza del contratto. Se il periodo richiesto è inferiore a trentasei (36) mesi, il costo del servizio sarà proporzionale ai mesi richiesti.
12.3 Manutenzione – Ambienti SW
Per quanto riguarda il Servizio di Manutenzione legato agli Ambienti SW, sulla base delle stime proposte dall’Offerente, nell’Offerta Economica dovranno essere presentati i seguenti schemi opportunamente completati.
12.3.1 Manutenzione Preventiva
Descrizione | Prezzo Unitario (€) (giornata/uomo) | Quantità | Totale parziale (€) |
Servizio di Manutenzione Preventiva | 24 (8 gg/uomo x 3 anni di erogazione del servizio) |
12.3.2 Manutenzione Adeguativa/Correttiva (MAC)
Descrizione | Prezzo Unitario (€) (FP) | Quantità | Totale parziale (€) |
Servizio di Manutenzione Adeguativa/Correttiva (MAC) | 98 (7% dei 700FP previsti per lo sviluppo, x 2 anni di erogazione del servizio, escluso il primo in Garanzia) |
12.3.3 Manutenzione Evolutiva (MEV)
Descrizione | Prezzo Unitario (€) (FP tipo ADD) | Quantità | Totale parziale (€) |
Servizio di Manutenzione Evolutiva (MEV) | 210 (10% dei 700FP previsti per lo sviluppo, per 3 anni di erogazione del servizio) |
Totale Progetto (€, iva esclusa) | ||
Totale Manutenzione (€, iva esclusa) | ||
TOTALE APPALTO (€, iva esclusa) | ||
di cui oneri previsti per sicurezza, specifici di attività di impresa | ||
12.5 Tariffe figure professionali
Tariffa offerta (costo giornaliero in €) | |
Capo Progetto | |
Analista Funzionale | |
Analista Programmatore | |
Programmatore | |
Specialista di Prodotto | |
Specialista Tecnologico | |
Altre figure: inserire una riga per ogni figura professionale offerta |
13 Criteri di valutazione delle Offerte
La gara verrà aggiudicata, anche in presenza di una sola offerta formalmente valida, purché ritenuta conveniente e congrua da parte dell’Amministrazione, mediante il criterio dell’offerta economicamente più vantaggiosa.
La valutazione tecnico - economica delle offerte ricevute sarà effettuata dalla Commissione di Gara (di seguito, Commissione) sulla base dei seguenti elementi:
Criterio | Punteggio Massimo (PM) |
Offerta Tecnica | 80 (PMT) |
Offerta Economica | 20 (PME) |
Totale | 100 |
Il punteggio complessivo per le Offerte sarà determinato dalla somma algebrica del punteggio tecnico (PT) e del punteggio economico (PE), calcolato applicando la seguente formula:
Punteggio Totale = PT + PE
Di seguito vengono proposti i criteri che verranno utilizzati dalla Commissione per la valutazione delle Offerte Tecniche.
Per l’attribuzione del punteggio tecnico complessivo dovranno essere svolte due valutazioni distinte, incentrate sui punti seguenti:
o requisiti opzionali (Q) legati alle componenti hardware/software da installare presso il CEN (𝑃𝑇𝐶𝐸𝑁);
o qualità dei servizi offerti per il progetto GUS-N (𝑃𝑇𝐺𝑈𝑆).
Una volta terminata l’analisi di tutte le offerte presentate ed assegnati i due distinti punteggi sopra elencati, secondo i criteri di seguito specificati, per l’attribuzione del Punteggio Tecnico (PT) si dovrà applicare la seguente formula:
𝑃𝑇 = 𝑃𝑀𝑇 (𝑃𝑇𝐶𝐸𝑁+𝑃𝑇𝘎𝑈𝑆) ,
max(𝑃𝑇𝐶𝐸𝑁+𝑃𝑇𝘎𝑈𝑆)
dove xxx(𝑃𝑇𝐶𝐸𝑁 + 𝑃𝑇𝐺𝑈𝑆) corrisponde al punteggio tecnico provvisorio più elevato attribuito dalla Commissione tra tutte le offerte analizzate.
13.1.1 Componenti Hardware/Software
Partendo dalle schede compilate dall’Offerente, relative alle componenti hardware proposte ed alle certificazioni del personale che verrà impiegato per l’erogazione dei servizi correlati, la Commissione dovrà calcolare il punteggio tecnico con la formula seguente:
𝑃𝑇𝐶𝐸𝑁 = ∑ 𝑝𝑖
𝑖
dove pi corrisponde al punteggio assegnato al singolo requisito opzionale Xx (con i = 1, 2, 3,...), assegnato secondo le modalità di seguito descritte.
Sulla base della tabella di seguito riportata, i punteggi associati ai singoli requisiti opzionali Qi
specificatamente legati agli elementi hardware verranno calcolati con la seguente formula:
dove:
𝑝𝑖
= 𝑃𝑚𝑎𝑥
× ( 𝑉0 )0.2
𝑉𝑚𝑎𝑥
- Pmax è il punteggio massimo assegnabile al requisito Qi;
- Vmax è il valore massimo offerto per il requisito Qi tra tutte le Offerte;
- Vo è il valore offerto per il requisito Qi.
Si precisa che nell’attribuzione dei punteggi dovranno essere considerate le prime 3 (tre) cifre dopo la virgola senza procedere ad alcun arrotondamento (es. PT: 3,23456 punteggio attribuito 3,234).
Indice | Area di Valutazione | Pmax | Elementi da valutare per l’assegnazione dei punteggi |
Q.01 | SPECint_rate_base2006 | 4 | ≥ 500 |
Q.02 | SPECfp_rate_base2006 | 4 | ≥ 400 |
Q.03 | Memoria (RAM) Installata | 6 | ≥ 256 GB ECC |
Totali | 14 | ||
13.1.1.2 Certificazioni del personale
Sulla base della griglia di valutazione di seguito riportata, la Commissione dovrà assegnare il punteggio tecnico legato alle certificazioni in possesso del personale che verrà impiegato per l’installazione e configurazione delle componenti hardware e software presso il CEN.
Questo punteggio tecnico verrà calcolato come diretta somma di tutti i punteggi tabellari che verranno assegnati (pi) ai singoli requisiti opzionali Qi.
I punteggi tabellari dovranno essere attribuiti in ragione della oggettiva offerta o mancata offerta di quanto specificatamente richiesto; non è consentita l’attribuzione di punteggi parziali.
Per questa valutazione, non è prevista l’assegnazione di punteggi discrezionali.
Indice | Area di Valutazione | Tot D | Tot T | Elementi da valutare per l’assegnazione dei punteggi discrezionali (D) | Elementi da valutare per l’assegnazione dei punteggi tabellari (T) |
Q.04 | Certificazioni Cisco | 0 | 4 | Cisco Certified Internetwork Expert (CCIE) |
Indice | Area di Valutazione | Tot D | Tot T | Elementi da valutare per l’assegnazione dei punteggi discrezionali (D) | Elementi da valutare per l’assegnazione dei punteggi tabellari (T) |
Q.05 | Certificazioni VMWare | 0 | 2 | Almeno una tra le seguenti certificazioni: - VMware Certified Advanced Professional 5 - Data Center Administration (VCAP5-DCA) - VMware Certified Advanced Professional 5 - Data Center Design (VCAP5-DCD) - VMware Certified Design Expert 5 - Data Center Virtualization (VCDX5-DCV) | |
Q.06 | Certificazioni Microsoft | 0 | 2 | Microsoft Certified Solutions Expert (MCSE) Data Platform | |
Totali | 0 | 8 | |||
Sulla base della griglia di valutazione di seguito riportata, la Commissione dovrà assegnare il punteggio tecnico relativo alla qualità dei servizi legati al progetto GUS-N, secondo il seguente criterio:
𝑃𝑇𝐺𝑈𝑆 = ∑ 𝑝𝑖
𝑖
dove pi (con i = 1, 2, 3,...) corrisponde al punteggio assegnato ad ogni singola voce della griglia, come somma della componente tabellare e di quella discrezionale:
𝑝𝑖 = 𝑝𝑇𝐴𝐵𝑖 + 𝑝𝐷𝐼𝑆𝑖
I punteggi tabellari saranno attribuiti in ragione della oggettiva offerta o mancata offerta di quanto specificatamente richiesto; non è consentita l’attribuzione di punteggi parziali.
I punteggi discrezionali saranno attribuiti in ragione dell’esercizio della discrezionalità tecnica spettante alla Commissione; per l’attribuzione di tali punteggi, si dovrà assegnare un valore parziale come percentuale del peso massimo stabilito per ogni singola voce, seguendo la tabella che segue.
Si sottolinea che l’assegnazione di ogni singolo punteggio discrezionale non deve essere il risultato di una valutazione complessiva dell’prodotto/servizio sotto esame, ma esclusivamente degli eventuali elementi migliorativi presentati rispetto alle caratteristiche minime richieste da Capitolato. Il mancato rispetto, oggettivamente riscontrato, di una o più di tali caratteristiche deve portare ad una esclusione dell’offerta dalla procedura di gara (cfr. Cause di esclusione dalla gara) e non, bensì, ad una discrezionale valutazione di inadeguatezza.
VALUTAZIONE | Percentuale del peso stabilito (%) |
OTTIMO | 100 |
QUASI OTTIMO | 90 |
ECCELLENTE | 80 |
QUASI ECCELLENTE | 70 |
MOLTO BUONO | 60 |
BUONO | 50 |
DISCRETO | 40 |
SUFFICIENTE | 20 |
INADEGUATO | 0 |
Si precisa che nell’attribuzione dei punteggi dovranno essere considerate le prime 3 (tre) cifre dopo la virgola senza procedere ad alcun arrotondamento (es. PT: 3,23456 punteggio attribuito 3,234).
Indice | Area di Valutazione | Tot D | Tot T | Elementi da valutare per l’assegnazione dei punteggi discrezionali (D) | Elementi da valutare per l’assegnazione dei punteggi tabellari (T) |
1 | Servizio di Conduzione del Progetto | 4 | 0 | Qualità del servizio offerto, valutato l’insieme coeso degli elementi richiesti nell’associato paragrafo “Contenuto dell’Offerta Tecnica”: 4 punti. | |
2 | Allestimento Piattaforma SW | 5 | 0 | Qualità del servizio offerto, valutato l’insieme coeso degli elementi richiesti nell’associato paragrafo “Contenuto dell’Offerta Tecnica”: 5 punti. | |
3 | Allestimento Postazioni Remote | 0 | 1 | Previsto in fornitura l’allestimento di una seconda postazione remota, oltre quella da allocarsi presso la Direzione Centrale di Sanità: 1 punti. | |
4 | Servizio di Sviluppo Software | 8 | 3 | Qualità del servizio offerto, valutato l’insieme coeso degli elementi richiesti nell’associato paragrafo “Contenuto dell’Offerta Tecnica”: 6 punti. | Membro del team di sviluppo software, incaricato della stima dei FP, certificato IFPUG CFPS (Certified Function Point Specialist): 2 punti. |
Qualità e completezza dei controlli proposti relativi ai requisiti sulla privacy imposti dal D. Lgs. 196/03: 2 punti. | Valore percentuale di copertura del codice (statement coverage) garantito almeno pari al 90%: 1 punto. | ||||
5 | Servizio di Migrazione Dati | 3 | 0 | Qualità del servizio offerto, valutato l’insieme coeso degli elementi richiesti nell’associato paragrafo “Contenuto dell’Offerta Tecnica”: 3 punti. |
Indice | Area di Valutazione | Tot D | Tot T | Elementi da valutare per l’assegnazione dei punteggi discrezionali (D) | Elementi da valutare per l’assegnazione dei punteggi tabellari (T) |
6 | Servizio di Garanzia/Manutenzione – Ambienti SW | 4 | 3 | Qualità del servizio offerto, valutato l’insieme coeso degli elementi richiesti nell’associato paragrafo “Contenuto dell’Offerta Tecnica”: 4 punti. | Riduzione di almeno il 20% dei tempi di esecuzione degli interventi di manutenzione correttiva (MAC): 2 punti. |
Servizio orario, per gli interventi di MAC, esteso all’intervallo orario 8-18, dal lunedì al venerdì (esclusi festivi): 1 punto. | |||||
7 | Trasferimento Know-How | 1 | 0 | Qualità del servizio offerto, valutato l’insieme coeso degli elementi richiesti nell’associato paragrafo “Contenuto dell’Offerta Tecnica”: 1 punto. | |
8 | Piano Preliminare dei Tempi di Progetto | 1 | 1 | Livello di consistenza della motivazione addotta alla riduzione della durata del progetto ad un massimo di 9 mesi (1 mese = 30 giorni solari): 1 punto. N.B. Questo punteggio dovrà essere posto pari a zero, qualora la durata del progetto indicata sia superiore a 9 mesi. | Riduzione della durata complessiva del progetto ad un massimo di 10 mesi (1 mese = 30 giorni solari): 1 punti. |
9 | Sicurezza delle Informazioni | 2 | 0 | Qualità ed adeguatezza degli strumenti proposti per garantire la riservatezza dei dati sensibili trattati: 2 punti. | |
10 | Comprensione del Progetto da parte dell’Offerente | 3 | 0 | Percepito livello di comprensione delle esigenze generali di progetto, basato sulla completezza e chiarezza espositiva dell’Offerta: 3 punti. | |
Totali | 31 | 8 | |||
L’attribuzione dei punteggi relativi all’offerta economica saranno calcolati sulla base della seguente formula:
𝑃𝐸𝑖 = {
𝑃𝑀𝐸 × 0.9 × 𝑅𝑖
𝑅𝑚𝑒𝑑
, 𝑠𝑒 𝑅𝑖 ≤ 𝑅𝑚𝑒𝑑
𝑃𝑀𝐸 × [0.9 + 0.1 × 𝑅𝑖 − 𝑅𝑚𝑒𝑑
𝑅𝑚𝑎𝑥 − 𝑅𝑚𝑒𝑑
] , 𝑠𝑒 𝑅𝑖 > 𝑅𝑚𝑒𝑑
Tuttavia, in caso di presentazione di sole due offerte valide, il punteggio relativo al prezzo sarà calcolato sulla base della seguente formula:
𝑃𝐸𝑖 = 𝑃𝑀𝐸 × 𝑅𝑖
𝑅𝑚𝑎𝑥
dove, in entrambe le formule:
- PEi: punteggio economico definitivo attribuito all’offerta del concorrente i-simo;
- Ri: ribasso rispetto all’importo complessivo a Base d’Asta (BA), determinato in ragione del prezzo complessivo offerto dal concorrente i-simo (Pi), mediante la seguente formula:
𝑅𝑖 = (𝐵𝐴 − 𝑃𝑖)
𝐵𝐴
- Rmed: media aritmetica dei ribassi Ri offerti dai concorrenti;
- Rmax: valore massimo tra i ribassi Ri offerti dai concorrenti.
Si precisa che nell’attribuzione dei punteggi dovranno essere considerate le prime tre cifre dopo la virgola senza procedere ad alcun arrotondamento (es. PE: 3,23456 punteggio attribuito 3,234).