Contract
PROCEDURA NEGOZIATA SENZA PREVIA PUBBLICAZIONE DI UN BANDO DI GARA VOLTA ALL’AFFIDAMENTO DELLA REALIZZAZIONE DEL SISTEMA INFORMATIVO DI GESTIONE DEL MINORE IN COMUNITÀ A FAVORE DELLA PROCURA DELLA REPUBBLICA PRESSO IL TRIBUNALE PER I MINORENNI
GIUSTIZIA-DIGITALE2 – SISTEMA-MINORENNI (LF2)
CUP E79J16000590002 - CIG 70214679DC
ALLEGATO 1A – CAPITOLATO SPECIALE DESCRITTIVO E PRESTAZIONALE
POR-FESR 2014-2020 - AZIONE 2.2.2 “SOLUZIONI TECNOLOGICHE PER LA REALIZZAZIONE DI SERVIZI E-GOVERNMENT INTEROPERABILI, INTEGRATI (JOINED-UP SERVICES) E PROGETTATI CON CITTADINI E IMPRESE, SOLUZIONI INTEGRATE PER LA SMART CITIES AND COMMUNITIES”.
INDICE
0 CONTESTO DI RIFERIMENTO E OGGETTO DELL’INTERVENTO 4
1 SERVIZI ATTESI 4
1.1 Architettura generale del sistema 6
1.2 SISTEMA-MINORENNI – Realizzazione del sistema informativo di gestione del minore in comunità a favore della procura della repubblica presso il tribunale per i minorenni 11
1.2.1 Contesto di riferimento e obiettivi strategici 11
1.2.2 Caratteristiche tecniche del sistema dei minori 23
1.2.3 Modalità di erogazione e approvazione dell’intervento 24
1.3 Evoluzione, manutenzione, gestione e supporto al change management dei sistemi realizzati . 25
1.3.1 Servizi di gestione operativa e sistemistica 25
1.3.1.1 Gestione operativa e sistemistica 25
1.3.1.2 Help desk per l’assistenza all’utente 26
1.3.1.3 Affiancamento in corso di esecuzione e finale 27
1.3.1.4 Inventario dell’hardware (macchine virtuali), del software applicativo e della base dati 27
1.3.2 Servizi di manutenzione correttiva e adeguativa 28
1.3.2.1 Manutenzione correttiva 29
1.3.2.2 Manutenzione adeguativa 30
1.3.2.2.1 Manutenzione conservativa 30
1.3.2.2.2 Manutenzione implementativa 31
1.3.2.3 Modalità di erogazione dei servizi di manutenzione correttiva e adeguativa 31
1.3.3 Servizi di manutenzione evolutiva 32
1.3.3.1 Manutenzione evolutiva 32
1.3.3.2 Modalità di erogazione e approvazione dei servizi di manutenzione evolutiva 33
1.3.4 Servizi di supporto al change management 35
2 MODALITÀ DI ESECUZIONE 38
2.1 Gestione e governo del progetto 38
2.2 Fasi di realizzazione degli interventi SISTEMA-MINORENNI 39
2.2.1 Analisi e raccolta dei requisiti 39
2.2.2 Disegno tecnico e funzionale 40
2.2.3 Sviluppo del software. 40
2.2.4 Testing del software 41
2.2.5 Ripresa dati anno in corso 41
2.2.6 Rilascio in esercizio. 41
2.3 Consistenza e caratteristiche del team di progetto dell’aggiudicatario 42
2.3.1 Capo progetto 44
2.3.2 Sistemista IT senior 45
2.3.3 Coordinatore e Operatore di help desk 45
2.3.4 Architetto di sistema 45
2.3.5 Consulente senior 46
2.3.6 Consulente junior 46
2.3.7 Programmatori 47
2.3.8 Formatori 47
2.4 Fasce orarie e luogo per l’erogazione dei servizi 48
2.5 Piano operativo, piano di qualità, piano di gestione dei rischi, piano delle verifiche 48
2.6 Documenti di progetto 51
2.7 Obblighi in tema di informativa e comunicazione 52
3 LIVELLI DI SERVIZIO E COMMISURAZIONE DELLE PENALI 54
3.1 Rispetto delle tempistiche di erogazione dei servizi di gestione operativa e sistemistica 54
3.2 Rispetto delle tempistiche di erogazione dei servizi di manutenzione correttiva e adeguativa 55
3.3 Rispetto delle tempistiche di erogazione dei servizi di manutenzione evolutiva 55
3.4 Rispetto della qualità di erogazione del servizio di supporto alla gestione del cambiamento 56
3.5 Rispetto delle tempistiche per la consegna dei documenti di progetto ed il raggiungimento delle milestone di progetto 56
4 CRONOPROGRAMMA 58
5 STATI DI AVANZAMENTO LAVORI, VERIFICHE INTERMEDIE E FINALI 58
0 Contesto di riferimento e oggetto dell’intervento
Il contesto di riferimento e l’oggetto dell’intervento del presente appalto sono descritti nella relazione tecnico-illustrativa cui si fa integrale rinvio.
1 Servizi attesi
Nel presente capitolo si descrivono i servizi attesi che l’aggiudicatario dovrà erogare nell’ambito del presente appalto:
1.2) SISTEMA-MINORENNI – Realizzazione del sistema informativo di gestione del minore in comunità a favore della procura della repubblica presso il tribunale per i minorenni;
1.3) Evoluzione, manutenzione, gestione e supporto al change management dei sistemi realizzati, comprendente le seguenti attività:
1.3.1) Gestione operativa e sistemistica;
1.3.2) Manutenzione correttiva e adeguativa;
1.3.3) Manutenzione evolutiva;
1.3.4) Supporto al change management.
I servizi erogati per la realizzazione dei sistemi informativi, e le successive attività di gestione e manutenzione dovranno essere rese nel rispetto dei principi generali architetturali riportati nel paragrafo 1.1) Architettura generale del sistema.
SISTEMA-MINORENNI - Macrofasi
Nei successivi paragrafi vengono descritti i requisiti che dovrà rispettare il sistema da realizzare che andrà a costituire la piattaforma. Sono incluse nel presente intervento, e dunque nelle prestazioni da erogare in ambito dei servizio a corpo e senza oneri aggiuntivi per l’Amministrazione Regionale, le attività di gestione, manutenzione e supporto alla gestione del cambiamento di quanto realizzato, da erogare:
> secondo le modalità descritte nei paragrafi 1.3.1, 1.3.2, 1.3.3 e 1.3.4;
> a partire dal rilascio in produzione del sistema fino alla conclusione del contratto, così come previsto da cronoprogramma;
> nel rispetto degli SLA di cui al paragrafo 3 e di eventuali ulteriori SLA proposti dall’offerente. L’intervento si articola in due macrofasi:
- la prima (macrofase 1) ha ad oggetto le seguenti attività:
a) l’analisi dell’attuale iter di gestione del minore in Comunità (inserimento in una definita comunità, invio delle relazioni semestrali, creazione del fascicolo del minore, ispezioni, etc);
b) analisi, disegno, sviluppo, test, messa in produzione e avvio di un sistema informativo destinato alla Procura della Repubblica presso il Tribunale dei Minorenni, per la gestione delle funzionalità descritte nel presente Capitolato Speciale Descrittivo e Prestazionale;
c) fornitura, installazione e configurazione su almeno 5 postazioni di lavoro di quanto necessario per l’utilizzo degli applicativi rilasciati, presso la sede della procura di Cagliari;
d) addestramento degli utenti chiave del sistema informativo realizzato e affiancamento durante l’avvio;
e si riterrà conclusa a seguito della messa in produzione del sistema pronto all’avvio;
- la seconda (macrofase 2) avrà ad oggetto l’avvio all’esercizio del sistema informativo SISTEMA MINORENNI, e la gestione, la manutenzione e il supporto alla gestione del cambiamento fino alla conclusione del contratto. La seconda macrofase inizia immediatamente alla conclusione della prima macrofase.
Il SISTEMA MINORENNI dovrà essere realizzato mantenendo marcate caratteristiche di integrazione tra i moduli interni, e dovrà essere scalabile nelle prestazioni e nelle possibilità di ulteriore estensione ed integrabile con nuove funzionalità attualmente non richieste.
Qualora in fase di analisi o di realizzazione del progetto dovessero riscontrarsi particolari problematiche di natura tecnica, organizzativa od amministrativa nell’attuazione dell’intervento che comportassero la rinuncia a parte degli sviluppi o la realizzazione di parte degli sviluppi con modalità differenti dalle previsioni, l’Amministrazione Regionale, si riserva di concordare con l’aggiudicatario variazioni del contratto o modifiche del piano operativo in conseguenza di tali scostamenti.
- Le prestazioni di cui alla macrofase 1 dovranno essere concluse entro 12 mesi dall’avvio delle attività.
- Le prestazioni di cui alla macrofase 2 relative all’avvio all’esercizio dovranno essere concluse entro il primo mese di tale fase, mentre quelle relative alle attività di gestione, manutenzione e supporto alla gestione del cambiamento dovranno essere rese per l’intera durata e fino alla data di conclusione del contratto (36 mesi).
L’Amministrazione si riserva la facoltà di prorogare il termine finale di esecuzione delle due macrofasi. Le prestazioni dovranno essere rese presso la sede operativa dell’aggiudicatario, nonché nella sede della Procura presso il Tribunale per i minorenni interessato dall’intervento.
1.1 Architettura generale del sistema
Nel presente paragrafo sono descritte in maniera sintetica le caratteristiche attese dalla “SISTEMA- MINORENNI”.
Nell’offerta dovrà essere adeguatamente descritta l’architettura proposta comprensiva delle tecnologie impiegate in tutte le sue componenti, con specificazione dei prodotti offerti e allegazione delle schede tecniche rilasciate dal produttore (per quanto riguarda i prodotti di mercato e non sviluppati ad hoc).
La piattaforma, che costituisce il sistema “SISTEMA-MINORENNI”, ricomprende funzionalità logicamente distinte in front office e back office, le prime includono i servizi erogati attraverso il portale, il secondo riguarda l‘insieme di funzionalità volte alla gestione del minorenne in comunità.
Ai fini meramente illustrativi si riporta lo schema architetturale della piattaforma.
Figura 1. Schema logico generale
Lo schema sopra riportato descrive i blocchi logici principali costituenti l’architettura::
> Il sistema deve essere costituito da un PORTALE (Front-End) e un’APPLICAZIONE (Back- End), con funzionalità e servizi erogati agli utentiattraverso una tipica applicazione web-based in alta affidabilità, che opera attraverso una interconnessione sicura via web;
In ogni caso, l’offerente potrà proporre ulteriori interconnessioni e ulteriori livelli di sicurezza e ridondanza, motivando la scelta tecnica e descrivendo la modalità di sicurezza dello scambio dei dati.
Scalabilità, portabilità e interoperabilità. I sistemi realizzati dovranno essere scalabili per consentire un eventuale incremento del numero e delle tipologie di utenza. Anche il numero e la tipologia di servizi potranno, in futuro, variare; pertanto si dovrà progettare un sistema modulare che faciliti
l’implementazione di nuove funzionalità e l’adeguamento del software alle variazioni normative che potrebbero verificarsi.
Accessibilità, usabilità e rispetto dell’identità visiva dell’Amministrazione per le sezioni accessibili da Internet. Il front office della soluzione offerta, con particolare riguardo al PORTALE, dovrà rispettare la normativa vigente in materia di accessibilità dei contenuti. I documenti pdf eventualmente generati in automatico dal sistema dovranno essere accessibili anch’essi, secondo le indicazioni contenute nella manualistica sull’accessibilità dei documenti elettronici pubblicata nel sito XxxxxxXxxxxxx.xxx.xx ed in particolare nella pagina:
xxxx://xxx.xxxxxxxxxxxxx.xxx.xx/xxxxxxxxxx/xxxxxxxxxxxx/xxxxx.xxx
La soluzione offerta dovrà rispettare i canoni grafici e stilistici del portale xxxx://xxxxxx.xxxxxx.xx. Per migliorare la fruibilità delle funzioni agli utenti, il back-office del sistema potrà discostarsi da tali linee guida secondo modalità da concordare con l’Amministrazione in fase esecutiva.
Sicurezza del sistema e accesso alle informazioni. Il sistema con particolare riguardo al PORTALE dovrà rispettare le pratiche comuni e consolidate in materia di sicurezza delle applicazioni. In particolare, devono essere rispettati i requisiti di:
> Riservatezza: le informazioni gestite dall’applicativo web devono essere accessibili direttamente e indirettamente solo agli utenti che ne hanno diritto e che sono espressamente autorizzati a conoscerle; Durante l’analisi di dettaglio dovranno essere individuate i vari livelli di sicurezza, che determinano di conseguenza i livelli di accesso ed i relativi ruoli. Tale infrastruttura di sicurezza deve poter essere gestita a sistema da utenti amministratori.
> Integrità: le informazioni gestite dall’applicativo web devono essere protette da alterazioni (modifiche, danneggiamenti o cancellazioni improprie) ad opera di utenti non autorizzati;
> Disponibilità: le informazioni gestite dall’applicativo web devono essere sempre accessibili agli utenti che ne hanno diritto, nei tempi e nei modi previsti.
In particolare, per la verifica delle caratteristiche di sicurezza dell’applicazione, dovranno essere concordati con la committenza dei test di “penetrazione” intesi a verificare la solidità e l’assenza di vulnerabilità dell’applicazione.
Per quanto riguarda i dati sensibili eventualmente gestiti dall’applicazione si dovrà fare riferimento alle norme in materia di trattamento dei dati personali, in particolare il Decreto legislativo 30 giugno 2003, n. 196 e s.m.i..
Dimensionamento infrastrutturale
Attraverso il Data Center dell’Amministrazione Regionale verrà messa a disposizione la potenza computazione, la capacità di storage, la capacità di network e lo spazio backup necessario all’intervento. Pertanto, nella presente procedura non è richiesta la fornitura dell’hardware su cui installare la piattaforma SISTEMA-MINORENNI, in quanto sarà cura dell’Amministrazione Regionale fornire tutte le macchine virtuali, la potenza di calcolo, lo spazio su disco, lo storage, i servizi di backup e di networking che si renderanno necessari sulla base del progetto architetturale definitivo proposto e approvato in fase esecutiva. Eventuale hardware aggiuntivo presente in offerta (es. lame dedicate, appliance di ricerca, dispositivi specifici, ecc.) sarà valutato come elemento migliorativo qualora effettivamente funzionale al raggiungimento degli obiettivi del presente progetto e al rispetto dei requisiti sopra specificati. In ogni caso l’offerente dovrà proporre l’uso ottimane delle seguenti componenti virtuali/fisiche messe a disposizione.
COMPONENTE DI EROGAZIONE | DESCRIZIONE | QUANTITÀ |
1 o più Server (tipologia Cisco Blade Server M4 B200) processori 2.60 GHz E5-2697 v3 | Shared Virutal CPU | 20 |
2 o più Server (tipologia Cisco Blade Server M4 B200) memoria XXX0-0000-XXx | Xxxxxxx RAM | 400GB |
EMC VNX 5600 | Spazio Disco SSD (Allocabile) | 500GB |
EMC VNX 5600 | Spazio Disco SAS (Allocabile) | 3.000GB |
Sistemi Operativi vari | S.O | Windows Data Center Edition, Suse Linux EE for SAP o Red Hat EE for SAP |
EMC DD4200 | Backup | Spazio necessario deduplicato |
L’offerente avrà l’onere, anche sulla base dei requisiti prestazionali descritti nei successivi paragrafi, della progettazione in termini di disegno architetturale e dimensionamento delle risorse necessarie per ospitare la soluzione proposta, avendo cura di specificare:
> Numero e tipologia delle macchine virtuali richieste, con riferimento alla loro collocazione e ruolo all’interno della soluzione architetturale proposta.
> Dimensionamento di massima, in termini di RAM, vCPU, storage e capacità di banda;
> Tipologia di dischi richiesti (SAS/SSD);
> Sistemi operativi prescelti;
> Temporizzazione e caratteristiche del backup;
> Altre caratteristiche ritenute rilevanti al fine di una migliore valutazione.
L’offerente dovrà inoltre descrivere l’architettura proposta esplicitando le modalità di scalabilità, la gestione degli scenari di guasto e le modalità di fault tolerance implementate nei vari strati. In fase esecutiva, l’aggiudicatario dovrà perfezionare la progettazione proposta in offerta, giungendo alla sua versione definitiva. L’architettura dovrà essere compatibile con l’ambiente di virtualizzazione (VmWare VSphere 5 Enterprise Plus).
Licenze d’uso
L’Amministrazione acquisisce la titolarità esclusiva dei diritti di proprietà, di utilizzazione e sfruttamento economico di quanto realizzato in esecuzione del contratto, dei relativi materiali e della documentazione predisposta.
I prodotti software proposti come costituenti la piattaforma del SISTEMA-MINORENNI devono essere offerti con la seguente modalità di licensing.
SISTEMA | COMPONENTE | LICENZA | METRICA | MANUTENZIONE E ASSISTENZA |
SISTEMA- MINORENNI | DATA BASE | Prodotti di tipologia Open Source e privo di costi di licenza | - | Supporto di tipo enterprise edition e manutenzione rilasciata dal produttore per 36 mesi |
APPLICATION SERVER | Prodotti di tipologia Open Source e privo di costi di licenza | Supporto di tipo enterprise edition e manutenzione rilasciata dal produttore per 36 mesi |
Peertanto si intende che la manutenzione prevista per tutto il software di base rientra tra i servizi che devono essere previsti nell’offerta, per 36 mesi così come specificato nella tabella precedente.
Restano esclusi dalla titolarità dell’Amministrazione tutti i marchi (inclusi di marchi di servizio), brevetti, diritti d’autore e tutti gli altri diritti di proprietà intellettuale relativi ai prodotti.
1.2 SISTEMA-MINORENNI – Realizzazione del sistema informativo di gestione del minore in comunità a favore della procura della repubblica presso il tribunale per i minorenni
Il seguente paragrafo descrive il contesto, gli obiettivi e le specifiche di massima per la realizzazione di un applicativo per la gestione informatizzata del minore in comunità da erogare a favore della Procura della Repubblica presso il Tribunale dei Minori.
1.2.1 Contesto di riferimento e obiettivi strategici
Contesto di riferimento
L’intervento SISTEMA-MINORENNI dovrà consentire di informatizzare i processi e i provvedimenti che determinano l’inserimento di un minore in Comunità e il monitoraggio della vita dello stesso nella Comunità fino al completamento del suo percorso di inserimento come da “progetto del minore”. Il sistema deve consentire non solo il singolo inserimento di un minore in una determinata comunità, ma anche la storia degli eventuali inserimenti, anche in comunità differenti, nel tempo,, con la possibilità di gestire e visualizzare la storia di un minore. Nel dettaglio il contesto di riferimento delle attività svolte dalla Procura presso il Tribunale per i Minorenni e dalle comunità è descritto nella relazione tecnico- illustrativa cui si fa integrale rinvio.
Di seguito si riportano gli attori coinvolti nel flusso di gestione dei provvedimenti in oggetto:
> La Procura della Repubblica presso il Tribunale per i minorenni;
> I soggetti autorizzati ad ospitare il minore nelle strutture di accoglienza - Comunità;
> I Servizi Sociali degli Enti Locali
> Il Tribunale per i Minorenni;
> Il Centro Regionale di Giustizia Minorile;
Di seguito si riportano, a titolo meramente esemplificativo, le dimensioni dei principali attori e/o funzioni relativi al 2016 che sono coinvolti nel processo.
SOGGETTO | SEZIONE | DESCRIZIONE BREVE | Dati (2016 ) |
Procura della Repubblica presso il Tribunale per i minorenni | GESTIONE ORDINARIA | Numero totale di minorenni in Comunità | 643 |
Numero di MSNA in Comunità | 336 | ||
Numero minori italiani in Comunità | 307 | ||
Numero di ispezioni complessive | 41 | ||
Numero di ispezioni ordinarie | 34 | ||
Numero di ispezioni straordinarie | 7 | ||
Numero di verbali ispettivi | 41 | ||
Strutture di accoglienza - Comunità | GESTIONE ORDINARIA | Numero di Comunità autorizzata ad ospitare minori (giurisdizione del Tribunale per i Minorenni di Cagliari) | 130 |
Servizi sociali degli Enti Locali | GESTIONE ORDINARIA | Numero di Enti Locali coinvolti | 257 |
N.B. i dati del 2016 non sono completi in quanto suscettibili di continue modifiche che il sistema informatico attuale non consente di aggiornare in tempo reale.
PROCURA DELLA REPUBBLICA PRESSO IL TRIBUNALE PER I MINORENNI
Nel seguito si presentano le attività principali della Procura della repubblica in relazione alle attività di affidamento extra familiare dei minori:
> Gestione ordinaria. Il Pubblico Ministero della Procura della Repubblica presso il Tribunale per i Minorenni iscrive il minore nel registro SIGMA (sistema informativo in uso presso il Tribunale per i Minorenni) Affari Civili (A.C.), chiedendo l’apertura, tramite ricorso, della procedura di Volontaria Giurisdizione (V.G.) al Tribunale per i Minorenni. Tramite il SIGMA avviene la prima raccolta dati dei minori.
> La seconda fase è costituita dall’apertura della procedura di V.G. da parte del Tribunale per i Minorenni, nell’ambito della quale sono disposti la gran parte degli inserimenti dei minori in comunità.
Attività ispettiva. La Procura della Repubblica presso il Tribunale per i Minorenni di Cagliari svolge regolarmente l’attività ispettiva ai sensi dell’art. 9 della Legge 184/1983 e delle successive modifiche con la Legge 149/2001. Nel corso del 2016 gli uffici della Procura
hanno lavorato ad una riorganizzazione interna della suddetta attività ispettiva per rendere più efficace l’attività di controllo dei minori in comunità e per garantire detto intervento anche sulle numerose strutture sorte per l’ospitalità dei Minori Stranieri Non Accompagnati (MSNA).
> La riorganizzazione dell’attività della Procura ha visto la costituzione di un Ufficio Ispezioni, che provvede alla sistematizzazione del flusso di informazioni provenienti dalle strutture tramite apposite schede predisposte dagli stessi uffici della Procura. Detta documentazione, incrociata con le schede informatiche del registro SIGMA, è utilizzata per la successiva attività ispettiva. Di ogni ispezione viene redatto apposito processo verbale. Inoltre, all’esito dell’attività ispettiva sono valutate le criticità emerse, anche con la ricostruzione della storia giudiziaria del minore. Una volta completata l’attività ispettiva nella sua totalità anche di redazione di schede sulla storia giudiziaria del minore, il Procuratore dispone la trasmissione del verbale di ispezione al Tribunale per i Minorenni e relativa documentazione al magistrato assegnatario del procedimento pendente, per l’esercizio dei poteri di parte. Il Magistrato assegnatario trasmette, per conoscenza, all’ufficio Ispezioni le richieste avanzate al Tribunale per i Minorenni, (in conseguenza delle informazioni ricevute da eliminare) di modo che lo stesso Xxxxxxx lo coadiuvi nella successiva attività di monitoraggio del fascicolo. La documentazione relativa alla predetta attività è anche archiviata nel fascicolo informatico della Procura,(costituito per i nuovi fascicoli, fin dal momento dell’iscrizione da eliminare).
Nel caso in cui il collocamento in comunità sia avvenuto su provvedimento del giudice Ordinario o della Pubblica Autorità, ai sensi dell’art. 403 c.c., la Procura, previa acquisizione delle opportune informazioni, anche attraverso l’acquisizione degli atti dei procedimenti davanti al Tribunale Ordinario, valuta la sussistenza dei presupposti per una nuova iscrizione nel registro Affari Civili. Il verbale di ispezione può essere inviato, per le parti di interesse, anche alle Pubbliche Amministrazioni competenti. Le ispezioni avvengono in parte in forma diretta, a cura del Procuratore della Repubblica e, in parte, in forma delegata alla Polizia Giudiziaria.
.
STRUTTURE DI ACCOGLIENZA (Comunità)
> Gestione ordinaria. Le strutture di accoglienza (Comunità) hanno come riferimento nei confroni dell’autorità gudiziaria un Legale Rappresentate che risponde delle attività poste in essere dalla Comunità. L’organizzazione interna di ogni Comunità prevede un’articolazione, ai fini delle attività di gestione, costituita da un responsabile della comunità, da un coordinatore e da personale
dipendente e non dipendente (volontari, servizio civile e tirocinanti). Le strutture di accoglienza sono autorizzate al funzionamento con appositi provvedimenti da vari soggetti (Comuni, ASL, Prefettura). Le comunità hanno l’obbligo di segnalare, alla Procura presso il Tribunale per i Minorenni, l’elenco dei minori ospiti in comunità, ai sensi dell’art.9 della legge 184/1983 e succ. modifiche.
o Gestione delle attività delle comunità. La struttura di accoglienza ha in carico il minore di intesa con le autorità che ne hanno disposto il collocamento. Il compito della Comunità è quello di mettere in atto tutte le azioni previste nel progetto di affidamento, elaborato dal Servizio Sociale del Comune in condivisione con la Comunità, per la realizzazione e il raggiungimento degli obiettivi previsti nello stesso. Le comunità trasmettono alla Procura
tutte le informazioni relative al minore e alle attività svolte a favore del medesimo, tramite la compilazione di apposite schede nelle quali si da atto anche del coinvolgimento dei servizi sociali, delle visite familiari, della informazioni scolastiche e sanitarie, degli allontanamenti o trasferimenti ad altra struttura, ecc.
o Gestione del minore in comunità. La comunità ha l’obbligo di descrivere le attività svolte dal minore durante la giornata (in comunità e all’esterno) attraverso un diario di servizio.
o Gestione della disponibilità alla ricezione. La comunità deve gestire, nei limiti imposti dalle autorizzazioni, le disponibilità alla ricezione e al mantenimento dei minori che alloggiano nel periodo di affidamento. Questo punto trova particolare rilievo con il maggiore afflusso di MSNA. Nello specifico si dovrà tener conto dei casi particolari quali allontanamento, dimissioni e trasferimento ad altra struttura, per il calcolo dei posti letto effettivi a disposizione.
SERVIZI SOCIALI DEGLI ENTI LOCALI
> Gestione ordinaria. I servizi sociali del Comune, titolari del caso, hanno il compito di predisporre e monitorare il progetto d’affido alla Comunità, di vigilare sulle attività predisposte dalla stessa nei confronti del minore ospite e di erogare la retta di permanenza.
TRIBUNALE PER I MINORENNI
> Gestione ordinaria. Il Tribunale per i Minorenni su ricorso del P.M. apre una procedura di V.G. e, a seguito delle necessarie acquisizioni (come ad es. la richiesta di approfondimento ai Servizi Sociali ) dispone l’intervento che ritiene più opportuno nell’interesse del minore, come ad esempio
il collocamento in Comunità. Chiede al Servizio Sociale di predisporre un progetto per il superamento della situazione di pregiudizio del minore, con obiettivi e tempi, e di relazionare periodicamente l’andamento dell’intervento.
IL CENTRO REGIONALE DI GIUSTIZIA MINORILE
> Gestione ordinaria. Il Centro di Giustizia Minorile, tramite l’USSM (Servizio Sociale per i Minorenni), fornisce assistenza ai minori autori di reato in ogni grado e stato del procedimento penale. Avvia l’intervento per il minore in stato di arresto e di fermo, segue il progetto educativo del minore in misura cautelare non detentiva, come il collocamento dello stesso in una comunità, gestisce la misura della sospensione del processo e della messa alla prova, complessivamente svolge attività di sostegno e controllo della fase di attuazione delle misure cautelari e sostitutive disposte dall’Autorità Giudiziaria nei confronti dei minori.
Per completezza si allegano le schede ad ora utilizzate per la gestione dell’attuale flusso.
a. Allegato 1A-1 - Scheda dati MSNA;
b. Allegato 1A-2 - Scheda dati comunità̀ ;
c. Allegato 1A-3 - Scheda Inf. semestrali art.9 L.184 del 1983 def
d. Allegato 1A-4 - Scheda Minore.
Descrizione dell’intervento
In questo contesto si inserisce l’intervento “SISTEMA INFORMATIVO DI GESTIONE DEL MINORE IN COMUNITÀ’”, il cui obiettivo è quello di razionalizzare i dati acquisiti attraverso la creazione di una banca dati nella quale confluiscono le informazioni sui minori e sulle comunità, anche in collegamento con le altre Pubbliche Amministrazioni aventi compiti di controllo sulle strutture. Un sistema di gestione dell’iter di affidamento sopra descritto consentirà di riorganizzare tutte le informazioni inerenti l’attività di controllo dei minori inseriti in Comunità permettendo così l’utilizzo degli esiti dell’attività di controllo nei procedimenti giudiziari a tutela dei minori ospiti delle strutture. Di seguito è mostrato uno schema logico generale del sistema.
Figura 2. Schema logico generale
Il Sistema Informativo Minorenni rappresenterà il gestionale dell’iter di affidamento del minore in una determinata struttura di accoglienza, a seguito del perfezionamento del provvedimento di affidamento da parte del Tribunale per i Minorenni. Il provvedimento di affidamento da parte del Tribunale per i
Minorenni non rientra nel flusso gestionale del sistema ma deve poter essere allegato nella pratica di un affidamento.
L’intervento consiste nella progettazione e realizzazione di una soluzione che consenta la digitalizzazione dei provvedimenti/documenti, e dei procedimenti sopra descritti, nel rispetto delle seguenti caratteristiche e condizioni:
> La soluzione dovrà permettere la gestione digitale dei flussi descritti in precedenza, nell’ottica di garantire l’univocità dell’imputazione a sistema del dato sulla banca dati del minore e delle comunità, eventuali verifiche di integrità e controlli, dovranno essere gestite ON-LINE, in fase di imputazione;
> la gestione dei flussi dovrà consentire l’intero iter del ciclo di affidamento del minore, della gestione del suo progetto d’inserimento, di verifica e riscontro delle comunità, di gestione delle ispezioni, di invio delle richieste di relazione semestrale, di validazione ed approvazione delle relazioni e quanto descritto in precedenza. Rientrano in tale ambito anche le attività compiute da attori differenti dalle comunità o gli organi della procura (a mero titolo di esempio i Servizi Sociali degli enti locali, eventuali organi che svolgono operazioni di verifica e vigilanza in delega, etc).Come caratteristiche generali la gestione dei flussi deve poter consentire il monitoraggio dello stato di avanzamento del flusso da parte di utenti dotati di particolare ruolo, la visualizzazione di eventuali ritardi o blocchi nel procedimento, la veicolazione di documenti nelle forme così come meglio precisate nel punto seguente. Il flusso deve prevede anche la gestione del diario dell’attività giornaliera dei minori in affidamento, con funzionalità che consentano di creare ex novo il rapporto giornaliero oppure di copiarlo a partire da precedenti giornate e successivamente variarlo .
> I provvedimenti/documenti dovranno essere scomposti nelle loro parti strutturali essenziali e gestiti in forma digitale;. Si prevedono di seguenti formati:
o A) formato strutturato, composto da più campi (a mero titolo di esempio nei formati di testo, numerico, valuta, data, ad input controllato come codice fiscale, email, telefono, o suggerito, e dati a scelta singola e scelta multipla, i cui domini di valore come anagrafiche d’impianto devono essere gestibili con le operazioni di tipo CRUD con funzionalità di utente amministratore). Devono essere consentiti anche campi di tipo container in cui sia possibile inserire qualunque tipo di documento con associato un testo descrittivo.
o B) formato documento, che deve poter essere inserito in formato digitale come documento formato al computer (nei formati word, pdf, excel, txt, eml, xml, etc) oppure documento immagine multipagina proveniente da scanner o altra fonte digitale. Tali documenti devono essere corredati da metadati descrittivi, tra i quali almeno il titolo del documento, la data di creazione, ultima modifica e ultimo accesso, l’autore, l’eventuale riferimento di protocollo, l’oggetto e l’abstract, eventuali documenti collegati
o C) aggregati di documenti in cui siano esplicitate le relazioni tra documenti, e che consentano di articolare insiemi di documenti di tipo A e B e con la possibilità di definire la semantica dei collegamenti attraverso attribuiti che saranno raccolti in fase di analisi di dettaglio (il sistema deve pertanto consentire la creazione di sottocartelle di documenti metadatati).
o Il sistema deve consentire anche campi con valori multipli che possono essee aggiunti ed elimnati dinamicamente, così da poter gestire associazioni 1 a n tra entità
> Dovranno essere realizzati nel formato A) (in via prioritaria) e B i documenti relativi alle schede sulla base di quanto quanto condiviso con la Procura della Repubblica presso il Tribunale per i minorenni. Al momento sono individuati 4 modelli di scheda che devono essere totalmente informatizzati (ogni tipologia di provvedimento dovrà avere il relativo modello, ed ogni documento, nel passaggio fuori contesto, dovrà essere debitamente validato con il modello di riferimento per evitare incongruenze).
Inoltre la soluzione dovrà essere realizzata in modo da perseguire le seguenti finalità:
> Gestione del workflow integrato e dinamico. I flussi dovranno essere gestiti attraverso un workflow che consenta di mantenere traccia dei passaggi di stato e dello sviluppo informatizzato del procedimento. I componenti all’interno del workflow si devono integrare perfettamente in modo dinamico, ovvero non devono esistere rigidità nella sequenza di realizzazione del procedimento e nella creazione dei provvedimenti/documenti. Inoltre dovrà essere permesso un processo di cooperazione tra gli utenti coinvolti nella produzione degli atti, tale processo cooperativo dovrà essere appositamente descritto e non dovrà prevedere limitazioni nello sviluppo in parallelo di diverse sezioni di una stessa bozza; Attraverso il meccanismo del message broker di cui si specifica più avanti i vari attori che utilizzano il sistema si distingueranno in:
o A) attori che avviano l’iter di un processo
o B) attori che contribuiscono all’iter compilando alcuni campi, allegando documenti, attivando particolari processi di autorizzazione.
o Ogni commutazione di stato è riportata in modo visuale sul message broker.
o A mero titolo di esempio un flusso può prevedere la richiesta da parte di un magistrato dell’avvio ad un organo di polizia giudiziaria d di una ispezione. Tale organo pertanto riscontra nel message broker la richiesta, a cui da esito con la registrazione dell’eventuale allegato relativo al processo verbale di ispezione. E a cui deve eseguire l’eventuale informazione relativa alla commutazione di stato visibile per il magistrato in relazione alla presenza del verbale.
> Gestione delle schede informative. Dovrà essere sviluppata la gestione delle schede informative per il caricamento dei dati relativi ai vari stati e informazioni del minore e delle comunità; Tali schede devono poter essere realizzate con i documenti nei 3 formati citati
> Gestione delle notifiche. Il sistema dovrà consentire la gestione delle notifiche per i principali cambi di stato. Le notifiche dovranno essere svolte via mail e all’interno del sistema stesso attraverso un apposito message-broker, che visualizzi le notifiche in una lista sulla quale deve essere possibile effettuare operazioni di selezione ed ordinamento, nonché di export in formato tabellare; rientrano tra i cambi di stato anche informazioni relative alla presenza, assenza, allontanamento, trasferimento, dimissione di minori, così da poter avere tutte le informazioni singole e di dettaglio, oppure in forma aggregata su un certo minore oppure sui minori di una certa comunità.
> Gestione dei ruoli/accessi. Il sistema dovrà garantire un accesso sicuro all’applicazione attraverso una profilazione utente. Il sistema dovrà consentire la gestione dei ruoli e degli accessi con una granularità tale da poter consentire la suddivisione dei moduli e sotto-moduli tra i vari attori coinvolti, ovvero la possibilità di svolgere consultazioni nei dati in maniera mirata. I ruoli devono poter essere amministrati da utenti inseriti in gerarchia così che a mero titolo di esempio sia possibile in una comunità delegare un operatore a compiere determinate operazioni sui flussi e sui documenti. Il sistema deve consentire anche il meccanismo della delega per sostituzione, che consenta ad un titolare di ruolo di delegare, previa approvazione dell’organo sovraordinato, le operazioni abilitate ad esempio in caso di assenza.
> Gestione delle ispezioni. Il sistema dovrà consentire la gestione delle ispezioni effettuate, le eventuali deleghe e gli esiti dei verbali delle ispezioni. Le funzionalità dovranno consentire di operare selezionando le ispezioni per organo ispettivo, entità ispezionata (comunità, gruppo di minori o singoli minori. Con la possibilità di caricare da parte del soggetto delegato sia il verbale in
formato elettronico che eventuali allegati digitali (immagini, altri documenti) che costituiscano il fascicolo della singola ispezione.
> Reporting. Il sistema dovrà consentire di svolgere il reporting delle principali informazioni attraverso lo sviluppo di apposite sezioni che consentano di aver il controllo dello sviluppo quantitativo dei provvedimenti/procedimenti. I report devono essere configurabili per utente, devono poter consentire l’esportazione in formato tabellare (csv, excel, etc) delle informazioni testuali, con la possibilità di definire criteri di estrazione predefiniti che possano essere richiamati in momenti successivi. L’output deve prevedere come formato anche il PDF. Deve poter essere prodotta in report ogni tabella anagrafica d’impianto significativa così come le liste di record tabellari, connessi alla descrizione di un singolo minore e le relative informazioni (sanitarie, scolastiche, sociali, estremi del report semestrale) o anche dei minori ed altri soggetti presenti in comunità.
In particolare si deve prevedere, attraverso vari moduli, lo sviluppo delle seguenti funzionalità:
> Modulo Procura della Repubblica presso il Tribunale per i minori. Si tratta del modulo in uso presso la Procura della Repubblica
o Gestione della scheda anagrafica del minore: dovrà essere possibile gestire la scheda anagrafica del minore, con tutti i dati essenziali relative al minore. Inoltre, dovrà essere possibile registrare: i nominativi dei famigliari (con indicazione della eventuale sospensione o decadenza delle responsabilità genitoriale), i nominativi del tutore e del curatore. Si specifica che nel caso di MSNA dovrà essere possibile disporre la verifica della veridicità dell’età anagrafica, mediante la generazione di un documento in formato elettronico in cui siano inseriti, sulla base di un modello testuale predefinito, una lista di minori selezionati dal sistema da inviare agli esami medici e antropometrici. Il sistema dovrà garantire la storicizzazione della modifica dei dati;
o Gestione/Consultazione del Progetto di affidamento del minore: dovrà essere possibile la gestione/consultazione del progetto di affidamento assegnato al minore compreso gli eventuali allegati tecnici e schede informative con la specifica del personale addetto all’elaborazione del progetto; Il sistema deve tenere in linea se presenti nella storia del minore, tutti i progetti di affidamento, e con riferimento a quello vigente consentire le operazioni ordinarie di gestione, mentre per quelli pregressi dovrà essere consentita la sola visualizzazione, lasciando ad utenti dotati di
particolari diritti ampliati, la possibilità di effettuare operazioni di modifica, integrazione e cancellazione
o Gestione del fascicolo informazioni sanitarie del minore: dovrà essere possibile la consultazione delle basilari informazioni sanitarie quali il medico di medicina generale assegnato, pediatra e altri servizi sanitari o socio-sanitari coinvolti;
o Gestione del fascicolo scolastico del minore: dovrà essere possibile la gestione del fascicolo scolastico con i dati dell’istituto e del dirigente responsabile, della classe frequentata, dell’andamento scolastico e una relazione dei rapporti con compagni e insegnanti;
o Consultazione delle relazioni semestrali sul minore in cui devono essere riportati i dati anagrafici dell’operatore addetto alla compilazione della scheda semestrale, l’aggiornamento della data, e la segnalazione di eventuali variazioni intervenute rispetto all’ultimo aggiornamento trasmesso, i dati del minore, numero procedura e eventuali variazioni sul minore stesso rispetto all’ultimo aggiornamento trasmesso;
o Gestione di vari provvedimenti giudiziari disposti dal Tribunale per i Minorenni, dal Tribunale Ordinario, e dal Giudice tutelare.
> Modulo Comunità. Si tratta del modulo in uso alle comunità e il cui impiego consente di raccogliere le informazioni necessarie alla banca dati dei minori in affidamento extra familiare.
o Gestione della scheda anagrafica della comunità: dovrà essere possibile gestire la scheda anagrafica della comunità, con tutti i dati essenziali per poter verificare la tipologia in cui viene classificata la comunità. Inoltre dovrà essere possibile visualizzare le autorizzazioni al funzionamento e sanitarie rilasciate alla comunità, i dati anagrafici del rappresentante legale della società/ente gestore della comunità, i dati anagrafici del responsabile della comunità, i dati anagrafici del coordinatore e di tutto il personale dipendente e non presente in struttura, i dati anagrafici dell’operatore addetto al caricamento dei suddetti dati. Il sistema dovrà garantire la storicizzazione della modifica dei dati;
o Gestione della struttura ricettiva e posti letto: dovrà essere possibile poter mantenere costantemente aggiornata la disponibilità di ricezione di nuovi minori della struttura di accoglienza. Inoltre, dovrà essere possibile inserire i dati relativi ad eventuale allontanamento del minore (data di allontanamento non autorizzato, data della
presentazione della denuncia di allontanamento, autorità a cui è stata presentata la denuncia, data di ritrovamento del minore da parte dell’autorità, data del rientro spontaneo del minore), al trasferimento del minore in altra struttura (data, dati anagrafici della struttura), il provvedimento di dimissione (autorità che ha disposto la dimissione e data effettiva della dimissione) e motivi della dimissione (rientro nella famiglia di origine o raggiungimento della maggiore età o altro). Questi dati consentono di avere un aggiornamento in tempo reale sulla disponibilità alla ricezione e al mantenimento dei minori che alloggiano nel periodo di affidamento, oltre che il monitoraggio degli effettivi posti letto disponibili.
o Gestione da parte della comunità degli “incontri familiari”: dovrà essere possibile tenere traccia di tutti gli incontri con i familiari gestiti all’interno della comunità e le uscite con gli stessi.
> Modulo servizi sociali. Si tratta del modulo in uso con le funzionalità disponibili per gli operatori delle strutture dei servizi sociali.
o Gestione della scheda anagrafica dell’operatore del servizio sociale che ha preso in carico il minore, scheda anagrafica dell’operatore ASL assegnato alla gestione del minore.
o Gestione dei progetti dei minori e funzionalità di monitoraggio e valutazione dei progetti, sdei minori seguiti dalle comunità e delle comunità stesse.
o Consultazione dei provvedimenti disposti dal Tribunale per i Minorenni.
Tutte le funzionalità di gestione dovranno comprendere con esplicite funzionalità di ricerca, modifica, creazione, cancellazione, stampa, filtro e selezione e quant’altro concorre a realizzare le funzionalità di gestione, con una modalità caratterizzata dalla facilità d’uso, dalla presenza di help e manuali in linea che spieghino il significato di ogni campo e ogni operazione che può essere svolta. Quest’ultimo aspetto deve essere realizzato sia a livello globale, con informazioni generali c e di dettagli o che guidino gli utenti sia con informazioni di contesto associate ai singoli moduli. Il sistema deve anche prevedere funzionalità utente di esportazione di dati, di stampa.
Il sistema deve, per i dati anagrafici d’impianto che prevedono tendine a discesa singole e multiple funzionalità per il data entry dei dati di dominio, con la disponibilità delle funzionalità di tipo CRUD e con funzioni di caricamento massimo a partire da formati standard (xml, cvs, xls, etc).;
Nell’offerta tecnica dovrà essere descritto nel dettaglio la modalità con la quale si intende realizzare il sistema con indicazione delle funzionalità aggiuntive, che dovrà consentire il monitoraggio della vita del minore in comunità.
1.2.2 Caratteristiche tecniche del sistema dei minori
Di seguito si riportano le principali caratteristiche tecniche che dovrà rispettare il sistema.
Layer di servizi
La piattaforma dovrà essere suddivisa in tre livelli principali:
> Presentation. Il portale dovrà utilizzare le più moderne tecnologie per l’esposizione dei servizi al Cittadino. Dovrà essere di tipo responsive adattandosi dinamicamente al dispositivo utilizzato per l’accesso (PC, Tablet e Smartphone);
> Application. Il portale dovrà disporre di un livello separato di esposizione dei servizi applicativi che dovrà essere sviluppato in logica RESTful.
> Data. Il portale dovrà disporre di un livello separato per la gestione dei dati attraverso un DataBase di tipo relazionale. L’offerta tecnica dovrà essere chiarita la modalità di sicurezza dei dati che si intende utilizzare.
Protocolli di sicurezza web
L’aggiudicatario dovrà fornire per tutta la durata del contratto i certificati, rilasciati da un ente autorizzato, per la connessione HTTPS al portale.
Protocolli di sicurezza dei dati
In offerta dovranno essere descritte le modalità di salvaguardia della base dati con specifico riferimento ai dati sui minori.
Esposizione delle informazioni
Il portale dovrà essere realizzato al fine di poter esporre i servizi in modalità RESTful. Questo al fine di poter garantire il passaggio dei dati per l’esposizione anche da portali terzi. L’esposizione dei servizi
attraverso standard dovrà essere garantito al fine di poter veicolare le informazioni anche su altri portali.
Open data
Il sistema dovrà prevedere un modulo specifico per l’esposizione dei dati in modalità servizi web (RESTFull) per la realizzazione dell’open-data. In offerta dovrà essere specificata la modalità tecnica di esposizione con una proposta di tracciato dati.
Nell’offerta dovrà essere descritto anche attraverso delle immagini esemplificative il template grafico che si intende sviluppare per la realizzazione della grafica del portale.
1.2.3 Modalità di erogazione e approvazione dell’intervento
Il servizio di sviluppo dell’applicazione dovrà essere reso con le analoghe modalità di sviluppo e approvazione descritte nel paragrafo 2.2 (adattandole in accordo con la Procura della Repubblica presso il Tribunale per i Minorenni ove necessario), si specifica che per tale servizio si prevede un prezzo a corpo e delle tempistiche di realizzazione indicate nella sezione del cronoprogramma (paragrafo 4). E’ inoltre inclusa nel prezzo a corpo per tale servizio, senza oneri aggiuntivi, la gestione, la manutenzione e il supporto alla gestione del cambiamento, che dovranno essere erogati:
> secondo le modalità descritte nei paragrafi 1.3.1, 1.3.2, 1.3.3 e 1.3.4;
> a partire dal rilascio in produzione della soluzione fino alla conclusione del contratto, così come previsto da cronoprogramma;
> nel rispetto degli SLA di cui al paragrafo 3.
Nell’offerta dovrà essere descritto il cronoprogramma di realizzazione suddiviso in varie fasi e specificando le tempistiche di sottoposizione degli UAT.
Saranno valutate positivamente proposte migliorative per rendere maggiormente rispondente il sistema offerto alle esigenze finali dell'Amministrazione.
1.3 Evoluzione, manutenzione, gestione e supporto al change management dei sistemi realizzati
1.3.1 Servizi di gestione operativa e sistemistica
Nella redazione dell’offerta tecnica il concorrente dovrà descrivere le metodologie proposte e dettagliare i servizi offerti, con particolare riguardo alle attività di amministrazione di tutti gli ambienti realizzati, alla organizzazione del servizio di help desk, con descrizione del flusso di presa in carico, gestione, risoluzione delle problematiche e segnalazione al servizio di manutenzione correttiva. Dovranno inoltre essere descritti, in forma sintetica, tutti gli elaborati che l’aggiudicatario produrrà per il monitoraggio delle segnalazioni, delle soluzioni e del numero di segnalazioni pervenute con distinzione per area, applicativo e modulo.
1.3.1.1 Gestione operativa e sistemistica
Con riferimento ai sistemi realizzati, l’aggiudicatario dovrà eseguire le attività di gestione operativa e sistemistica, comprendenti tra l’altro:
> Amministrazione di tutti gli ambienti;
> Attività di installazione, configurazione, manutenzione, patching, monitoring, auditing e tuning di tutti i sistemi hardware (inclusa infrastruttura di rete) e software;
> Configurazione, gestione di back-up e restore su database e sistemi;
> Creazione e manutenzione tabelle e altri oggetti degli RDBMS;
> Gestione della sicurezza e delle relative politiche, nonché della business continuity delle piattaforme applicative hardware/software;
> Gestione della configurazione;
> Gestione dei rapporti con i fornitori esterni per le componenti hardware e software coperti da garanzia o da contratti di manutenzione;
> Gestione dell’integrazione con altri sistemi informativi e/o prodotti software;
> Il dimensionamento apparati hardware/virtuali server e storage, application server, database server, ecc.;
> Le necessarie attività a supporto dell’esecuzione di tutti gli interventi manutentivi, inclusi i trasporti, la messa in esercizio e il collaudo, con predisposizione dei relativi ambienti.
Nell’offerta tecnica dovrà essere descritto come tali servizi saranno resi in riferimento al contesto tecnologico di elevata complessità dei sistemi da gestire.
1.3.1.2 Help desk per l’assistenza all’utente
L’aggiudicatario dovrà garantire l’erogazione del servizio di assistenza tecnica ed assistenza agli utenti finali, unitamente al servizio di help desk di I e II livello.
Il servizio richiesto ha ad oggetto i sottosistemi e le relative funzionalità, incluse le nuove realizzazioni a seguito di interventi manutentivi.
Con riferimento ai servizi di help desk l’aggiudicatario dovrà garantire l’articolazione sui due livelli richiesti per l’erogazione, tra l’altro, delle seguenti attività:
> Analisi e soluzione delle problematiche nell’utilizzo dei sottosistemi e degli applicativi;
> Creazione e gestione delle utenze, con collazione e consegna del documento di tracciamento di tutti gli utenti con distinzione di profilo e/o moduli usati;
> Analisi, soluzione e/o segnalazione delle problematiche derivanti da malfunzionamenti a differenti gruppi di lavoro (es. manutenzione correttiva) o a fornitori terzi, quali a titolo esemplificativo i gestori della rete o i titolari di contratti di manutenzione su prodotti hardware o software;
> Assistenza agli utenti anche mediante la previsione di interventi on site, con affiancamento nell’utilizzo dei sottosistemi, salva la possibilità di ricorso all’affiancamento on site e on-demand descritto in seguito;
> Redazione di FAQ e di un glossario, che dovrà essere mantenuto costantemente aggiornato, con consegna all’Amministrazione a conclusione di ogni trimestre di gestione da pubblicare sull’intranet regionale;
> Collazione e consegna dei documenti tecnici descrittivi dell’architettura di sistema, dei prodotti, degli applicativi e delle funzionalità, da mantenere aggiornato alla luce delle manutenzioni effettuate;
L’aggiudicatario dovrà dimensionare il gruppo di lavoro che opererà sul servizio di assistenza tecnica ed assistenza utenti finali ed help desk di I e II livello nel rispetto dei livelli di servizio richiesti dall’Amministrazione.
L’aggiudicatario dovrà mettere a disposizione un numero di telefono e una mail per l’attivazione del servizio di help desk.
Infine, l’aggiudicatario dovrà contribuire a che le applicazioni e la base dati trattata rispettino quanto previsto dalla misure minime di sicurezza di cui al Decreto Legislativo n. 196/2003.
1.3.1.3 Affiancamento in corso di esecuzione e finale
Nel corso dell’esecuzione dei servizi, l’aggiudicatario dovrà garantire l’addestramento di risorse individuate dall’Amministrazione Regionale, al fine di consentire che la gestione dei sottosistemi sia, a conclusione dell’esecuzione del contratto, garantita da personale preposto all’utilizzo dell’applicazione.
Sarà onere del concorrente esplicitare le modalità di realizzazione dell’affiancamento.
L’aggiudicataria dovrà predisporre un piano operativo (meglio descritto nel paragrafo 2.5) delle attività di trasferimento delle competenze tecniche e specialistiche di gestione dei sottosistemi. Il piano operativo dovrà essere presentato entro trenta giorni dalla stipulazione del contratto e dovrà essere approvato dall’Amministrazione.
Il piano potrà essere aggiornato alla luce di eventuali sopravvenienze e, comunque, entro 12 mesi prima della scadenza del contratto per la programmazione dettagliata dell’affiancamento finale.
1.3.1.4 Inventario dell’hardware (macchine virtuali), del software applicativo e della base dati
Nell’esecuzione dei servizi di gestione, l’aggiudicatario dovrà predisporre un documento riepilogativo contenente il dettaglio di tutti gli oggetti hardware e software, che compongono i sottosistemi, da mantenere aggiornato con inserimento di tutte le modifiche apportate in corso di esecuzione del contratto, indicazione delle interdipendenze, al fine di consentire la gestione delle condizioni di utilizzo, garantirne la rintracciabilità e l’adeguatezza.
L’inventario del software applicativo dovrà contenere l’indicazione della versione del software esistente in relazione alle ultime modifiche apportate al sistema (attuale versione) e per ciascuna macroarea:
> L’elenco delle applicazioni standard o custom con l’indicazione della descrizione e del nome tecnico.
> Elenco dei report standard e custom, degli script, delle query e di tutti gli oggetti che compongono i sottosistemi;
> Elenco di tutti gli oggetti software che compongono gli applicativi e delle modifiche apportate;
> Elenco di tutti gli oggetti software che compongono gli applicativi della macroarea SISTEMA- MINORENNI e delle modifiche apportate;
Nell’inventario delle basi dati dovranno essere prodotte le liste delle tabelle custom e dei relativi elementi. Inoltre dovrà essere descritta la struttura del database e di eventuali dataset e file di I/O comprensiva della descrizione delle interfacce.
L’inventario dovrà essere predisposto entro trenta giorni dalla messa in produzione del sistema e consegnato nella versione aggiornata ogni 2 mesi, unitamente alla consegna del SAL. Sarà cura dell’Amministrazione, a seguito di segnalazione da parte dell’aggiudicatario, fornire alla stessa tutti i dati che non possa rilevare autonomamente. L’inventario dovrà essere accessibile al personale coinvolto nella gestione del contratto.
1.3.2 Servizi di manutenzione correttiva e adeguativa
I servizi di manutenzione correttiva e adeguativa hanno ad oggetto tutte le componenti software, parametrizzazioni e integrazioni comprese, che compongono i sistemi/sottosistemi realizzati con il presente intervento.
L’aggiudicatario dovrà garantire la correzione, la manutenzione, l’ottimizzazione, anche in termini di maggiore usabilità, e l’aggiornamento delle procedure e dei programmi, rispettando le metodologie e gli standard di prodotto.
I servizi che l’aggiudicatario dovrà porre in essere comprendono:
> La manutenzione correttiva;
> La manutenzione adeguativa.
A conclusione degli interventi di manutenzione l’aggiudicatario dovrà aggiornare la documentazione in uso, inclusi i manuali operativi.
Conformemente a quanto previsto dagli atti di gara le attività poste in essere in esecuzione del contratto sono coperte da garanzia.
Il concorrente nell’offerta tecnica dovrà descrivere le modalità di erogazione del servizio e la documentazione che sarà predisposta.
Saranno positivamente valutate proposte migliorative che permettono di migliorare e adeguare il funzionamento dei differenti sottosistemi.
1.3.2.1 Manutenzione correttiva
I servizi di manutenzione correttiva hanno ad oggetto l’insieme delle modifiche alle procedure ed ai programmi standard e realizzati ad hoc (custom) al fine di correggere le cause e gli effetti di malfunzionamenti dopo il rilascio in produzione.
L’aggiudicatario dovrà eliminare le cause e gli effetti dei malfunzionamenti delle procedure e dei programmi a seguito della rilevazione di impedimenti all’esecuzione dell’applicazione (errori bloccanti) o di differenze tra il comportamento atteso e l’effettivo. L’aggiudicatario dovrà effettuare la diagnosi e, quindi, procedere all’eliminazione dei funzionamenti errati; dovrà eseguire il ripristino delle funzionalità previste dalle procedure e dai programmi, con rimozione degli effetti prodotti dai malfunzionamenti sulle basi dati.
Quando il malfunzionamento riguarda programmi standard, il ripristino della funzionalità deve avvenire mediante l’applicazione di patch, correzioni o mediante l’applicazione di “note rilasciate dal produttore” eventualmente modificando i programmi realizzati ad hoc, a tal fine l’aggiudicatario dovrà monitorare i siti dei produttori dei software in uso nei sottosistemi.
Nelle restanti ipotesi l’aggiudicatario dovrà prendere in carico tutte le segnalazioni di malfunzionamento, sia quelle trasmesse dall’help desk sia quelle provenienti dal responsabile del contratto e suoi incaricati.
Sarà in ogni caso onere dell’aggiudicatario effettuare il costante monitoraggio e l’analisi degli applicativi per rilevare, autonomamente, anomalie e malfunzionamenti e proporre le necessarie soluzioni. A tal fine, mensilmente l’aggiudicatario dovrà fornire un report dell’attività di monitoraggio e analisi, con indicazione dei test eseguiti. Metodologia e test che saranno eseguiti devono essere descritti in offerta.
L’aggiudicatario dovrà creare e aggiornare una registrazione dei malfunzionamenti del software con le informazioni necessarie per la valutazione e l’elaborazione di statistiche.
Il concorrente dovrà descrivere in offerta la metodologia seguita e le informazioni che saranno tracciate ai fini della compilazione del registro.
Si specifica inoltre quanto segue:
> L’offerente dovrà descrivere, in offerta, la modalità di segnalazione del malfunzionamento al fornitore terzo, obbligato a eseguire gli interventi manutentivi sui beni eventualmente forniti; sarà onere dell’aggiudicatario documentare, all’interno del registro, tempi di risposta e soluzione, con
una codifica che consenta all’Amministrazione di individuare l’esecutore dell’intervento manutentivo.
> Tutte le componenti dovranno essere prese in carico, ai fini della manutenzione correttiva, dall’aggiudicatario al momento del subentro o dalla data di messa in produzione degli sviluppi applicativi resi a seguito di interventi di manutenzione adeguativa o evolutiva; all’Amministrazione dovrà essere data adeguata evidenza delle componenti oggetto di intervento e della data di messa in produzione ai fini dell’assunzione della responsabilità, che si determinerà anche con riferimento alle componenti indirettamente impattate dalla manutenzione eseguita.
1.3.2.2 Manutenzione adeguativa
1.3.2.2.1 Manutenzione conservativa
L’aggiudicatario dovrà assicurare la costante aderenza delle procedure e dei programmi all'evoluzione dell’ambiente tecnologico del sistema informativo, come ad esempio l’innalzamento dei livelli di software di base o l’introduzione di nuove apparecchiature, in un contesto generale di compatibilità con l’esistente. A titolo esemplificativo sono considerati mutamenti dell’ambiente l’innalzamento di versioni del software di base, l’introduzione di nuovi prodotti software e le nuove modalità di gestione del sistema.
Inoltre, l’aggiudicatario dovrà mantenere l’efficienza delle procedure e dei programmi al variare delle condizioni e dei carichi di lavoro, ottimizzare i tempi di risposta dei sottosistemi, ad esempio al crescere di banche dati o all’ampliamento del parco utenza, apportare miglioramenti ed ottimizzazioni, anche al fine di garantire la maggiore usabilità degli applicativi, derivanti dalla modifica di maschere, transazioni, report, base dati, configurazioni e parametri.
La realizzazione del servizio potrà, tra l’altro, riguardare esigenze di migliorare le prestazioni, la robustezza e la sicurezza degli applicativi, anche senza alterare le funzionalità e migliorare anche la facilità d’uso. Nell’esecuzione del servizio l’aggiudicatario dovrà verificare l’esigenza di miglioramenti delle forniture hardware e proporre un piano di acquisti, contenente il dettaglio delle specifiche tecniche e l’incidenza positiva sul funzionamento dei sottosistemi.
Gli interventi di manutenzione conservativa la cui realizzazione stimata supera i 60 giorni/uomo rientrano nell’ambito del servizio di manutenzione evolutiva.
1.3.2.2.2 Manutenzione implementativa
Inoltre, l’aggiudicatario dovrà adeguare le procedure e i programmi mediante la realizzazione di nuove funzionalità e/o la modifica di funzionalità preesistenti, per rendere i sottosistemi rispondenti alle mutate esigenze dell’Amministrazioni, alle modifiche organizzative o agli aggiornamenti della normativa.
L’aggiudicatario dovrà garantire il costante monitoraggio delle modifiche normative, in particolare in materia fiscale, contributiva, previdenza obbligatoria e/o integrativa/complementare statali e regionali o, comunque, incidenti sulle funzionalità degli applicativi.
Sono, inoltre, inclusi nel servizio descritto gli interventi implementativi, diversi da quelli sopra elencati, per i quali si richiede un impegno temporale inferiore o uguale a 30 giorni/uomo. Gli interventi di manutenzione implementativa la cui realizzazione stimata supera i 30 giorni/uomo rientrano nell’ambito del servizio di manutenzione evolutiva. L’Amministrazione si riserva di validare a campione la congruità degli effort stimati, anche ricorrendo a servizi di Quality Assurance erogati da terze parti.
1.3.2.3 Modalità di erogazione dei servizi di manutenzione correttiva e adeguativa
Nella realizzazione dei servizi sopra descritti l’aggiudicatario dovrà seguire il processo di lavorazione di seguito descritto.
Intervento in assenza di segnalazione. In presenza di malfunzionamento riguardante i programmi standard, la cui risoluzione sia rilasciata dal produttore, l’aggiudicatario dovrà - rilevata la presenza on line della soluzione - effettuare un’analisi di impatto della sua applicazione ai sottosistemi, in caso di assenza di impatto dovrà procedere immediatamente, altrimenti dovrà presentare una programmazione dell’intervento al responsabile del contratto, che approverà modalità e pianificazione, dopo avere esaminato le analisi di rischio presentate dall’aggiudicatario.
Analogamente l’aggiudicatario dovrà procedere per la manutenzione adeguativa derivante da modifiche normative.
In ogni caso la realizzazione dell’intervento manutentivo dovrà essere preceduta da una comunicazione al responsabile del contratto e ai suoi incaricati, che potranno richiedere ulteriori informazioni.
Intervento su segnalazione. Il responsabile del contratto o suoi incaricati, nonché l’help desk di II livello potranno richiedere l’intervento manutentivo a fronte di malfunzionamenti, anomalie, o in presenza di esigenze ulteriori non rilevate autonomamente dall’aggiudicatario.
A seguito della presa in carico della segnalazione, effettuata l’analisi di impatto, l’aggiudicatario dovrà presentare una programmazione per la risoluzione dell’intervento; l’Amministrazione dovrà approvare la programmazione proposta, con stima dell’effort, in caso di superamento della soglia di 60 giorni/uomo per la manutenzione conservativa o di 30 giorni/uomo per la manutenzione implementativa, per l’effettuazione dell’intervento, la cui esecuzione in caso di incidenza sull’operatività dei sottosistemi dovrà essere preceduta da comunicazione agli utenti.
Ove possibile, l’Amministrazione nella segnalazione individuerà la classe di rischio del malfunzionamento o dell’anomalia.
1.3.3 Servizi di manutenzione evolutiva
1.3.3.1 Manutenzione evolutiva
Nell’esecuzione dei servizi l’aggiudicatario dovrà porre in essere tutte le attività necessarie a:
> Realizzare nuove funzionalità non presenti nei sottosistemi, corrispondenti a significative estensioni di procedure preesistenti oppure da creare ad hoc mediante lo sviluppo di programmi, la modifica di programmi preesistenti, l’attività di personalizzazione di parametri preesistenti o la creazione e valorizzazione di nuovi parametri;
> Procedere alla profonda revisione di funzionalità applicative e/o della struttura della base dati, con reingegnerizzazione dal punto di vista tecnico e organizzativo;
> Rendere i sottosistemi rispondenti alle nuove norme, legislative o regolamentari.
Conformemente a quanto previsto dal Disciplinare le attività poste in essere in esecuzione del contratto sono coperte da garanzia.
Il concorrente nell’offerta tecnica dovrà descrivere le modalità di erogazione del servizio.
A conclusione degli interventi di manutenzione l’aggiudicatario dovrà aggiornare la documentazione in uso, inclusi i manuali operativi.
Per quanto riguarda la progettazione del modello software, dovranno essere prodotti dei documenti che, utilizzando dei modelli di progettazione standard, permettano di fornire una rappresentazione di dettaglio di quanto sviluppato. In tali documenti dovranno essere presenti almeno le seguenti sezioni:
> il disegno funzionale della soluzione da realizzare con il dettaglio dei ruoli e delle azioni previste per ciascun ruolo, ove richiesto anche tramite l’uso di modellizzazione UML – Unified Model Language 2.x, flowchart diagram;
> il disegno del modello dati concettuale e logico, ove richiesto anche tramite l’uso di modellizzazione E/R – schemi entità/relazione e per quanto concerne gli strumenti di datawarehouse e business intelligence, gli schemi a stella – schema dei fatti/dimensioni;
> il prototipo grafico per le interfacce web.
La tipologia di modelli e la definizione del livello di dettaglio sarà soggetta all’approvazione del Direttore dell’esecuzione del contratto.
1.3.3.2 Modalità di erogazione e approvazione dei servizi di manutenzione evolutiva
Modalità di erogazione. Per ogni singolo intervento di manutenzione evolutiva l’aggiudicatario dovrà predisporre un progetto, concordato con l’Amministrazione Regionale, con stima dell’effort previsto in termini di risorse professionali e giornate uomo, definizione del cronoprogramma delle attività, con particolare riferimento ai tempi di realizzazione, di test e di rilascio. Il progetto contenente la descrizione delle attività e tutta la documentazione prodotta dovranno essere sottoposti all’Amministrazione per la sua validazione. L’Amministrazione dovrà, nel termine di venti giorni dalla consegna, approvare i documenti o esprimere osservazioni; a seguito della formulazione delle osservazioni l’aggiudicatario dovrà rettificare i documenti nei termini richiesti, l’approvazione dovrà essere resa dall’Amministrazione entro cinque giorni, in assenza di osservazioni o di diniego espresso il documento si intenderà approvato. Una differente tempistica di approvazione potrà essere concordata nell’ambito dell’approvazione del Piano Operativo (paragrafo 2.5).
Gli interventi dovranno essere realizzati secondo il seguente ciclo, le cui fasi di seguito riportate potranno subire modificazioni da concordare con l’Amministrazione:
> L’analisi di fattibilità e l’individuazione della funzionalità da sviluppare con riferimento sia alle motivazioni sia all’impatto che lo stesso produce sull’organizzazione e dal punto di vista tecnico;
> La verifica delle attività di sviluppo nell’ambito delle piattaforme applicative cui l’intervento si riferisce;
> L’analisi delle risorse necessarie per l’intervento, espressa in giorni/uomo e per figura professionale;
> La definizione di un cronoprogramma dell’intervento e l’inserimento nel piano dei lavori;
> La messa a punto della documentazione tecnica dell’intervento, comprendente i manuali operativi, i manuali utente, le specifiche tecniche di dettaglio relative alle varie attività (analisi, disegno, realizzazione e test) nonché i sorgenti;
> La realizzazione dell’intervento (customizing, sviluppo di programmi ad hoc, sviluppo di programmi custom, personalizzazioni, integrazioni, ecc.);
> Il test della funzionalità realizzata e il collaudo funzionale e tecnico;
> La messa in esercizio.
A conclusione di ogni singolo intervento l’aggiudicatario dovrà presentare un report che rendiconti l’effort effettivo delle figure professionali impiegate, le attività svolte ed i relativi deliverable, consegnare all’Amministrazione tutta la documentazione del progetto-intervento realizzato.
L’aggiudicatario dovrà garantire l’acquisizione da parte degli utenti delle necessarie conoscenze per l’utilizzo delle nuove funzionalità realizzate.
Con riferimento alla quantificazione in termini di giornate uomo si specifica che:
> In nessun caso l’effort effettivo ammesso a rendicontazione potrà essere superiore a quello inizialmente stimato;
> Non saranno ammesse a rendicontazione giornate uomo di cicli progettuali non conclusi.
Modalità di approvazione. L’aggiudicatario, una volta terminato il lavoro di sviluppo, dovrà comunicare la disponibilità all’esecuzione delle sessioni di user acceptance test (UAT); l’Amministrazione attraverso i propri referenti operativi, eseguirà le sessioni di test proposte dall’aggiudicatario per verificare la qualità del prodotto realizzato. I test proposti dovranno essere atti a verificare la qualità funzionale e tecnica del prodotto, in particolare dovranno consentire la verifica delle performance e dell’usabilità, garantendo all’Amministrazione massima libertà nel valutare
l’oggetto sotto esame, anche eseguendo verifiche ulteriori rispetto a quelle proposte dall’aggiudicatario.
Nel caso in cui lo UAT dovesse produrre un risultato negativo, l’aggiudicatario dovrà porne rimedio mediante la correzione e il miglioramento degli oggetti coinvolti nella verifica, e richiedere una successiva sessione di test. Nel caso in cui gli UAT diano esito positivo l’aggiudicatario procederà alla messa in produzione di quanto sviluppato e alla consegna della documentazione tecnica e del manuale utente (si specifica che le date di messa in produzione degli oggetti realizzati dovranno essere concordate con l’Amministrazione).
Ogni prodotto rilasciato dovrà avere un manuale utente accessibile in xxx xxxxxxxxxxx.
0.0.0 Servizi di supporto al change management
Nell’ambito degli interventi oggetto del presente appalto, la gestione del cambiamento diventa strategica nell’ottica di assicurare l’assimilazione, da parte della struttura organizzativa, dei nuovi metodi e procedure, minimizzando così l’impatto sull’operatività quotidiana della macchina amministrativa.
L’offerente dovrà presentare in offerta un adeguato piano che descriva il giusto mix degli elementi su cui si basa una corretta gestione del cambiamento, ovvero formazione, comunicazione e coinvolgimento, nel rispetto dei requisiti sotto riportati.
Il piano dovrà contenere una descrizione della metodologia, dell’organizzazione, degli interventi a supporto ed una prima pianificazione temporale degli stessi.
La prima versione di dettaglio del piano integrato di supporto alla gestione del cambiamento dovrà essere consegnato entro trenta giorni dalla stipulazione del contratto, fatta salva la possibilità di rimodulazioni temporali in corso di esecuzione del contratto, previa richiesta e successiva approvazione da parte dell’Amministrazione.
Per quanto riguarda gli interventi di formazione, l’offerente deve descrivere le modalità e i tempi di erogazione dei servizi richiesti, che dovranno essere resi durante l’intera fase esecutiva, nel rispetto delle esigenze minimali sotto descritte e in coerenza con il piano integrato.
Le migliorie valutabili non potranno avere ad oggetto estensioni della durata in termini di ore delle giornate formative.
TIPOLOGIA | GIORNATE MINIME (DURATA 4 ORE) |
Formazione in aula | 30 (120 ore = 30*4 ore) |
Gli interventi di formazione di cui sopra dovranno avere ad oggetto:
> Utilizzo delle applicazione per gestione della piattaforma.
La formazione dovrà avvenire, ove possibile, su singoli moduli e con il coinvolgimento dei relativi utenti; ogni sessione non dovrà coinvolgere più di quindici utenti; l’aggiudicatario dovrà, inoltre, formare degli esperti di dominio su ognuno dei moduli in uso.
Le aule per la realizzazione delle attività di formazione/affiancamento previste nel presente appalto, saranno messe a disposizione dal SISTEMA-MINORENNI. Rimangono a completo carico dell’aggiudicatario le attività di verifica delle impostazioni delle postazioni informatiche presenti nell’aula stessa, per garantire il corretto funzionamento degli applicativi oggetto della sessione di formazione. In caso di esito negativo delle verifiche sulle postazioni, sarà cura dell’aggiudicatario comunicare le problematiche riscontrate e provvederà a risolverle o fornirà una nuova aula.
Si specifica che le giornate di formazione in aula indicate nella tabella precedente, saranno considerate incluse nei servizi a corpo per la realizzazione dell’intervento SISTEMA-MINORENNI. Nei servizi di formazione erogati a consumo saranno computate esclusivamente le eventuali giornate supplementari richieste dall’Amministrazione.
Modalità di erogazione servizi di formazione/affiancamento su richiesta.
Nel corso del contratto, l’Amministrazione potrà richiedere l’erogazione di ulteriori giornate di formazione necessarie per l’illustrazione di nuove funzionalità realizzate e/o di moduli applicativi già esistenti.
L’aggiudicatario dovrà, inoltre, prevedere un sistema di affiancamento on site che sarà richiesto dall’Amministrazione come supporto nell’utilizzo dei sistemi ed in particolare in occasione di specifiche scadenze legate agli obblighi fiscali e di legge quali, a titolo esemplificativo, la chiusura dell’esercizio finanziario, l’elaborazione del conto consuntivo, la predisposizione degli allegati alla finanziaria, l’approvazione del bilancio.
Gli affiancamenti on – site e le eventuali ulteriori giornate di formazione che saranno richieste dall’Amministrazione, anche per gestire eventuali rilasci di nuove funzionalità dei sistemi a seguito di interventi di manutenzione evolutiva, saranno soggetti all’autorizzazione del Direttore dell’esecuzione nel limite del budget a consumo messo a disposizione dall’Amministrazione.
L’esecuzione del servizio comprende, inoltre, l’elaborazione di proposte di azioni di riallineamento o miglioramento organizzativo, volte alla semplificazione dei processi. L’offerente dovrà descrivere la
metodologia e dettagliare i servizi che saranno resi. Saranno positivamente valutate eventuali proposte di migliorie e utilizzo di soluzioni innovative.
2 Modalità di esecuzione
2.1 Gestione e governo del progetto
Con un’efficiente gestione del progetto l’aggiudicatario contribuisce ad assicurare il successo e la qualità dell’intervento. Ai fini del raggiungimento degli obiettivi è necessario garantire una forte partecipazione da parte degli utenti interni e la costante concertazione con gli attori coinvolti.
Sono incluse nella gestione del progetto le modalità di conduzione, monitoraggio e rendicontazione dell’intervento, il coordinamento, l’organizzazione e la composizione del team di progetto, gli strumenti utilizzati per garantire il rispetto dei livelli essenziali di servizio e la gestione del rischio.
L’offerente dovrà presentare il modello organizzativo prescelto per la gestione del progetto, differenziando organi di direzione e team progettuale per la fornitura dei prodotti e l’erogazione dei servizi, esplicitando articolazione, ruoli, profilo professionale, compiti assegnati e connesse responsabilità.
L’offerente dovrà, inoltre, descrivere le metodologie e gli strumenti utilizzati per il governo dell’intervento.
Come supporto alla gestione dell’intervento, l’aggiudicatario dovrà utilizzare un sistema software che permetta:
> la programmazione delle attività e delle risorse necessarie per lo specifico progetto;
> il monitoraggio dell’andamento dei servizi;
> la memorizzazione delle principali caratteristiche del progetto;
> la gestione degli aspetti relativi alla rendicontazione delle attività;
> elaborazioni statistiche e reportistica sulle informazioni gestite;
> pubblicazione di tutti i documenti e prodotti predisposti in esecuzione del contratto.
L’accesso al software dovrà essere consentito alle figure coinvolte nella gestione del contratto; a tal fine l’Amministrazione comunicherà i nominativi del personale autorizzato.
L’aggiudicatario, ai fini della verifica dello stato di avanzamento lavori (SAL) da parte dell’Amministrazione, dovrà produrre e allegare la documentazione minimale utile al monitoraggio del progetto.
2.2 Fasi di realizzazione degli interventi SISTEMA-MINORENNI
L’aggiudicatario dovrà realizzare i sistemi e gli applicativi con un ciclo di sviluppo che dovrà comprendere le fasi di:
> Analisi e raccolta dei requisiti;
> Disegno tecnico e funzionale;
> Sviluppo del software;
> Test;
> Ripresa dati anno in corso;
> Rilascio in esercizio.
Alla fine di ogni fase dovranno essere rilasciati uno o più deliverable la cui pianificazione e descrizione dovrà essere dettagliata nell’offerta tecnica. Per l’attività di sviluppo software i deliverable documentali minimi richiesti sono elencati nel paragrafo 2.6. Di seguito si dettagliano le varie fase progettuali.
2.2.1 Analisi e raccolta dei requisiti.
In corso di esecuzione l’aggiudicatario dovrà completare e integrare l’analisi preliminare contenuta nel presente documento, con particolare riferimento al flusso di gestionale e alla situazione organizzativa ed ai processi attualmente adottati dalla Procura della Repubblica presso il Tribunale per i Minorenni.
L’aggiudicatario dovrà definire in dettaglio:
> L’organizzazione e i processi afferenti alle entità oggetto degli interventi;
> Le esigenze specifiche della Procura della Repubblica presso il Tribunale per i Minorenni, definendo le diversità e le ipotesi di omogeneizzazione organizzativa e di processo;
All’interno dell’offerta tecnica dovranno essere descritti gli strumenti, le metodologie e le risorse professionali che si propone di utilizzare per l’esecuzione delle attività sopra indicate.
L’approvazione dei deliverable prodotti in questa fase sarà sottoposta per approvazione al Direttore dell’esecuzione del contratto.
2.2.2 Disegno tecnico e funzionale.
Ultimata l’analisi e ridefiniti i processi, l’aggiudicatario dovrà predisporre la documentazione di disegno della soluzione software da realizzare.
L’aggiudicatario dovrà definire nel dettaglio:
> il disegno architetturale ed infrastrutturale della soluzione adottata, ove richiesto anche tramite l’uso di modellizzazione UML – Unified Model Language 2.x;
> il disegno funzionale della soluzione con il dettaglio dei ruoli e delle azioni previste per ciascun ruolo, ove richiesto anche tramite l’uso di modellizzazione UML – Unified Model Language 2.x, flowchart diagarm;
> il disegno del modello dati concettuale e logico, ove richiesto anche tramite l’uso di modellizzazione E/R – schemi entità/relazione e per quanto concerne gli strumenti di datawarehouse e business intelligence, gli schemi a stella – schema dei fatti/dimensioni.
Dovranno essere prodotti una serie di documenti tecnici di dettaglio sull’architettura e sul funzionamento della soluzione software.
L’approvazione dei deliverable prodotti in questa fase sarà sottoposta alla sola approvazione da parte del Direttore dell’esecuzione del contratto.
2.2.3 Sviluppo del software.
Durante questa fase l’aggiudicatario dovrà implementare quanto dettagliato nella documentazione di disegno. Il codice sorgente sviluppato dovrà essere adeguatamente commentato e documentato.
Al termine della fase di realizzazione dovranno essere rilasciati:
> Il codice sorgente;
> La documentazione del codice sorgente;
> Gli script per la configurazione delle basi di dati;
> Gli script di installazione dell’applicazione software;
> Il manuale di installazione e configurazione;
> Il manuale utente in formato PDF, corredato di screen-shot illustrativi, per gli utenti interni.
Allo scopo di avere riscontri oggettivi e puntuali sul lavoro svolto, l’aggiudicatario dovrà coinvolgere la direzione dell’esecuzione mediante il rilascio periodico di prototipi e/o versioni parziali delle soluzioni in corso di sviluppo.
Tutto il software fornito/prodotto dovrà essere ceduto all’Amministrazione Regionale che ne acquisirà di fatto la proprietà.
2.2.4 Testing del software.
Al fine di garantire un elevato standard qualitativo dovranno essere predisposti da parte dell’aggiudicatario specifici Unit e Integration Test, per la verifica del corretto funzionamento delle applicazioni da parte del team di progetto, e User Acceptance Test, per la convalida del corretto funzionamento delle applicazioni da parte dell’utenza finale.
Oltre ai test “funzionali” dovranno essere eseguiti i test sulle performance del sistema per garantire i requisiti di solidità espressi nei precedenti paragrafi.
I test dovranno essere organizzati in maniera da avere una copertura totale delle funzionalità previste e, per quanto riguarda gli User Acceptance Test, dovranno essere preventivamente concordati con il Direttore dell’esecuzione del contratto.
2.2.5 Ripresa dati anno in corso
Per poter garantire la completezza e la coerenza del dato presente sui nuovi sistemi, sarà onere dell’aggiudicatario la ripresa di tutti i dati e le informazioni presenti nelle banche dati in uso alla Procura della Repubblica presso il Tribunale per i Minorenni, anagrafiche e dati storici, che saranno fornite secondo un formato concordato ed adatto all’inserimento nella nuova piattaforma. I dati, forniti secondo tracciati predefiniti studiati in fase di analisi, dovranno essere importati sul sistema entro la data di avvio dello stesso. I referenti individuati per la collazione dei dati oggetto di ripresa, dovranno essere adeguatamente supportati ed affiancati al fine di garantire agli stessi la massima comprensione nell’utilizzo e compilazione dei tracciati di cui sopra.
2.2.6 Rilascio in esercizio.
A seguito dell’esito positivo degli User Acceptance Test si potrà procedere all’avvio in esercizio delle soluzioni realizzate.
2.3 Consistenza e caratteristiche del team di progetto dell’aggiudicatario
L’aggiudicatario dovrà costituire e mantenere per tutta la durata dell’appalto un gruppo di lavoro che garantisca il rispetto dei livelli di servizio stabiliti per la fornitura dei prodotti e l’esecuzione dei servizi oggetto dell’appalto (cfr. paragrafo 1).
Le risorse utilizzate devono, in base al ruolo ricoperto, soddisfare i seguenti requisiti:
> Esperienza di lavoro in progetti analoghi a quello in oggetto;
> Disponibilità e attitudine sperimentata al lavoro di gruppo;
> Capacità di ascolto e di comunicazione scritta, verbale e non verbale, nonché capacità motivazionale;
> Orientamento al cliente e al problem solving;
> Flessibilità, elevata capacità di percezione e comunicazione del valore di progetto;
> Esperienza di lavoro in ambienti di gestione organizzata dell’assistenza e manutenzione di applicazioni web-based;
> Conoscenza dei prodotti di Office Automation, sia come strumenti di produttività individuale sia per le funzioni di integrazione degli stessi con gli ambienti di cui al punto precedente.
Il governo dell’intervento dovrà essere assicurato da un Capo progetto, da nominarsi all’atto della stipula contrattuale, di provata competenza ed esperienza professionale nelle materie oggetto dell’appalto e, in particolare, nel campo dell’organizzazione, della gestione del cambiamento e della comunicazione, al fine di supportare l’Amministrazione nella fissazione degli obiettivi da raggiungere, nella pianificazione del processo dl cambiamento da effettuare e nella definizione delle strategie di comunicazione e sviluppo organizzativo e tecnologico.
All’interno dell’offerta tecnica dovrà essere descritto, anche con rappresentazione grafica, il modello organizzativo prescelto per la realizzazione dell’intervento, con indicazione delle figure professionali individuate distinte per ruolo e attività.
Il team di progetto dovrà comprendere, almeno, le seguenti figure professionali per i vari servizi.
Per il governo e gestione del progetto
> Capo progetto;
Per la realizzazione del sistema contabile integrato SISTEMA-MINORENNI
> Architetto di sistema;
> Consulente senior;
> Consulente junior;
> Programmatore;
Per l’erogazione del servizio di gestione operativa e sistemistica
> Sistemista IT senior;
> Coordinatore di help desk;
> Operatore help desk;
Per l’erogazione del servizio di manutenzione correttiva, adeguativa ed evolutiva
> Architetto di sistema;
> Consulente senior;
> Consulente junior;
> Programmatore;
Per l’erogazione dei servizi di supporto al change management
> Formatore.
L’assenza di una o più delle figure professionali richieste comporta l’inammissibilità dell’offerta, con conseguente esclusione dell’offerente.
L’offerente dovrà allegare all’offerta tecnica i curriculum nominativi delle figure professionali che intende impiegare per l’esecuzione dell’appalto, unitamente alla copia fotostatica del documento di identità, con indicazione del ruolo/servizio svolto. Ove l’offerente indichi risorse non incluse all’interno del proprio organico dovrà essere allegata una dichiarazione d’impegno all’espletamento dei servizi richiesti nell’ambito del presente appalto, sottoscritta dal dichiarante. La mancata allegazione della dichiarazione d’impegno è suscettibile d’integrazione. I curriculum dovranno essere inseriti in un unico tomo, pinzato o rilegato, contenente l’elenco delle risorse umane impiegate, con indicazione della figura professionale e del ruolo/servizio svolto. Dovrà essere inoltre allegata una tabella che riepiloghi le risorse offerte ed il relativo ruolo per servizio erogato. L’esclusione sarà comminata in caso di mancato inserimento di una o più figure professionali.
La valutazione della struttura organizzativa avverrà tenendo conto della composizione del team, in termini di articolazione dei ruoli e delle mansioni (Resource Breakdown Structure). Sarà oggetto di positiva valutazione l’inserimento di profili professionali aggiuntivi rispetto a quelli richiesti, funzionali alla migliore esecuzione dei servizi offerti; è onere dell’offerente esplicitarne il ruolo e le mansioni assegnate all’interno del progetto.
L’Amministrazione in corso di esecuzione potrà richiedere la sostituzione dei componenti del team di progetto, fino a un massimo pari al 20% del totale; la sostituzione dovrà avvenire con figure professionali di livello equivalente. Nel rispetto degli stessi limiti, l’aggiudicatario potrà sostituire i componenti del proprio team, previa comunicazione anticipata e valutazione del curriculum e approvazione da parte dell’Amministrazione. In tale evenienza, la presentazione del curriculum della risorsa sostitutiva e la sua approvazione da parte dell’Amministrazione, dovranno intervenire entro tempi congrui, tali da non comportare alcuna interruzione o ritardo nei servizi resi. Le medesime previsioni e limiti dovranno intendersi rispettati anche nel caso la sostituzione riguardi le eventuali risorse aggiuntive proposte quale elemento migliorativo dell’offerta.
Nei seguenti paragrafi sono dettagliate le caratteristiche minime delle figure professionali richieste.
2.3.1 Capo progetto
Il governo dell’intervento dovrà essere assicurato da un Capo progetto, di provata competenza ed esperienza professionale di almeno otto anni nell’ambito della gestione di progetti che prevedano l’erogazione di servizi nell’ambito di sistemi web-based per la Pubblica Amministrazione.
Il capo progetto deve aver sviluppato adeguate competenze in tutte le aree di conoscenza della gestione di progetto, con particolare riferimento alle aree della gestione organizzativa, della gestione del cambiamento, della gestione del rischio, della comunicazione e della gestione delle risorse umane.
Il capo progetto deve essere in possesso di diploma di laurea.
Xxxxx: il capo progetto, in accordo con l’Amministrazione, gestisce e coordina le risorse del team di progetto, ne conosce gli skill, le specializzazioni e le attitudini e ne assicura il pieno coinvolgimento e la condivisione degli obiettivi.
Svolge le funzioni di supervisione scientifica e metodologica del servizio affidato ed è garante del rispetto dei tempi, dei costi e della qualità del progetto e dei risultati.
Comunica tempestivamente all’Amministrazione regionale le criticità, le eventuali variazioni o scostamenti rilevati e intraprende, in accordo con l’Amministrazione, le necessarie azioni correttive e preventive. Collabora in maniera attiva con il Direttore dell’esecuzione identificato dall’Amministrazione.
Nel caso in cui l’Amministrazione, a suo insindacabile giudizio, non lo ritenesse idoneo a svolgere i compiti citati, il capo progetto deve essere sostituito.
2.3.2 Sistemista IT senior
In quest’ambito rientrano le figure professionali con competenze specifiche di progettazione, pianificazione e stima delle risorse e che sono inoltre dotate, dal punto di vista qualitativo, delle stesse competenze dei sistemisti con un livello professionale più elevato. Gli ambiti di specializzazione sono: Area sistemi (aree UNIX/SOLARIS, VMWARE e Microsoft), Area networking, Area RDBMS Oracle, Area prodotti dei portali web, e Area sicurezza. È richiesta un’esperienza di lavoro non inferiore ai 5 anni assieme alla capacità di coordinamento di gruppi di lavoro e di controllo della qualità del servizio e delle procedure operative.
2.3.3 Coordinatore e Operatore di help desk
Sono le figure professionali che erogano il servizio di primo supporto all’utente. Devono essere in grado di comprendere e analizzare le segnalazioni degli utenti e offrire pronta soluzione. Tali figure devono possedere una buona conoscenza:;
> delle applicazioni in area Portale WEB;
Esperienza di lavoro richiesta non inferiore ai 2 anni per gli operatori dell’Help Desk. Per il coordinatore si rinvia a quanto previsto per i consulenti senior.
2.3.4 Architetto di sistema
In quest’ambito rientrano:
> La figura professionale con elevata competenza applicativa e vista d’insieme su una o più soluzioni web-based. E’ in grado di orientare l’Amministrazione nelle scelte implementative, lato funzionale / applicativo, in relazione ai processi di business supportati dalle soluzioni web-based ed alla loro integrazione nell’ambito dell’architettura applicativa con particolare riferimento al settore della Pubblica Amministrazione;
> La figura professionale di analogo livello di competenze sull’ambiente Portali WEB e in generale sulle architetture applicative che abilitano la piena dematerializzazione della documentazione amministrativa.
Esperienza di lavoro richiesta non inferiore ai 5 anni.
2.3.5 Consulente senior
In quest’ambito rientrano:
> La figura professionale con competenza applicativa specifica nei sistemi web-based. Ha competenza funzionale ed applicativa sui processi di business supportati dalle soluzioni web-based con particolare riferimento al settore della Pubblica Amministrazione, e conoscenza delle norme vigenti almeno in materia. Svolge attività di parametrizzazione delle soluzioni, di analisi e progettazione funzionale e di processo;
> La figura professionale che ha competenza applicativa specifica sull’ambiente dei Portali WEB e in generale sulle applicazioni che abilitano la piena dematerializzazione della documentazione amministrativa.
Queste figure hanno il compito di tradurre le specifiche dei requisiti richieste dall'Amministrazione in specifiche funzionali degli sviluppi software, in coerenza con gli obiettivi concordati con il capo progetto, di realizzare e testare le soluzioni informatiche da consegnare.
Il Consultente Senior è una figura professionale di elevata competenza ed esperienza nel ruolo, che verrà impiegata in progetti complessi.
In ogni caso dovranno essere coperte tutte le seguenti aree funzionali in ambiente della contabilità integrata, digitalizzazione dei flussi e portali web di consulenti esperti presenti nel team di lavoro:
> Presentation layer;
> Application layer;
> Data layer;
Esperienza di lavoro richiesta non inferiore ai 4 anni.
2.3.6 Consulente junior
In quest’ambito rientrano:
> La figura professionale che ha competenza applicativa specifica sull’ambiente Portali Web e in generale sulle applicazioni che abilitano la piena dematerializzazione della documentazione amministrativa.
Queste figure, coordinate dai consulenti senior, hanno il compito di analizzare i requisiti raccolti e trasformarli in specifiche funzionali degli sviluppi software, in coerenza con gli obiettivi concordati con il capo progetto, di realizzare e testare le soluzioni informatiche da consegnare.
Il Consulente Xxxxxx è una figura professionale di media competenza ed esperienza nel ruolo, che verrà impiegata in ambiti di media complessità.
Esperienza di lavoro richiesta non inferiore ai 2 anni.
2.3.7 Programmatori
In quest’ambito rientrano:
> La figura professionale con analogo livello di competenze sull’ambiente sulle applicazioni in Java. Approfondita conoscenza delle tecnologie JAVA.
Il programmatore, sulla base delle specifiche di dettaglio e/o delle indicazioni delle figure senior/junior o del capo progetto, ha il compito di realizzare routine, programmi, librerie di oggetti e di verificarne la funzionalità. Partecipa alla stesura della documentazione tecnica, del manuale utente e del manuale di gestione. Per quanto di competenza partecipa all'installazione e all'avviamento delle soluzioni realizzate curando anche l'addestramento e l'assistenza degli Utenti.
Esperienza di lavoro richiesta non inferiore ai 3 anni.
2.3.8 Formatori
In quest’ambito rientrano specialisti della formazione dotati di capacità di progettazione e conduzione di interventi di formazione, di supporto formativo e di affiancamento. Il formatore deve inoltre possedere capacità di comunicazione, didattica e conoscenza delle tecnologie formative, con particolare riferimento agli ambienti di apprendimento in gruppo, alla preparazione del materiale didattico e di test di valutazione sull’apprendimento. Le figure devono essere specializzate su:
> una o più soluzione di portale web e, in generale, sulle applicazioni che abilitano la piena dematerializzazione della documentazione amministrativa;
Esperienza di lavoro richiesta non inferiore ai 2 anni.
2.4 Fasce orarie e luogo per l’erogazione dei servizi
L’aggiudicatario dovrà garantire l’esecuzione dei servizi nelle fasce orarie di seguito indicate.
I servizi di gestione operativa e sistemistica che riguardano l’Amministrazione e conduzione dei sistemi dovranno essere resi con una modalità che consenta l’operatività dei sottosistemi e la fruizione dei relativi servizi applicativi dal lunedì al venerdì dalle ore 8.00 alle ore 20.00; l’aggiudicatario è comunque tenuto allo svolgimento di attività di manutenzione tecnica ordinaria e straordinaria sistemistica al di fuori dell’orario succitato, in modo da non pregiudicare la fruizione dei servizi applicativi. L’arresto dei sottosistemi, in caso di comprovati motivi d’urgenza, dovrà essere concordata con l’Amministrazione regionale.
L’help desk, di I e II livello dovrà essere attivo dal lunedì al venerdì nelle ore 8.30-13.30 e 15.30-18.30.
L’attività di affiancamento dovrà essere realizzata dal lunedì al giovedì nelle ore 8.30-13.30 e 15.30- 18.30, le richieste di affiancamento on site e on demand dovranno essere concordate con l’Amministrazione.
Per i restanti servizi di manutenzione correttiva e adeguativa non si prevedono limitazioni orarie. Per i servizi di manutenzione evolutiva si specifica che una giornata uomo è pari a otto ore.
2.5 Piano operativo, piano di qualità, piano di gestione dei rischi, piano delle verifiche
L’aggiudicatario, entro trenta giorni naturali e consecutivi dalla stipulazione del contratto, dovrà predisporre e fornire, per la sua approvazione, all’Amministrazione regionale i seguenti documenti:
> Piano Operativo;
> Piano di Qualità;
> Piano di gestione dei rischi;
> Piano delle verifiche.
Durante l’esecuzione del contratto l’Amministrazione potrà effettuare tutte le verifiche ritenute opportune allo scopo di controllare il rispetto di quanto stabilito nei Piani sopra citati.
Il Piano Operativo. Nel rispetto di quanto dichiarato all’interno dell’offerta tecnica, il Piano Operativo dovrà includere almeno le seguenti informazioni:
> le modalità di erogazione dei servizi, con particolare riferimento alla sequenza di attività prevista per ciascun servizio (predisposizione apparati, consegna, installazione, assistenza e manutenzione);
> l'organizzazione del gruppo di lavoro impegnato sul contratto, con il dettaglio dei ruoli e delle responsabilità attribuite a ciascun componente del gruppo di lavoro;
> le interfacce organizzative e tecniche;
> il cronoprogramma di dettaglio;
> la scomposizione dei deliverable contrattuali al fine di definire unità di lavoro al livello di dettaglio idoneo a esercitare un efficace controllo in fase di esecuzione;
> la baseline per misurare le prestazioni di tempi e costi;
> gli indicatori da utilizzare per misurare lo stato di avanzamento e il calendario programmato per la presentazione di deliverable e lo svolgimento di riesami e verifiche;
> le principali milestone, vale a dire i momenti a cui corrispondono fatti rilevanti dal punto di vista gestionale e che costituiscono dei punti di controllo essenziali per la verifica del corretto avanzamento dei lavori;
> i problemi aperti e/o le decisioni pendenti;
> la stima dei costi di ogni attività (unità di lavoro);
Il Piano operativo dovrà essere accompagnato dal piano di fatturazione.
Il Piano di Qualità. Il piano dovrà rispondere all’esigenza di:
> fornire lo strumento per collegare i requisiti specifici dei servizi contrattualmente richiesti con le procedure generali del sistema qualità dell’aggiudicatario già esistenti;
> esplicitare le disposizioni organizzative e metodologiche adottate dall’aggiudicatario, allo scopo di raggiungere gli obiettivi tecnici e di qualità contrattualmente definiti;
> dettagliare i metodi di lavoro messi in atto dall’aggiudicatario, facendo riferimento o a procedure relative al proprio sistema, e per ciò descritte nel manuale qualità, o a procedure sviluppate per lo specifico contratto a supporto delle attività in esso descritte, in questo caso da allegare al piano;
> garantire il corretto e razionale evolversi delle attività contrattualmente previste.
In particolare i contenuti del Piano di Qualità dovranno essere elaborati secondo l'indice di seguito proposto:
1. scopo del piano della qualità - deve essere definita l'organizzazione del documento e le notazioni adottate;
2. documenti applicabili e di riferimento - devono essere identificati, codificati, referenziati tutti i documenti contrattualmente vincolanti e tutti i documenti che, pur non contrattualmente vincolanti, costituiscono un riferimento per quanto esposto;
3. glossario;
4. documentazione - deve essere definito l'insieme della documentazione da produrre nel corso dell'attuazione del contratto. Detta documentazione assume il ruolo di evidenza oggettiva dell'esecuzione delle attività da cui è generata. Devono essere definiti modelli e formati per la presentazione di tutta la documentazione progettuale che riportino i logo del progetto e le informazioni (titoli, versione, audience, storia delle modifiche del documento, data, approvazione, firme, ecc.) e l’assolvimento degli obblighi di comunicazione previsti dalla normativa comunitaria;
5. obiettivi di qualità - devono essere identificati in modo chiaro ed inequivocabile gli obiettivi di qualità del contratto; per questo è necessario definire: i prodotti intermedi che l'attuazione del contratto genera, i prodotti finali da passare in esercizio, i servizi erogati per il tramite dei prodotti realizzati; gli attributi di qualità (caratteristiche e sottocaratteristiche nella terminologia iso 9126) relativi a ciascun prodotto e/o servizio; le metriche con cui misurare gli attributi identificati; i valori limite ritenuti accettabili con cui confrontare le misure degli attributi di qualità effettuate sulla base delle metriche definite;
6. procedura per la valutazione della qualità di un prodotto/servizio - deve essere definita una procedura per la valutazione della qualità dei prodotti e/o servizi che espliciti: modalità di misura, modalità di calcolo e aggregazione di misure per il computo di indicatori derivati, frequenza delle misure, periodi temporali di riferimento. Devono essere esplicitate le regole con cui si perviene ai giudizi di approvazione incondizionata/approvazione con riserva/non approvazione, considerati i risultati relativi alle singole caratteristiche di qualità associate al prodotto e/o servizio nei requisiti di qualità;
7. verifiche ispettive - devono essere definite le modalità con cui effettuare le visite ispettive in conformità alla norma iso 19011, le motivazioni che possono richiederne l'uso estemporaneo, la quantità e la pianificazione;
8. informazioni di qualità e archiviazioni - devono essere identificate tutte le registrazioni di qualità del sistema qualità adottato e specificatamente previste per l'attuazione del contratto, a supporto delle attività di gestione del contratto e assicurazione della qualità.
9. riesami e revisioni - devono essere identificate le sessioni di riesame e di revisione in funzione del ciclo di erogazione dei servizi adottato e descritto nel piano di progetto;
10. prove e collaudi - devono essere indicate le attività di test e verifica e le relative modalità di esecuzione;
11. segnalazione di problemi e azioni correttive - devono essere riportate o referenziate le specifiche procedure previste per la gestione di problemi e non conformità; la descrizione deve comprendere la casistica, la modulistica di supporto prevista, i ruoli e le responsabilità delle risorse coinvolte;
12. strumenti, tecniche e metodi - devono essere indicate per le attività di erogazione dei servizi e produzione della documentazione, le apparecchiature e le metodologie adottate;
13. controllo dei sub-fornitori - devono essere delineate le procedure e gli accorgimenti da adottare quando alla erogazione dei servizi partecipano sub-fornitori in termini sia di valutazione preventiva, sia di controllo di quanto da questi fornito;
14. raccolta e salvaguardia dei documenti - deve essere descritta la procedura per la gestione, conservazione e salvaguardia della documentazione di progetto, nonché il periodo di mantenimento previsto della documentazione.
Il Piano di gestione dei rischi. Il piano dovrà contenere la definizione del rischio, l’identificazione dei fattori che lo determinano, la classificazione secondo entità dell’impatto e probabilità, le strategie e le tipologie di azione per ridurre le probabilità di occorrenza. In sede di offerta il concorrente dovrà descrivere la metodologia che sarà seguita per la classificazione e la strategia di gestione del rischio. Il Piano delle verifiche. Il piano dovrà essere predisposto dall’aggiudicatario e consegnato all’Amministrazione; tale documento conterrà le metodologie e tempi previsti per le verifiche della regolare fornitura della piattaforma e dei servizi erogati.
Nell’esecuzione dei servizi l’aggiudicatario dovrà tenere costantemente aggiornati i piani suddetti.
2.6 Documenti di progetto
Si riporta di seguito un elenco minimale dei deliverable che dovranno essere predisposti dall’aggiudicatario e approvati dall’Amministrazione.
ATTIVITÀ | ID | DELIVERABLE |
Gestione del progetto | GP1 | Piano operativo |
GP2 | Piano di qualità | |
GP3 | Piano di gestione dei rischi | |
GP4 | Piano delle verifiche | |
SISTEMA-MINORENNI | SISTEMA- MINORENNI-AR | Analisi dei Requisiti dell’applicazione |
ATTIVITÀ | ID | DELIVERABLE |
SISTEMA- MINORENNI -DT | Disegno Tecnico (architetturale e applicativo) dell’applicazione | |
SISTEMA- MINORENNI -MAN | Manuale Utente dell’applicazione | |
Gestione operativa e sistemistica | GS1 | Registro dei malfunzionamenti |
GS2 | Inventario HW e SW | |
GS3 | Piano di subentro | |
Manutenzione correttiva e adeguativa | MAC1 | Registro delle manutenzione correttive |
MAD1 | Registro delle manutenzioni adeguative | |
MAD-Ixx | Relativi documenti del singolo ciclo di sviluppo dell’intervento (xx è il suo numero progressivo) | |
Manutenzione evolutiva | MEV1 | Registro delle manutenzioni evolutive |
MEV-Ixx | Relativi documenti del singolo ciclo di sviluppo dell’intervento (xx è il suo numero progressivo) | |
Formazione e supporto | FOR1 | Piano integrato di formazione e supporto al change management |
Stato avanzamento lavori | SALxx | Stato avanzamento lavori xx |
Nel piano operativo dovranno essere specificate le date di consegna di ogni deliverable nel rispetto di quanto richiesto nel presente Capitolato Speciale Descrittivo e Prestazionale. Da tale scadenza, l’Amministrazione avrà a disposizione dieci giorni per richiedere eventuali integrazioni o modifiche. Per i deliverable più importanti, dovrà essere previsto il rilascio di semilavorati, i cui contenuti e le cui date di consegna saranno concordati con l’Amministrazione. Si precisa infine, che i documenti dovranno essere prodotti in lingua italiana, fatta eccezione per la documentazione di prodotto che, se non disponibile, potrà essere consegnata in lingua inglese.
2.7 Obblighi in tema di informativa e comunicazione
Tutta la documentazione e i prodotti del presente appalto dovranno riportare i seguenti elementi distintivi:
> Indicazione della sigla dell’intervento del progetto “GIUSTIZIA-DIGITALE2” – con riportato il codice CIG e CUP;
> l’inserimento dell’emblema della Regione Autonoma della Sardegna (1).
1 Secondo le indicazioni de “Lo stemma, patrimonio identitario della Regione - linee guida per l’utilizzo degli elementi di identità visiva istituzionale della Regione Autonoma della Sardegna”.
3 Livelli di servizio e commisurazione delle penali
È richiesta una particolare cura nella massimizzazione dei livelli di qualità delle attività e dei prodotti, per i quali dovranno essere predisposti degli strumenti di rilevazione quantitativa da mettere a disposizione dell'Amministrazione. L’aggiudicatario, per l’intera durata del contratto, dovrà effettuare una continua rilevazione dei livelli di servizio offerti e produrre la documentazione in cui si evidenzia il rispetto o meno delle soglie degli SLA, con una cadenza pari a quella di presentazione dello stato di avanzamento lavori.
Il Direttore dell’esecuzione del contratto si riserva la facoltà di verificare il rispetto dei livelli essenziali di servizio (SLA), analoga verifica sarà effettuata dalla Commissione incaricata della verifica finale di conformità; a tal fine l’aggiudicatario è tenuto a presentare, unitamente agli stati di avanzamento bimestrali, i report descrittivi dell’andamento dell’erogazione dei servizi, con misurazioni e controlli effettuati; i report dovranno essere redatti, ove possibile, utilizzando fogli di calcolo.
Ad ogni livello di servizio è collegato, per il mancato rispetto, la commisurazione di una penale che l’Amministrazione si riserva di applicare.
Ai fini della valutazione dell’offerta il concorrente dovrà descrivere il sistema di controllo e rendicontazione dei servizi erogati, al fine di rendere evidente il rispetto o meno degli SLA.
3.1 Rispetto delle tempistiche di erogazione dei servizi di gestione operativa e sistemistica
PENALI | |||||
ID | Descrizione | Soglia e metodo di calcolo | Penale da applicare | ||
SLA01 | Disponibilità dei sistemi/sottosistemi in esercizio dal Lunedì al Venerdì ore 08.00-20.00. Esclusi blocchi programmati. | Valore >=99% di disponibilità Rapporto tra i periodi di disponibilità del sistema/sottosistema e il totale del periodo previsto | 250 Euro per ogni scostamento inferiore. | punto % | di |
SLA02 | Accuratezza dei backup | Valore >=99% NS = numero di salvataggi NSOK = numero di salvataggi completati correttamente e schedulati secondo i piani Valore=(NSOK / NS) * 100 sul periodo di riferimento pari al SAL | 500 Euro per ogni scostamento inferiore | punto % | di |
SLA03 | Help desk 1° livello: Indice di tempestività di risoluzione delle chiamate all’help desk primo livello in caso di assistenza | Valore >=95% NTR = Numero totale delle chiamate risolte dal I livello NR = Numero delle chiamate risolte in tempo <= 30 minuti Valore=(NR*100)/NTR | 100 Euro per ogni scostamento inferiore | punto % | di |
3.2 Rispetto delle tempistiche di erogazione dei servizi di manutenzione correttiva e adeguativa
PENALI | |||
ID | Descrizione | Soglia e metodo di calcolo | Penale da applicare |
SLA04 | > Tempo di intervento e ripristino dell’operatività delle applicazioni in caso di errori e malfunzionamenti che necessitano di un intervento correttivo. | Tempo max di risoluzione dal momento della segnalazione e classificazione del problema | > 300 Euro per ogni punto di scostamento inferiore alla soglia per i problemi di alta priorità > 200 Euro per ogni punto di scostamento inferiore alla soglia per i problemi di media priorità > 100 Euro per ogni punto di scostamento inferiore alla soglia per i problemi di bassa priorità |
> 1 giorno per i problemi di alta priorità (per almeno il 95% | |||
delle segnalazioni) | |||
> 3 giorni per i problemi di media priorità (per almeno il 93% delle segnalazioni) | |||
> 5 giorni per i problemi di bassa priorità (per almeno il 90% delle segnalazioni) | |||
SLA05 | Tasso di rispetto dei tempi per interventi di manutenzione adeguativa richiesti. | Valore >=95% NITP = numero di interventi attuati nei tempi previsti NIT = numero totale di interventi Valore =(NITP/ NIT)*100 % | 200 Euro per ogni punto % di scostamento inferiore |
Per il servizio relativo alla risoluzione dei problemi di guasto si specifica che la presa in carico e la classificazione del problema dovrà avvenire entro le 2 ore dal momento della segnalazione pervenuta dall’utente. La classificazione dovrà esser concordata con l’utente e dovrà tener conto della seguente specifica generale:
> I problemi di alta priorità si riferiscono agli eventi che pregiudicano gravemente il funzionamento della piattaforma, quali ad esempio il blocco del sistema o l’impossibilità di accesso ad esso da parte dell’utenza qualificata alle operazioni di sviluppo;
> I problemi di media priorità si riferiscono agli eventi relativi alle anomalie del dato o malfunzionamenti di parte dei servizi della piattaforma;
> I problemi di bassa priorità riguardano guasti o malfunzionamenti che non pregiudicano la disponibilità e l’utilizzo del sistema.
Il Fondo FITQ si riserva di concedere una dilazione temporale per la risoluzione delle problematiche di alta e media complessità dinanzi a motivazioni scritte e dettagliate dall’aggiudicatario.
3.3 Rispetto delle tempistiche di erogazione dei servizi di manutenzione evolutiva
PENALI
ID | Descrizione | Soglia e metodo di calcolo | Penale da applicare |
SLA06 | Rispetto della pianificazione per gli interventi di manutenzione evolutiva | Valore >=95% NITP = numero di interventi attuati nei tempi previsti NIT = numero totale di interventi Valore =(NITP/ NIT)*100 % | 250 Euro per ogni punto % di scostamento inferiore |
3.4 Rispetto della qualità di erogazione del servizio di supporto alla gestione del cambiamento
Per i seguenti SLA la periodicità di calcolo e monitoraggio è da riferirsi ad un arco temporale bimestrale. In accordo con l’Amministrazione nella fase di predisposizione del piano operativo potranno essere proposte delle differenti cadenze di monitoraggio.
PENALI | |||
ID | Descrizione | Soglia | Penale da applicare |
SLA07 | Livello generale di qualità delle lezioni frontali erogate | Valore >=80% Per i questionari anonimi di fine corso per cui è stata compilata la domanda conclusiva: “Come si reputa la qualità generale del corso”, si deve rispettare la soglia media di gradimento minima di 7 punti in un intervallo tra 1 e 10, sul totale dei test effettuati nel periodo. | 50 Euro per ogni punto % di scostamento inferiore |
3.5 Rispetto delle tempistiche per la consegna dei documenti di progetto ed il raggiungimento delle milestone di progetto
PENALI | ||
ID | Descrizione | Soglia e penale da applicare |
SLA08 | Consegna dei piani operativo, di qualità, di gestione dei rischi e delle verifiche | 0,1 per mille del corrispettivo contrattuale netto per ogni giorno di scostamento della tempistica indicata nel paragrafo 2.5 |
SLA09 | Consegna piano integrato di supporto al change management | 0,1 per mille del corrispettivo contrattuale netto per ogni giorno di scostamento della tempistica indicata nel paragrafo 1.3.4 |
SLA10 | Consegna dei documenti sullo stato di avanzamento lavori | 0,1 per mille del corrispettivo contrattuale netto per ogni giorno di scostamento della tempistica indicata nel paragrafo 5 |
SLA11 | Consegna documentazione | 0,1 per mille del corrispettivo contrattuale netto per il SISTEMA-MINORENNI per ogni |
giorno di scostamento della tempistica indicata in offerta o nel piano operativo. | ||
SLA 12 | Rilascio in produzione SISTEMA-MINORENNI | 0,1 per mille del corrispettivo contrattuale netto per il progetto per la realizzazione dell’applicazione SISTEMA-MINORENNI per ogni giorno di scostamento della tempistica indicata nel paragrafo 4 |
4 Cronoprogramma
Il cronoprogramma di massima degli interventi è riportato nella relazione tecnica-illustrativa, alla quale si fa rinvio.
Di seguito sono riportate le principali milestone del progetto che prevedono la consegna dei deliverable più rilevanti che l’aggiudicatario è obbligato a rispettare ed il rilascio in produzione delle soluzioni realizzate. Il tempo è calcolato in mesi solari a partire dalla stipula del contratto.
L’offerente nell’offerta tecnica dovrà produrre un cronoprogramma di progetto con l’indicazione delle attività e tempi di realizzazione, nel rispetto delle milestone di seguito indicate:
Milestone | Descrizione | Mesi dalla stipula del contratto |
MS-DOC | Consegna del piano operativo, di qualità, di gestione dei rischi e delle verifiche e del piano integrato di supporto al change maSnagement. | 1 |
SISTEMA- MINORENNI | Rilascio in produzione SISTEMA-MINORENNI | 24 |
Infine, si specifica che:
> La gestione dei sistemi già in essere dovrà essere presa in carico a partire dalla sottoscrizione del contratto fino alla fine del 36-esimo mese;
> La gestione, manutenzione e il supporto alla gestione del cambiamento per i sistemi e gli applicativi realizzati con il presente appalto, SISTEMA-MINORENNI, dovranno essere garantite dall’avvio in produzione fino alla conclusione del contratto, con le medesime modalità e livelli di servizio di cui al punto uno e sarà inclusa nel prezzo a corpo dell’offerta.
5 Stati di avanzamento lavori, verifiche intermedie e finali
La complessità dell'iniziativa prevede una forte governance da parte dell'Amministrazione, che dovrà costantemente partecipare all'esecuzione durante tutte le fasi progettuali, con continue verifiche ed indicazioni sulle scelte progettuali principali e sulle modalità di esecuzione. Questa modalità di governo continuo sarà accompagnato da formali verifiche intermedie (Stati Avanzamento Lavori), associate all’erogazione di tranches di pagamento.
Per quanto riguarda i servizi di gestione, sono previsti Stati Avanzamento Lavori bimestrali, durante i quali saranno verificate e rendicontate tutte le attività svolte nel bimestre precedente. In sostanza, per
i servizi a canone gli stati di avanzamento saranno presentati con cadenza bimestrale; si specifica che il prezzo pattuito deriva da quello offerto dall’aggiudicatario per i relativi servizi.
Per i servizi da erogare a consumo gli stati di avanzamento saranno presentati con cadenza bimestrale; si specifica che potranno essere portate in pagamento sole le attività completate (per le relative giornate/uomo effettivamente erogate), con allegazione degli esiti positivi degli UAT e delle eventuali ulteriori verifiche effettuate.
Per quanto riguarda gli interventi a corpo, SISTEMA-MINORENNI, le verifiche saranno cadenzate e dettagliate nell’ambito del piano operativo, sulla base del cronoprogramma di dettaglio proposto in offerta dall’aggiudicatario.
Tutte le verifiche potranno essere accompagnate, a discrezione dell'Amministrazione, da verifiche di conformità parziali.
Si sottolinea che:
> in occasione di ogni SAL è previsto l’accantonamento di una riserva pari al 0,5% dell’importo rendicontato ai sensi dell’art. 30 comma 5 del D.Lgs 50/2016;
> la riserva accantonata sarà sbloccata al termine della verifica di conformità finale di tutti i servizi.
La verifica di conformità finale sarà terminata entro 2 mesi dalla dichiarazione di approntamento e potrà essere anticipata da verifiche parziali in corso d’opera che saranno fissate a discrezione della stazione appaltante.
Il Responsabile del Procedimento
Xxx. Xxxxxx xxxxx
Il Direttore del Servizio
Xxx. Xxxxxxxxxx Xxxxxxx