Procedura aperta per la “Realizzazione dell’Infrastruttura del Sistema Informativo Sociale Regionale”

Relazione Tecnico Progettuale

(Allegato A)

INDICE

1. INTRODUZIONE 5

1.1 Obiettivi del documento 5

1.2 Struttura del documento 5

1.3 Acronimi 6

2. OGGETTO DELLA REALIZZAZIONE 8

2.1 Il contesto di riferimento 8

2.2 Gli obiettivi ed i requisiti del progetto 9

2.3 Le linee guida per la redazione dell’Offerta Tecnica 10

3. IL QUADRO DI RIFERIMENTO REGIONALE E NORMATIVO 11

3.1 Quadro degli interventi ICT regionali 11

3.2 Normativa di riferimento 12

3.3 Gli obiettivi strategici della Regione Abruzzo 13

4. LA SOLUZIONE PROGETTUALE 15

4.1 Cittadino 15

4.2 Comune 16

4.3 Ambito Distrettuale Sociale 16

4.4 Xxxxxxx Xxxxxxx 00

4.5 Il Sistema informativo dei Servizi Sociali 18

4.6 Principali funzioni del software 20

4.7 Ulteriori integrazioni 22

5. IL CONTESTO TECNOLOGICO ED APPLICATIVO 23

5.1 Architetture di riferimento 23

5.2 INFRASTRUTTURA DI RIFERIMENTO: CTTL 24

5.2.1 Infrastruttura di Comunicazione Integrata 24

5.2.2 Infrastruttura elaborativa/applicativa 25

5.2.3 Infrastruttura Storage Area Network virtualizzata 29

5.2.4 Moduli software di base per DR e BC 30

5.2.5 Standard di sicurezza per l’interscambio delle informazioni 30

5.2.6 Infrastruttura applicativa di test e sviluppo 32

6. STANDARD E TECNOLOGIE DI RIFERIMENTO 33

6.1 SOA e Web Services 33

6.2 ROA e Rest 35

6.3 Standard di sicurezza per l’interscambio delle informazioni 35

7. LE CARATTERISTICHE DEI SERVIZI 38

7.1 Servizio di analisi preliminare 38

7.1.1 Servizio di verifica preliminare dei locali 38

7.1.2 Servizio di analisi preliminare dell’infrastruttura elaborativa esistente 39

7.1.3 Analisi preliminare dei servizi applicativi esistenti 39

7.2 Servizio di sviluppo applicativo 40

7.3 Servizio di consegna e installazione 41

7.4 Servizio di integrazione 43

7.5 Servizio di configurazione e messa in esercizio 43

7.6 Servizio di garanzia e manutenzione 44

7.7 Servizio di formazione e addestramento 46

7.8 Servizi accessori 47

7.9 Modalità di esecuzione dei servizi 47

8. ELEMENTI QUANTATIVI 49

8.1 Hardware di base 49

9. MODALITA’ DI ESECUZIONE DELLE ATTIVITA’ 50

9.1 Il Piano delle attività 50

9.2 La documentazione di progetto 50

9.3 Il gruppo di lavoro 51

9.3.1 Project Management 51

9.3.2 Il capo progetto tecnico per il Concorrente 53

9.4 I PROFILI PROFESSIONALI 53

9.4.1 I curricula 55

10. I COSTI 57

10.1 Costi di realizzazione complessivi 57

10.2 Il quadro analitico dei costi 57

11. LE MODALITA’ DI PRESENTAZIONE DEL PROGETTO 58

11.1 L’Offerta Tecnica 58

12. CONCLUSIONI 59

13. ALLEGATI 60

1. INTRODUZIONE

L’Agenzia Regionale, che opera quale Soggetto Attuatore per conto della Regione Abruzzo, attraverso il presente intervento si pone l’obiettivo di avviare la realizzazione di un sistema informativo sociale regionale per l’Osservatorio Sociale Regionale, in base alle indicazioni fornite dai responsabili regionali del “Servizio Programmazione Sociale e Sistema Integrato Sociosanitario”, al fine di creare un sistema integrato e interoperabile tra le diverse strutture coinvolte che consenta l’elaborazione nonché il monitoraggio dei dati sui servizi alla persona.

In particolare la Regione Abruzzo intende procedere con la realizzazione di un sistema che, grazie ad una opportuna gestione delle informazioni, permetta un monitoraggio efficiente delle attività degli Ambiti Distrettuali Sociali.

Nel progetto è incluso anche un insieme di servizi finalizzati al raggiungimento degli obiettivi. L’insieme dei servizi deve essere inteso come l’insieme delle attività complementari e necessarie ad una integrazione a livello operativo e gestionale all’interno dell’infrastruttura esistente, oltre che finalizzate a garantire la completa messa a punto e tuning del sistema complessivo per mezzo della definizione di uno schema metodologico per la gestione in esercizio validato in corso di realizzazione.

1.1 Obiettivi del documento

La Relazione Tecnico Progettuale si pone come obiettivo quello di fornire alle Ditte concorrenti il riferimento per predisporre l’Offerta Tecnica e l’Offerta Economica richieste dal bando di gara.

Le indicazioni fornite costituiscono i requisiti minimi di cui tenere conto e sono da intendersi come base per la realizzazione del progetto, conseguentemente le Ditte concorrenti potranno individuare soluzioni migliorative a quanto proposto con il vincolo di non modificare il quadro architetturale ed applicativo generale proposto.

1.2 Struttura del documento

La Relazione Tecnico Progettuale, articolata in dodici capitoli, illustra l’insieme delle attività da realizzare in tutte le sue componenti e le collega alle procedure di gara.

Nel primo capitolo sono illustrati gli obiettivi e lo scopo del documento.

Nel secondo capitolo sono illustrati l’oggetto della gara, gli obiettivi da realizzare e le linee guida per la redazione dell’Offerta Tecnica.

Nel terzo capitolo si descrive il contesto di riferimento normativo e gli obiettivi strategici della Regione Abruzzo.

Nel quarto capitolo si descrive la soluzione progettuale per quanto riguarda i dettagli

implementativi e le caratteristiche minime.

Nel quinto capitolo si illustra l’architettura tecnologica e applicativa di riferimento all’interno della quale la soluzione dovrà essere contestualizzata per quanto riguarda l’infrastruttura esistente.

Nel sesto capitolo si descrivono gli standard e le tecnologie di riferimento.

Nel settimo capitolo sono dettagliate le caratteristiche dei servizi del progetto.

Nell’ottavo capitolo si riportano gli elementi quantitativi collegati alla fornitura ed ai servizi richiesti.

Nel nono capitolo sono dettagliate le modalità di esecuzione delle attività di progetto.

Nel decimo capitolo sono illustrate le modalità di presentazione dei prospetti dei costi di progetto. Nell’undicesimo capitolo sono riportate nel dettaglio le modalità di presentazione dell’Offerta Tecnica.

Infine nel dodicesimo capitolo si riportano sinteticamente le conclusioni e nel tredicesimo l’elenco degli allegati.

1.3 Acronimi

Nel seguito si farà uso dei seguenti acronimi:

ARIT	Agenzia Regionale per l’informatica e la Telematica
ARIC	Agenzia Regionale per l’informatica e la Committenza
CTTL	Centro Tecnico Tortoreto Lido
GUI	Graphical User Interface
HTML	HyperText Mark-Up Language
ICT	Information and Communication Technologies
IDE	Integrated Development Environment
INPS	Istituto Nazionale della Previdenza Sociale
J2EE	Java2 Platform Enterprise Editing
LAN	Local Area Network
SOA	Service Oriented Architecture
SOI	Service Oriented Integration
ROA	Resource Oriented Architecture
HTTP	Hiper Text Transfer Protocol
SOAP	Simple Object Access Protocol
WSDL	Web Services Definition Language

REST	REpresentational State Transfer
UDDI	Universal Description Discovery and Integration
TCP	Transfer Control Protocol
SPC	Sistema Pubblico di Connettività
SPCooP	Sistema Pubblico Connettività e Cooperazione
SQL	Structured Query Language
SSO	Single Sign On
UC	Use Case
UML	UnifiedModeling Language
VPN	Virtual Private Network
XML	eXtensibleMarkUp Language
MMG	Medici di Medicina Generale
PLS	Pediatri di Libera Scelta
SIUSS	Sistema informativo Unitario dei Servizi Sociali

2. OGGETTO DELLA REALIZZAZIONE

Il progetto è finalizzato a creare un sistema applicativo che permetta un adeguato e affidabile monitoraggio delle informazioni sociali automaticamente integrate in un applicativo centralizzato.

La soluzione deve permettere la creazione di una banca dati contenente le informazioni di pertinenza degli utenti dei servizi che implementino la “Cartella sociale del cittadino”. Dovrà essere possibile l’estrazione dei dati in forma aggregata e anonima, in formato idoneo alle analisi necessarie, attraverso un pannello regionale che consenta in automatico analisi standard, di base e più evolute al fine di effettuare verifiche sui dati reali caricati dagli operatori sociali.

La realizzazione progettuale prevede la fornitura di applicativi software, ma anche la loro personalizzazione per una perfetta integrazione con i sistemi in essere presso la Regione Abruzzo e gli Enti coinvolti.

Nel progetto, pertanto, dovranno essere previsti gli elementi software necessari al raggiungimento degli obiettivi congiuntamente alla possibilità di sviluppare nuovi moduli applicativi, e allo svolgimento di attività di assistenza e supporto operativo diretto, di conduzione funzionale, di garanzia, di help desk e di formazione mirati alla realizzazione degli interventi per l’utilizzo effettivo del sistema.

Le attività di seguito descritte saranno realizzate sulla base delle indicazioni definite dalla Stazione Appaltante, che detiene il know-how di riferimento e la responsabilità del progetto complessivo.

Tutto il materiale documentale realizzato nell’ambito delle attività sarà di proprietà esclusiva della Regione Abruzzo e dell’Agenzia.

Per la realizzazione operativa sarà costituito un adeguato gruppo di lavoro caratterizzato da diversi ruoli e responsabilità, continuità operativa a medio termine e obiettivi condivisi.

Il gruppo di lavoro per la realizzazione sarà coordinato dall’ARIT secondo le indicazioni definite nel presente documento.

2.1 Il contesto di riferimento

Le attività dell’Osservatorio Sociale Regionale coinvolgono direttamente i ventiquattro “Ambiti Distrettuali Sociali”; l’intento è di ottimizzare le attività degli Ambiti attraverso la fornitura di uno strumento applicativo per la gestione dei flussi informativi di dati relativi alla programmazione sociale regionale e poter così elaborare/estrarre dati utili a livello generale per un monitoraggio

sia regionale che nazionale.

I servizi contemplati nel progetto dovranno tener conto di:

• realizzazioni già implementate o in avanzato stato di sviluppo nel campo socio assistenziale a livello nazionale , regionale e locale;

• normativa in tema di riservatezza, accesso, gestione, protezione dei dati personali;

• Piano Sociale Regionale 2016-2018 della Regione Abruzzo (disponibile sul sito dell’Osservatorio Sociale Regionale: http:// xxx.xxxxxxxxxxxxxx.xx);

• Casellario dell’assistenza dell’INPS con dati sulle prestazioni assistenziali ai cittadini;

• nomenclatore degli interventi e dei servizi sociali;

• Sistema Pubblico di Connettività (SPC).

2.2 Gli obiettivi ed i requisiti del progetto

Il Progetto persegue l’obiettivo primario della realizzazione di un sistema informativo per la gestione informatizzata dei dati. Nel dettaglio intende:

• Realizzare un sistema applicativo interoperabile tra Comuni, Ambiti e Regione ed eventuali altre strutture coinvolte;

• Fornire un servizio che permetta ai Comuni e agli Ambiti Distrettuali Sociali regionali di gestire le informazioni relative alla cartella sociale del cittadino;

• Fornire un servizio che consenta alla Regione di monitorare le informazioni in forma aggregata e anonima, dei servizi erogati al cittadino e dei loro costi.

Nel perseguire detti obiettivi saranno altresì considerate e applicate metodiche progettuali atte a consentire l’erogazione di servizi online anche da parte dei cittadini residenti.

A tal proposito, i servizi professionali previsti in fornitura dovranno possedere adeguate professionalità con conoscenze e competenze specifiche in grado di supportare il Gruppo di Lavoro composto dall’area tecnica di Agenzia in fase operativa nella realizzazione di tutti quei servizi necessari per assicurare il pieno raggiungimento degli obiettivi prefissati.

La realizzazione del progetto dovrà prevedere l’esecuzione di attività con livelli professionali di assoluta eccellenza e, in parallelo, la formazione di un gruppo di lavoro che operi in maniera coordinata e in linea con le esigenze manifestate dall’Osservatorio Sociale Regionale e dall’Agenzia. Tale integrazione consentirà di raggiungere gli obiettivi indicati tenendo conto del

contesto tecnologico e normativo, in cui dovrà essere calata la soluzione proposta, e delle aspettative espresse dagli attori coinvolti.

Nell’Offerta Tecnica dovrà essere inclusa la presentazione dei soggetti partecipanti e le referenze delle figure professionali ad essi collegati in merito alle realizzazioni di analoghi progetti nell’ambito di tecnologie, architetture e servizi.

In generale le referenze numerate e ordinate da quelle temporalmente più recenti includono i titoli dei progetti con altre informazioni accessorie (dimensione quantitativa, personale impiegato, tecnologie impiegate, ecc.) in modo da consentire la valutazione di quanto già realizzato.

2.3 Le linee guida per la redazione dell’Offerta Tecnica

Sulla base degli obiettivi sopraindicati la progettazione da sviluppare dovrà essere tesa ad ottenere un livello qualitativo di eccellenza.

Di conseguenza, gli aspetti metodologici e tematici saranno collegati alla definizione di un progetto che privilegi la qualità tecnica complessiva della proposta e che ponga in evidenza la conoscenza degli ambienti tecnologici proposti, l’affidabilità e l’esperienza realizzativa maturata in analoghi progetti.

Gli aspetti collegati alla valutazione delle competenze ed esperienze possedute saranno affrontati con la redazione dei curricula nominativi del personale proposto che sinteticamente illustreranno il know-how posseduto, l’esperienza acquisita, la pratica progettuale ed operativa acquisita in interventi analoghi e l’esperienza maturata in progetti simili.

Le esperienze in modo complessivo saranno collegate alla definizione di un quadro aziendale tale da presentare il soggetto esecutore come un partner capace, affidabile ed esperto, avvalorato da esperienze di successo reali ottenute sul campo.

Gli aspetti e gli elementi quantitativi per la realizzazione delle attività si riferiscono alla dimensione dei servizi previsti ed agli obiettivi necessari per il loro raggiungimento.

I livelli quantitativi indicati sono quelli minimi e possono essere superati fermo restando il valore economico previsto per la realizzazione del progetto stesso.

3. IL QUADRO DI RIFERIMENTO REGIONALE E NORMATIVO

In questo capitolo si descrivono il quadro normativo e il contesto all’interno del quale il progetto si inserisce.

3.1 Quadro degli interventi ICT regionali

La Regione Abruzzo ha già avviato nel corso degli anni una serie di progetti a vari livelli nel segmento specifico dell’Information and Communication Technology, gestiti principalmente dall’Agenzia Regionale per l’Informatica e la Telematica (ARIT), istituita con la Legge Regionale

n. 25 del 14 Marzo 2000 e ss.mm.ii. con lo scopo di assicurare un supporto operativo in materia informatica, telematica e di comunicazione.

Di seguito viene riportata una panoramica dei progetti in corso di realizzazione suddivisi per livello di servizio con particolare riferimento al livello infrastrutturale:

• Livello Infrastrutture ha come obiettivo la realizzazione di un efficiente insieme di infrastrutture elaborative e applicative che costituiscano la base per l’erogazione di servizi agli Enti della Pubblica Amministrazione regionale, ai cittadini e alle imprese.

• Livello Servizi di base ha come obiettivo la realizzazione di un insieme di servizi erogabili direttamente sulle infrastrutture di comunicazione integrate ed in grado di assicurare una serie di funzionalità quali la sicurezza in modo completamente trasparente agli utilizzatori delle stesse. Il livello Servizi di base rappresenta il Centro Tecnico della Community della Regione Abruzzo quale intranet di tipo territoriale inteso come strato architetturale abilitante per l’erogazione di servizi degli Enti Pubblici della Regione Abruzzo e della Regione stessa. La Regione ha previsto nelle azioni tese alla realizzazione della Società dell’Informazione, il Piano Regionale per lo Sviluppo della Società dell’Informazione - e-Government (P.A.S.I. e-Government) la realizzazione del CTTL per la gestione dell’infrastruttura e per l’erogazione dei servizi alla base, dei servizi applicativi utilizzabili dai cittadini, dagli Enti locali e dalle imprese. Con la realizzazione del CTTL si è creata l’infrastruttura di base per l’interoperabilità amministrativa e per l’erogazione di servizi on-line per una pluralità di soggetti che hanno reso all’amministrazione regionale (centrale e locale) nuove sinergie. Il CTTL è una struttura operativa della Regione in grado di effettuare il controllo, la gestione, il monitoraggio e l’erogazione di servizi ICT previsti dai vari progetti regionali e nazionali. Il CTTL rappresenta, pertanto, una struttura cruciale e nevralgica per l’intera Regione alla quale è necessario assicurare un continuo

adeguamento tecnologico idoneo a sostenere, con mezzi e livelli prestazionali, le esigenze delle amministrazioni regionali e della relativa utenza.

• Livello Servizi applicativi ha come obiettivo la realizzazione e lo sviluppo di un insieme di infrastrutture applicative in grado di erogare in modalità telematica e multicanale servizi Web oriented a Enti, cittadini e imprese e incrementare sia il livello di fruibilità degli stessi che la facilità di utilizzo.

L’insieme degli interventi sopraelencati è collocato all’interno di un quadro di riferimento generale del Piano PASI e successivamente perfezionati con Accordi di Programma Quadro e interventi DocUP e si integrano con le iniziative di livello nazionale quali SPC o quelle relative all’Amministrazione Digitale.

3.2 Normativa di riferimento

Tale progetto è volto a promuovere un maggiore utilizzo delle nuove tecnologie ICT in ambito sociale. Il contesto normativo di riferimento è costituito da un insieme di norme nazionali e regionali.

La normativa nazionale di riferimento è la seguente:

• D.Lgs. 147 del 15/09/2017 "Diposizioni per l'introduzione di una misura nazionale alla povertà";

• Decreto 16 dicembre 2014, n. 206 (modalità attuative del Casellario dell’assistenza);

• Decreto del Ministero dell’Interno 19 gennaio 2012, n.32 (GURI del 30 marzo 2012). Nuovo regolamento di gestione dell'Indice nazionale delle anagrafi.

• Decreto Lgs. 7 marzo 2005, n. 82 (Codice dell’Amministrazione Digitale), aggiornato con il D.Lgs. 4 aprile 2006, n. 159.

• Legge 8 novembre 2000, n. 328 "Legge quadro per la realizzazione del sistema integrato di interventi e servizi sociali".

Il quadro normativo di livello regionale è il seguente:

• con la L.R. n. 25 del 14.3.2000 “Organizzazione del comparto sistemi informativi e telematici”, è stata istituita l’Agenzia Regionale per l’Informatica e la Telematica (ARIT), con lo scopo di assicurare un supporto operativo in materia informatica, telematica e di comunicazione;

• l’ ARIT opera come da legge istitutiva, sotto forma di delega interorganica che non esula

dalla sfera amministrativa della Regione;

• la Giunta Regionale, nei confronti dell’ ARIT esercita “un controllo analogo a quello” da essa “esercitato sui propri servizi” e che l’Agenzia stessa “realizza la parte più importante della propria attività con” la Regione Abruzzo;

• l’art. 8 della citata L.R. n. 25/2000 dispone che “L'Agenzia concorre al perseguimento degli obiettivi della politica informatica, telematica e di comunicazione regionale assicurando la predisposizione degli atti necessari per la fornitura di prodotti, infrastrutture e servizi anche in outsourcing, l'Agenzia assicura il supporto tecnico- scientifico, operativo e di consulenza alla Giunta regionale”.

• L.R. 27 settembre 2016, n. 34 “Disposizioni in materia di centrale unica di committenza regionale e modifiche alle leggi regionali 14 marzo 2000, n. 25 (Organizzazione del comparto sistemi informativi e telematici), 29 luglio 1998, n. 64 (Istituzione dell'Agenzia Regionale per la Tutela dell'Ambiente (A.R.T.A.) e 3 agosto 2011, n. 27 (Modifiche alla legge regionale 21 luglio 1999, n. 44 (Norme per il riordino degli Enti di edilizia residenziale pubblica): attuazione del comma 1, dell'articolo 2 della legge regionale 24 marzo 2009, n. 4 (Principi generali in materia di riordino degli Enti regionali)”.

3.3 Gli obiettivi strategici della Regione Abruzzo

Gli obiettivi di lavoro e proposte di miglioramento dell’attuale sistema di welfare sono stati definiti nel Piano Sociale Regionale 2016-2018 della Regione Abruzzo, uno strumento redatto al fine di promuovere la programmazione strategica e integrata, fornendo indirizzi e stimoli e favorendo forme di coordinamento del sistema dei servizi e delle attività sociali e socio-sanitarie.

Le finalità di ordine generale sono:

• promuovere e sostenere il rafforzamento di un welfare “dei diritti” caratterizzato da obiettivi essenziali di servizio, al fine di consentire progressivamente la soddisfazione dei diritti di cittadinanza;

• rafforzare un welfare “comunitario e integrato”, che investa risorse pubbliche anche attraverso forme di integrazione fra politiche sociali, sanitarie, educative, del lavoro e dell’inclusione sociale, e che stimoli la partecipazione attiva della società civile al benessere collettivo. In questa direzione il Piano propone anche un cambiamento significativo nei rapporti intercorrenti tra soggetti pubblici e soggetti del privato sociale;

• promuovere un welfare “attivo” che, oltre a fornire una base sicura ai cittadini grazie alla assicurazione di livelli essenziali di prestazioni sociali e socio-sanitarie, centralizzi i processi proattivi, ponga attenzione alla personalizzazione degli interventi e promuova crescita e cambiamento a partire dalle capacità individuali, accompagnando e sostenendo le singole persone, i gruppi di cittadini, gli attori della scena sociale e della società civile.

Sulla scorta di queste premesse, la Regione Abruzzo sta ponendo in essere come strategia generale per il triennio 2016/2018 il riordino e lo sviluppo del sistema territoriale integrato degli interventi e dei servizi in campo sociale e socio-sanitario. Tale strategia, ambiziosa, ma essenziale e necessaria per il territorio, è perseguita con una modalità di sviluppo di tipo incrementale e interattivo, che vede la riforma dell’intero sistema come un traguardo possibile e raggiungibile attraverso passi anche piccoli ma progressivi, che nel corso del prossimo triennio possano consentire di procedere solidamente nella prospettiva dell’innovazione e del cambiamento.

In questa direzione il Piano presenta indirizzi di carattere più vincolante e prescrittivo, ovvero aspetti che richiedono un adeguamento dei territori, e aspetti più di carattere stimolante e propositivo, che richiedono specifici investimenti nella direzione dell’auspicato cambiamento e innovazione. La Regione Abruzzo attraverso il Piano Sociale Regionale all’interno di tale quadro promuove e assume le seguenti attenzioni:

• Attenzione alla centralità della persona: con il riconoscimento della personalizzazione degli interventi e con la partecipazione attiva delle persone stesse alla definizione di progetti individualizzati;

• Rispetto e soddisfazione dei diritti: attraverso la riduzione delle disparità sociali e riconoscimento a tutte le persone del diritto di accesso al sistema di protezione sociale;

• Sviluppo di forme di democrazia e cittadinanza attiva orientate alla responsabilizzazione e alla costruzione, da parte dei cittadini e della società civile, di legami comunitari, che coniughino sussidiarietà e solidarietà.

Discende da qui la necessità di realizzare un’azione complessa e articolata che sia in grado di integrare e valorizzare tutte le misure messe in campo e tutte le risorse attivabili sia a livello regionale che territoriale.

4. La soluzione progettuale

La soluzione deve permettere di gestire la profilazione utenti e l’attività di raccolta e censimento di informazioni di varia natura sulla domanda e offerta di Servizi Sociali, per i diversi Ambiti distrettuali, e la loro elaborazione da parte dell'Osservatorio Regionale Sociale ai fini del monitoraggio, dell'analisi e della programmazione e pianificazione di interventi finalizzati ad una corretta impostazione della politica sociale nel territorio.

Gli attori coinvolti sono:

1. Cittadino

2. Comune

3. Ambito Distrettuale Sociale

4. Regione Abruzzo.

Ma è auspicabile anche il coinvolgimento di:

1. Medici di Medicina Generale/Pediatri di Libera Scelta

2. ASL

3. Altri Enti

al fine di integrare il sistema sociale con quello sanitario con l’auspicio di un sistema di autenticazione unico.

La soluzione offerta dovrà creare una cartella sociale informatizzata contenente l’anagrafica del cittadino e la storia dei suoi rapporti con l’erogazione dei servizi sociali.

Il set di dati minimo da considerare per la cartella informatizzata dovrà coincidere con quello della cartella sociale cartacea già adottata dai servizi sociali.

Dovrà essere data la possibilità della gestione dei file cartacei sia lato cittadino che Ente, dal momento che non tutti i cittadini richiedenti i servizi sono informatizzati e non tutti i Comuni effettuano direttamente la registrazione dell’utente, ma inviano le informazioni necessarie all’ambito di pertinenza che la formalizzerà .

4.1 Cittadino

Il cittadino dovrà visualizzare i propri dati e il proprio “stato” relativamente alla progressione del servizio erogato. Dovranno prevedersi metodiche per il rilascio delle credenziali di accesso nel rispetto della normativa vigente.

Le funzionalità che andranno abilitate per il cittadino saranno:

• Visualizzazione dei propri dati

• Visualizzazione dello storico dei servizi erogati a proprio beneficio

• Compilazione delle domande online.

4.2 Comune

Il Comune, Ente che detiene i dati e le informazioni dei cittadini che presentano le richieste e beneficiano dei servizi, dovrà prevedere:

• Gestione anagrafica del cittadino

• Gestione anagrafica enti erogatori dei servizi

• Gestione istanze di accesso ai servizi

• Gestione presa in carico del cittadino

• Gestione erogazione del servizio.

Inoltre dovrà avere a disposizione un modulo informatizzato per rendere disponibili all’Osservatorio Sociale Regionale i dati relativi ad autorizzazioni al funzionamento e all’accreditamento di strutture.

4.3 Ambito Distrettuale Sociale

L’Ambito distrettuale sociale è il riferimento territoriale per l’attuazione da parte dei Comuni, singoli o associati, delle politiche sociali a livello territoriale, ivi comprese le scelte relative all’individuazione degli assetti più funzionali alla gestione, alla spesa e ai rapporti con i cittadini.

Gli Ambiti distrettuali sociali sono rappresentati dall’Ente Capofila dell’Ambito distrettuale sociale (ECAD), che assicura la regia dei processi istituzionali ed esercita le funzioni di organizzazione e gestione unitaria dei servizi sociali, secondo gli assetti più funzionali alla gestione stessa, alla spesa conseguente e ai rapporti con i cittadini.

A livello generale i servizi svolti dagli Ambiti sono:

• Gestione anagrafica del cittadino

• Gestione anagrafica enti erogatori dei servizi

• Gestione catalogo servizi erogati

• Gestione istanze di accesso ai servizi

• Gestione presa in carico del cittadino

• Gestione erogazione del servizio

• Gestione dati economici del servizio

• Monitoraggio dei servizi erogati (per tipologia, per livello territoriale, per fonte di finanziamento, ecc.)

• Gestione integrazione con altre base-dati (anagrafe, protocollo, ecc.)

• Gestione reportistica, statistiche, export dei dati:

o Secondo modelli ministeriali e/o regionali standard

o Per rendicontazione annuale.

4.4 Regione Abruzzo

I flussi informativi per il monitoraggio, la valutazione e la rendicontazione dei Piani Sociali di ambito sono fondamentali per garantire l’andamento del sistema dei servizi alla persona e per programmare secondo precisi dati basati sull’evidenza.

Il sistema di monitoraggio e valutazione dovrà essere supportato dall’utilizzo di tecniche e strumenti quali/quantitativi, secondo un approccio che si richiama esplicitamente alla metodologia della ricerca sociale.

Il sistema dovrà permettere:

• La gestione del sistema di offerta, attraverso il catalogo generale dei servizi;

• La disponibilità di un sistema di elaborazioni predisposte su aspetti di particolare rilevanza ai fini del monitoraggio (per tipologia di utenza, per livello territoriale, per tipologia di servizio…);

• La disponibilità di strumenti di dialogo con l’utenza dei servizi sociali;

• Un’attenzione specifica dovrà essere dedicata al monitoraggio periodico delle risorse impegnate per fonte di finanziamento, in particolare:

o Dettaglio risorse programmate per fonte di finanziamento (es. fondi regionali, risorse proprie da bilanci comunali, altre risorse pubbliche, altre risorse private);

o Dettaglio risorse impegnate per fonte di finanziamento (es. fondi regionali, risorse proprie da bilanci comunali, altre risorse pubbliche, altre risorse private);

o Incidenza % risorse impegnate/risorse programmate;

o Residui al (data);

o Dettaglio risorse liquidate;

o Incidenza % risorse liquidate su risorse impegnate;

o Risorse già impegnate da liquidare al (data);

o Dettaglio risorse non impegnate.

La soluzione applicativa offerta dovrà permettere un ampio insieme di elaborazioni che consentano di analizzare i dati raccolti.

Devono essere rese disponibili tutte le elaborazioni statistiche necessarie a valutare le attività e la produzione dei flussi nazionali e regionali.

Il sistema deve inoltre avere uno strumento di facile utilizzo al fine di permettere agli operatori, correttamente formati, di realizzare statistiche ad hoc, e memorizzarle per un uso successivo.

La soluzione proposta tramite strumenti di estrazione dati consentirà di salvare nei formati file più diffusi.

Al fine di ottimizzare questa fase è necessario che il software preveda delle funzionalità avanzate che finalizzate a:

• Monitorare ambiti e comuni

• Gestire dati aggregati

• Monitorare Catalogo generale servizi

• Monitorare Catalogo territoriale servizi

• Monitorare risorse programmate per fonte di finanziamento (regionale, comunale, altro) e relative analisi

• Monitorare costi servizi per tipologia e territorio

• Monitorare percentuale servizio erogato su richiesta.

4.5 Il Sistema informativo dei Servizi Sociali

L’Art. 21 della Legge n. 328 dell’8 Novembre 2000 "Legge quadro per la realizzazione del sistema integrato di interventi e servizi sociali" prevedeva che lo Stato, le Regioni, le province e i comuni istituissero un sistema informativo dei servizi sociali per assicurare una compiuta conoscenza dei bisogni sociali, del sistema integrato degli interventi e dei servizi sociali e poter disporre tempestivamente di dati ed informazioni necessari alla programmazione, alla gestione e alla valutazione delle politiche sociali, per la promozione e l'attivazione di progetti europei, per il coordinamento con le strutture sanitarie, formative, con le politiche del lavoro e dell'occupazione.

Sono state definite le modalità e individuati, anche nell'ambito dei sistemi informativi esistenti, gli strumenti necessari per il coordinamento tecnico con le regioni e gli enti locali ai fini dell'attuazione del sistema informativo dei servizi sociali, in conformità con le specifiche tecniche della rete unitaria delle pubbliche amministrazioni di cui all'articolo 15, comma 1, della legge 15 marzo 1997, n. 59, tenuto conto di quanto disposto dall'articolo 6 del citato decreto legislativo n.

281 del 1997, in materia di scambio di dati ed informazioni tra le amministrazioni centrali, regionali e delle province autonome di Trento e di Bolzano. Le regioni, le province e i comuni individuano le forme organizzative e gli strumenti necessari ed appropriati per l'attivazione e la gestione del sistema informativo dei servizi sociali a livello locale.

In questa ottica era fondamentale l’utilizzo del “Casellario dell’assistenza” (D.M. 206/2014) da parte di tutti gli Ambiti distrettuali e i Comuni, quale condizione necessaria per l’erogazione dei finanziamenti. Il Casellario, entrato in funzione dal 25 marzo 2015 presso l’INPS, sta progressivamente implementando tutte le sue funzioni di banca dati delle prestazioni sociali. Tutti i Comuni e gli Ambiti distrettuali, anche attraverso i rispettivi Uffici di Piano, concorrono ad alimentare sia i flussi della banca dati INPS sia i flussi richiesti dalla Regione Abruzzo tramite il Sistema Informativo gestito dall’Osservatorio sociale regionale. Al tempo stesso, la Regione Abruzzo accede al sistema del Casellario per il monitoraggio continuo delle prestazioni, configurandosi quale Sistema Informativo fondamentale per l’esercizio della funzione di monitoraggio e valutazione.

Con il nuovo disposto normativo ovvero il D.Lgs. 147 del 15/09/2017 e in particolare con l’Art. 24 viene introdotto il Sistema informativo unitario dei servizi sociali.

il Sistema informativo unitario dei servizi sociali, di seguito denominato «SIUSS», per le seguenti finalità:

• assicurare una compiuta conoscenza dei bisogni sociali e delle prestazioni erogate dal sistema integrato degli interventi e dei servizi sociali e di tutte le informazioni necessarie alla programmazione, alla gestione, al monitoraggio e alla valutazione delle politiche sociali;

• monitorare il rispetto dei livelli essenziali delle prestazioni;

• rafforzare i controlli sulle prestazioni indebitamente percepite;

• disporre di una base unitaria di dati funzionale alla programmazione e alla progettazione integrata degli interventi mediante l'integrazione con i sistemi informativi sanitari, del lavoro e delle altre aree di intervento rilevanti per le politiche sociali, nonché con i sistemi informativi di gestione delle prestazioni già nella disponibilità dei comuni;

• elaborare dati a fini statistici, di ricerca e di studio.

Il SIUSS integra e sostituisce i precedenti sistemi ovvero il sistema informativo dei servizi sociali, di cui all'articolo 21 della legge n. 328 del 2000, e il casellario dell'assistenza, di cui all'articolo 13 del decreto-legge n. 78 del 2010, convertito, con modificazioni, dalla legge n. 122 del 2010.

Il SIUSS si articola nelle seguenti componenti:

• Sistema informativo delle prestazioni e dei bisogni sociali, a sua volta articolato in:

o Banca dati delle prestazioni sociali;

o Banca dati delle valutazioni e progettazioni personalizzate;

o Sistema informativo dell'ISEE, di cui all'articolo 11 del decreto del Presidente del Consiglio dei ministri n. 159 del 2013;

• Sistema informativo dell'offerta dei servizi sociali, a sua volta articolato in:

o Banca dati dei servizi attivati;

o Banca dati delle professioni e degli operatori sociali.

4.6 Principali funzioni del software

La soluzione offerta dovrà garantire il seguente set minimo di funzionalità.

Di seguito le principali funzionalità che si dovranno prevedere per la Cartella Utente.

La Gestione Anagrafica dei soggetti e relativi nuclei familiari deve prevedere le funzioni di gestione delle informazioni relative a tutti i soggetti coinvolti nelle attività di assistenza: gli assistiti e tutte le persone ad esse in qualche modo correlate in relazione agli interventi di assistenza gestiti (familiari, persone di riferimento, medici, ecc.). Le principali informazioni anagrafiche dovranno essere gestite in profondità storica, al fine di permettere una conoscenza approfondita degli eventi riguardanti il soggetto.

La “Presa in Carico” (PiC) rappresenta il momento principale dell’evento socio-sanitario e formalizza la presa in carico della situazione del soggetto da parte dello specifico Servizio dell'Ente, che dovrebbe essere possibile anche in assenza di un evento specifico (Segnalazione o Domanda). A seguito della presa in carico sarà possibile l’attivazione di determinati interventi da parte del Servizio, ma si dovrà anche prevedere una possibilità di una presa in carico a posteriori in seguito all’attivazione di specifici servizi.

La gestione della PiC dovrà consentire:

• l’inserimento

• la ricerca

• la modifica

• la cancellazione.

L’Agenda

Il sistema dovrà fornire un’agenda al fine di gestire le attività di un soggetto o di un nucleo, in cui l’operatore può annotare sul calendario il tipo di attività, ora di inizio e fine, destinatario e se programmata o meno.

Acquisizione dei bisogni

Per quanto riguarda l’acquisizione dei bisogni espressi dai cittadini e delle richieste formali di attivazione di un servizio, la soluzione dovrà prevedere almeno due possibilità la “Segnalazione” e la “Domanda.

La Segnalazione corrisponde alla semplice notizia di presunto bisogno, in qualunque modo tale notizia sia pervenuta, senza una formale richiesta del soggetto.

La Domanda è la richiesta formale (firmata, protocollata, ecc.) presentata dal Soggetto a un preciso Ente deputato istituzionalmente a riceverla e tenuto a dare una risposta.

Valutazione

La valutazione ed eventuale richiesta di valutazione collegata dovranno essere gestite totalmente dal sistema in modo tale che i bisogni e le condizioni (familiari, sociali, economiche, sanitarie) del richiedente siano esaminati e pertanto sia possibile giungere alla decisione di erogare o meno il servizio di assistenza.

Le funzionalità dovranno gestire gli incontri di valutazione con:

• Scheda di rilevazione strutturata

• Possibilità di redigere un testo libero di sintesi dell’incontro.

Contributi Economici

La soluzione dovrà prevedere un modulo che consenta la corretta gestione dei Contributi Economici erogati e da erogare.

Assistenza

Il modulo Assistenza dovrà gestire le varie tipologie:

• Assistenza residenziale

• Assistenza domiciliare

Estrazioni e analisi dei dati

Il sistema dovrà essere fornito delle “Estrazioni” che permettono di produrre un file Excel o Csv utilizzabile per stampe ed elaborazioni varie, contenente le informazioni principali delle attività e degli interventi che rispettano determinate condizioni di selezione e ordinati secondo alcuni possibili criteri. La funzione è basata su una serie di tabelle di configurazione che permettono di parametrizzare query di estrazione, parametri di filtro, criteri di ordinamento, ecc.

Nella piattaforma la parte di Analisi dei Dati è uno degli elementi più qualificanti e innovativi. Innovazione in quanto viene garantita la completa integrazione tra lo strato gestionale e l’analisi dei dati a supporto alle decisioni: persistenza di contesto, quindi, tra input dei dati e maschere gestionali e strumenti di simulazione e decisione sui dati stessi. Per esprimere questa realizzazione con una definizione riassuntiva “decido ciò che devo fare intanto che lo sto facendo”. L’analisi dei dati infatti soffre di asincronie strutturali, oppure viene fatta “ex-ante”, limitandosi a simulazioni non implementabili direttamente, oppure “ex-post”, limitando la visione a fatti già accaduti con approccio del tipo della reportistica di consuntivo.

4.7 Ulteriori integrazioni

La soluzione dovrà altresì essere predisposta per l’integrazione, anche futura, con gli applicativi delle Pubbliche Amministrazioni quali SPID, PagoPA, ecc. ed eventualmente prevedere la possibilità dell’utilizzo della firma grafometrica. Dovrà inoltre essere integrata con l’anagrafe sanitaria.

5. IL CONTESTO TECNOLOGICO ED APPLICATIVO

In questo capitolo si descrive il contesto tecnologico ed applicativo in cui si inserisce il progetto per mezzo di un’analisi dei principali aspetti collegati agli interventi di natura infrastrutturale, dei servizi già disponibili e di quelli ancora da sviluppare, sia in ambito regionale che nazionale.

La descrizione del contesto regionale tecnologico e applicativo risulta determinante per comprendere lo stato attuale, consentire ai soggetti partecipanti la redazione di un’Offerta Tecnica adeguata e in grado di assicurare quanto richiesto sia a livello qualitativo che quantitativo. Inoltre essa consente di descrivere, progettare e realizzare gli elementi infrastrutturali, elaborativi e applicativi necessari per l’attivazione di quanto proposto in maniera compatibile con il sistema infrastrutturale già attualmente in uso e di evidenziare in modo preventivo le peculiarità e le criticità associate.

5.1 Architetture di riferimento

L’infrastruttura per l’esecuzione delle funzionalità e per l’erogazione dei servizi si avvarrà delle Infrastrutture Comunicative, Elaborative e Applicative del Centro Tecnico dell’Agenzia Regionale per l’Informatica e la Telematica di Tortoreto Lido (CTTL).

Il CTTL renderà disponibili le infrastrutture necessarie per l’attivazione dei servizi richiesti dall’intervento, sia per quanto concerne la parte elaborativa che per quella di comunicazione integrata.

La realizzazione progettuale, inclusi i software di base e applicativi necessari per la messa in produzione di quanto previsto dalla progettazione, dovrà essere completamente integrabile con i sistemi esistenti e già in uso, assicurando la piena compatibilità con l’infrastruttura esistente, oltre che garantire tutte le necessarie misure di sicurezza connesse all’autenticazione dell’utente, alla definizione delle responsabilità e dei ruoli applicativi di competenza secondo le vigenti normative in materia.

Il CTTL costituirà il centro stella, nodo logico centrale, dei servizi di interoperabilità e interscambio tra i diversi Sistemi Informativi secondo un modello architetturale generale che prevede un insieme di strutture interconnesse e interoperanti tra loro, dotate ciascuna di una infrastruttura di comunicazione ed elaborativa omogenea mediante protocolli standard.

Il CTTL costituisce il polo erogatore delle funzioni di interoperabilità e di interscambio tra Sistemi Informativi regionali attraverso la comunicazione con la Porta di Dominio regionale presente nello

stesso Centro Tecnico mediante un’architettura orientata al paradigma SOA.

L’accesso ai differenti servizi dovrà essere garantito mediante delle interfacce conformi ai vincoli tecnici indicati nei documenti di e-government e nelle specifiche W3C (World Wide Web Consortium) per le architetture Web Services mediante l’impiego di tecnologie e standard aperti.

In questo contesto il CTTL fornirà le risorse elaborative a supporto dei servizi applicativi e di middleware funzionali al progetto in parola.

5.2 Infrastruttura di riferimento: CTTL

Presso la sede dell’Agenzia di Xxxxxxxxx Xxxx xx xxx Xxxxxx 0, è stata realizzata l'infrastruttura del Centro Tecnico della Regione Abruzzo. Tale infrastruttura è principalmente rivolta a offrire servizi informatici e telematici agli uffici della Regione Abruzzo sparsi sul territorio e costituisce, di fatto, uno dei due Centri di eccellenza per l'erogazione di servizi telematici sul territorio abruzzese.

L'Infrastruttura si è sviluppata nell'ambito dell'azione coordinata di una serie di progetti in Accordo di Programma Quadro e E-Governement.

5.2.1 Infrastruttura di Comunicazione Integrata

L’infrastruttura di rete presente nel CTTL è costituita da un’architettura di switching, routing e firewalling consolidata composta da apparati idonei ad erogare funzionalità avanzate di instradamento L2/L3, e di sicurezza oltre che di bilanciamento di carico e QoS. La tecnologia utilizzata è principalmente del produttore Cisco ed è strutturata nei seguenti livelli logici: core, distribution ed access/datacenter.

L’interconnessione con Internet e con le reti regionali (ComNet-RA), avviene mediante il sottosistema di accesso perimetrale costituito da due coppie di Cisco ASA serie 5500 per ciascuna linea di connettività presente, dotati di moduli software per la terminazione VPN (Remote Access, Hub&Spoke, site-to-site) e di funzionalità di firewall.

La componente core dell’infrastruttura è affidata ad apparati modulari della classe Cisco 6500 e Cisco Nexus 5596UP, mentre la componente di accesso è realizzata con apparati della classe Cisco 4500 e 3750. La componente datacenter è invece costituita dagli switch virtuali operanti nelle piattaforme di virtualizzazione installate nel CTTL. Sull’infrastruttura di switching del data center sono attestati i server che risultano collocati logicamente nelle varie zone di sicurezza attraverso l’uso di VLAN suddivise da opportuni livelli di routing e firewalling definiti sui moduli

Cisco FWSM (FireWall Service Module) alloggiati negli apparati di core.

Il layer di bilanciamento di carico è garantito dai moduli Cisco ACE (Application Control Engine), anch’essi alloggiati negli apparati di core, che operano sino al livello L7 della pila protocollare ISO/OSI in funzione degli attributi caratteristici dei singoli livelli (L3/L4: indirizzi e porte sorgente e/o destinazione, protocolli; L7: HTTP, RADIUS, RDP, RTSP, SIP, SSL).

A livello di Storage Area Network l’infrastruttura di comunicazione costituita dalla coppia di enterpriseswitch SAN a chassis modulari (Cisco MDS 9513) garantisce il raccordo in fibra dei principali server e componenti di storage presenti presso il CTTL, e consente altresì il collegamento WAN per il trasporto di traffico FC su diversi protocolli (FCIP, FCoE, iSCSI) tra poli geograficamente distinti.

Il monitoraggio e la gestione infrastrutturale del CTTL sono demandati sia a software specifici dei diversi vendor impiegati (es. VMWARE, Microsoft, Tivoli) che a sistemi open-source (es. Nagios + Groundworks).

Sono presenti, inoltre, sistemi per l’autenticazione degli utenti sulla rete e degli apparati (es. Cisco ACS, CertificationAuthority), per la gestione avanzata delle configurazioni degli elementi di sicurezza sugli apparati nonché quelli per la raccolta e l’analisi dei log.

5.2.2 Infrastruttura elaborativa/applicativa

Il CTTL è costituito da una piattaforma ICT basata su un’architettura modulare, per livelli, a componenti distribuiti, che utilizza protocolli di comunicazione standard aperti in conformità alle linee guida per la progettazione dei sistemi informativi per le pubbliche amministrazioni.

L'infrastruttura elaborativa servente presente nel CTTL è segmentata in zone logiche distinte in modo da garantire massima sicurezza, scalabilità e flessibilità, cosa che consente un efficiente utilizzo delle risorse informatiche ed una loro futura evoluzione per sostenere una domanda di utilizzo crescente e l’implementazione di nuovi servizi.

Lo schema logico dell’infrastruttura elaborativa è riportato nelle figure successive. In esse si illustra la logica multi-livello su cui è articolata la server farm, ove sono rappresentati tutti gli elementi architetturali che contribuiscono all’erogazione di servizi in modalità sicura, in alta affidabilità ed eventualmente bilanciati in base al carico.

Il nucleo elaborativo di riferimento per i servizi di base ed applicativi è costituito dalla piattaforma Unified Computing System (UCS) Cisco, che integra elaborazione, networking e virtualizzazione in una singola piattaforma basata su standard di mercato ottimizzando le

prestazioni, riducendo i costi generali del data center e fornendo un provisioning dinamico delle risorse per una maggiore agilità aziendale.

La piattaforma UCS del CTTL è composta da 2 chassis, ognuno dotato di 7 server blade: il loro complesso implementa un’infrastruttura elaborativa in alta affidabilità per la virtualizzazione basata su tecnologia VMWare 4.x e 5.x.

Per quanto riguarda l’ambito sanitario, esiste un’infrastruttura dedicata costituita da blade server Fujitsu-Siemens Primergy BX924 su uno Chassis BX400 e storageNetApp FAS 2240 con sistema di virtualizzazione VMWare 5.x.

In linea con le direttive architetturali adottate, l’infrastruttura servente è configurata in loadbalancing e cluster, in modo da garantire alta affidabilità ed elevate prestazioni dal punto di vista elaborativo ed è collegata all’area di storage.

Figura 1 - Schema logico generale con architettura gerarchica del Centro Tecnico di Tortoreto Lido

Dallo schema generale si evidenzia l’architettura multi-livello gerarchica ed organizzata in aree logiche separate (VLAN) omogenee per tipologia di servizi erogati. Gli apparati serventi, in analogia con quelli dedicati alla comunicazione, sono implementati con soluzioni in alta affidabilità a diversi livelli (sia hardware che software). Ogni link disegnato in figura è, quindi, da intendersi costituito da almeno un doppio canale di comunicazione in tecnologia full-duplex, rame o fibra, quest’ultima impiegata principalmente nei collegamenti afferenti alla storage area network (SAN). Oltre alla ridondanza hardware, l’alta affidabilità è ottenuta mediante il clustering dei servizi offerti, bilanciati con opportune politiche dipendenti dal traffico coinvolto.

Figura 2- Schema logico del Centro Tecnico di Tortoreto Lido

Nello schema logico si evidenzia che in frontiera è presente uno strato in grado offrire i servizi di proxy e reverse proxing per l’accesso e per la pubblicazione dei servizi applicativi (DMZ1). Nelle stesse aree sono collocati gli apparati per l’esposizione dei servizi di base offerti alle utenze e, per competenza, in esse sono presenti i servizi DNS, SMTP, NTP, DHCP, oltre ad altri specifici servizi infrastrutturali.

Nell’area intermedia è posizionata la zona dedicata ad ospitare le componenti di front end di ogni servizio applicativo: detta area (DMZ2) ospita, quindi, a livello generali i servizi WEB e diversi flussi applicativi, oltre alle componenti dei servizi infrastrutturali di competenza.

Con diversi pesi di sicurezza sono poi definite in affiancamento alla DMZ2 delle aree applicative

specifiche: a titolo di esempio, quella VoIP deputata a ospitare esclusivamente gli elementi infrastrutturali propri delle architetture di convergenza voce/video/dati.

In sequenza, secondo opportune politiche di sicurezza, è poi definita la zona militarizzata (MZ) in cui sono ospitati tipicamente i repository dati in generale oltre alle specifiche componenti di back end chiamate ad interagire esclusivamente con servizi posizionati nella DMZ2 dell’infrastruttura elaborativa.

Come zone interne sono, poi, definite una serie di aree tematiche di supporto alla gestione ed alla sicurezza, ognuna delle quali ospita per competenza servizi specifici ed i serventi master di una serie di servizi di base.

Sono presenti, per lo più, tipologie di prodotti Open Source o soluzioni riconducibili ad una tipologia di licenza di tipo GNU General Public License.

I sistemi operativi utilizzati sono in particolare Windows server 2003/2008/2012 EE, GNU/Linux RedHat (versione AS) e CentOS 5.x/6.x, tutti customizzatiedhardenizzati per ospitare al meglio i rispettivi servizi ed offrire al tempo stesso le richieste caratteristiche di affidabilità.

ARIT (così come la RA) dispone di infrastrutture applicative software in linea con gli attuali standard architetturali del segmento (tipicamente multi-tiering), conformi alle specifiche tecniche per la Pubblica Amministrazione ed alle direttive ministeriali relative al riuso ed all’utilizzo quando possibile di prodotti open source.

L’infrastruttura applicativa costituita dai servizi attualmente erogati presso il CTTL ARIT si appoggia completamente sul layer di virtualizzazione SAN correntemente in uso.

5.2.3 Infrastruttura Storage Area Network virtualizzata

L’infrastruttura di Storage Area Network virtualizzata pre-esistente presso il CTTL è stata adeguata con un recente intervento per rispondere non solo a emergenti richieste di spazio fisico di immagazzinamento dati, ma anche all’esigenza di una migliore gestione delle risorse di storage stesse. L’infrastruttura fisica di storage è basata essenzialmente sulla piattaforma EMC2CLARiiON CX4-960: la capacità di storage lorda, distribuita su più array di diversi brand, è di circa 250 TB in tecnologia SATA, FC ed SSD.

Per la realizzazione di un‘infrastruttura che garantisca continuità di servizio, massima scalabilità e condivisione delle risorse, la soluzione tecnologica correntemente in uso è l’appliance “EMC2VPlex VS2” per l’attuale ambiente di produzione, identica a quella implementata presso il CTAQ.

5.2.4 Moduli software di base per DR e BC

Nell’infrastruttura del CTTL sono presenti delle componenti software sufficienti per l’implementazione di un’infrastruttura di DR e BC tra i due poli regionali. Nello specifico, i moduli forniti e disponibili per la configurazione sono:

• EMC2MirrorView e SnapView: realizzano la sincronizzazione remota in ambito geografico (distanza asincrona) dei volumi di storageafferenti al DR tra gli array di back-end sui poli regionali (storage server EMC2Clariion CX4-960). I moduli sono licenziati ed attivati sugli array ma non configurati.

• VTL Data Domain 660: libreria a disco per la memorizzazione dei backup da allineare tra i due poli regionali, dotata di licenza di replica IP su distanza asincrona e con licenza HBA FC dualport, con 36 TB SATA di capacità lorda.

• VMWareSiteRecovery Manager: realizza l’automazione del ripristino di un servizio applicativo qualora occorra un evento disastroso, gestendo automaticamente la partenza delle macchine virtuali sul sito secondario, l’accesso allo storage sincronizzato remotamente, l’indirizzamento e la redirezione dei servizi. Il componente, non installato, dovrà essere integrato con il VMWare Virtual Center.

5.2.5 Standard di sicurezza per l’interscambio delle informazioni

La sicurezza è l’insieme delle misure atte a garantire la disponibilità, la integrità e la riservatezza delle informazioni gestite. È un concetto fondamentale in un contesto di sistemi distribuiti che trattano dati sensibili come quelli sanitari.

Per garantire che siano rispettati i vincoli inerenti la sicurezza, nell’ambito della realizzazione del FSE nella Regione Abruzzo sono impiegati diversi standard a livello elaborativo, applicativo e comunicativo.

Lo standard WS-Security è un protocollo di comunicazione che si applica ad architetture SOA che utilizzano il paradigma dei Web Services per l’interoperabilità applicativa. Esso stabilisce il grado di confidenzialità e le regole per verificare l’integrità delle informazioni scambiate attraverso web-services. Uno degli aspetti fondamentali di WSS è l’uso del concetto di Security Token. Un SecurityToken è simile ad una carta d’identità o meglio ad un pass che deve essere mostrato per usufruire di un determinato WS.

WS-Security è lo standard definito da XXXXX che descrive gli enhancements introdotti in SOAP al

fine di soddisfare i requisiti di integrità, riservatezza ed autenticazione dei messaggi. WS- Security utilizza XML-Signature per fornire l'integrità e l'autenticazione del messaggio ed XML- Encryption per la riservatezza. La specifica offre una serie di meccanismi (profili) per associare security token all’interno dei messaggi. I token di sicurezza previsti sono di tipo Username (UsernameTokenProfile), certificati digitali X.509v3 (X.509 TokenProfile), asserzioni SAML 1.1 (XXXX XxxxxXxxxxxx). La versione utilizzata dal framework corrisponde alla specifica Web Service Security - SOAP Message Security 1.0.

Il tipo di token impiegato nell’infrastruttura in ambito sanitario, che sarebbe auspicabile utilizzare anche nel campo dei Servizi Sociali al fine di avere un unico punto di accesso ai servizi sociosanitari, è la SAML assertion, dichiarazione di autorizzazione espressa mediante un particolare linguaggio utilizzato, SAML, appunto, che definisce le regole e la sintassi per lo scambio di informazioni e per l’autenticazione sicura tra applicazioni. Le asserzioni SAML sono allegate al messaggio SOAP usando lo standard WS-Security all’interno di un header.

Un sistema di Single Sign On permette l’autenticazione unica dell’attore/utente al sistema per la fruizione di una moltitudine di risorse informatiche alle quali è abilitato. Il concetto alla base è quello di consentire ad un utente di accedere ad un sistema software complesso e consistente di più applicazioni, attraverso una unica procedura di controllo dell’accesso. Nel caso di accesso al sistema via Web, ci si interfaccia una sistema che ha il compito di verificare le credenziali degli attori che saranno, in tal modo, soggette a validazione e autenticazione prima che sia effettuato l’accesso e la fruizione dei servizi.

A livello comunicativo le interconnessioni sicure sono realizzate in tecnologia VLAN (Virtual LAN) e assegnate ai diversi servizi. L’interconnessione e il filtraggio fra le diverse VLAN realizzate è garantito per mezzo di apparati L3 Switch con protocollo Ethernet. Lo switch L3 è poi collegato a 100Mbps al router che costituisce la terminazione dell’infrastruttura di trasporto regionale.

La realizzazione delle varie sottoreti tramite VLAN separate garantisce il massimo livello di sicurezza e di separazione fra le LAN sicure e quella insicura, ed allo stesso tempo da la possibilità di differenziare le prestazioni di rete a seconda delle esigenze dei diversi segmenti garantendo caratteristiche di scalabilità e costi ottimali.

Un ulteriore livello di sicurezza all’architettura è fornito dall’utilizzo del protocollo HTTPS, che consente di applicare al protocollo di trasferimento ipertesti l’algoritmo di crittografia asimmetrica Secure Sockets Layer (SSL): esso consente di creare un canale di interscambio cifrato tra client e server per mezzo dello scambio di certificati attraverso la rete Internet, che, una volta instaurato, consente di utilizzare al suo interno il protocollo HTTP per la comunicazione.

5.2.6 Infrastruttura applicativa di test e sviluppo

Al fine di sviluppare, testare e collaudare le applicazioni per lo sviluppo dei servizi e moduli applicativi richiesti nel presente il progetto, si segnala la presenza e la disponibilità di un’infrastruttura applicativa di test/collaudo che rappresenta la replica con capacità limitate dell’ambiente di produzione, ma che mantiene una valenza significativa per le attività di pre- produzione.

6. STANDARD E TECNOLOGIE DI RIFERIMENTO

In questo capitolo vengono riportati alcuni standard e tecnologie di riferimento per la realizzazione di servizi applicativi e per la loro interoperabilità con sistemi esistenti.

6.1 SOA e Web Services

Con il termine Service-Oriented Architecture (SOA) si indica generalmente un'architettura software adatta a supportare l'uso di servizi Web per garantire l'interoperabilità tra diversi sistemi, preservandone caratteristiche e funzionalità native, così da consentire l'utilizzo delle singole applicazioni come componenti del processo di business e soddisfare le richieste degli utenti in modo integrato e trasparente. Una SOA è un’architettura software, fortemente orientata al riuso e alla integrazione, che prevede la esposizione della logica applicativa sotto forma di servizi accoppiati tra loro in modo “debole”. A livello implementativo la tecnologia utilizzata per lo sviluppo dei servizi non è determinante: l‘idea di base è quella di racchiudere le funzionalità all’interno di interfacce che, nascondendo i dettagli tecnico/implementativi, sono esposte secondo modalità e forme documentate in modo standard e messe a disposizione su un apposito catalogo.

Si tratta di una filosofia progettuale particolarmente adatta a contesti applicativi distribuiti caratterizzati da marcata eterogeneità e complessità, forte dinamismo e elevato grado di interazione tra le diverse componenti. In esso infatti, è presente una molteplicità di attori che, a seconda delle specifiche situazioni, creano o utilizzano le informazioni, ed interagiscono tra loro secondo modalità non del tutto prevedibili a priori. Inoltre, molti Enti/strutture coinvolte, dispongono già di un patrimonio informativo e applicativo (legacy) che costituisce un bene rilevante, sia dal punto di vista economico (in quanto frutto di consistenti investimenti), sia da quello tecnologico: tale patrimonio richiede da un lato di essere preservato e dall’altro di essere messo in condizione di interagire con gli omologhi di altri enti, qualunque siano le piattaforme applicative sulle quali sono stati realizzati.

Il sistema maggiormente utilizzato negli ultimi anni per la realizzazione di architetture orientate ai servizi è quella dei Web Services, una specifica di protocolli e standard utilizzata per realizzare comunicazioni tra applicazioni di diversa natura interconnessi ad una medesima rete per garantirne l’interoperabilità. I Web Services sono pensati per realizzare dei blocchi funzionali indipendenti che, nel complesso, possano costituire un ambiente applicativo. Essi godono di alcune proprietà che li rendono particolarmente adatti per essere impiegati all’interno delle SOA. Una di queste proprietà è la completa autonomia che caratterizza ciascun servizio rispetto agli

altri: ogni servizio è responsabile di un proprio dominio, con conseguente formazione di unità funzionali ben delineate e blandamente collegate tra loro mediante la aderenza ad uno standard di comunicazione. In virtù della indipendenza di cui i servizi godono, la logica applicativa che ciascun servizio incapsula non deve conformarsi a nessuna piattaforma particolare.

I Web Services sono pensati per realizzare dei blocchi software funzionali indipendenti che, nel complesso, possano offrire un'interfaccia software, descritta in un formato automaticamente elaborabile quale, ad esempio, il Web Services Description Language, utilizzando la quale altri sistemi possono interagire con il Web Service stesso attivando le operazioni descritte nell'interfaccia tramite appositi "messaggi" inclusi in una "busta", in particolare la SOAP: tali messaggi sono, solitamente, trasportati tramite il protocollo HTTP e formattati secondo lo standard XML. Essi godono di alcune proprietà che li rendono particolarmente adatti per essere impiegati all’interno delle SOA. Una di queste proprietà è la completa autonomia che caratterizza ciascun servizio rispetto agli altri: ogni servizio è responsabile di un proprio dominio, con conseguente formazione di unità funzionali ben delineate e blandamente collegate tra loro mediante la aderenza ad uno standard di comunicazione. In virtù della indipendenza di cui i servizi godono, la logica applicativa che ciascun servizio incapsula, non deve conformarsi a nessuna piattaforma particolare. Proprio grazie all'utilizzo di standard basati su XML, tramite un'architettura SOA, applicazioni software scritte in diversi linguaggi di programmazione ed implementate su diverse piattaforme hardware possono, quindi, essere utilizzate tramite le interfacce che queste "espongono" pubblicamente e mediante l'utilizzo delle funzioni che sono in grado di effettuare (i "servizi" che mettono a disposizione) per lo scambio di informazioni e l'effettuazione di operazioni complesse (quali, ad esempio, lo scambio di dati tra strutture sanitarie che utilizzano sistemi ICT eterogenei fra loro) sia su reti aziendali, come su Internet.

Tutti i dati scambiati sono formattati mediante tag XML in modo che gli stessi possano essere utilizzati ad entrambi i capi delle connessioni; il messaggio può essere codificato conformemente allo standard SOAP. L'interfaccia pubblica di un Web Service viene descritta tramite WSDL,un linguaggio basato su XML usato per la creazione di "documenti" descrittivi delle modalità di interfacciamento ed utilizzo del Web Service. La centralizzazione della descrizione e della localizzazione dei Web Service in un "registro" comune permette la ricerca ed il reperimento in maniera veloce dei Web Service disponibili in rete; a tale scopo viene attualmente utilizzato il protocollo UDDI.

La ragione principale per la creazione e l'utilizzo di Web Service è il disaccoppiamento che l'interfaccia standard esposta dal Web Service rende possibile fra il sistema utente ed il Web Service stesso: modifiche ad una o all'altra delle applicazioni possono essere attuate in maniera

"trasparente" all'interfaccia tra i due sistemi; tale flessibilità consente la creazione di sistemi software complessi costituiti da componenti svincolati l'uno dall'altro e consente una forte riusabilità di codice ed applicazioni già sviluppate. I Web service hanno inoltre guadagnato consensi visto che, come protocollo di trasporto, possono utilizzare HTTP "over" TCP sulla porta 80; tale porta è, normalmente, una delle poche (se non l'unica) lasciata "aperta" dai sistemi firewall al traffico di entrata ed uscita dall'esterno verso i sistemi aziendali e ciò in quanto su tale porta transita il traffico HTTP dei web browser: ciò consente l'utilizzo dei Web Service senza modifiche sulle configurazioni di sicurezza dell'azienda (un aspetto che se da un lato è positivo solleva preoccupazioni concernenti la sicurezza).

6.2 ROA e Rest

In contrapposizione alle architetture SOA, negli ultimi anno sono andate sviluppandosi le Resource Oriented Architecture: architetture software basate sulla condivisione di “risorse” distribuite nel web.

L’architettura ROA è un’architettura software ispirata ai principi “REST” (REpresentational State Transfer), sfrutta perciò le funzionalità del protocollo HTTP, per quello che è, un protocollo di livello applicativo, e ne utilizza a pieno tutte le potenzialità.

L’approccio REST tende a conservare e ad esaltare le caratteristiche intrinseche del Web evidenziandone la predisposizione ad essere una piattaforma per l’elaborazione distribuita. Quindi, non è necessario aggiungere nulla a quanto è già esistente sul web per consentire ad applicazioni remote di interagire, infatti REST non prevede alcuna modalità per descrivere come interagire con una risorsa. Il web ha già tutto quello di cui si ha bisogno, ossia l’infrastruttura che si basa sul protocollo HTTP e le informazioni, che diventano vere e proprie risorse; non si ha quindi bisogno di inserire un ulteriore strato software come avviene con i web services in soap.

6.3 Standard di sicurezza per l’interscambio delle informazioni

La sicurezza è l’insieme delle misure atte a garantire la disponibilità, la integrità e la riservatezza delle informazioni gestite. E’ un concetto fondamentale in un contesto di sistemi distribuiti che trattano dati sensibili come quelli sanitari.

Per garantire che siano rispettati i vincoli inerenti la sicurezza nella Regione Abruzzo sono impiegati diversi standard a livello elaborativo, applicativo e comunicativo.

Lo standard WS-Security è un protocollo di comunicazione che si applica ad architetture SOA che

utilizzano il paradigma dei Web Services per l’interoperabilità applicativa. Esso stabilisce il grado di confidenzialità e le regole per verificare l’integrità delle informazioni scambiate attraverso web-services. Uno degli aspetti fondamentali di WSS è l’uso del concetto di Security Token. Un SecurityToken è simile ad una carta d’identità o meglio ad un pass che deve essere mostrato per usufruire di un determinato WS.

WS-Security è lo standard definito da XXXXX che descrive gli enhancements introdotti in SOAP al fine di soddisfare i requisiti di integrità, riservatezza ed autenticazione dei messaggi. WS- Security utilizza XML-Signature per fornire l'integrità e l'autenticazione del messaggio ed XML- Encryption per la riservatezza. La specifica offre una serie di meccanismi (profili) per associare security token all’interno dei messaggi. I token di sicurezza previsti sono di tipo Username (UsernameTokenProfile), certificati digitali X.509v3 (X.509 TokenProfile), asserzioni SAML 1.1 (XXXX XxxxxXxxxxxx). La versione utilizzata dal framework corrisponde alla specifica Web Service Security - SOAP Message Security 1.0.

Il tipo di token impiegato nell’infrastruttura è la SAML assertion, dichiarazione di autorizzazione espressa mediante un particolare linguaggio utilizzato, SAML, appunto, che definisce le regole e la sintassi per lo scambio di informazioni e per l’autenticazione sicura tra applicazioni. Le asserzioni SAML sono allegate al messaggio SOAP usando lo standard WS-Security all’interno di un header.

7. LE CARATTERISTICHE DEI SERVIZI

Il progetto richiede la realizzazione di un insieme di servizi di base connessi alla fornitura del materiale (hardware, software di base, moduli applicativi, ecc.) previsti in questa Relazione Tecnico Progettuale.

I servizi di base associati alla fornitura del materiale e dei moduli applicativi personalizzati costituiscono, quindi, un elemento imprescindibile che deve essere integrato all’interno dell’Offerta Tecnica per consentire la piena fruibilità di quanto richiesto.

Il concorrente, per la corretta definizione dell’Offerta Tecnica e delle modalità esecutive, dovrà effettuare tutti gli accertamenti necessari per l’elaborazione dello stesso e per la successiva esecuzione delle attività e la definizione del prezzo offerto.

Il concorrente, pertanto, non potrà richiedere variazioni di prezzo, giustificate da difficoltà nella esecuzione delle attività dovute ad elementi che avrebbero potuto essere riscontrati nell’ambito dei sopralluoghi e dei rilievi in parola.

7.1 Servizio di analisi preliminare

Di seguito sono riportati i servizi di analisi preliminare per definire e contestualizzare le attività da realizzare secondo gli obiettivi progettuali.

7.1.1 Servizio di verifica preliminare dei locali

Preliminarmente ad ogni consegna dovrà essere realizzata una verifica dei locali interessati ed installazione del materiale e delle apparecchiature (hardware, software di base, moduli applicativi, ecc.).

Tale servizio, erogato da personale specializzato del soggetto esecutore, dovrà essere concordato in forma anticipata con la Direzione di Progetto dell’Agenzia.

Il servizio di verifica darà origine a un documento nel quale saranno riportati gli eventuali adeguamenti necessari a rendere idoneo il sito alla messa in opera ed allaccio degli apparati.

La sottoscrizione di tale documento da parte del responsabile di progetto del soggetto esecutore e della Direzione di Progetto dell’Agenzia concluderà la fase preliminare e permetterà l’avvio delle attività di consegna ed installazione oppure, in caso di adeguamenti, il blocco delle attività fino ad una nuova comunicazione all’esecutore da parte dell’Agenzia con la quale sarà indicato il

completamento degli adeguamenti ed il conseguente “pronti alla consegna”.

7.1.2 Servizio di analisi preliminare dell’infrastruttura elaborativa esistente

Nella fase iniziale del progetto e preliminarmente all’inizio delle attività di sviluppo e di implementazione, dovrà essere realizzata un’analisi dell’infrastruttura elaborativa e di comunicazione esistente situata presso il CTTL destinata ad ospitare gli applicativi software e le personalizzazioni collegate all’intervento. Le stesse attività dovranno essere svolte presso gli Ambiti Distrettauli Sociali.

Tale servizio, erogato da personale specializzato del soggetto esecutore, dovrà essere concordato in forma anticipata con la Direzione di Progetto dell’Agenzia e con i referenti regionali del “Servizio Programmazione Sociale e Sistema Integrato Sociosanitario”.

Il servizio di analisi dell’infrastruttura elaborativa necessaria per la messa in esercizio dei moduli software e l’erogazione dei servizi proposti del soggetto esecutore ha come punto di partenza le indicazioni contenute nella presente Relazione Tecnico Progettuale e darà origine ad un documento nel quale dovranno essere riportati gli eventuali adeguamenti necessari a rendere idonee le infrastrutture elaborative del CTTL alla piena e completa messa in esercizio del sistema.

La proposta di progetto dovrà contenere tutte le indicazioni dettagliate, sia a livello di schema che di elementi (hardware necessario dimensionato sia come caratteristiche tecniche che come livello quantitativo) dell’infrastruttura elaborativa (definita come una nuova realizzazione ed il cui valore economico non dovrà essere riportato in offerta) necessaria per la messa in esercizio dei moduli software e l’erogazione dei servizi proposti dal soggetto esecutore e le modalità di esecuzione del servizio di analisi preliminare.

7.1.3 Analisi preliminare dei servizi applicativi esistenti

Nella fase iniziale del progetto e prima dell’inizio delle attività di sviluppo, dovrà essere realizzata un’analisi preliminare dei servizi applicativi offerti dalla Regione Abruzzo e dal CTTL.

Tale servizio, erogato da personale specializzato del soggetto esecutore, dovrà essere concordato in forma anticipata con la Direzione di Progetto dell’Agenzia.

Il servizio di analisi necessario per la messa in esercizio dei moduli software e l’erogazione dei servizi proposti dal soggetto esecutore avrà come punto di partenza le indicazioni contenute nella presente Relazione Tecnico Progettuale e darà origine a un documento nel quale dovranno essere

Area Tecnica Pagina39 di 60

riportati gli eventuali adeguamenti necessari a rendere idonea l’infrastruttura applicativa del CTTL alla piena e completa messa in esercizio del sistema.

Dovranno essere indicati i profili del personale utilizzato per tali servizi e le modalità di esecuzione della varie fasi con il personale interessato.

Resta inteso che ogni azione di analisi, sviluppo o di verifica preliminare necessarie all'integrazione degli applicativi rientrano all'interno del dimensionamento a corpo dell'attività e non potrà essere richiesto, né addebitato alcun costo aggiuntivo per il completamento della stessa.

7.2 Servizio di sviluppo applicativo

Lo sviluppo applicativo dovrà prevedere una fase iniziale, di impostazione complessiva del progetto generale con la definizione di un quadro di riferimento metodologico ed operativo, seguita da un ciclo di sviluppo per i diversi moduli applicativi.

L’Offerta Tecnica dovrà contenere una descrizione dettagliata delle modalità utilizzate dalla Ditta offerente per lo sviluppo dei moduli applicativi, in modo da consentire alla Stazione Appaltante una valutazione preventiva del modello di sviluppo in grado di minimizzare le incertezze operative e di semplificare le fasi di produzione software, a partire dai requisiti congiuntamente individuati.

Una corretta metodologia di sviluppo consentirà di ridurre i rischi collegati alle definizioni di specifiche non perfettamente condivise e percepite, di adattarsi rapidamente ai feedback ottenuti dal gruppo di lavoro, che dovrà includere anche gli utenti finali, e di valutare e migliorare con continuità il processo di sviluppo del software.

L’insieme dei moduli applicativi software del progetto, in particolare quelli realizzati, dovranno rispondere ai requisiti di qualità previsti dagli standard ed essere in linea con le disposizioni normative vigenti per la Pubblica Amministrazione.

Il software applicativo prodotto sarà soggetto a controllo di qualità, secondo procedure elaborate congiuntamente dal fornitore e dalla Stazione Appaltante; dovrà essere consegnato completo della relativa documentazione comprendente tra l’altro (come riferimento minimo):

• il documento descrittivo che include le funzionalità, le modalità di installazione e la distribuzione applicativa all’interno dell’infrastruttura elaborativa prevista da progetto;

• le note sulla release, in cui siano chiaramente evidenziate le caratteristiche della nuova versione, la documentazione di problemi noti, nonché eventuali differenze con versioni

precedenti;

• il manuale di amministrazione, necessario a chi si occuperà della gestione e del monitoraggio delle funzionalità del software rilasciato;

• il manuale utente, che rappresenta guida per l’utente finale per apprendere le funzionalità ed utilizzare correttamente il software sviluppato.

Le attività di collaudo riguarderanno tanto gli eventuali rilasci intermedi quanto quelli finali di ciascuna componente, sia a livello di base che applicativa.

Il collaudo, che dovrà essere preventivamente progettato e pianificato dalla Stazione Appaltante anche su indicazioni a cura del fornitore, prevede tra l’altro le seguenti attività:

• definizione del modello di test: requisiti, ambiente di test, approccio alla regressione, approcci alla manutenzione di casi di test, tools di test

• pianificazione del test per processo

• stesura degli script di test per processo

• progettazione della base dati di test

• definizione e strutturazione del DB delle anomalie.

Nel periodo immediatamente successivo a ciascun rilascio deve essere previsto un affiancamento degli utenti finali, con un’adeguata disponibilità di risorse per il monitoraggio della qualità del SW e per l’interazione con la struttura di assistenza e conduzione tecnica.

Tutto il software, sia di base che applicativo, collaudato con successo sarà posto in produzione a cura del Fornitore, che provvederà a tutte le attività necessarie per l’avviamento.

Il presente documento è protetto da copyright particolare riguardo alla formazione degli utenti e del personale tecnico, relativamente alle applicazioni rilasciate e all’utilizzo delle connesse infrastrutture tecnologiche.

Questa tipologia di servizio dovrà essere inclusa a corpo e non dovrà comportar nessun altro onere aggiuntivo per la Stazione Appaltante.

7.3 Servizio di consegna e installazione

Il servizio di consegna e installazione includerà in modo omnicomprensivo tutti gli oneri relativi alla produzione di supporti (CD – DVD, ecc.), materiale accessorio (documentazione, ecc.), consegna, installazione, verifica funzionalità e qualsiasi attività ad esse strumentale.

La verifica di funzionalità in questa fase sarà intesa unicamente per il materiale hardware come

accensione e riscontro dei principali parametri operativi di funzionamento e per il materiale software come la presenza dei moduli software comprensivi di tutto il materiale accessorio (supporti, documentazione, ecc.) e della collocazione di tali moduli software all’interno dell’infrastruttura elaborativa.

Tutto il materiale hardware e software dovrà essere catalogato ed etichettato secondo uno schema da concordare con la Direzione di Progetto che consenta un diretto collegamento alla localizzazione del materiale ed alla documentazione economica (bolle, fatture, inventari, documenti accessori, ecc.) e di consegna.

La proposta di progetto dovrà contenere, tra le altre cose, i termini di consegna e d’installazione sull’intera realizzazione prevista nel progetto.

Il servizio di consegna e installazione include un insieme di attività tra loro collegate.

La proposta di progetto dovrà contenere i termini anche temporali per l’installazione sull’intera realizzazione prevista nel progetto (hardware e software di base, moduli applicativi, ecc.), l’attivazione degli applicativi con la conseguente messa in esercizio dell’intera infrastruttura.

La verifica di funzionalità in questa fase viene intesa unicamente come la presenza di quanto previsto nel progetto e della sua installazione all’interno dell’infrastruttura elaborativa e del materiale accessorio (supporti, documentazione, ecc.).

Dovranno essere indicati i profili del personale utilizzato per tali servizi e le modalità di esecuzione della varie fasi con il personale interessato.

Questa tipologia di servizio dovrà essere inclusa in modo forfettario, espressa in termini di personale con i relativi profili e relativi impegni temporali, e non dovrà comportare nessun altro onere aggiuntivo per la Stazione Appaltante.

Ai fini della redazione del progetto e delle attività si specifica che tutte le forniture si intendono eseguite e compiute solamente quando il materiale occorrente alla corretta funzionalizzazione del progetto nonché del rispetto minimo della fornitura prevista e dei servizi connessi saranno pienamente operativi rispetto gli obiettivi di progetto. Quindi oltre alle azioni di legge riguardanti errori ed omissioni derivanti dallo svolgimento delle attività si ribadisce che qualsiasi materiale anche consegnato ed installato, qualora si dovesse verificare l’inidoneità agli scopi del progetto, sarà a cura e spese della ditta esecutrice fornire nuovo materiale idoneo secondo soluzioni che dovranno prevedere standard tecnologici non solo equivalenti ma al minimo superiori rispetto l’offerta stessa . Inoltre sempre a carico della ditta saranno comprese qualsiasi ulteriore fornitura di elementi, anche se non previsti, ma che costituiscono elementi fondamentali per il

funzionamento della soluzione, e quindi senza nessun onere aggiuntivo per l’Agenzia, ovvero qualsiasi introduzione funzionale per i fabbisogni delle soluzioni offerte devono considerarsi compresi nella fornitura assieme a tutti i servizi correlati relativi all’installazione, posa in opera e tutti le voci correlate ai vari servizi di avviamento.

7.4 Servizio di integrazione

I servizi di integrazione riferiti agli applicativi interessati all’intervento e presenti presso l’Agenzia o presso la Regione Abruzzo includono un insieme di attività tra loro collegate.

L’analisi dell’integrazione dell’infrastruttura con i servizi applicativi già presenti dovrà essere inteso in senso generale e non strettamente collegato alla singola implementazione, pertanto lo schema di riferimento generale da produrre dovrà prevedere un quadro complessivo per la realizzazione di applicativi ed interfacce di accesso che facciano uso degli standard di riferimento precedentemente descritti nel documento.

In sede operativa dovranno essere concordate con la Stazione Appaltante le priorità d’intervento delle attività di sviluppo e di integrazione e relative tempistiche. Resta inteso che le attività di sviluppo e di integrazione potranno avere corso solo dopo esplicita approvazione del piano operativo da parte della Stazione Appaltante.

Questa tipologia di servizio dovrà essere inclusa a corpo e non dovrà comportare nessun altro onere aggiuntivo per la Stazione Appaltante.

7.5 Servizio di configurazione e messa in esercizio

Il servizio di configurazione e messa in esercizio include un insieme di attività tra loro collegate.

La proposta di progetto dovrà contenere i termini anche temporali di configurazione e messa in esercizio per l’intera realizzazione prevista nel progetto (hardware e software di base, moduli applicativi, ecc…), per l’installazione e l’attivazione delle componenti applicative.

Il servizio di configurazione e messa in esercizio includerà in modo omnicomprensivo tutti gli oneri relativi alla definizione delle configurazioni (definizione profili, indirizzamenti, policy, ecc.) per la piena e completa messa in esercizio di quanto realizzato.

Lo schema delle configurazioni riportato in un documento sarà validato dalla Direzione di Progetto della Stazione Appaltante preliminarmente all’esecuzione operativa delle attività.

Per l’insieme complessivo dei prodotti forniti e di quanto altro realizzato dovrà essere prodotta una documentazione che illustri complessivamente tutte le configurazioni effettuate e preveda la memorizzazione delle stesse in appositi CD-ROM per il ripristino.

Le operazioni di verifica in questa fase prevedono test di riscontro sul funzionamento inteso quale controllo delle configurazioni e delle politiche implementate.

La proposta di progetto dovrà contenere, tra l’altro, i termini temporali di configurazione e messa in esercizio sull’intera realizzazione prevista nel progetto.

Dovranno essere indicati i profili del personale utilizzato per tali servizi e le modalità di esecuzione della varie fasi con il personale interessato.

Questa tipologia di servizio dovrà essere inclusa in modo forfetario, espressa in termini di personale con i relativi profili e relativi impegni temporali, e non dovrà comportare nessun altro onere aggiuntivo per la Stazione Appaltante.

7.6 Servizio di garanzia e manutenzione

L’Offerta Tecnica dovrà contenere i termini di garanzia sull’intera realizzazione prevista nel progetto (hardware, software di base, moduli applicativi, ecc.) e le condizioni per il ripristino di eventuali malfunzionamenti che non dovranno prevedere costi aggiuntivi perla Stazione Appaltante.

Tutti i moduli di integrazione offerti dovranno avere una garanzia minima di 36 mesi on site a partire dalla data di superamento con esito positivo del collaudo finale così come le apparecchiature eventualmente incluse nella fornitura (hardware, ecc.).

Tale attività si esplica, per il software di base, nel fixing dei bug con il rilascio di aggiornamenti e, per il software applicativo inteso nella sua più ampia accezione (pagine web, moduli applicativi, strutture dati, software pacchettizzato, RDBMS, ecc.), nella manutenzione correttiva avente lo scopo di rimuovere eventuali malfunzionamenti riconducibili ad errori imputabili al soggetto esecutore in una delle fasi precedenti il rilascio in esercizio, incluse quelle di installazione e configurazione.

Durante il periodo di garanzia e manutenzione, il soggetto esecutore si dovrà impegnare ad intervenire, in risposta alla segnalazione, per la risoluzione di eventuali gravi malfunzionamenti, con tempistiche diversificate in funzione del livello di gravità del malfunzionamento rilevato.

Il software dovrà prevedere l’aggiornamento alle nuove versioni, comprensivo dei servizi di

installazione e configurazione, per un periodo di 36 mesi.

I termini di garanzia per tutta la fornitura saranno calcolati a partire dalla data di superamento con esito positivo del collaudo finale.

Inoltre dovrà esservi l’impegno ad intervenire per la risoluzione di eventuali gravi malfunzionamenti, con tempistiche diversificate in funzione del livello di gravità dello stesso:

• errori gravi: impediscono l’operatività anche parziale di una funzione o la degradano sensibilmente;

• altri errori: non hanno un impatto immediato, evidente e generalizzato sull’operatività del sistema.

I tempi massimi d’intervento saranno diversificati in funzione della tipologia dell’errore. Per errori gravi dovranno essere assicurati i seguenti livelli di servizio:

• problem determination (entro le 2 ore lavorative dalla chiamata);

• ripristino dello stato di esercizio per i servizi erogati entro le 4 ore dalla chiamata;

• intervento on-site in caso di necessità per il ripristino dell’operatività dei servizi anche mediante operazioni di recovery entro le 4 ore lavorative dalla chiamata;

• riconfigurazione e personalizzazione del software sostituito e/o reinstallato in modo da ripristinare le funzionalità operative dell’area del sito web interessata.

Per tutti gli altri errori che non hanno un impatto immediato, evidente e generalizzato sull’operatività del sistema dovranno essere assicurati i seguenti livelli di servizio:

• problem determination (entro le 4 ore lavorative dalla chiamata);

• ripristino dello stato di esercizio per i servizi erogati entro 1 giorno dalla chiamata;

• intervento on-site in caso di necessità per il ripristino dell’operatività dei servizi anche mediante operazioni di recovery entro 1 giorno lavorative dalla chiamata;

• riconfigurazione e personalizzazione del software sostituito e/o reinstallato in modo da ripristinare le funzionalità operative dell’area del sito web interessata.

Le fasce di servizio precedentemente indicate sono, inoltre, da considerarsi come l’orario giornaliero di riferimento durante il quale il soggetto esecutore opererà per la risoluzione dei problemi e delle anomalie ad esclusione delle urgenze collegate ad errori bloccanti che dovranno prevedere uno schema di manutenzione anche nei giorni festivi secondo gli orari sopra indicati.

Dovranno, altresì, essere indicati eventuali servizi di assistenza telefonica con numero verde o

Area Tecnica Pagina45 di 60

assistenza telematica via Internet per effettuare operazioni preventive ai fini della esatta determinazione dei malfunzionamenti (e H

elp Desk).

Nel caso in cui il rispetto dei livelli di servizio dovesse comportare la sostituzione di intere componenti software, il soggetto esecutore dovrà prevedere, a suo completo carico, tale sostituzione, nonché tutte le attività di ripristino, inclusi il salvataggio dei dati e degli eventuali programmi software da reinstallare secondo opportune sequenze.

Relativamente ai livelli di servizio, il soggetto esecutore dovrà presentare mensilmente alla Direzione di Progetto della Stazione Appaltante un documento in formato elettronico che riporti i livelli di servizio misurati nel periodo in esame.

Dovrà essere redatto un piano di manutenzione che dovrà contenere l’indicazione delle modalità e delle strutture compresi i profili qualitativi/quantitativi del personale con il quale si intenderà gestire il contratto di manutenzione, nonché le ipotesi per una schedulazione di interventi di manutenzione preventiva. Il piano di manutenzione e le relative modalità di interazione proposte potranno essere rielaborate dalla Stazione Appaltante sulla base di specifiche e motivate indicazioni. In esso dovrà essere definita la copertura dell’infrastruttura applicativa esistente, così da garantire livelli operativi compatibili con le specifiche definite dal progetto per lo sviluppo dei servizi di interoperabilità applicativa. Dovrà, inoltre, contenere le indicazione di manutenzione evolutiva relativamente ai servizi locali, in modo che siano definite le modalità di integrazione di tali servizi alle specifiche di progetto.

Dovranno essere indicati i profili del personale utilizzato per tali servizi, gli strumenti utilizzati, le modalità di interazione e le modalità di esecuzione della varie fasi con il personale interessato. I livelli di servizio minimi sono quelli indicati nei capitoli precedenti.

Questa tipologia di servizio dovrà essere intesa a corpo e non dovrà comportare nessun altro onere aggiuntivo per la Stazione Appaltante.

7.7 Servizio di formazione e addestramento

La proposta di progetto dovrà contenere un insieme di servizi specificamente orientati alla formazione e all’addestramento del personale tecnico secondo le indicazioni della Stazione Appaltante in riferimento alla realizzazione dei servizi.

Dovrà essere previsto il necessario affiancamento operativo ai predetti operatori nella fase di start-up ed avviamento del sistema.

Il modello organizzativo e di servizio ipotizzato dovrà essere inteso come formazione in training on the job di un primo nucleo in grado di replicare poi la formazione in termini esaustivi, solo per gli operatori di gestione del sistema.

Mentre, per gli operatori sanitari, l’offerta dovrà contenere la descrizione qualitativa e quantitativa dei percorsi di e-learning che il concorrente intende attivare.

I docenti dovranno essere d’elevato profilo ed esperienza professionale ed in possesso delle certificazioni inerenti le tematiche dei corsi da essi tenuti.

Tutti i corsi dovranno essere pianificati in modo da concludersi in coincidenza del rilascio definitivo del sistema oggetto dell’infrastruttura determinata dal progetto e dovranno essere corredati di materiale didattico documentale ed illustrativo in formato elettronico e cartaceo.

La formazione in aula dovrà essere erogata presso le sedi che verranno in fase operativa comunicate dalla Stazione Appaltante.

Il piano di formazione sarà validato in sede operativa dalla Stazione Appaltante in relazione alle tecnologie ricadenti negli interessi regionali o relativamente all’implementazione progettuale, anche in riferimento alle problematiche di integrazione dei servizi locali. Il piano di formazione dovrà essere determinato e dimensionato almeno secondo quanto riportato nel relativo paragrafo del capitolo successivo.

7.8 Servizi accessori

L’Offerta Tecnica dovrà contenere anche tutti gli eventuali servizi accessori offerti. L’insieme di tali servizi sarà utilizzato sia in collegamento con i servizi di avviamento che con eventuali specifiche necessità che dovessero manifestarsi in corso di realizzazione.

In particolare a tale proposito potranno essere inclusi servizi atti a migliorare la qualità del dato, specifici servizi di affiancamento del personale interno nel segmento della security, di gestione (Configurazioni, Back-Up, ecc.), nella personalizzazione avanzata dei sistemi software, nella personalizzazione e gestione delle infrastrutture di monitoraggio e nelle interazioni dell’infrastruttura elaborativa con l’infrastruttura di comunicazione, necessari al progetto.

7.9 Modalità di esecuzione dei servizi

In questa sezione sono esplicitate le modalità di erogazione dei servizi. I servizi potranno essere

erogati on-site o da remoto così come previsto dalla RTI, ma andranno preventivamente concordati ed autorizzati dai referenti tecnici Regionali.

• Servizio di assessment: le attività di assessment dovranno essere preventivamente concordate con i referenti tecnici e si svolgeranno prevalentemente presso la sede ARIT negli orari di apertura degli uffici. Sempre di concerto con i referenti tecnici alcune attività potranno essere svolte presso le altri sedi Regionali.

• Servizio di gestione delle procedure applicative: il servizio di gestione delle procedure applicative dovrà prevedere la disponibilità di adeguato personale tecnico capace di risolvere i problemi di natura tecnica, che possono verificarsi nell’operatività. Il gruppo opera in autonomia, al suo interno, e a sua scelta, si relaziona attraverso un suo responsabile che si relaziona con la Direzione di Progetto dell’ARIT.

• Servizio di manutenzione e sviluppo applicativo: il servizio di manutenzione e sviluppo applicativo dovrà prevedere la gestione della risoluzione dei problemi applicativi segnalati dalla Stazione Appaltante o dagli operatori.

8. ELEMENTI QUANTATIVI

In questo capitolo sono riportati esclusivamente gli elementi quantitativi collegati alla fornitura che devono essere intesi come minimi.

Nell’Offerta Tecnica dovrà essere riportato un prospetto riepilogativo che indichi l’insieme del materiale e un prospetto riepilogativo che indichi l’insieme dei servizi offerti per numero e profilo professionale.

Nell’Offerta Tecnica e di conseguenza anche nei prospetti del materiale offerto, non dovranno essere contenute indicazioni economiche.

Attività/servizio/prodotto	Unità di Misura	Quantità Minima
Servizio di analisi preliminare dell’infrastruttura elaborativa esistente	Numero	A Corpo
Servizio di analisi preliminare dei servizi applicativi esistenti	Numero	A Corpo
Servizio di sviluppo applicativo	Numero	A corpo
Servizio di consegna e installazione	Numero	A Corpo
Servizio di integrazione	Numero	A Corpo
Servizio di configurazione e messa in esercizio	Numero	A Corpo
Servizio di garanzia	Mesi	36
Servizio di manutenzione	Mesi	36
Servizio di formazione e addestramento	GG/uomo	25
Servizi Accessori	Numero	A Corpo

8.1 Hardware di base

Il concorrente dovrà dimensionare le forniture di hardware, software base e materiale di consumo.

Particolare attenzione dovrà essere rivolta all’infrastruttura da realizzarsi presso il CTTL ed eventuali altre sedi.

9. MODALITA’ DI ESECUZIONE DELLE ATTIVITA’

L’insieme delle attività collegate alla fornitura di un supporto specialistico connesso alla realizzazione dei servizi sarà realizzato secondo le indicazioni, le limitazioni e le modalità operative di seguito riportate.

Tali modalità di esecuzione potranno essere congiuntamente riviste anche su proposta del soggetto esecutore e potranno essere concordate opportune semplificazioni o variazioni in funzione delle specificità riscontrate.

9.1 Il Piano delle attività

La realizzazione del progetto implica l’esecuzione di una serie di attività eterogenee con l’impiego di personale qualificato e richiede per il raggiungimento degli obiettivi un esecuzione coordinata, efficace e con controlli e verifiche puntuali.

L’esecuzione delle attività collegate alla realizzazione del progetto saranno interamente a carico della Ditta aggiudicataria, come anche quelle di coordinamento tecnico dei singoli sottoprogetti o macro attività, di progettazione, realizzazione, messa in opera, gestione e manutenzione delle necessarie infrastrutture e di tutto quanto altro necessario alla messa in esercizio del progetto.

La Ditta aggiudicataria dovrà prevedere un Capo Progetto unico a coordinamento di tutte le attività erogate, che sia responsabile dei rapporti con la Stazione Appaltante e dell’attuazione per le attività di competenza.

Tale figura non è esplicitata nelle richieste quantitative e nei profili in quanto l’indicazione della quota di partecipazione del Capo Progetto, nella composizione dei team relativi alle attività progettuali, da esplicitarsi nei servizi di Project Management e non inferiore al 3% del totale dei giorni/uomo richiesti, è di specifica competenza della Ditta offerente.

9.2 La documentazione di progetto

Le attività definite all’interno del progetto richiedono, in funzione della loro tipologia, la produzione di documentazione differenziata che consenta la piena comprensione e la completa conoscenza delle situazioni realizzative.

Lo schema documentale a corredo delle attività operative dovrà consentire alla Stazione Appaltante di conservare il pieno controllo del Progetto e la messa in atto di tutte le attività di controllo per il rispetto dei piani di qualità al fine di garantire l’assoluta eccellenza delle

realizzazioni.

Per tutte le attività è richiesta la documentazione progettuale organizzativa e pianificatoria (Diagrammi di GANTT, Piani di Allocazione delle Risorse con i relativi profili professionali, Lista degli Obiettivi da raggiungere ecc.) e quella di accettazione e validazione (verbali di accettazione, stato di consistenza, ecc.) il cui dettaglio sarà definito nella fase di pianificazione iniziale del progetto.

Deve essere predisposta inoltre tutta la documentazione relativa all’installazione, al test ed alla gestione dell’infrastruttura oggetto del progetto, oltre che una relazione che illustri le modalità di funzionamento e faciliti le attività formative ed il trasferimento di conoscenza al personale della Stazione Appaltante.

Tutta la documentazione progettuale dovrà essere prodotta sia in forma cartacea che in formato elettronico su supporti CD/DVD.

La documentazione progettuale sarà di esclusiva proprietà della Stazione Appaltante che potrà modificarla senza nessun vincolo o restrizione.

9.3 Il gruppo di lavoro

Il gruppo di lavoro è caratterizzato da diversi ruoli e responsabilità, da continuità operativa e da obiettivi condivisi.

La Stazione Appaltante ha la facoltà di verificare con propri mezzi, anche mediante colloqui tecnici, che le persone incaricate di svolgere le attività abbiano le capacità e le esperienze professionali corrispondenti a quanto descritto nei curricula.

La Ditta aggiudicataria dovrà assicurare il costante aggiornamento del personale del gruppo di lavoro in base all’evoluzione tecnologica ed applicativa prevista dal progetto. La Stazione Appaltante si riserva di verificare periodicamente l’adeguatezza del livello di competenze del gruppo di lavoro.

Le attività del personale della Ditta aggiudicataria impiegato nel gruppo di lavoro dovranno essere svolte presso il CTTL o se espressamente autorizzate presso una sede della ditta.

La Stazione Appaltante può a proprio insindacabile giudizio variare la sede di svolgimento delle attività, senza alcun aggravio di costi.

9.3.1 Project Management

La Ditta aggiudicataria dovrà gestire in modo efficiente tutte le attività relative al Contratto. A tal fine dovrà designare un Project Manager che sarà responsabile della gestione e dell’esecuzione del lavoro richiesto, del coordinamento del lavoro del team di Progetto e delle relazioni con l’Amministrazione. Il Project Manager sarà l’unico punto di Contatto ufficiale dell’Amministrazione.

In particolare oltre all’azione organizzativa dovranno essere descritti gli schemi atti a garantire un livello qualitativo di eccellenza coniugato al rispetto delle tempistiche definite congiuntamente in fase di esecuzione delle attività.

La Ditta dovrà fornire al kick-off (inizio lavori) il Piano di Gestione del Progetto con le seguenti informazioni:

1. descrizione delle attività

2. strategia del progetto

3. aspetti critici

4. Risk Analisys

5. organizzazione e Gestione o Struttura del Raggruppamento o Team di Progetto (Organizzazione, Responsabilità, Persone chiave)

6. gestione dei sottocontraenti (in caso di RTI)

7. pianificazione di Progetto (GANTT)

8. riunioni di progetto e rapporti

9. responsabile della qualità.

Le attività dovranno essere gestite secondo la pianificazione proposta dalla Ditta aggiudicataria ed approvata dall’Amministrazione. La pianificazione presentata in Offerta costituisce la “Baseline” contrattuale, salvo modifiche al contratto stesso. La Ditta sarà responsabile dell’aggiornamento della pianificazione del Progetto e dovrà fornire eventuali aggiornamenti della pianificazione entro 3 giorni lavorativi dall’evento che ha causato la necessità dell’aggiornamento della pianificazione. In ogni caso la pianificazione aggiornata dovrà riportare il riferimento alla “Baseline” contrattuale.

Variazioni alla pianificazione saranno valide ed impegnative per l’Amministrazione solo se approvate e sottoscritte.

Nell’Offerta Tecnica dovrà essere inclusa la specifica descrizione dei servizi di project

management offerti.

Il livello qualitativo/quantitativo del project management dovrà essere adeguato al volume complessivo di attività (e non solo ai servizi affidati in una prima fase) e ovviamente, dovrà fare riferimento al corrispettivo complessivo al netto di IVA, richiesto in modo omnicomprensivo, per le prestazioni oggetto della gara, che deve essere indicato unicamente nella Offerta Economica: non è, quindi, richiesto un corrispettivo unitario per la figura professionale collegata a tale servizio.

9.3.2 Il capo progetto tecnico per il Concorrente

Nell’ottica del coordinamento delle attività e della fornitura dei materiali e dei servizi necessari per la realizzazione del progetto la Ditta aggiudicataria dovrà anche designare un capo progetto tecnico per il Concorrente, vale a dire una figura altamente specializzata che sia demandata a seguire il progetto sotto tutti gli aspetti tecnici ed analitici, oltre che a coordinare i gruppi di lavoro.

La figura in questione dovrà inoltre essere esperta nelle tecniche di analisi e progettazione dell’ambiente di sviluppo e di test di progetto e negli strumenti a supporto dell'esecuzione dei lavori.

Analogamente al project management, il livello qualitativo/quantitativo del capo progetto tecnico deve essere adeguato al volume complessivo di attività e far riferimento al corrispettivo complessivo al netto di IVA, richiesto in modo omnicomprensivo, per le prestazioni oggetto della gara.

Non sarà richiesto un corrispettivo unitario per la figura professionale collegata a tale servizio.

9.4 I profili professionali

Il “pool” di risorse umane da utilizzare per l’esecuzione delle attività realizzative è particolarmente vario e differenziato.

Di seguito sono elencate le figure professionali con gli specifici requisiti richiesti in termini di professionalità ed esperienza per l’esecuzione della fornitura dei servizi oggetto della soluzione progettuale.

Per tutti i curricula senior collegati ai profili professionali è propedeutica e obbligatoria la laurea vecchio ordinamento oppure la laurea specialistica del nuovo ordinamento sempre in discipline scientifiche. La laurea vecchio ordinamento e quella specialistica possono essere mutuate con

cinque anni di esperienza lavorativa negli specifici segmenti di seguito indicati. Un laureato di primo livello con due anni di esperienza lavorativa negli specifici segmenti di seguito indicati viene considerato come un laureato con specialistica (laurea II livello).

Specialista area sviluppo applicativo

- Ha maturato un’approfondita esperienza e conoscenza dei principali moduli applicativi Microsoft: IIS, Exchange, SQL Server e in moduli applicativi Open Source: Apache, Firebird, SendMail, MySQL, Tomcat e JBOSS e nelle operazioni di gestione, tuning e configurazioni avanzate.

- Ha esperienza nello sviluppo in ambiente middleware distribuito e in particolare conosce i maggiori framework applicativi in ambito ICT con i relativi sistemi operativi (Linux/Unix, Windows, Solaris, ecc.)

- Ha esperienza nello sviluppo Jsp/Servlet/Ejb e più in generale dell’ambiente J2EE, buona conoscenza della programmazione e dei paradigmi OO.Ha, inoltre, esperienza nello sviluppo .Net C# e SQL Server. Ha conoscenza approfondita del web 2.0 ed in particolar modo degli standard definiti dal W3C. Conosce i linguaggi e la sintassi XML, XSL e XHTML.

- Ha esperienza nello sviluppo di applicazioni web oriented, ed ha esperienza in ambito SOA e nello sviluppo di web services

- Ha esperienza nella integrazione di applicativi tramite l’uso di protocolli di comunicazione (messaggi) i quali sono stati sviluppati con diversi linguaggi di programmazione e vengono eseguiti su diversi sistemi e piattaforme

- Ha esperienza in ambito RDBMS, PL/SQL e IDE di programmazione e sullo sviluppo di applicativi front-office e back-office.

- Ha esperienza in sviluppo di applicazioni sociosanitarie

Specialista Senior area Infrastrutture elaborative ed applicative

• Ha esperienza nella progettazione di infrastrutture elaborative integrate in ambiente eterogeneo. In particolare conosce le problematiche generali organizzative della P.A. regionale, è in grado di redigere analisi, raccolta di requisiti e progetti in linea con le più recenti tecnologie di settore.

• Ha maturato un’approfondita esperienza nella configurazione e tuning a livello avanzato di infrastrutture elaborative in ambiente eterogeneo (Server, Server Blade, Server Virtuali, SAN, ecc.).

• Ha maturato un’approfondita esperienza e conoscenza dei principali Sistemi Operativi a livello Server ed in particolare VMWare ESX,Windows2000/2003, Linux e Solaris e nelle operazioni di gestione, tuning e configurazioni avanzate.

• Ha maturato un’approfondita esperienza e conoscenza dei principali moduli applicativi Microsoft: IIS, Exchange, SQL Server e in moduli applicativi Open Source: Apache, Firebird, SendMail, MySQL, Tomcat e JBOSS e nelle operazioni di gestione, tuning e configurazioni avanzate.

• Ha maturato un’approfondita esperienza e conoscenza nel segmento della security infrastrutturale e applicativa ed in particolare nei moduli applicativi di reverse proxy e Proxy Server, nella suite applicativa per la security Symantec e nei prodotti IBM Tivoli Storage Manager e nelle operazioni di gestione, tuning e configurazioni avanzate, anche in merito alle librerie a nastro.

• Ha maturato un’esperienza lavorativa di cinque anni nella funzione e nel coordinamento e assistenza in attività di progetti relativi a infrastrutture elaborative di dimensione medio- alta.

• Ha esperienza nella implementazione e gestione di infrastrutture che supportano servizi ed applicativi Web Services in ambiente SOA.

• Ha esperienza nei sistemi Single Sign On, Identity Manager, Policy Manager per stabilire i meccanismi di Identità Federata.

9.4.1 I curricula

In funzione dei profili professionali richiesti nell’Offerta Tecnica possono essere inclusi più curricula da intendere come componenti del pool di risorse specialistiche rese disponibili dalla

ditta ai fini dell’esecuzione del complesso delle attività all’interno del progetto.

Ogni curriculum, numerato, riportante i dati anagrafici (Cognome, Nome, data di nascita) del personale e la corrispettiva qualifica professionale come indicato nella tabella precedente, dovrà contenere le informazioni necessarie a stabilire il livello di competenze e l’esperienza tecnica posseduta.

Si specifica che la Stazione Appaltante si riserva, a suo insindacabile giudizio, di verificare in sede operativa e con specifici colloqui il grado di preparazione e competenza tecnica delle risorse presentate dalla ditta per i servizi specifici previsti da progetto. Nella circostanza in cui la verifica evidenziasse delle carenze la Stazione Appaltante ne darà immediato riscontro formale al soggetto esecutore e, se necessario, ne chiederà l’eventuale sostituzione.

10. I COSTI

I costi relativi al progetto saranno valutati sia a livello complessivo che analiticamente, in base all’insieme dei servizi offerti.

Tutte le indicazioni economiche devono essere contenute all’interno del documento “Quadro Economico”, con l’esplicita specificazione dell’elenco prezzi. Nessuna indicazione economica deve essere riportata sull’Offerta Tecnica. Tutte le indicazioni economiche devono essere contenute all’interno della busta contenente l’Offerta Economica.

In questo capitolo si riporta un insieme di requisiti e di elementi necessari per la redazione del piano economico, in aggiunta a quanto altro previsto nella Relazione Tecnico Progettuale.

10.1 Costi di realizzazione complessivi

Nell’Offerta Economica dovrà essere incluso il costo complessivo, IVA esclusa, per la realizzazione di tutto quanto previsto in questa Relazione Tecnico Progettuale.

Tale costo includerà conseguentemente tutto l’hardware, il software, il costo del personale per i servizi di base, il costo per il personale dei servizi di sviluppo e quanto altro necessario per assicurare il pieno e completo avviamento del progetto indicato.

10.2 Il quadro analitico dei costi

Nell’Offerta Economica dovrà essere incluso un prospetto indicante il quadro di costo analitico di dettaglio collegato al costo complessivo offerto.

Tale prospetto deve essere costituito da una tabella che dettagli il costo complessivo offerto in base ad una ripartizione per area (software di base, servizi di base, servizi di sviluppo, servizi infrastrutturali specialistici, ecc…). Per ciascuna area dovrà essere definito il dettaglio con i relativi importi economici. L’importo economico complessivo deve coincidere con quello risultante dalla somma degli importi collegati alle singole aree.

11. LE MODALITA’ DI PRESENTAZIONE DEL PROGETTO

Le Ditte concorrenti, in sede di gara, dovranno presentare un progetto strutturato in modo da consentire la piena e completa comprensione di quanto proposto per la realizzazione del progetto e consentire, quindi, le naturali valutazioni comparative.

La struttura del progetto sarà definita dalla concorrente tenendo conto del fatto che la valutazione dello stesso sarà basata anche sulle modalità e sulla qualità della redazione.

E’, quindi, opportuno che, nel presentare le soluzioni architetturali e tecnologiche e nel descrivere i servizi di base e quelli specialistici, sia privilegiata la chiarezza espositiva.

Di seguito si riporta una possibile modalità di strutturazione dell’Offerta Tecnica: naturalmente tale strutturazione non è, e non vuole essere, esaustiva in quanto l’Offerta tecnica deve risultare in linea con le indicazioni contenute nella presente Relazione Tecnico Progettuale e nel Capitolato Speciale d’Appalto ad essa associato.

L’Offerta Tecnica deve presentare una pagina di copertina che riporti:

• la dicitura Gara d’Appalto – Procedura aperta mediante MePA per la “Realizzazione dell’Infrastruttura del Sistema Informativo Sociale Regionale” (CIG ) (CUP );

• Ragione Sociale della Ditta o delle imprese dell’eventuale R.T.I.;

• coordinatore del progetto e/o referente per la parte tecnica (nome e cognome, recapito telefonico, numero di fax e indirizzo e-mail).

11.1L’Offerta Tecnica

“L’Offerta Tecnica” è il documento progettuale che riporta le informazioni che consentono di determinare, per ogni Ditta offerente, le soluzioni architetturali e tecnologiche, i livelli ed i dimensionamenti inclusi in fornitura, le competenze e l’esperienza tecnica possedute relativamente agli strumenti ed agli ambienti tecnologici collegati alle realizzazione del progetto.

Tale documento potrà essere strutturato in completa autonomia ma dovrà contenere obbligatoriamente dei capitoli che illustrino tutto quanto richiesto.

12. CONCLUSIONI

La Relazione Tecnico Progettuale costituisce, insieme al Capitolato Speciale d’Appalto, la base di partenza per la definizione da parte delle Ditte offerenti, dell’Offerta Tecnica da presentare in fase di gara.

Si ribadisce che nell’Offerta Tecnica non dovrà essere inclusa alcuna indicazione economica, ma unicamente la quantità costituenti la fornitura in termini di hardware, software e servizi offerti per i relativi profili professionali (in linea con le richieste formulate) oltre ai servizi di project management per i quali non è richiesto uno specifico dettaglio quantitativo.

Sulla base delle esigenze e delle necessità della Stazione Appaltante, l’Offerta Tecnica dovrà essere, quindi, tesa ad ottenere nella realizzazione degli obiettivi progettuali un livello di qualità particolarmente elevato.

Di conseguenza gli aspetti tecnologici di riferimento dovranno essere collegati alla definizione di un’offerta che privilegi la qualità tecnica complessiva della proposta e che ponga in evidenza la conoscenza degli ambienti tecnologici individuati e l’esperienza realizzativa maturata in progetti analoghi.

13. ALLEGATI

ALLEGATO 1 alla Relazione Tecnico Progettuale : “Piano Sociale Regionale 2016-2018”.

Document Metadata

Table of Contents

Procedura aperta per la “Realizzazione dell’Infrastruttura del Sistema Informativo Sociale Regionale”

Document Metadata