capitolato rif1 def1 · all’interno di un repository di informazioni. OO Object Oriented ......

Capitolato tecnico Allegato 1

Capitolato tecnico Sviluppo e ammodernamento del sistema informativo dell’Assemblea regionale

Versione: definitiva

Data: 4 agosto 2008

Numero pagine: 56

Sviluppo e ammodernamento del

Sistema Informativo dell’Assemblea regionale

Capitolato Tecnico pag. 2 di 56

INDICE dei CONTENUTI

CAPITOLATO TECNICO 1

1. INTRODUZIONE 5

1.1 STRUTTURA DEL DOCUMENTO .............................................................................. 5 1.2 DOCUMENTI DI RIFERIMENTO E APPLICABILI ..................................................... 6 1.3 ACRONIMI, ABBREVIAZIONI, DEFINIZIONI .......................................................... 6

2. GENERALITÀ DEL PROGETTO 9

2.1 OBIETTIVI ................................................................................................................. 9 2.2 PRINCIPI FONDAMENTALI .................................................................................... 12 2.3 SINTESI ATTIVITÀ E OGGETTI DI FORNITURA................................................... 13

3. IL SISTEMA ATTUALE 15

3.1 FUNZIONALITÀ ...................................................................................................... 15 3.2 ARCHITETTURA...................................................................................................... 16

4. DEFINIZIONE DEL NUOVO SISTEMA 18

4.1 ARCHITETTURA FUNZIONALE.............................................................................. 18 4.1.1 Requisiti generali ................................................................................................ 21 4.1.2 Sicurezza ........................................................................................................... 24 4.1.3 Servizi – componenti – moduli............................................................................ 25

4.2 UTENTI.................................................................................................................... 27 4.3 ARCHITETTURA TECNOLOGICA ........................................................................... 27

4.3.1 Componenti hardware ......................................................................................... 27 4.3.2 Componenti software di base ............................................................................... 30

5. MISURE DI ACCOMPAGNAMENTO 31

5.1 SERVIZI.................................................................................................................... 31 5.1.1 Installazione e configurazione .............................................................................. 32 5.1.2 Migrazione dati .................................................................................................. 32 5.1.3 Avvio in esercizio................................................................................................ 33 5.1.4 Assistenza di manutenzione migliorativa, adeguativa e correttiva.......................... 33




5.1.4.1 Livelli di servizio e penali....................................................................................................................36 5.1.5 Assistenza di manutenzione evolutiva.................................................................. 38

5.1.5.1 Livelli di servizio e penali....................................................................................................................39 5.2 FORMAZIONE (CORSI E TRAINING ON THE JOB)................................................ 40 5.3 GARANZIA .............................................................................................................. 42

5.3.1 Livelli di servizio e penali ................................................................................... 42 5.4 ELEMENTI QUANTITATIVI DELLE MISURE ......................................................... 44

6. REALIZZAZIONE DEL SISTEMA 46

6.1 REQUISITI ORGANIZZATIVI .................................................................................. 46 6.1.1 Metodologie di progetto........................................................................................ 46 6.1.2 Requisiti di documentazione ................................................................................ 47 6.1.3 Modalità di pianificazione, controllo e revisione.................................................... 48

6.2 PIANO DI IMPLEMENTAZIONE............................................................................. 51 6.2.1 Piano di progetto................................................................................................. 55




INDICE delle TABELLE

Tabella 1: organizzazione per capitoli del documento..................................................... 5 Tabella 2: documenti di riferimento..................................................................................... 6 Tabella 3: acronimi, abbreviazioni, definizioni................................................................... 8 Tabella 4: moduli dei componenti...................................................................................... 26 Tabella 5: caratteristiche dei server .................................................................................... 28 Tabella 6: possibile configurazione dei server .................................................................. 29 Tabella 7: modalità di erogazione dei servizi .................................................................... 31 Tabella 8: livelli servizio e penali per manutenzione adeguativa/correttiva................. 37 Tabella 9: livelli servizio e penali per manutenzione evolutiva ...................................... 40 Tabella 10: dimensionamento dei corsi di formazione ................................................... 41 Tabella 11: schema del corso di formazione..................................................................... 41 Tabella 12: metriche dei tempi di intervento per la garanzia.......................................... 43 Tabella 13: metriche dei tempi di ripristino per la garanzia............................................ 43 Tabella 14: Garanzia - misure di accompagnamento ...................................................... 44 Tabella 15: Formazione – misure di accompagnamento ................................................ 44 Tabella 16: Servizi - Esempio di misure di accompagnamento .................................... 45 Tabella 17: manualistica tecnica.......................................................................................... 48 Tabella 18: sintesi del piano di implementazione............................................................. 55

INDICE delle FIGURE

Figura 1: gli attuali servizi applicativi del CRV................................................................. 16 Figura 2: infrastruttura e servizi applicativi....................................................................... 17 Figura 3: il modello concettuale.......................................................................................... 18 Figura 4: il modello logico dell’architettura funzionale................................................... 20 Figura 5: schema indicativo dell’infrastruttura tecnologica ............................................ 29 Figura 6: fasi di realizzazione .............................................................................................. 52 Figura 7: Gantt di progetto ................................................................................................. 56




1. INTRODUZIONE

Il presente documento rappresenta il Capitolato Tecnico di riferimento per la gara relativa allo sviluppo e ammodernamento del Sistema Informativo dell’Assemblea Regionale del CRV.

1.1 STRUTTURA DEL DOCUMENTO

Il documento si compone di 56 pagine ed è strutturato, oltre a questo capitolo, come sintetizzato nella tabella seguente:

Capitolo Num. Titolo

Contenuto

2 GENERALITÀ DEL PROGETTO

Descrive le finalità del Sistema, fornendo una panoramica di sintesi del progetto in termini di obiettivi, e principi fondamentali.

3 IL SISTEMA ATTUALE

Descrive in modo sintetico il sistema attualmente in uso presso il CRV, con particolare riferimento all’architettura tecnologica e alle funzionalità utilizzate.

4 DEFINIZIONE DEL NUOVO SISTEMA

Individua dapprima l’architettura funzionale, in termini di requisiti generali, di sicurezza e dei servizi applicativi; definisce quindi le categorie di utenti e l’architettura tecnologica di riferimento.

5 MISURE DI ACCOMPAGNAMENTO

Definisce le misure di accompagnamento da porre in essere per l’avvio del Sistema con particolare riferimento ai servizi da erogare in termini di installazione e configurazione, migrazione dati, avvio in esercizio, assistenza di manutenzione, formazione (corsi e training on the job), e garanzia, con i rispettivi livelli di servizio e penali. Il capitolo si chiude indicando gli elementi quantitativi minimali previsti per l’erogazione di tali misure.

6 REALIZZAZIONE DEL SISTEMA

Identifica le modalità da attuare per la conduzione del progetto sia per quanto riguarda i requisiti organizzativi (metodologie, documentazione, pianificazione – controllo – revisione) sia per il relativo piano di implementazione.

Tabella 1: organizzazione per capitoli del documento




1.2 DOCUMENTI DI RIFERIMENTO E APPLICABILI

I documenti citati nella seguente tabella sono usati come riferimento e contengono obblighi di progetto vincolanti per il Fornitore verso il Cliente.

Ente Titolo Rif.

CRV Sviluppo e ammodernamento del sistema informativo dell’Assemblea regionale - Studio di fattibilità R[1]

CRV Requisiti Funzionali con Use Case del sistema informativo del Consiglio Regionale Veneto R[2]

CRV Documenti del sistema per la gestione di qualità R[3] CRV Statuto Regione Veneto R[4] CRV Regolamento del CRV R[5] CRV Regolamento interno per l’Amministrazione R[6] CRV www.consiglioveneto.it R[7]

Tabella 2: documenti di riferimento

I documenti da R[3] a R[6] sono consultabili anche su R[7].

1.3 ACRONIMI, ABBREVIAZIONI, DEFINIZIONI

Nella tabella seguente sono indicati, in ordine alfabetico, i significati e le relative descrizioni attribuiti agli acronimi e alle abbreviazioni utilizzate nel presente documento. Non sono invece riportate quelle abbreviazioni considerate di significato non ambiguo nel settore dell’Information Technology (quali, ad esempio CD, Hz, Gb, Mb, PC, RAM, , etc.) e, per quelle relative al contesto informativo del Consiglio regionale del Veneto (di seguito indicato anche con CRV o Cliente), non è riportata la descrizione.

Acronimo Abbrev.ne Significato Descrizione

BI Business Intelligence

Cluster Due macchine collegate in maniera che quando una delle due smette di funzionare, l’altra subentra allo scopo di garantire un servizio continuativo (Fail-over Cluster).

CRV Consiglio Regionale del Veneto Organo legislativo della Regione Veneto.

DB Data Base Strumento di gestione e archiviazione dei dati. DBMS DB Mag.nt System Sistema di gestione di un Data Base.

DM Document Management

Gestione documentale; rappresenta l’insieme delle attività necessarie per archiviare i documenti, controllarne gli accessi e la loro “versione”.

DMS Document Management System Sistema di supporto alle attività di gestione documentale.





DMZ DeMilitarized Zone

Zona perimetrale di una rete di un sistema informativo in cui sono presenti le risorse raggiungibili direttamente dagli utenti esterni senza che ciò comprometta la sicurezza della zona interna del sistema.

ERP Enterprise Resource Planning

ESB Enterprise service Bus GR Giunta Regionale Organo Esecutivo dell’Amministrazione Regionale

HTML Hyper Text Markup Language

Linguaggio usato per descrivere i documenti ipertestuali disponibili nel Web.

HTTP Hyper Text Transfer Protocol

Protocollo di trasferimento di un ipertesto, utilizzato per la trasmissione di informazioni sul Web.

HW Hardware Parte fisica di un elaboratore.

IAM Identity Access Management

ICT Information and Communication

Technology

Convergenza fra informatica e telematica per la trasmissione dell’informazione; tecnologie comprendenti le reti, l’architettura e la multimedialità.

IT Information Technology Sinonimo di ICT.

LAN Local Area Network Identifica una rete locale che consente di far comunicare fra loro computer e periferiche.

LDAP Lightweight Directory Access Protocoll

Protocollo standard di accesso ai servizi presenti all’interno di un repository di informazioni.

OO Object Oriented Orientato agli Oggetti. Paradigma di analisi, disegno e sviluppo di sistemi software.

PEC Posta Elettronica Certificata

PM Project ManagementPianificazione, esecuzione e monitoraggio di un progetto, inteso come insieme di attività di durata finita nel tempo.

PSW Password

Rack Armadio, con dimensioni standard, che consente l’allestimento di computer in posizione verticale.

SI Sistema Informativo

Sistema che organizza e gestisce in modo efficace ed efficiente le informazioni necessarie per perseguire uno o più scopi, per automatizzare e supportare le procedure di lavoro all’interno dell’organizzazione.

SLA Service Level Agreement

Strumenti contrattuali, attraverso i quali si definiscono le metriche di servizio che devono essere rispettate da un fornitore (sia esso interno o esterno all’azienda).

SO Service Oriented Orientato ai Servizi. Paradigma di modellazione basato sull’individuazione di funzionalità offerte come servizi..

SOA Service Oriented Architetture Architettura Orientata ai Servizi.

SW Software Programma o un insieme di programmi in grado di funzionare in un elaboratore.

SWAP Single Web Access Point

Applicazione interna del CRV, che consente l’accesso alle applicazioni (portale interno del CRV).





TT Trouble Ticketing Sistema di gestione delle richieste di intervento per malfunzionamenti.

UCSI Unità Complessa Sistema Informativo

UML Unified Modelling Language

Linguaggio di modellazione e specifica di sistemi applicativi

VPN Virtual Private Network

Rete privata instaurata tra soggetti che utilizzano un sistema di trasmissione pubblico e condiviso.

WAI Web Accessibility Initiative

WBS Work Breakdown Structure

Struttura analitica del progetto, identifica l’insieme delle attività in cui è possibile decomporre un progetto

WF Work Flow Insieme di processi cooperanti fra loro che consistono in una o più attività, ognuna delle quali rappresenta un lavoro da svolgere per giungere a un obiettivo comune.

WFMS WorkFlow Management System

Sostiene l’organizzazione del processo di lavoro mediante l’utilizzo di software specifici.

W3C World Wide Web Consortium

Tabella 3: acronimi, abbreviazioni, definizioni




2. GENERALITÀ DEL PROGETTO

Il progetto in argomento prevede lo sviluppo e l’ammodernamento tecnologico del Sistema informativo attualmente in uso presso il CRV al fine di consentire allo stesso di svolgere al meglio il supporto alle funzioni legislative, di indirizzo politico e di controllo così come definite dalla Costituzione della Repubblica Italiana (art. 117) e dallo Statuto del Veneto (art. 8 e art. 9). In particolare, il progetto punta all’introduzione delle nuove tecnologie emergenti allo scopo di migliorare i processi interni di automazione dei flussi procedurali legati alle attività istituzionali e i processi esterni finalizzati al miglioramento della comunicazione e interoperabilità con altri enti esterni. Questo sarà raggiunto attraverso il potenziamento delle infrastrutture hardware, l’acquisizione di specifico software di base e la riorganizzazione dei processi di “business” che, attraverso l’introduzione di funzionalità applicative sviluppate ad hoc, consentirà un uso efficace del Sistema e un proficuo scambio informativo con i Cittadini e gli Enti istituzionalmente coinvolti nelle attività dell’Assemblea legislativa Regionale.

2.1 OBIETTIVI

Nell'ambito degli organi istituzionali e delle strutture organizzative del CRV, è sempre più avvertita l'esigenza di un miglioramento dei sistemi tecnologici a supporto delle attività. Il CRV fa già uso di un sistema informativo per lo svolgimento di tali attività; lo sviluppo tecnologico attuale da un lato, l’esigenza di disporre di un “collante” che permetta di continuare a gestire la complessità delle problematiche legate al mondo IT (tenendo conto delle esigenze di “business dell’azienda CRV”) e la necessità di far fronte alle criticità architetturali ormai evidenti (sviluppo del sistema in assenza di un piano organico in armonia con un delineato indirizzo strategico, frammentazione tecnologica che rende difficoltoso il presidio, orientamento di governo verso attività di gestione operativa piuttosto che di sviluppo) hanno determinato l’esigenza di ammodernamento e potenziamento del sistema informativo attualmente in uso presso il CRV. In particolare, sono state individuate le seguenti tre aree di interesse strategico, per ognuna delle quali sono definiti i principi fondamentali con i relativi obiettivi generali che si intendono perseguire per questo progetto. Area Business: servizi ad alto livello su cui insistono i processi aziendali.

Potenziamento della comunicazione: • Migliorare l’immagine istituzionale; • Introdurre strumenti di comunicazione bi-direzionale con il cittadino; • Raggiungere tutti gli stakeholder del Consiglio Regionale in tempo reale;




• Realizzare un sistema in grado di cogliere ed integrare nuove opportunità di comunicazione sotto la spinta di nuove tecnologie.

Automazione dei flussi procedurali: • Sostituire l’attuale strumento di supporto all’attività istituzionale (che

risulta difficile da usare, incompleto e non integrato) con la gestione documentale;

• Introdurre uno strumento avanzato di workflow management per migliorare la governabilità e l’efficienza dell’organizzazione.

Interfaccia con il sistema informativo della Giunta Regionale: • Favorire la collaborazione tra due organizzazioni sinergiche; • Abbattere gli ostacoli tecnologici allo scambio di informazioni in tempo

reale tra CRV e Giunta.

Introduzione di un cruscotto gestionale: • Migliorare la governabilità dell’organizzazione; • Semplificare l’accesso agli indicatori di performance dell’organiz-

zazione; • Migliorare dell’efficienza nella gestione delle risorse discrezionali.

Area Information: principali flussi informativi e tipi di dati scambiati tra gli

attori coinvolti nelle singole fasi dei processi.

Razionalizzazione del patrimonio informativo: • Migliorare l’accessibilità ai dati; • Migliorare e semplificare l’organizzazione delle banche dati; • Eliminare i problemi di duplicazione dei dati e le conseguenti

inconsistenze; • Garantire la salvaguardia del patrimonio informativo fino ad oggi

raccolto, predisponendo un accurato piano di migrazione dati.

Introduzione della firma digitale e della posta elettronica certificata: • Ridurre la mole di documenti cartacei; • Ridurre i problemi associati al doppio iter (elettronico vs. cartaceo) di

atti e pratiche; • Migliorare e controllare i processi di approvazione; • Garantire al mittente la fornitura della documentazione elettronica, con

valenza legale, attestante l'invio e la consegna di documenti informatici; • Favorire l’interoperabilità con altre organizzazioni.

Area Information Systems: principali tipologie di sistemi e componenti dei

sistemi informativi utilizzati nelle singole fasi dei processi (Servizi Applicativi).

Priorità nel rilascio dei servizi applicativi (1^ Riuso, 2^ Acquisto, 3^ Sviluppo): • Salvaguardare il patrimonio applicativo; • Contenere il disagio per gli utenti del sistema;




• Ridurre il TCO (Total Cost of Ownership) per il nuovo sistema informativo;

• Mitigare i rischi associati allo sviluppo di nuovi progetti.

Accesso ad applicazioni e dati attraverso un browser web, dove possibile: • Semplificare l’accesso a diverse tipologie di canali, dispositivi, utenti; • Fornire all’utente la percezione di un insieme integrato di servizi

raggiungibili con semplicità.

Standardizzazione della tecnologia applicativa: • Ridurre il tempo di rilascio di nuovi servizi richiesti dall’utente; • Ridurre i costi di nuove soluzioni; • Ridurre i costi associati al training del personale IT; • Semplificare la manutenzione del sistema.

Realizzazione di un’architettura a componenti con interfacce standardizzate: • Realizzare un sistema modulare; • Ridurre tempi e costi per il rilascio di nuovi servizi richiesti dall’utente; • Favorire l’interoperabilità tra sistemi.

Utilizzo del paradigma “Service -Oriented” nel disegno della nuova architettura: • Realizzare un sistema in cui le funzionalità sono fornite come servizi; • Identificare i servizi comuni che pertanto possono essere riutilizzati; • Utilizzare soluzioni che integrino il concetto di separazione tra

interfaccia di un servizio e sua implementazione.

Utilizzo di piattaforme applicative Enterprise: • Semplificare la gestione della complessità del sistema; • Migliorare portabilità, scalabilità, transazionalità, persistenza, supporto

Utilizzo di una metodologia consolidata nel disegno e nello sviluppo delle soluzioni custom: • Promuovere l’utilizzo di tool basati su UML come strumento di

disegno; • Favorire un approccio di tipo iterativo ed incrementale nel processo di

sviluppo (es. RUP); • Introdurre pratiche e tool per la gestione del ciclo di vita del prodotto

software (es. RUP); • Definire un set di documenti con cui gestire il ciclo di vita del SW.




2.2 PRINCIPI FONDAMENTALI

Sulla base dell’esame del contesto informativo attuale e delle competenze raggiunte dal personale del CRV a potenziamento del sistema informativo attualmente in uso, analogamente con quanto definito nel § 2.1, sono state individuate le seguenti tre aree di interesse tecnologico, per ognuna delle quali sono definiti i principi fondamentali con i relativi obiettivi di tipo tecnico che si intendono perseguire per questo progetto.

Area Infrastruttura tecnologica.

Introduzione di un middleware di integrazione/comunicazione tra gli applicativi: • Migliorare il livello di automazione dei processi e dei flussi informativi; • Migliorare i processi di pubblicazione delle informazioni sul sito

internet; • Introdurre un meccanismo di integrazione basato su standard (es. ESB,

CORBA, DCOM, RPC, ecc...).

Scalabilità: • Realizzare un’infrastruttura in grado di essere adattata a cambiamenti

della capacità richiesta.

Sostenibilità: • Utilizzare tecnologie note, largamente utilizzate e largamente

supportate; • Realizzare un’infrastruttura che avrà un tempo di vita lungo (>= 5 anni)

Disponibilità: • Realizzare un’infrastruttura in grado di fornire un’adeguata continuità di

servizio; • Selezionare prodotti che consentano l’implementazione di architetture

ridondate; • Selezionare prodotti che consentano il rilascio “a caldo” dei servizi.

Monitoraggio e gestione dell’infrastruttura tecnologica: • Utilizzare, se possibile, gli strumenti attualmente in possesso del CRV.

Separazione degli ambienti di sviluppo, testing e produzione: • Evitare che un’attività (sviluppo, test, produzione) possa influenzare le

altre. Area Sicurezza.

Centralizzazione del processo di autenticazione/autorizzazione: • Semplificare l’accesso al sistema; • Semplificare il provisioning dell’utenza; • Favorire l’aderenza agli standard normativi e alle policy di sicurezza.




Area Governo.

Riorganizzazione della struttura IT: • Favorire il riconoscimento della strategicità dei servizi IT da parte di

tutta l’organizzazione; • Razionalizzare gli investimenti in IT; • Ridurre il tempo di rilascio di nuovi servizi richiesti dall’utente; • Migliorare le attività di manutenzione sui servizi applicativi.

Miglioramento dei processi IT: • Introduzione di pratiche e tool di project management; • Introduzione di pratiche e tool per la gestione del ciclo di vita del

prodotto software (es. RUP); • Ridisegnare il processo di erogazione dei servizi IT secondo il

paradigma SO introducendo il concetto di qualità di servizio (SLA); • Estendere la gestione dei Trouble Ticket anche ai servizi applicativi; • Gestire al meglio la relazione con i fornitori.

2.3 SINTESI ATTIVITÀ E OGGETTI DI FORNITURA

In termini generali, il presente documento fornisce le indicazioni minimali, tecniche e non, per tutte le componenti del Sistema che si intende realizzare. Pertanto, il Sistema dovrà essere progettato e sviluppato in linea con gli obiettivi e i principi appena descritti, tenendo conto delle assunzioni, dei vincoli, delle dipendenze e dei requisiti posti in questo documento e in [R2]. Laddove nel presente documento siano citati prodotti specifici o Ditte produttrici, si è voluto fornire un riferimento sintetico rispetto alle funzionalità richieste e non un’indicazione di preferenza del Cliente. Infatti, tali citazioni sono sempre da intendersi seguite dalla dicitura “o equivalente” che lascia alle Società concorrenti la possibilità di proporre soluzioni alternative, anche con l’utilizzo di prodotti “open source”, allo specifico prodotto menzionato. Ai fini della completa valutazione delle offerte, le soluzioni proposte dalle Società concorrenti dovranno quindi essere corredate di tutti gli elementi e le precisazioni tecniche necessarie a dimostrare il raggiungimento, e l’eventuale incremento, delle funzionalità richieste, nonché la piena compatibilità con l’infrastruttura tecnologica esistente. Le proposte tecniche saranno perciò valutate esclusivamente sulla base dei citati elementi e precisazioni tecniche, nonché sulla bontà globale del progetto presentato. In estrema sintesi, il progetto per il potenziamento del sistema informativo del CRV, prevede la fornitura dei seguenti beni e servizi:

1. componenti hardware, in particolare di tipo server (cfr. § 4.3.1);




2. specifico software, pacchetti applicativi di base (cfr. § 4.3.2); 3. servizi – componenti - moduli custom (cfr. § 4.1.3); 4. misure di accompagnamento, ovvero servizi di:

• installazione e configurazione (cfr. § 5.1.1); • migrazione dati (cfr. § 5.1.2); • avvio in esercizio (cfr. § 5.1.3); • assistenza di manutenzione migliorativa, adeguativa, correttiva (cfr. § 5.1.4) • assistenza di manutenzione evolutiva (cfr. § 5.1.5). • formazione (corsi e training on the job, cfr. § 5.2); • garanzia (cfr. § 5.3).

Il servizio di “installazione e configurazione” è comprensivo delle attività di sviluppo e personalizzazione dei moduli software. Le attività e i relativi oggetti di fornitura dovranno essere coerenti con gli obiettivi (§ 2.1), i principi (§ 2.2) e i requisiti individuati per il Sistema, siano essi di natura funzionale (§ 4.3), organizzativa (§ 6.1) e documentativa (§ 6.1.2). Tutte le attività di progetto dovranno svolgersi ì in accordo alle modalità di controllo e revisione definite (§ 6.1.3), in piena armonia con il programma di pianificazione delineato (§ 6.2) garantendo le minime quantità previste (§ 5.4).




3. IL SISTEMA ATTUALE

In questo capitolo è descritto in modo sintetico il sistema attualmente in uso presso il CRV, in termini di funzionalità e di architettura; per una più specifica e dettagliata trattazione si rimanda il lettore ai documenti citati nella precedente Tabella 2: , con particolare riferimento a R[1] e R[2].

3.1 FUNZIONALITÀ

Dal punto di vista funzionale, le capacità offerte dal Sistema sono rese disponibili attraverso un portafoglio di servizi applicativi; per i dettagli si veda [R1]. Tali servizi applicativi, erogati e disponibili all’interno del sistema informativo del CRV schematizzati nella figura seguente, sono suddivisibili nelle seguenti cinque macro categorie:

Servizi di Gestione Risorse e Personale: ► contiene i servizi che si occupano di fornire e di realizzare le

funzionalità necessarie al CRV per la gestione delle risorse economiche, finanziarie, patrimoniali e del personale (Consiglieri o Ex e personale interno del CRV);

Servizi Documentali: ► contiene i servizi di gestione, archiviazione, protocollazione

e fornitura del corpo documentale in uso all’interno del CRV;

Servizi Tecnologici: ► contiene i servizi che si occupano di fornire e di realizzare le

funzionalità più propriamente tecnologiche, quali servizi di notifica (SMS, Fax), servizi di autenticazione (fornita al livello applicativo oppure dall’ infrastruttura tecnologica), telegrammi e di Help Desk;

Servizi Pubblicazione Informazioni: ► contiene i servizi che si occupano di fornire e di realizzare le

funzionalità necessarie al CRV per rendere fruibili le informazioni (documenti, immagini, filmati) sia all’interno del consiglio sia all’esterno verso l’utente cittadino o verso le altre amministrazioni pubbliche;

Servizi Gestione Atti Istituzionali: ► contiene i servizi per la gestione degli atti amministrativi,

delle attività di supporto all’assemblea, della gestione delle nomine degli enti dipendenti dal Consiglio e del servizio di Biblioteca.




Figura 1: gli attuali servizi applicativi del CRV

3.2 ARCHITETTURA

L’attuale architettura del Sistema, schematizzato nella figura seguente, rappresenta la distribuzione dei servizi di base sull’infrastruttura hardware e rappresenta una visione di insieme dei componenti applicativi che direttamente supportano le logiche di processo del CRV, dei componenti applicativi e dei servizi a supporto dei primi, nonché della loro allocazione sulle macchine fisiche. Per i dettagli di questa rappresentazione e degli elementi riferiti si veda [R1].




Figura 2: infrastruttura e servizi applicativi




4. DEFINIZIONE DEL NUOVO SISTEMA

I contenuti di questo capitolo dettagliano tutti gli elementi necessari per la progettazione e la realizzazione del Sistema passando in rassegna, nell’ordine, l’architettura funzionale, gli utenti e l’architettura tecnologica di riferimento.

4.1 ARCHITETTURA FUNZIONALE

L’architettura funzionale per il sistema informativo del CRV dovrà essere coerente con il paradigma di modellazione basato sull’individuazione di funzionalità offerte come servizi. Nella nuova architettura, i tradizionali “silos” applicativi, che comunicano tramite interfacce dedicate, dovranno lasciare il posto a servizi elementari con interfacce standardizzate che potranno essere composti ed orchestrati al fine di realizzare le funzionalità applicative richieste dall’organizzazione. Al livello di astrazione concettuale, la definizione dei servizi è rappresentata secondo la gerarchia descritta nella figura che segue.

Figura 3: il modello concettuale

Secondo tale modello, le funzionalità offerte dal sistema informativo sono, al livello più alto di astrazione, raggruppate nei seguenti domini:




Servizi multicanale – accesso a servizi e informazioni attraverso diversi canali/dispositivi (es. computer, palmari, smart phone, etc..);

Servizi di presentazione – look & feel coerente nell’accesso a servizi e informazioni attraverso i vari canali supportati (es. portale, browser, etc..);

Servizi di orchestrazione – supporto all’automazione dei flussi procedurali, implementando la logica di business;

Servizi applicativi – principali funzionalità richieste dai processi dell’organizzazione. Possono essere combinati utilizzando i servizi di orchestrazione;

Servizi di infrastruttura tecnologica – funzionalità tecnologiche a supporto degli obiettivi di business e/o dei servizi applicativi (includono i servizi di integrazione intesi sia come integrazione dati, sia come integrazione di servizi in tier verticali);

Servizi di sicurezza – garantiscono confidenzialità, integrità e disponibilità di servizi e informazioni di proprietà dell’organizzazione;

Servizi di gestione IT – supporto dei processi di governance e gestione del sistema informativo.

In accordo al suddetto modello concettuale, qui di seguito è fornito un livello più articolato di dettaglio nel quale, per ogni servizio, sono schematizzati e descritti i componenti logici opportunamente raggruppati, ognuno con i rispettivi moduli. I nuovi moduli, sono evidenziati con il testo di colore blu rispetto a quelli con il testo nero rappresentanti i servizi già presenti nel sistema attuale. Si evidenzia che tutti i moduli (sia bordati di rosso che di verde, sia con la scritta blu che nera) costituiscono oggetto di fornitura: i relativi vincoli di integrazione (per quelli che “vanno bene così come sono”) o di rifacimento (per quelli da “realizzare ex novo”) sono esplicitati nel documento R[2].




Figura 4: il modello logico dell’architettura funzionale

I componenti logici individuati sono descritti brevemente nel seguito (maggiori dettagli in [R2]:

Portale – fruizione di informazioni e servizi da parte degli utenti del sistema informativo. Dovrà fornire strumenti di accesso alle applicazioni, supporto alla multicanalità, content management avanzato, motori di ricerca ma anche newsletter e, più in generale, strumenti che incoraggino la comunicazione bi-direzionale con i cittadini;

Gestione Flussi Procedurali – servizi di supporto all’automazione dei flussi procedurali interni. Deve consentire l’orchestrazione dei servizi applicativi, e la definizione della stessa attraverso formalismi grafici ad alto livello;

Cruscotto – funzionalità di supporto alle decisioni che dovrà consentire il monitoraggio di flussi procedurali, utilizzo delle risorse, indicatori di performance;

Firma Digitale e PEC – funzionalità per l’autenticazione di documenti digitali e della posta elettronica certificata;

Strumenti di collaborazione – funzionalità di messaggistica immediata, videoconferenza, file sharing, condivisione di strumenti, etc.;

Gestione Risorse – funzionalità di contabilità analitica e finanziaria, gestione inventario, gestione del personale, etc.. Può essere implementato attraverso




un Enterprise Resource Planning (ERP), integrato con le soluzioni custom dedicate alla gestione dei Consiglieri;

Gestione Documentale – archiviazione, indicizzazione e gestione di documenti, immagini e contenuti multimediali in forma digitale. Deve integrare funzionalità di workflow documentale (es.: iter di emissione e approvazione);

Partner – funzionalità a supporto dello scambio di informazioni con la Giunta Regionale o altri enti;

Gestione Accessi – funzionalità di Identity and Access Management (implementazione del Single Sign On e gestione centralizzata del provisioning).

4.1.1 Requisiti generali

L’architettura generale del Sistema, in tutti le sue componenti, dovrà soddisfare, ai massimi livelli consentiti dalla tecnologia odierna, i requisiti minimi relativi alle seguenti categorie:

Aderenza agli standard

1) delle apparecchiature: deve essere aderente agli standard IMQ, ISO e di sicurezza previsti dalla comunità europea;

2) delle tecnologie: deve adottare gli strumenti considerati, a livello internazionale, standard di mercato o “de-facto”;

3) della sicurezza: standard ITSEC e normativa ISO 17799; 4) delle metodologie e della documentazione: deve essere aderente alla normativa

ISO/9000, agli standard di documentazione riconosciuti a livello europeo e/o militare, alla metodologia OO/UML;

Sicurezza 1) della Banca Dati: deve essere prevista la duplicazione della banca dati interna verso

l’area internet limitatamente alle informazioni/documenti di carattere pubblico. I meccanismi di replica devono attivarsi, al minimo, giornalmente e in forma asincrona. Sono auspicabili soluzioni che consentano una maggiore frequenza di replicazione se non il real-time;

2) degli accessi: deve consentire l’accesso selettivo ad utenti con livelli di autorizzazione diversi e garantire la registrazione delle operazioni. Per l’aggiornamento delle utenze (cfr. Linea Guida per la Sicurezza ICT delle Pubblica Amministrazione (I Quaderni n°23, Marzo 2006) si deve far riferimento a quanto sintetizzato nella tabella seguente:

Tipologia di utenza Frequenza max Lunghezza min. psw

Amministratore 6 mesi 8 caratteri Applicativa ai servizi Internet 1 settimana 8 caratteri Applicativa ai servizi interni 1 mese 8 caratteri

3) delle applicazioni: deve essere inibito l’uso non autorizzato alle funzionalità

applicative, con meccanismi di tipo hardware e/o di tipo software. Per la gestione




del protocollo informatico deve essere coerente con le indicazioni di cui agli articoli 1, 17 e 47 del Decreto legislativo 7 marzo 2005, n. 82;

4) disponibilità: deve mantenere un alto grado di disponibilità, ridondando gli elementi critici al fine di evitare single point of failure;

5) integrità dei dati: deve prevenire l’introduzione dei dati non aventi i requisiti formali e di congruenza richiesti, realizzando il contro-aggiornamento automatico nel caso di chiusura anomala della transazione ed effettuando procedure di backup e recovery;

6) trattamento delle informazioni: devono essere garantiti i servizi di “certificazione, validazione e documentazione oggettiva” delle informazioni, in quanto il Sistema si configura, essenzialmente, come una infrastruttura per la generazione, la gestione e lo scambio di informazioni attendibili e sensibili. A tale scopo, la struttura dei dati scambiati tra le applicazioni deve essere tale da garantire l'identificazione, e quindi il controllo, dei flussi informativi;

7) firma digitale: deve essere coerente con il codice dell'amministrazione digitale entrato in vigore nel gennaio 2006 attraverso il Decreto legislativo 7 marzo 2005, n. 82, che ha modificato il valore probatorio del documento informatico con il comma 2 dell'articolo 21, come modificato dal D.Lgs. 4 aprile 2006, n. 159;

8) posta elettronica certificata: deve essere conforme al DPR 11 febbraio 2005, n. 68 (G.U. 28 aprile 2005, n. 97), che disciplina le modalità di utilizzo della Posta Elettronica Certificata non solo nei rapporti con la PA, ma anche tra privati cittadini;

9) normativa: deve essere assicurata l’adozione della base minima di sicurezza prevista dalle direttive vigenti (almeno quella del 16 gennaio 2002 del Presidente del Consiglio dei Ministri - Dipartimento per l'innovazione e le tecnologie "Sicurezza informatica e delle telecomunicazioni nelle pubbliche amministrazioni statali").

Interfaccia utente

1) help contestuali: deve prevedere help contestuali (come utilizzare l’applicazione) e operativi (legati al contesto applicativo, ad es. relativi a normativa di legge) che facciano uso di tecniche come ipertesti, gestione macro, gestione di vocabolari e thesaurus, multimedia, recording e playback;

2) semplicità operativa: deve garantire facilità d’uso nell’utilizzo delle procedure e della strumentazione attraverso un’interfaccia amichevole, dotata di aiuto in linea che suggerisca l’azione in caso di difficoltà; deve altresì essere posta particolare attenzione affinché l’interfaccia proposta agli operatori del settore sia quanto più possibile aderente a quella disponibile negli applicativi attualmente utilizzati;

3) tecnologia: deve implementare una interfaccia di tipo grafico a finestre, che semplifichi al massimo il dialogo con il Sistema, riduca al minimo i tempi di apprendimento, integri perfettamente la componente grafica dei dati con quella descrittiva, faccia uso dei più diffusi e avanzati widget grafici e del drag & drop.

4) Normativa per l’accessibilità: le pagine pubblicate devono seguire le direttive in materia di accessibilità agli strumenti informativi da parte di utenti diversamente abili stabilite dal CNIPA e dai principali organismi internazionali. Le linee guida sono quelle definite dal WAI, organo del W3C.




Integrazione e cooperazione con altri Sistemi

1) deve adottare il “modello di interscambio" coerente con le direttive CNIPA al fine di garantire l’interazione, il colloquio, l’interoperabilità e la cooperazione con altri sistemi, legacy o di interscambio, già esistenti o in via di sviluppo/realizzazione, in particolare con la Giunta Regionale;

2) per la cooperazione dei sistemi SPC deve essere coerente con il Decreto Legislativo n° 42 del 2005. per i servizi di connettività, sicurezza, interoperabilità di base, supporto e applicativi.

Caratteristiche architetturali 1) flessibilità: deve essere pronta verso cambiamenti organizzativi e procedurali in

corso d’opera che richiedano interventi sia sulle componenti hardware che software (di base1 e applicativo);

2) modularità: deve essere realizzata con una struttura modulare integrata, che permetta una facile e graduale apertura della stessa all’introduzione di nuove funzionalità, sia da un punto di vista hardware che software (di base e applicativo);

3) scalabilità: deve essere garantita l’estensione del Sistema e la sua evoluzione attraverso il potenziamento del singolo server oppure attraverso la capacità di suddividere i singoli servizi software tra più server, al fine di aumentare le performance complessive senza la necessità di modificare le applicazioni esistenti;

4) usabilità: dovrà essere adottata la compressione dei dati e la loro crittografia, ove rilevante, per ridurre il traffico sulla rete e garantire le opportune condizioni di sicurezza;

5) modalità di accesso: deve supportare ambienti eterogenei, prevedendo accessi sia in modalità Web (Intranet - Internet) che tramite apparati mobili (quali telefoni o palmari) che Client/Server (su rete locale). Verrà considerato un plus la possibilità di accesso off-line (opzionale), come modalità di lavoro alternativa e tramite applicazioni stand alone quando per cause accidentali o volute il server chiamato non è attivo o disponibile, prevedendo successivamente un adeguato meccanismo di riallineamento quando il server è nuovamente disponibile;

6) gestione degli errori: dovranno essere garantiti al minimo le seguenti capacità: a) registrazione in appositi log dei codici di errore e descrizione, b) visualizzazione standardizzata della messaggistica di errore, c) gestione dei codici di errore evitando l’interruzione delle applicazioni; d) registrazione in appositi log e su diversi livelli delle operazioni effettuate da

ogni utenza; 7) ambienti tecnologici: deve adottare, per la migliore efficienza e per una maggiore

“cost-effectiveness”, gli indiscussi leader del mercato, che rappresentino uno standard a livello nazionale e internazionale, in modo da facilitare anche lo scambio e l’acquisizione di dati con/da altri Enti. Sebbene siano richiesti prodotti software COTS specifici per gli scopi prefissati, come indicato nel seguito, il Sistema non si configura come un insieme di componenti software specifiche utilizzate così come sono da utenti esperti, ma, al

1 Con il termine software di base si intende tutto quello non scritto ad hoc (definito come software

applicativo). Rientrano in questa accezione i prodotti relativi al Sistema Operativo, al RDBMS, e a quant’altro acquisibile dal mercato.




contrario, si propone come un Sistema omogeneo, integrato, dedicato a scopi specifici e adatto all’utilizzo anche da parte di utenti non particolarmente esperti; questi vedranno le capacità loro offerte dagli specifici prodotti di base in modo integrato, trasparente e attraverso un’interfaccia omogenea e di semplice utilizzo, che mascheri eventuali capacità non richieste. Inoltre, come riferimento sintetico relativo agli ambienti software richiesti si indicano:

a) sistema operativo: Linux, MS Windows o equivalenti, sul quale implementare gli strati applicativi e le interfacce grafiche verso l’utente utilizzatore;

b) ambiente Banca Dati: ORACLE, DBII o equivalenti, come ambiente architetturale per la gestione dei dati in ambito RBDMS;

c) piattaforme applicative enterprise: J2EE, .NET; d) ambienti di sviluppo: deve essere predisposto un apposito ambiente di

sviluppo che adotti strumenti e linguaggi tecnologicamente avanzati, aperti e avviati a diventare standard consolidati:

programmazione Object Oriented, di tipo “visuale” ove necessario e, comunque, utilizzo di linguaggi di programmazione aderenti a standard ANSI, ISO, IEEE, X/OPEN;

adozione di middleware standard (CORBA, DCOM); XML per il trattamento degli schemi di rappresentazione in modo da

separare la sintassi e la semantica dalla rappresentazione delle informazioni;

linguaggio standard server-based per RDBMS al fine di semplificare le operazioni di accesso ai dati;

viewer leggeri per la distribuzione e la consultazione dei dati in modalità web (HTLM, Java, ASP, ...).

e) Tipologie di licenze:

per l’eventuale software di base distribuito sui client, deve essere adottata una politica di licenza non legata ad un nodo specifico, ma che ne consenta la distribuzione e l’utilizzo su più piattaforme, anche su quelle già disponibili;

il software applicativo, in forma di eseguibili e codice sorgente, dovrà essere consegnato al Cliente, che ne disporrà della proprietà intellettuale esclusiva.

4.1.2 Sicurezza

Il Sistema deve fornire l’insieme delle disposizioni atte a proteggere dati e risorse da eventi accidentali o intenzionali, garantendo quanto segue:

• riservatezza: il dato dovrà essere disponibile solamente ai processi che lo devono elaborare e all’utilizzatore che ne ha oggettivamente bisogno e ne è pertanto legittimato all’utilizzo;

• integrità: ogni dato dovrà essere realmente quello immesso in origine nel Sistema ovvero solo legittimamente modificato;

• disponibilità: prevenzione dalla impossibilità di utilizzo di una informazione o risorsa, nel caso in cui l’utilizzo sia espressamente autorizzato.




Sebbene sia evidente che la definizione, la progettazione e la realizzazione di un sistema di protezione preventivo sia necessario per la salvaguardia dei dati gestiti, si deve tener sempre presente che lo scopo della sicurezza è di abilitare gli accessi al patrimonio informativo, rendendo disponibili e “sicure” le risorse a chi ne è legittimato all’utilizzo, e non di impedirli. Le misure di sicurezza adottate dovranno influenzare il meno possibile la flessibilità dell’architettura del Sistema, potendo costituire dei vincoli architetturali solo in particolari situazioni. La progettazione di tali misure deve:

• tendere a permetterne l’evoluzione, estendendo ed espandendo quanto già realizzato ed esistente;

• prevedere la pianificazione delle attività di sensibilizzazione, addestramento, controllo, e monitoraggio, nonché aggiornamento a seguito di malfunzionamenti;

• tener conto delle eventuali attività di certificazione. Come per tutti i sistemi complessi, dal punto di vista globale, la sicurezza del Sistema dovrà essere garantita da funzioni di differente tipologia, e più precisamente da misure di sicurezza tecniche (realizzate tramite meccanismi hardware e/o software) e non tecniche, di tipo fisico, procedurale o sul personale (funzioni di tipo organizzativo e logistico). Si fa notare come non sia possibile in alcun modo prescindere da quest’ultima misura per ottenere il corretto funzionamento del sistema di sicurezza: nessun meccanismo infatti, può garantire il livello di protezione desiderato soltanto attraverso gli strumenti, gli apparati, l'hardware e il software, senza adeguate procedure, norme di utilizzo e gestione, in grado di realizzare le funzioni di sicurezza previste. Se è vero quindi che le misure di sicurezza dovranno offrire le specifiche funzionalità atte alla:

• gestione e controllo di utenti e assegnazione di privilegi, • sicurezza dei dati, • protezione e controllo del Sistema da intrusioni, • protezione dei dati sensibili, • protezione dei diritti di proprietà intellettuale dei documenti,

è altrettanto vero che esse avranno influenza sul Sistema nel suo complesso, dovendo garantire il corretto svolgimento di tutti i processi di utilizzazione dello stesso. Per i dettagli sulle funzionalità atte a garantire il necessario livello di sicurezza ed il rispetto della normativa di riferimento si faccia riferimento a R[2].

4.1.3 Servizi – componenti – moduli

Con riferimento ai servizi e ai rispettivi componenti indicati nel § 4.1, sono di seguito riepilogati i rispettivi moduli, da integrare o da realizzare ex novo; per maggiori dettagli di integrazione o realizzazione, si rimanda il lettore al documento [R2]. Componente Moduli

Portale • Accesso a contenuti multimediali • Gestione siti internet • Diretta sedute consiliari




Componente Moduli • Gestione della Banca Dati delle leggi regionali, dei

regolamenti e dei provvedimenti • Pubblicazione documenti • Accesso ai servizi applicativi • Agenda istituzionale • Gestione indirizzari • Pratiche difensore civico • Gestione Nomine • Gestione verbali sedute

Gestione flussi procedurali • Gestione atti amministrativi e delibere • Gestione della logica di business • Notifica

Cruscotto • Monitoraggio dei flussi procedurali

Certificazione Identità • Firma digitale • Posta elettronica certificata

Strumenti di collaborazione • Messaggistica immediata • Audioconferenza • Videoconferenza

Gestione risorse

• Gestione inventario • Gestione giuridica Personale • Gestione pedaggi autostradali • Contabilità analitica • Contabilità e Finanziamento gruppi consiliari • Contabilità economica patrimoniale • Gestione economica Personale • Gestione missione Consiglieri • Rilevazione presenze Personale • Contabilità finanziaria

Gestione documentale

• Fornitura documenti • Gestione contenuti multimediali • Archiviazione documentale • Gestione diapositive • Protocollazione documentale • Rassegna stampa

Partner • Interazione Giunta Regionale • Interazione con altre strutture regionali

Gestione accessi • Autenticazione centralizzata • Gestione del provisioning

Media Center

• Videoteca • WebTV • Streaming Dirette • Rassegna stampa

Tabella 4: moduli dei componenti




4.2 UTENTI

Il Sistema dovrà essere accessibile mediante tecnologia tipo web, tramite Internet/Intranet o comunque con le modalità di collegamento, differenziate in relazione al tipo di utente, indicate nel seguito di questo documento. In questa fase si identificano le seguenti 2 (due) tipologie di utenti:

amministratori - hanno accesso ad una o più componenti tecnologiche; applicativi o generici - per ciascuna componente software hanno diritti diversi

in base ai ruoli funzionali che verranno delineati.

4.3 ARCHITETTURA TECNOLOGICA

In accordo ai requisiti funzionali definiti precedentemente, il presente capitolo presenta le componenti tecnologiche che costituiscono l’environment del Sistema e delinea i requisiti architetturali di base individuati. Sono quindi riepilogate le caratteristiche minime richieste per le diverse componenti del Sistema con particolare riferimento a quelle hardware e software di base. Riguardo quest’ultime, si precisa che il Fornitore è libero di proporre qualsiasi prodotto “open source” ritenga utile. In ogni caso, si evidenzia che le componenti hardware e software di base proposte dovranno integrarsi con quelle esistenti.

4.3.1 Componenti hardware

Considerato il parco tecnologico attualmente presente presso il CRV, le componenti hardware che il Fornitore dovrà prevedere, si limitano a macchine di tipo server che dovranno essere installate e opportunamente configurate in modo da risultare perfettamente integrate e operative con le piattaforme esistenti. Quindi, nella redazione della propria offerta il Fornitore avrà cura di:

• individuare le componenti che meglio si integrano con l’esistente, evitando eventuali possibili conflitti “operativi”;

• prevedere almeno una quantità minimale di server pari a 5 (cinque) unità; • se ritenuto più funzionale al progetto, aumentare la quantità di macchine

rispetto al numero minimo previsto; • disegnare la propria architettura sulla base di quanto indicativamente

schematizzato nella [Figura 5: schema indicativo dell’infrastruttura tecnologica];

• prevedere, se necessario, la fornitura dei server non in unica soluzione ma nelle varie fasi operative di progetto;

• garantire una configurazione in rack, con doppia alimentazione, completo di monitor flat e tastiera estraibile per ospitare server e SAN e per una migliore organizzazione degli spazi;




• offrire quanto di meglio disponibile sul mercato, anche in considerazione della probabile obsolescenza cui vanno incontro le apparecchiature (si pensi ai diversi momenti di stesura del presente documento, presentazione dell’offerta, aggiudicazione della gara, consegne in fasi differite);

• predisporre, a proprie spese, l’ambiente di sviluppo che riterrà più consono per il progetto.

Le tipologie delle macchine server, sono suddivise in tre fasce in relazione al possibile carico da supportare e al servizio da erogare; le caratteristiche minimali e una possibile configurazione dei server per ogni servizio erogato, sono riepilogate nelle due seguenti tabelle puramente indicative:

Tipologia Server Prestazioni RAM Esempio CPU

High_Server Elevate 8 GB Quad Core XEON Medium_Server Ridotte 4 GB Dual Core XEON Low_Server Necessarie 2 GB Dual Core XEON

Tabella 5: caratteristiche dei server

Tutti server forniti dovranno avere almeno le seguenti caratteristiche: • doppio alimentatore; • doppia ventola di raffreddamento; • doppia scheda di rete a 1Gb; • controller RAID per dischi; • 2 dischi SAS da 72GB da almeno 10.000 rpm; • capacità di montaggio della scheda di interfacciamento alla SAN fornita.

Componente Logico

Tipologia Server

Descrizione del componente ospitato - ubicazione e accessi

Cluster

Internal Portal Server High_Server

Portale - all’interno della rete del CRV, può essere acceduta solo dagli utenti interni o esterni tramite l’utilizzo di una VPN.

Si

ECM Server High_Server Gestione documentale - all’interno della rete del CRV, può essere acceduta solo dagli utenti interni o esterni tramite l’utilizzo di una VPN.

Si

ERP Server Medium_Server Gestione risorse - all’interno della rete del CRV, può essere acceduta solamente dagli utenti interni o esterni tramite l’utilizzo di una VPN.

Si

ESB Server Medium_Server Interazione con i Partner - all’interno della rete del CRV, può essere acceduta solo dagli utenti interni o esterni tramite l’utilizzo di una VPN.

Si

Communicator Server Medium_Server

Strumenti di Collaborazione - all’interno della rete del CRV, può essere acceduta solo dagli utenti interni o esterni tramite l’utilizzo di una VPN.

No

BPM Server Single_Server Gestione dei flussi procedurali - all’interno della rete del CRV, può essere acceduta solo dagli utenti interni o esterni tramite l’utilizzo di una VPN.

Si

IAM Server Single_Server Gestione accessi - all’interno della rete del CRV, può essere acceduta solo dagli utenti interni o esterni tramite l’utilizzo di una VPN.

No

DB Server High_Server Insieme dei database utilizzati dalle varie Si




Componente Logico

Tipologia Server

Descrizione del componente ospitato - ubicazione e accessi

Cluster

componenti, è accessibile direttamente dagli amministratori del sistema informativo.

Storage Area Network

Memorizzazione di tutti i dati delle singole componenti, in particolare dei dati gestiti dalla componente DB Server.

HW Load Balancer

Bilanciamento di carico fra i due External Portal Server

External Portal Server

High_Server Portale per l’erogazione dei servizi relativi accessibili agli utenti esterni del CRV.

Si

Tabella 6: possibile configurazione dei server

La seguente figura mostra invece una possibile configurazione dell’infrastruttura tecnologica nella quale sono state inserite i seguenti server già in uso presso il CRV:

• Proxy server; • Domain Controller; • E-mail Server; • Server Legaci; • Encoding Media Server.

Figura 5: schema indicativo dell’infrastruttura tecnologica




4.3.2 Componenti software di base

Sulla base di quanto precedentemente descritto, sono previsti i prodotti software che il Fornitore dovrà garantire in relazione ai seguenti ambienti:

• DMS - Gestione Documentale:

memorizzazione, archiviazione, ricerca e pubblicazione dei documenti, filmati e contenuti multimediali;

gestione del protocollo informatico.

• WFMS - Gestione Flussi Procedurali:

disegno e la simulazione dei processi del CRV;

disegno, esecuzione e monitoraggio dei processi.

• ERP - Gestione Risorse:

gestione delle risorse finanziarie e del personale.

• BI - Cruscotto Gestionale:

estrapolazione dei dati aziendali per attività di supervisone e controllo.

• IAM - Gestione Accessi:

gestione delle utenze e degli accessi alle singole applicazioni.

• ESB - Piattaforma di Integrazione e orchestratore:

gestione dell’integrazione e utilizzo dei servizi forniti dal sistema informativo del CRV.

• Certificazione Identità:

gestione dei certificati digitali, della firma digitale e della posta elettronica certificata.

• Portale:

gestione e realizzazione del portale interno/esterno del CRV.

• Strumenti di Collaborazione:

scambio di messaggi istantanei, chat, realizzazione di video conferenze tramite PC.

• Gestione Multimediale:

gestione dei contenuti multimediali realizzati o utilizzati dal CRV. Per i dettagli dei moduli da integrare o da realizzare ex novo si rimanda il lettore al documento [R2]. Si ribadisce che il Fornitore potrà proporre, per qualsivoglia dei suddetti ambienti, i prodotti “open source” che riterrà opportuno, descrivendone le relative caratteristiche con dovizia di particolari.




5. MISURE DI ACCOMPAGNAMENTO

Questo capitolo è dedicato alle misure di accompagnamento da porre in essere per l’avvio e il buon andamento del progetto, in termini di:

• servizi:

installazione e configurazione;

migrazione dati;

avvio in esercizio;

assistenza di manutenzione migliorativa, adeguativa, correttiva con relativi livelli di servizio e penali;

assistenza di manutenzione evolutiva, con relativi livelli di servizio e penali.

• formazione (corsi e training on the job);

• garanzia, con relativi livelli di servizio e penali. Chiude questo capitolo, il paragrafo contenente alcune indicazioni relative alla quantificazione delle suddette misure di accompagnamento in termini di impegni minimali che il Fornitore dovrà garantire. Gli elementi quantitativi che il Fornitore dettaglierà nella propria offerta verranno utilizzati come elementi di valutazione della bontà della stessa.

5.1 SERVIZI

In considerazione delle esigenze espresse nel presente capitolato, si richiede al Fornitore di redigere la migliore proposta per l’erogazione dei servizi elencati nella tabella seguente e descritti nei successivi paragrafi di questo capitolo:

Descrizione del servizio Erogazione Installazione e configurazione a corpo Migrazione dati a corpo Avvio in esercizio a corpo

Assistenza di manutenzione migliorativa, adeguativa, correttiva a consumo – correttiva a corpo

Assistenza di manutenzione evolutiva a consumo Formazione (corsi e training on the job) a corpo Garanzia a corpo

Tabella 7: modalità di erogazione dei servizi




5.1.1 Installazione e configurazione

In accordo alla pianificazione proposta, il Fornitore dovrà garantire le attività di installazione e di configurazione delle componenti hardware e software oggetto di fornitura, prestando particolare attenzione, laddove necessario, alle varie fasi di installazione di una macchina e relativa “disattivazione” di quella corrispondente che svolgeva analogo servizio (ad esempio, nuovo server per DMS, al posto dell’attuale con riutilizzo di quest’ultimo). Il Fornitore dovrà specificare in dettaglio quali attività svolgerà, indicando la tipologia di figure professionali che intende utilizzare e i relativi giorni uomo necessari, tenendo presente le indicazioni contenute nel successivo § 5.4.

5.1.2 Migrazione dati

La migrazione dei dati riguarda il trasferimento dei dati operativi elettronici contenuti nell’attuale banca dati per l’utilizzo nel nuovo Sistema. Tale attività, quindi, dovrà essere effettuata tenendo conto dell’uso che se ne dovrà fare di ogni dato anche in funzione dei nuovi servizi introdotti, con particolare riferimento alla gestione documentale e al work flow management system. A discrezione del Fornitore, la migrazione potrà essere effettuata a step successivi, dapprima utilizzando procedure automatiche finalizzate ad una prima fase di caricamento dei dati “grezzi”, successivamente con procedure assistite su moli di dati ridotte finalizzate alla loro rifinitura e ai controlli di congruità. In ogni caso:

a) deve essere predisposto un adeguato Piano di Migrazione, già in fase di pianificazione di dettaglio (cfr. § 6.2);

b) deve essere garantita la migrazione di tutti i dati specifici fino ad oggi raccolti; c) devono essere predisposte apposite procedure automatiche per il travaso

delle informazioni dal vecchio al nuovo sistema, da potersi utilizzare in qualsiasi momento e con più iterazioni, anche asincrone;

d) devono essere previsti meccanismi automatici e semi-automatici di validazione dei dati immessi, con capacità di logging, possibilità di verifica e ripetizione della procedura, anche manualmente, per i dati scartati;

e) è necessario garantire la continuità operativa del Sistema, a meno di temporanee interruzioni di servizio (ipotizzabili nei giorni festivi e prefestivi, comunque presegnalate all’utenza), che non influiscano sul corretto utilizzo dei dati;

f) tutte le attività relative alla migrazione dei dati devono essere svolte in modo completamente trasparente all’utenza e senza alcun intervento manuale da parte degli operatori;

g) occorre prestare particolare attenzione alla verifica delle risultanze di tale attività di migrazione, in modo da minimizzare eventuali errori e perdite di informazioni. A tale scopo si suggerisce di effettuare tale attività in via preliminare su un campione ridotto di dati opportunamente selezionato; solo una volta garantito il risultato le procedure identificate potranno essere applicate a tutti i dati.




5.1.3 Avvio in esercizio

A maggior garanzia della buona riuscita del progetto, il Fornitore dovrà garantire le prestazioni professionali del proprio personale tecnico che ha contribuito alle fasi di analisi, progettazione, sviluppo e collaudo del Sistema, al fine di affiancare gli utenti operativi e gestori nella delicata fase di avviamento e messa a regime del Sistema stesso.

Tali prestazioni dovranno essere erogate per almeno 2 (mesi) mesi consecutivi a far data dal collaudo finale del sistema, in accordo alla pianificazione proposta e comprenderanno servizi di assistenza, consulenza e affiancamento agli utenti, finalizzati almeno a:

• descrivere le funzionalità delle postazioni operative in dotazione; • affiancare gli utenti operativi per: il supporto al normale utilizzo del Sistema,

la consultazione della manualistica, gli eventuali chiarimenti sui corsi di affiancamento effettuati e sul trasferimento del know-how;

• assistere gli utenti gestori nello svolgimento delle attività sistemistiche e operative necessarie al buon funzionamento del Sistema;

• verificare il corretto funzionamento dei servizi applicativi; • effettuare tempestivamente le necessarie correzioni per gli eventuali

malfunzionamenti; • definire con il Responsabile del Cliente le eventuali personalizzazioni da

implementare; • assicurare il corretto funzionamento e allineamento della banca dati.

Il servizio dovrà essere erogato presso il CRV, con le risorse professionali e relativo impegno in accordo ai profili indicati nella successiva Tabella 16:.

Si evidenzia che, a conclusione di ognuna delle tre fase operative di progetto (vedi § 6.2), è previsto il rilascio in esercizio delle procedure via via collaudate con esito positivo.

Il Fornitore dovrà quindi assicurare che l’apposita struttura del CRV che si occupa della gestione dell’infrastruttura IT, sia messa in grado di ricevere e gestire compiutamente e autonomamente quanto via via rilasciato in esercizio, garantendo quindi, la manualistica necessaria oltre agli strumenti che riterrà opportuno adottare al riguardo.

5.1.4 Assistenza di manutenzione migliorativa, adeguativa e correttiva

Il servizio di manutenzione migliorativa e adeguativa comprende tutti gli interventi volti ad adeguare l’applicazione alle nuove normative o a seguito delle evoluzioni tecnologiche funzionali del sistema o di altre caratteristiche non funzionali (quali, ad esempio, l’usabilità, le prestazioni, etc.).




Il servizio di manutenzione correttiva comprende invece tutti gli interventi volti all’eliminazione dei malfunzionamenti del software applicativo, ovvero al ripristino delle funzionalità previste, a fronte di errori, malfunzionamenti o incongruenze. I malfunzionamenti del software si possono manifestare nelle seguenti forme:

fine anomala dell’elaborazione o della transazione; fine completa dell’elaborazione o della transazione con devianza rispetto ai

risultati attesi; errori o anomalie nelle funzionalità dell’applicazione.

Sono individuati i seguenti livelli di severità dei problemi:

1. anomalia bloccante, se impedisce all’utente l’uso dell’applicazione; 2. anomalia non bloccante, se comporta errori, malfunzionamenti o

incongruenze che non impediscono all’utente l’uso dell’applicazione, ma che ne compromettono il pieno utilizzo.

La priorità di intervento è stabilita dalla severità del problema. Gli interventi di manutenzione migliorativa e adeguativa da realizzare saranno richiesti dal Cliente al Fornitore che dovrà garantire la disponibilità del servizio in tutti i giorni lavorativi dalle ore 8:30 alle 17:30. La richiesta di intervento conterrà la descrizione sintetica delle attività da svolgere ed eventuali elementi di dettaglio utili per completare la descrizione della richiesta e l’indicazione di massima dei tempi entro i quali deve essere completato l’intervento. A seguito della richiesta ricevuta, il Fornitore invierà al Cliente un documento (Piano di intervento migliorativo/adeguativo) contenente la stima e la pianificazione delle attività da svolgere, i tempi di realizzazione dell’intervento, gli eventuali deliverable che dovranno essere prodotti ed i relativi tempi di consegna, nonché i test che intende effettuare per la verifica delle funzionalità richieste. Detto Piano di intervento migliorativo/adeguativo sarà sottoposto all’approvazione del Cliente. In fase di approvazione, il Cliente potrà richiedere di sottoporre a collaudo, prima del rilascio in esercizio, le funzionalità realizzate, avvalendosi dei test effettuati dal Fornitore o procedendo, a suo insindacabile giudizio, all’esecuzione di altre prove. Il Cliente potrà chiedere di apportare modifiche al suddetto piano. Tali modifiche dovranno essere recepite dal Fornitore in una nuova versione del Piano stesso da sottoporre all’approvazione del Cliente entro i cinque giorni solari successivi alla data della richiesta di modifica. A seguito dell’approvazione da parte del Cliente, il Fornitore eseguirà l’intervento richiesto entro i termini definiti nel Piano approvato. Completato l’intervento, il Fornitore invierà al Cliente la comunicazione di chiusura dell’intervento stesso, dando evidenza delle funzionalità e implementazioni applicative realizzate, delle eventuali modifiche e/o adeguamenti effettuati sull’applicazione e sulla relativa




documentazione, dei test eseguiti e del loro esito, e contestualmente, nel caso in cui il Cliente abbia richiesto di sottoporre a collaudo le funzionalità realizzate, comunicherà di essere pronto al collaudo. All’atto della comunicazione di chiusura dell’intervento, il Fornitore consegnerà al Cliente le funzionalità realizzate. Nel caso in cui il Cliente abbia richiesto di sottoporre a collaudo le funzionalità realizzate nell’ambito dell’intervento migliorativo/adeguativo, il Cliente stesso, a seguito della comunicazione di chiusura dell’intervento, procederà al collaudo delle funzionalità realizzate, avvalendosi dei test effettuati dal Fornitore o procedendo, a suo insindacabile giudizio, all’esecuzione di altre prove, dandone preventiva comunicazione al Fornitore. Le operazioni di collaudo, che si svolgeranno in contraddittorio, avranno inizio entro dieci giorni solari dalla comunicazione di chiusura dell’intervento e di “pronti al collaudo” da parte del Fornitore. Al termine del collaudo sarà redatto apposito verbale che dovrà essere sottoscritto dalle parti. In caso di esito negativo del collaudo, ferma restando l’applicazione delle penali previste, lo stesso potrà essere reiterato con le medesime modalità e termini del primo collaudo. Sarà cura del Fornitore richiedere al Cliente, entro i dieci giorni solari successivi alla data del verbale da cui emerge l’esito negativo del collaudo, di convocare una nuova seduta per la ripetizione delle operazioni di collaudo. Sarà obbligo del Fornitore assicurare l’assistenza necessaria al rilascio in esercizio delle funzionalità realizzate. L’avvenuto passaggio in esercizio sarà formalmente comunicato al Fornitore da parte del Cliente. Trimestralmente il Fornitore dovrà procedere alla rendicontazione degli interventi di manutenzione migliorativa/adeguativa effettuati nel trimestre precedente ed inviarla al Cliente, dando evidenza del numero e del tipo di interventi effettuati, dei tempi di completamento degli interventi rispetto alle date previste, dell’esito degli eventuali collaudi e del rispetto dei livelli di servizio definiti. Lo scambio di informazioni tra le parti (la richiesta di intervento migliorativo / adeguativo, il documento contenente la stima della attività da svolgere, la comunicazione di chiusura dell’intervento stesso, con evidenza delle modifiche e/o adeguamenti effettuati sull’applicazione e sulla documentazione, l’eventuale comunicazione di “pronti al collaudo”), potrà avvenire per iscritto, via fax, tramite posta elettronica o con altri idonei strumenti messi a disposizione dal Fornitore. Gli interventi di manutenzione correttiva saranno attivati, a fronte di errori, incongruenze e malfunzionamenti, a seguito di una segnalazione dal Cliente al Fornitore che dovrà predisporre apposito TT (Trouble ticket) contenente la descrizione dettagliata dell’errore e/o anomalia, la data e ora di segnalazione dell’errore e/o anomalia, il livello di severità del problema. Il Fornitore, ricevuta la segnalazione del malfunzionamento, dovrà provvedere, nel rispetto dei livelli di servizio previsti, alla rimozione dell’errore e/o anomalia e, una volta effettuato l’intervento, dovrà far pervenire al Cliente la comunicazione di




risoluzione dell’anomalia, in cui dovranno essere indicati la data e l’ora di chiusura dell’intervento, la descrizione degli interventi effettuati sul software, le eventuali modifiche apportate alla documentazione, i test eseguiti ed il loro esito. Effettuata la modifica correttiva richiesta, il Fornitore procederà alla chiusura del TT e alla consegna al Cliente del software corretto. Sarà obbligo del Fornitore assicurare l’assistenza necessaria al rilascio in esercizio del software corretto. Si precisa che gli interventi di manutenzione correttiva sono da considerarsi senza alcun onere per il Cliente. L’avvenuto passaggio in esercizio sarà formalmente comunicato al Fornitore da parte del Cliente. Lo scambio di informazioni tra le parti (comunicazione di rilevazione errori, previsione di fine intervento, comunicazione di risoluzione anomalia), potrà avvenire per iscritto, telefono, via fax, tramite posta elettronica o con altri idonei strumenti messi a disposizione dal Fornitore. Trimestralmente il Fornitore dovrà produrre ed inviare al Cliente la rendicontazione degli interventi di manutenzione correttiva effettuati nel trimestre precedente, dando evidenza delle anomalie, dei malfunzionamenti e degli errori riscontrati, dei termini di risoluzione osservati distinti a seconda della tipologia di anomalia riscontrata (bloccante, non bloccante), degli interventi chiusi non rispettando i termini e i livelli di servizio definiti. Sia per le anomalie bloccanti sia per quelle non bloccanti, qualora il tempo stimato di risoluzione non rientri nei livelli di servizio previsti, dovrà essere fornita una soluzione temporanea accompagnata dalla pianificazione dell’intervento definitivo. L’eventuale soluzione temporanea dovrà garantire il ripristino delle funzionalità del servizio e dovrà comunque essere eseguita nel rispetto dei livelli di servizio previsti per l’anomalia originaria; delle eventuali soluzioni temporanee eventualmente adottate dovrà essere data evidenza nella rendicontazione periodica. La soluzione definitiva dovrà comunque essere effettuata nel rispetto dei tempi indicati nel TT.

5.1.4.1 Livelli di servizio e penali

Nelle tabelle seguenti sono riepilogati gli adempimenti e i livelli di servizio cui sono correlate, in caso di mancato rispetto dei valori soglia definiti e/o di inadempienza, le relative penali da applicare sui corrispettivi a qualunque titolo dovuti al Fornitore, relativamente al servizio di manutenzione migliorativa, adeguativa e correttiva.




Per i servizi di manutenzione migliorativa e adeguativa N° Adempimento Unità

misura Periodicità rilevazione Penale

Am1 Consegna del Piano di intervento migliorativo / adeguativo entro i termini previsti dal contratto

Giorni solari trimestrale

Per ogni giorno solare di ritardo sarà applicata una penale pari a 200 €

Am2

Consegna delle ver-sioni modificate del Piano di intervento migliorativo / adeguativo entro i termini previsti dal contratto



Am3

Rispetto della data di completamento dell’inter-vento migliorativo / adeguativo, delle attività e dei deliverable previsti nel Piano di intervento migliorativo/adeguativo con comunicazione di chiusura dell’intervento


Per ogni giorno solare di ritardo e per ogni inadempienza contestata sarà applicata una penale pari a 200 €

Am4 Superamento con esito positivo del collaudo, laddove richiesto

n.a. n.a.

Nel caso in cui non venga superato il collaudo, sarà applicata una penale pari a 500 €

Am5 Consegna della rendicon-tazione entro i termini previsti


Per ogni giorno solare di ritardo, sarà applicata una penale pari a 100 €

Per il servizio di manutenzione correttiva

N° Livello di Servizio Unità di misura

Valore soglia

Periodicità di

rilevazione Penale

Ac1

Le anomalie / malfunzionamenti / errori bloccanti de-vono essere ripristi-nati con chiusura del relativo TT entro le 8 ore lavorative suc-cessive alla segnala-zione

Ore lavorative

≤ 8 ore trimestrale

Per ogni ora lavorativa di ritardo rispetto al valore soglia, sarà applicata una penale pari a 200 €

Ac2

Le anomalie / malfunzionamenti / errori non bloccanti devono essere ripris-tinati con chiusura del relativo TT entro le 24 ore lavorative successive alla segna-lazione di anomalia

Ore lavorative

≤ 24 ore trimestrale

Per ogni ora lavorativa di ritardo rispetto al valore soglia, sarà applicata una penale pari a 100 €

Tabella 8: livelli servizio e penali per manutenzione adeguativa/correttiva




5.1.5 Assistenza di manutenzione evolutiva

Il servizio di manutenzione evolutiva comprende le attività di analisi, progettazione, realizzazione e collaudo di nuove componenti e/o funzionalità dell’applicazione di cui al punto 1 dell’oggetto dell’appalto. Gli interventi da realizzare saranno richiesti dal Cliente al Fornitore che dovrà garantire la disponibilità del servizio in tutti i giorni lavorativi dalle ore 8:30 alle 17:30. La richiesta di intervento conterrà la descrizione sintetica delle attività da svolgere ed eventuali elementi di dettaglio utili per completare la descrizione della richiesta e l’indicazione di massima dei tempi entro i quali deve essere completato l’intervento. A seguito della richiesta ricevuta, il Fornitore invierà al Cliente un documento (Piano di intervento evolutivo) contenente i deliverable che dovranno essere prodotti ed i relativi tempi di consegna, la stima e la pianificazione delle attività da svolgere, i tempi di realizzazione dell’intervento, nonché i test che intende effettuare per la verifica delle funzionalità richieste. Detto Piano di intervento evolutivo sarà sottoposto all’approvazione del Cliente. In fase di approvazione, il Cliente potrà richiedere di sottoporre a collaudo, prima del rilascio in esercizio, le funzionalità realizzate, avvalendosi dei test effettuati dal Fornitore o procedendo, a suo insindacabile giudizio, all’esecuzione di altre prove. Il Cliente potrà chiedere di apportare modifiche al suddetto piano. Tali modifiche dovranno essere recepite dal Fornitore in una nuova versione del Piano stesso da sottoporre all’approvazione del Cliente. A seguito dell’approvazione da parte del Cliente, il Fornitore eseguirà l’intervento richiesto entro i termini definiti nel Piano. Completato l’intervento, il Fornitore invierà al Cliente la comunicazione di chiusura dell’intervento stesso, dando evidenza delle funzionalità e implementazioni applicative realizzate, delle eventuali modifiche e/o adeguamenti effettuati sull’applicazione e sulla relativa documentazione, dei test eseguiti e del loro esito, e contestualmente, nel caso in cui il Cliente abbia richiesto di sottoporre a collaudo le funzionalità realizzate, comunicherà di essere pronto al collaudo. All’atto della comunicazione di chiusura dell’intervento, il Fornitore consegnerà al Cliente le funzionalità realizzate. Il Fornitore predisporrà e sottoporrà all’approvazione del Cliente il consuntivo di quanto realizzato la cui verifica potrà essere effettuata all’atto della consegna del software o in sede di collaudo. Il Cliente, completata la verifica con esito positivo, provvederà a comunicare al Fornitore l’approvazione del consuntivo. Nel caso in cui il Cliente abbia richiesto di sottoporre a collaudo le funzionalità realizzate nell’ambito dell’intervento evolutivo, il Cliente stesso, a seguito della comunicazione di chiusura dell’intervento, procederà al collaudo delle funzionalità realizzate, avvalendosi dei test effettuati dal Fornitore o procedendo, a suo insindacabile giudizio, all’esecuzione di altre prove, dandone preventiva comunicazione al Fornitore.




Nel caso in cui il Cliente non l’abbia effettuata in sede di consegna del software, durante le operazioni di collaudo, il Cliente stesso procederà alla verifica di quanto realizzato e, completata la verifica con esito positivo, provvederà a comunicare al Fornitore l’approvazione del consuntivo dei punti funzione. Le operazioni di collaudo si svolgeranno in contraddittorio, a partire dalla comunicazione di chiusura dell’intervento e di “pronti al collaudo” da parte del Fornitore. Al termine del collaudo sarà redatto apposito verbale che dovrà essere sottoscritto dalle parti. In caso di esito positivo del collaudo e previa formale autorizzazione da parte del Cliente al rilascio in esercizio delle funzionalità realizzate nell’ambito dell’intervento evolutivo, sarà obbligo del Fornitore assicurare l’assistenza necessaria al rilascio in esercizio delle funzionalità realizzate. In caso di esito negativo del collaudo, ferma restando l’applicazione delle penali previste, lo stesso potrà essere reiterato con le medesime modalità e termini del primo collaudo. Sarà cura del Fornitore richiedere al Cliente di convocare una nuova seduta per la ripetizione delle operazioni di collaudo. Sarà obbligo del Fornitore assicurare l’assistenza necessaria al rilascio in esercizio delle funzionalità realizzate. L’avvenuto passaggio in esercizio sarà formalmente comunicato al Fornitore da parte del Cliente. Il Fornitore dovrà procedere alla rendicontazione degli interventi di manutenzione evolutiva effettuati nel trimestre precedente ed inviarla al Cliente, dando evidenza del numero e del tipo di interventi effettuati, dei tempi di completamento degli interventi rispetto alle date previste, dell’esito degli eventuali collaudi e del rispetto dei livelli di servizio definiti. Lo scambio di informazioni tra le parti (la richiesta di intervento evolutivo, il documento contenente la stima della attività da svolgere, la comunicazione di chiusura dell’intervento stesso, con evidenza delle modifiche e/o adeguamenti effettuati sull’applicazione e sulla documentazione, l’eventuale comunicazione di “pronti al collaudo”), potrà avvenire per iscritto, via fax, tramite posta elettronica o con altri idonei strumenti messi a disposizione dal Fornitore.

5.1.5.1 Livelli di servizio e penali

Nella tabella seguente sono riepilogati gli adempimenti e i livelli di servizio cui sono correlate, in caso di mancato rispetto dei valori soglia definiti e/o di inadempienza, le relative penali da applicare sui corrispettivi a qualunque titolo dovuti al Fornitore, relativamente al servizio di manutenzione evolutiva. N. Adempimento Unità di

misura Periodicità di

rilevazione Penale

Am6 Consegna del Piano di Giorni trimestrale Per ogni giorno solare di




N. Adempimento Unità di misura

Periodicità di rilevazione Penale

intervento evolutivo entro i termini previsti dal contratto

solari ritardo sarà applicata una penale pari a 200 €

Am7 Consegna delle versioni modificate del Piano di intervento evolutivo entro i termini previsti dal contratto



Am8 Rispetto della data di completamento dell’intervento, delle attività e dei deliverable previsti nel Piano di intervento evolutivo e comunicazione di chiusura dell’intervento


Per ogni giorno solare di ritardo e per ogni inadempienza contestata sarà applicata una penale pari a 200 €

Am9 Superamento con esito positivo del collaudo, laddove richiesto

n.a. n.a.

Nel caso in cui non venga superato il collaudo, sarà applicata una penale pari a 500 €

Am10 Consegna della rendi-contazione entro i termini previsti


Per ogni giorno solare di ritardo, sarà applicata una penale pari a 100 €

Tabella 9: livelli servizio e penali per manutenzione evolutiva

5.2 FORMAZIONE (CORSI E TRAINING ON THE JOB)

Il piano di formazione, che si esplicita nell’erogazione di specifici corsi appositamente progettati e in attività di affiancamento e trasferimento del know-how svolte attraverso il “training on the job”, è finalizzato all’addestramento per l’uso degli applicativi e del Sistema in generale. Tale piano dovrà essere in linea con le tre condizioni essenziali individuate per la buona riuscita del progetto: efficacia dei programmi didattici, pieno coinvolgimento delle varie tipologie di utenza e affiancamento degli utenti nelle fasi di avvio in esercizio del Sistema. Per la buona riuscita del piano formativo dovranno essere garantite le seguenti minime condizioni:

• il numero dei partecipanti per ogni sessione sarà pari a 10 (dieci) utenti; • ogni utente dovrà disporre di proprio materiale didattico e della propria

postazione di lavoro per le attività pratiche (al massimo da condividere con un altro utente);

• lo svolgimento delle attività didattiche sarà articolato di mattina (orientativamente dalle ore 9,00 alle ore 13,00) e di pomeriggio (orientativamente dalle ore 14,30 alle ore 17,30);

• l’organizzazione dei corsi dovrà essere programmata su base settimanale (cinque giorni);




• le attrezzature previste (materiale didattico, lavagna, postazioni di lavoro con sistema installato e quant’altro si riterrà opportuno) dovranno essere a carico del Fornitore;

• la logistica sarà a carico del Cliente che renderà disponibili i locali preventivamente visionati dal Fornitore.

Il piano di addestramento dovrà prevedere la formazione di un consistente gruppo di utenti che potranno, eventualmente, costituire il nucleo idoneo per garantire l’assistenza ad altri utenti, nell’utilizzo degli appositi strumenti forniti. La seguente tabella fornisce le informazioni di dettaglio utili per progettare, erogare e pianificare il miglior piano formativo per l’utenza.

Titolo del corso Num. utenti

Utenti x sessione

Num. sessioni

Giorni x sessione

Seminario di Presentazione del Sistema 30 10 3 1

Introduzione al Sistema 300 10 30 1 Amministrazione sistemistica 10 10 1 5 Utilizzo del DMS 100 10 10 5 Utilizzo del WFMS 200 10 20 3 Utilizzo del Portale 240 10 24 3 Utilizzo del Cruscotto 10 10 1 2 Utilizzo ERP 30 10 3 3

Tabella 10: dimensionamento dei corsi di formazione

Ogni corso proposto il Fornitore dovrà essere presentato secondo la seguente tabella:

Codice Identificativo attribuito al Corso Titolo Titolo del Corso Durata Giorni previsti (in cifre e lettere) Partecipanti Numero di utenti previsti (in cifre e lettere) Sessioni Numero di sessioni previste (in cifre e lettere) Obiettivi Descrivere sinteticamente gli obiettivi che si propone il Corso Contenuti Elencare in dettaglio gli argomenti trattati dal Corso Prerequisiti SI = Codice e titolo del Corso - NO = Nessuno

Tabella 11: schema del corso di formazione




5.3 GARANZIA

Per servizio di Garanzia si intende l’obbligo per il Fornitore di eliminare eventuali anomalie che possano pregiudicare la funzionalità del Sistema nelle sue diverse componenti. Il servizio non dovrà prevedere l’addebito di corrispettivi al Cliente da parte del Fornitore e sarà esteso per almeno 4 (quattro) anni a far data dal rilascio in esercizio del Sistema. Il recapito telefonico del Servizio cui inoltrare la segnalazione dei malfunzionamenti, dovrà essere comunicato dal Fornitore all’inizio della decorrenza del periodo di Garanzia. In caso di serie interruzioni del servizio, dovute a malfunzionamenti, e su richiesta del Cliente, il Fornitore dovrà valutare la possibilità di predisporre un piano di intervento, comprendente anche il sabato e i giorni festivi, al fine di risolvere i problemi nel più breve tempo possibile. La fornitura del servizio di garanzia sarà subordinata al corretto uso di ogni componente del Sistema: non includerà componenti sottoposte a modifiche non espressamente approvate dal Fornitore. Le modifiche al software applicativo, per l'eliminazione di eventuali difetti, dovranno essere effettuate unicamente dal Fornitore o, qualora necessario, da terzi qualificati, rappresentanti il Fornitore, a seguito di preventivo accordo e consenso del Cliente. Qualora risultasse conveniente al fine di ridurre il tempo necessario alla risoluzione dei problemi, e comunque con l'accordo fra le parti, tali modifiche potranno essere effettuate presso le sedi di sviluppo del Fornitore, per essere immediatamente dopo installate presso il Cliente. Il Cliente consentirà l'accesso al personale del Fornitore o da questi autorizzato, e metterà a disposizione di detto personale le apparecchiature e i programmi per tutto il tempo necessario; inoltre fornirà l'assistenza del personale operativo e la disponibilità di luce, energia elettrica e dei beni di consumo occorrenti all'effettuazione delle verifiche necessarie.

5.3.1 Livelli di servizio e penali

Nelle tabelle seguenti sono sintetizzati i livelli di servizio minimi di garanzia, sia per i tempi di intervento (Tabella 12) sia di ripristino (Tabella 13), che dovranno essere previsti per le componenti hardware, software di base e software applicativo. Tali livelli di servizio sono stati formulati tenendo presente che:

a) il periodo di osservazione, ossia l’intervallo di tempo nel quale i livelli di servizio devono essere rispettati, è stato fissato in 3 (tre) mesi;




b) i valori di soglia fissati devono essere intesi come ore durante le quali il servizio è attivo;

c) le componenti hardware sono quelli previsti in sede di offerta; d) gli interventi devono essere effettuati in modalità on site o carry-in; e) in relazione al grado di criticità dei malfunzionamenti, sono stati definiti i

seguenti livelli di gravità dei problemi: 1. l’intero sistema è indisponibile agli utenti, 2. le funzionalità critiche del sistema sono indisponibili agli utenti, 3. le funzionalità non critiche del sistema sono indisponibili agli utenti, 4. le funzionalità non critiche del sistema sono indisponibili ma non c’è

immediato impatto sulla operatività degli utenti.

Componente Livello gravità Valori di soglia Penale

1 2 ore nel 96% dei casi, entro 4 ore nel restante 4%



Hardware, Software di base

e applicativo


0,2%, per ogni punto

percentuale in meno, sul valore contrattuale della

garanzia

Tabella 12: metriche dei tempi di intervento per la garanzia

Componente Livello

gravità Valori di soglia Penale



3 12 ore nel 96% dei casi, entro 24 ore nel 3% dei casi, entro 48 ore nel restante 1%

Hardware, Software di base e

applicativo

4 24 ore nel 96% dei casi, entro 48 ore nel 3% dei casi, entro 96 ore nel restante 1%

0,2%, per ogni punto

percentuale in meno, sul

valore contrattuale

della garanzia

Tabella 13: metriche dei tempi di ripristino per la garanzia

Il livello del servizio di Garanzia relativo a tutti prodotti software di base dovrà inoltre al minimo prevedere le seguenti attività:

• fornitura e installazione delle "patch" (aggiornamenti) correttive rese disponibili sul mercato dai produttori o distributori dei relativi prodotti;

• fornitura e installazione delle versioni più aggiornate dei relativi prodotti rese disponibili sul mercato dai produttori o distributori.




5.4 ELEMENTI QUANTITATIVI DELLE MISURE

In questo paragrafo sono indicati gli elementi minimali di tipo quantitativo per le misure di accompagnamento che il Fornitore dovrà rispettare nella redazione della propria offerta, classificati per Garanzia., Formazione e Servizi. La valutazione dell’offerta in relazione alla Garanzia verrà valutata considerando come elemento quantitativo minimo il valore specificato nella tabella seguente.

Garanzia Per almeno 4 (quattro) anni dopo il collaudo finale

Tabella 14: Garanzia - misure di accompagnamento

In relazione alla Formazione, gli elementi quantitativi minimi specificati nella tabella seguente concorreranno a formare il giudizio sulla bontà dell’offerta tecnica che verrà formulata dal Fornitore.

Formazione Seminario di Presentazione del Sistema 3 sessioni di 1 giorno ciascuna Introduzione al Sistema 30 sessioni di 1 giorno ciascuna Amministrazione sistemistica 1 sessione di 5 giorni ciascuna Utilizzo del DMS 10 sessioni di 5 giorni ciascuna Utilizzo del WFMS 20 sessioni di 3 giorni ciascuna Utilizzo del Portale 24 sessioni di 3 giorni ciascuna Utilizzo del Cruscotto 1 sessioni di 2 giorni ciascuna Utilizzo ERP 3 sessioni di 3 giorni ciascuna

Tabella 15: Formazione – misure di accompagnamento

Ulteriore elemento quantitativo che concorrerà alla valutazione della migliore proposta, in relazione all’erogazione dei Servizi, sarà il numero di giorni/uomo proposti per ciascuna figura professionale prevista nel piano di realizzazione. La proposta dovrà quindi prevedere almeno l’impiego delle seguenti figure professionali:

• Capo Progetto; • Architetto software; • Sistemista/DBA Senior; • Sistemista; • Analista Senior; • Analista; • Programmatore Senior; • Operatore.

A titolo puramente orientativo è di seguito specificato il tipo di impiego previsto per figure quali il Capo Progetto, l’Architetto software, il Sistemista ed il Programmatore Senior.




Figura Professionale Descrizione C

apo

Pro

gett

o

Arc

hit

etto

Sist

emis

ta

Pro

gram

mat

ore

Installazione e configurazione ■ ■ ■ Migrazione dati ■ ■ ■ ■ Avvio in esercizio ■ ■ ■ Assistenza di manutenzione migliorativa, adeguativa, correttiva ■ ■ ■ ■ Assistenza di manutenzione evolutiva ■ ■ ■ ■ Totale Giorni/uomo offerti n n n n

Tabella 16: Servizi - Esempio di misure di accompagnamento




6. REALIZZAZIONE DEL SISTEMA

Questo capitolo è dedicato alla descrizione delle modalità da attuare per la conduzione e la realizzazione del progetto, sia per quanto riguarda i requisiti organizzativi (metodologie, documentazione, pianificazione, controllo e revisione delle attività) sia per il relativo piano di implementazione. Le proposte tecniche contenute nell’offerta del Fornitore dovranno quindi tener conto delle indicazioni e dei confini posti in questo capitolo.

6.1 REQUISITI ORGANIZZATIVI

In questo paragrafo sono definiti i requisiti di natura organizzativa che il Sistema dovrà soddisfare, con particolare riferimento ai seguenti aspetti meglio dettagliati nei relativi paragrafi:

• le metodologie di progetto; • i requisiti di documentazione; • le modalità di pianificazione, controllo e revisione delle attività.

6.1.1 Metodologie di progetto

Il Fornitore è tenuto a dichiarare in fase di offerta la metodologia usata per le fasi di analisi, sviluppo e test del Sistema. Tale metodologia dovrà:

• essere in grado di supportare l’intero ciclo di vita del progetto nelle sue varie articolazioni;

• essere compatibile con gli standard indicati in questo documento e/o riconosciuti a livello internazionale;

• riflettersi in standard documentativi da utilizzarsi per la richiesta documentazione di progetto;

• essere supportata, nelle varie fasi di analisi, disegno, sviluppo, test e collaudo, mediante appositi strumenti automatici.

Il Fornitore è tenuto altresì a dichiarare in fase di offerta i tool di supporto che intende utilizzare per tutto il ciclo di vita del progetto, sebbene non ne sia obbligatoria la fornitura. Si sottolinea che tali tool dovranno essere utilizzati per le fasi di sviluppo e per tutte le attività di test (unitari, funzionali, di integrazione e di sistema) del software applicativo; l’output dovrà costituire parte integrante della documentazione di test e sarà valutato durante le sessioni di collaudo.




Per quanto riguarda le attività di test, il tool dovrà:

• consentire la creazione di casi di test che, in maniera semplice ed efficace, siano in grado di “stimolare” il Sistema simulando massicci accessi multi utente mirati alla esecuzione di singole funzionalità applicative (stress test), nonché accessi contemporanei eterogenei (load test) tali da riprodurre, in base a calcoli statistici, uno scenario operativo reale;

• generare, per ciascun caso di test, uno script implementato in un linguaggio standard di larga diffusione, che consenta la personalizzazione dello scenario simulato;

• consentire la parametrizzazione dei casi di test, utilizzando un repository dal quale prelevare le informazioni di input/output correlate a ciascun utente simulato;

• rendere disponibili le informazioni relative all’esecuzione dei test, generando diverse tipologie di report personalizzabili contenenti indicazioni in merito al tipo di scenario, di test eseguito e ai risultati (performance) misurati.

6.1.2 Requisiti di documentazione

Per tutta la durata del Contratto si prevede il rilascio di documentazione esplicativa delle varie fasi di sviluppo del Sistema, che sarà utilizzata come riscontro delle attività svolte. Tutta la documentazione dovrà essere redatta in lingua italiana. Tale documentazione, che dovrà essere costantemente aggiornata da parte del Fornitore e messa a disposizione del Cliente in formato cartaceo ed elettronico (word e pdf), prevede i seguenti documenti nelle quantità previste nella tabella successiva.

1. Piano esecutivo di Progetto; 2. Piano della Qualità; 3. Manualistica tecnica come sintetizzato nella seguente Tabella 17.




Titolo documento

Consegna al termine della

fase di Contenuto

Disegno Funzionale

Consolidamento analisi funzionale

Consolida i requisiti funzionali che il Sistema dovrà supportare, vedi R[2], descrivendo quindi i dati e le funzioni automatizzate, nonché i relativi modelli concettuale e logico.

Disegno Tecnico Analisi tecnica

Definisce l’architettura generale del Sistema e quella di dettaglio relativa alla banca dati (disegno fisico), alle funzioni, ai processi, alle interfacce uomo-macchina. Tale disegno dovrà essere fornito sia di livello più generale che ad un livello di dettaglio spinto.

Messa in Esercizio

Verifica, Test e Collaudo

Documenta gli archivi di prova, i test effettuati (singoli e di integrazione), i programmi (listati e supporti magnetici). Definisce le attività operative per la messa in esercizio del Sistema.

Manuale Generale

Avvio in Esercizio

Descrive il Sistema in tutti le sue componenti hardware, software, procedure applicative e le relative procedure di installazione e gestione.

Manuale Utente

Avvio in Esercizio,

Formazione

Descrive i passi operativi per l’interazione con le procedure applicative realizzate.

Tabella 17: manualistica tecnica

Per ognuno dei suddetti manuali il Fornitore dovrà descrivere, in sede di offerta, l’indice degli argomenti che in esso saranno trattati.

6.1.3 Modalità di pianificazione, controllo e revisione

Il presente paragrafo descrive gli aspetti organizzativi che dovranno essere approntati durante lo svolgimento delle attività contrattuali. In particolare, sono dettagliati:

• l’organizzazione del Cliente e del Fornitore; • i rapporti tra Cliente e Fornitore; • le interazioni nel progetto per le fasi di:

pianificazione; disegno dell’applicazione; accettazione e collaudo; avviamento; garanzia.

Organizzazione del Cliente e del Fornitore

A garanzia del coordinamento delle attività di controllo, il Cliente provvederà a nominare un Responsabile di progetto, coadiuvato da un’apposita struttura organizzativa, per la gestione dei rapporti con il Fornitore, avente funzioni di interfaccia per il rispetto delle esigenze e delle priorità del Cliente, nonché per la supervisione e la verifica dell’avanzamento della fornitura nelle sue diverse fasi.




A sua volta, il Fornitore, all’atto della stipula del Contratto, dovrà nominare il proprio Responsabile cui affidare la responsabilità di tutte le attività inerenti la fornitura e la realizzazione del Sistema. Si evidenzia che il Cliente si impegna a mettere a disposizione del Fornitore unicamente un locale di circa 50 mq. presso una delle sedi del CRV, attrezzato con alimentazione elettrica, punti rete, tavoli e sedie. Il soddisfacimento di ogni altra esigenza logistica è cura e responsabilità esclusiva del Fornitore.

Rapporti tra Cliente e Fornitore

Tutte le comunicazioni ufficiali del Fornitore, in merito alla fornitura e alla realizzazione del Sistema, dovranno essere indirizzate al Responsabile del Cliente, ed eventualmente a terzi da quest’ultimo indicati. Parimenti, tutte le comunicazioni ufficiali del Cliente, in merito alla fornitura e alla realizzazione del Sistema, dovranno essere indirizzate al Responsabile del Fornitore.

Interazioni nel progetto

Il presente appalto, dovendo prevedere la realizzazione di un sistema completo e integrato (oltre alle attività di gestione e manutenzione dello stesso), dovrà necessariamente essere suddiviso in fasi progettuali. Al fine di garantire il rispetto dei tempi contrattuali e il pieno soddisfacimento dei prodotti rilasciati all’utenza, nel seguito sono quindi evidenziate sia le attività progettuali più rilevanti di interazione tra Cliente e Fornitore durante la realizzazione dei vari componenti, sia le attività critiche di avvio e messa in esercizio del Sistema. Non sono perciò descritte le attività di assistenza di manutenzione (erogate a consumo) e le attività progettuali intermedie, come ad esempio lo sviluppo delle applicazioni, che potranno variare in funzione della metodologia adottata dal Fornitore sulla base di quanto proposto in sede di offerta. La conclusione delle seguenti attività progettuali, dovrà essere notificata in forma scritta insieme all’eventuale consegna dei prodotti previsti nella fase stessa:

• pianificazione di dettaglio; • disegno; • accettazione e collaudo; • avviamento; • garanzia.

Per ognuna delle suddette fasi dovranno essere previste le condizioni per iniziare, le attività da svolgere e le condizioni per finire.




Pianificazione di dettaglio

Condizioni per iniziare Presa d’atto dei documenti Contrattuali e dell’offerta del Fornitore, con particolare riferimento alla relativa pianificazione generale di progetto presentata.

Attività da svolgere Definizione degli strumenti e adattamento della metodologia agli strumenti prescelti;

Definizione degli standard di codifica e disegno; Definizione dei formalismi previsti dai requisiti di

documentazione; Consolidamento dei requisiti, delle esigenze e degli obiettivi del

Sistema; Stesura definitiva del Piano esecutivo di Progetto e di Qualità.

Condizioni per finire Accettazione dei prodotti previsti nella fase.

Disegno

Condizioni per iniziare Accettazione dei prodotti previsti nella precedente fase. Attività da svolgere Consolidamento dell’analisi dei dati e dei processi del Sistema;

Adozione dei formalismi previsti dai requisiti di documentazione;

Realizzazione dell’analisi tecnica di dettaglio; Realizzazione del Piano dei Test funzionali; Realizzazione dei Piani di Collaudo intermedi e generale; Progettazione e sviluppo delle Applicazioni.


Accettazione e collaudo

Condizioni per iniziare Accettazione dei prodotti previsti nella precedente fase. Attività da svolgere Descrizioni degli aspetti generali

Il Cliente nominerà una Commissione incaricata dell’effettuazione del collaudo complessivo del Sistema e della stesura dei relativi verbali. Tale collaudo, che sarà effettuato sull’ambiente di pre-esercizio presso il CRV opportunamente configurato dal Fornitore, dovrà essere preceduto dalle fasi di test unitari di “laboratorio” e dalla relativa accettazione provvisoria di ogni componente rilasciata. I test unitari di “laboratorio” dovranno essere effettuati in ambiente simulato sulla base dell’apposita specifica di test redatta dal Fornitore e accettata dal Cliente; questa fase di test dovrà consentire la verifica della rispondenza dell’applicazione ai requisiti con particolare attenzione all’interfaccia utente e le performance in termini di rispetto dei tempi di risposta previsti. Il collaudo complessivo del Sistema sarà eseguito dall’apposita Commissione entro un mese dalla data di disponibilità al collaudo comunicata dal Fornitore e si svolgerà in accordo a quanto specificato nel Piano di Collaudo generale, comprendendo almeno le seguenti attività: verifica delle componenti hw/sw di base almeno in termini di:

– conformità a quello previsto in offerta, – condizioni di funzionamento, – funzionalità del software di base.

esecuzione dei test di collaudo del software applicativo secondo specifica di test e loro rispondenza nei termini funzionali e




prestazionali, da effettuarsi su ogni componente di integrazione tra i vari sottosistemi già accettati provvisoriamente,

verifica dell’avvenuta esecuzione di tutte le attività previste. Condizioni per finire Accettazione dei prodotti previsti nella fase.

I collaudi s’intenderanno ad esito positivo per effetto del superamento di tutte le prove previste. In caso di collaudo negativo il Fornitore sarà tenuto a rimuovere le cause ostative riscontrate, fermo restando gli altri vincoli e le penali previste nel Contratto.

Avviamento

Condizioni per iniziare Accettazione dei prodotti previsti nella precedente fase. Attività da svolgere Dovranno essere previsti i necessari servizi relativi alle attività di

roll out per ogni specifica fase operativa di progetto fino all’avvio generale del Sistema così come specificato nel relativo paragrafo di questo documento.

Nota bene: al momento del passaggio in esercizio dei servizi previsti in una fase, deve esserne garantita la coesistenza con i servizi presenti nell’attuale sistema (ad esempio, il nuovo documentale previsto in fase 1 deve essere in grado di alimentare il “vecchio Portale” fino a quando quest’ultimo verrà sostituito da quello rilasciato in fase 2).


Garanzia

Condizioni per iniziare Accettazione del componente collaudato. Attività da svolgere Per servizio di Garanzia si intende l’obbligo per il Fornitore di

eliminare eventuali anomalie che possono pregiudicare la funzionalità del Sistema nelle sue diverse componenti così come specificato nel relativo paragrafo di questo documento.


6.2 PIANO DI IMPLEMENTAZIONE

Con riferimento a quanto definito nei precedenti § 4, 5 e 6.1, il piano di implementazione dovrà tenere conto delle indicazioni di seguito elencate.

L’intera fornitura sarà suddivisa in 4 (quattro) Fasi (1 di pianificazione e 3 operative), ognuna con le relative attività, ed avrà una durata complessiva non superiore a 30 (trenta) mesi, come di seguito specificato (t0 = inizio progetto):

Fase 0 – Pianificazione di dettaglio : t0 + 6 mesi; Fase 1 – Strumenti di back end : tre mesi prima di fine Fase 0 + 12 mesi; Fase 2 – Strumenti di front end : tre mesi prima di fine Fase 1 + 12 mesi; Fase 3 – Gestione risorse : tre mesi prima di fine Fase 2 + 9 mesi.

Le attività di formazione e di manutenzione sono distribuite nelle varie fasi operative.

Al termine di ciascun fase è prevista una sessione di collaudo, con relativo pagamento del corrispettivo collaudato con esito positivo.




Nella successiva Figura 6: è rappresentata la suddivisione delle 3 fasi operative, mentre nella Tabella 18 sono riepilogate le macro attività previste in ogni fase che il Fornitore avrò cura di dettagliare nella presentazione della propria offerta tecnica.

Figura 6: fasi di realizzazione

Nella seguente Tabella 18 è sintetizzato il piano di implementazione previsto che il Fornitore dovrà ulteriormente dettagliare in accordo a quanto proposto in sede di offerta tecnica.




ID Nome e descrizione attività Prodotti e documenti rilasciati

F0 Fase 0 – Pianificazione di dettaglio

A00 Definizione degli strumenti, degli standard di codifica e disegno, nonché dei formalismi documentativi

-----

A01 Adattamento della metodologia agli strumenti prescelti -----

A02 Consolidamento dei requisiti, delle esigenze e degli obiettivi del Sistema, nonché del piano di approvvigionamento dei beni

Piano di approvvigionamento dei beni hardware e software di base

A03 Stesura definitiva del Piano esecutivo di Progetto e di Qualità

Piano esecutivo di progetto Piano di qualità

A04 Consolidamento dell’analisi dei dati e dei processi del Sistema Analisi funzionale

A05 Progettazione e realizzazione del disegno tecnico di dettaglio

Piano di migrazione dati Architettura di dettaglio Disegno logico/fisico Banca Dati Analisi tecnica (applicazioni e interfacce)

A06 Progettazione e realizzazione del piano dei test funzionali Piano dei Test funzionali

A07 Progettazione e realizzazione dei piani di collaudo intermedi e finale

Piani di collaudo intermedi (per 4 fasi) Piano di collaudo finale

A08 Acquisto dei beni Componenti hardware e software di baseC0 1° Collaudo intermedio Verbale di Collaudo per Fase 0

F1 Fase 1 – Strumenti di back end

A10 Sviluppo dei servizi di orchestrazione: componente “gestione flussi procedurali”

Manuale utente (versione beta) per i servizi di A10

A11 Roll out di A10 Codice sorgente di A10 e Migrazione dati

A12 Sviluppo dei servizi applicativi: componenti “gestione documentale” e “strumenti di collaborazione”


A13 Roll out di A12 Codice sorgente di A12, Migrazione dati e Parallelo

A14 Sviluppo dei servizi di sicurezza: componente “gestione accessi”


A15 Roll out di A14

Codice sorgente di A14, Migrazione Dati; Manuale generale relativo agli strumenti di back end

C1 2° Collaudo intermedio Verbale di Collaudo per Fase 1 (comprensivo dei test effettuati)

T1 Svolgimento dei corsi di formazione e training on the job per i servizi di fase 1 Attestato di partecipazione

M1

Erogazione dei relativi servizi a corpo (manutenzione correttiva, migliorativa, adeguativa) e a consumo (manutenzione evolutiva)

Trouble Ticket Piano di intervento miglior./adeguativo Piano di intervento evolutivo Codice sorgente, versione xx Manuali utenti aggiornati

G1 Garanzia Fase 1 Erogazione dei servizi di garanzia per componenti di Fase 1




F2 Fase 2 – Strumenti di front end

A20 Sviluppo dei servizi di presentazione: componente “portale”


A21 Roll out di A20 Codice sorgente di A20 e Migrazione Dati

A22 Sviluppo dei servizi applicativi: componenti “cruscotto”, “partner” e “firma digitale”


A23 Roll out di A22 Codice sorgente di A22 e Migrazione dati Manuale generale degli strumenti di front end



M2


Trouble ticket Piano di intervento miglior./adeguativo Piano di intervento evolutivo Codice sorgente, versione xx Manuali utenti aggiornati





F3 Fase 3 – Gestione risorse A30 Sviluppo dei servizi applicativi:

componente “gestione risorse” Manuale utente (versione beta) per i servizi di A30


A32 Sviluppo/integrazione dei servizi multicanale Manuale utente (versione beta) per i servizi di A32


A34 Sviluppo/integrazione dei servizi gestione IT Manuale utente (versione beta) per i servizi di A34

A35 Roll out di A34 Codice sorgente di A34 e Migrazione dati Manuale generali per gestione risorse



M3


Trouble ticket Piano di intervento miglior./adeguativo Piano di intervento evolutivo Codice sorgente, versione xx Manuali utenti aggiornati


C4 Collaudo finale Verbale di Collaudo finale (comprensivo dei test effettuati)

A36 Avvio in esercizio del Sistema Manuale generale Manuali utenti

GF Garanzia minima per 4 anni

Tabella 18: sintesi del piano di implementazione

6.2.1 Piano di progetto

Nella figura seguente è rappresentato un’ipotesi di piano di progetto in cui si suppone che l’avvio avvenga indicativamente al 1° gennaio 2009 per concludersi, al massimo dopo 30 mesi, il 30 giugno 2011, ad esclusione dei servizi di garanzia richiesti per almeno 4 (quattro) anni a far data dal rilascio in esercizio dell’intera fornitura. Nei suddetti 30 mesi sono previste le attività delle 4 fasi di progetto e di avvio in esercizio del Sistema che non dovrà essere inferiore a 2 (due) mesi. Sulla base delle indicazioni riportate in tale diagramma, il Fornitore avrà cura di dettagliare il piano che intende proporre nel rispetto di tutti i vincoli e requisiti definiti in questo documento.


Sistema Informativo dell’Assemblea Regionale

Capitolato Tecnico


Figura 7: Gantt di progetto

capitolato rif1 def1 · all’interno di un repository di informazioni. OO Object Oriented ......

Documents

Transcript of capitolato rif1 def1 · all’interno di un repository di informazioni. OO Object Oriented ......