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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 3 di 56
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 4 di 56
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 5 di 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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 6 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 7 di 56
Acronimo Abbrev.ne Significato Descrizione
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).
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 8 di 56
Acronimo Abbrev.ne Significato Descrizione
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 9 di 56
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;
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 10 di 56
• 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;
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 11 di 56
• 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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 12 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 13 di 56
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);
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 14 di 56
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).
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 15 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 16 di 56
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].
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 17 di 56
Figura 2: infrastruttura e servizi applicativi
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 18 di 56
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:
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 19 di 56
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].
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 20 di 56
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 21 di 56
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 22 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 23 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 24 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 25 di 56
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 26 di 56
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 27 di 56
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;
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 28 di 56
• 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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 29 di 56
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 30 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 31 di 56
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 32 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 33 di 56
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.).
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 34 di 56
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 35 di 56
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 36 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 37 di 56
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
Giorni solari trimestrale
Per ogni giorno solare di ritardo sarà applicata una penale pari a 200 €
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
Giorni solari trimestrale
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
Giorni solari trimestrale
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 38 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 39 di 56
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 40 di 56
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
Giorni solari trimestrale
Per ogni giorno solare di ritardo sarà applicata una penale pari a 200 €
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
Giorni solari trimestrale
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
Giorni solari trimestrale
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);
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 41 di 56
• 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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 42 di 56
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;
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 43 di 56
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%
2 3 ore nel 96% dei casi, entro 6 ore nel restante 4%
3 4 ore nel 96% dei casi, entro 8 ore nel restante 4%
Hardware, Software di base
e applicativo
4 8 ore nel 96% dei casi, entro 12 ore nel restante 4%
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
1 4 ore nel 96% dei casi, entro 8 ore nel restante 4%
2 6 ore nel 96% dei casi, entro 12 ore nel restante 4%
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 44 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 45 di 56
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 46 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 47 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 48 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 49 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 50 di 56
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.
Condizioni per finire Accettazione dei prodotti previsti nella fase.
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 51 di 56
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).
Condizioni per finire Accettazione dei prodotti previsti nella fase.
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.
Condizioni per finire Accettazione dei prodotti previsti nella fase.
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 52 di 56
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.
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 53 di 56
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”
Manuale utente (versione beta) per i servizi di A12
A13 Roll out di A12 Codice sorgente di A12, Migrazione dati e Parallelo
A14 Sviluppo dei servizi di sicurezza: componente “gestione accessi”
Manuale utente (versione beta) per i servizi di A14
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
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 54 di 56
F2 Fase 2 – Strumenti di front end
A20 Sviluppo dei servizi di presentazione: componente “portale”
Manuale utente (versione beta) per i servizi di A20
A21 Roll out di A20 Codice sorgente di A20 e Migrazione Dati
A22 Sviluppo dei servizi applicativi: componenti “cruscotto”, “partner” e “firma digitale”
Manuale utente (versione beta) per i servizi di A22
A23 Roll out di A22 Codice sorgente di A22 e Migrazione dati Manuale generale degli strumenti di front end
C2 3° Collaudo intermedio Verbale di Collaudo per Fase 2 (comprensivo dei test effettuati)
T2 Svolgimento dei corsi di formazione e training on the job per i servizi di fase 2 Attestato di partecipazione
M2
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
G2 Garanzia Fase 2 Erogazione dei servizi di garanzia per componenti di Fase 2
Sviluppo e ammodernamento del
Sistema Informativo dell’Assemblea regionale
Capitolato Tecnico pag. 55 di 56
F3 Fase 3 – Gestione risorse A30 Sviluppo dei servizi applicativi:
componente “gestione risorse” Manuale utente (versione beta) per i servizi di A30
A31 Roll out di A30 Codice sorgente di A30 e Migrazione Dati
A32 Sviluppo/integrazione dei servizi multicanale Manuale utente (versione beta) per i servizi di A32
A33 Roll out di A32 Codice sorgente di A32 e Migrazione Dati
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
C3 4° Collaudo intermedio Verbale di Collaudo per Fase 3 (comprensivo dei test effettuati)
T3 Svolgimento dei corsi di formazione e training on the job per i servizi di fase 3 Attestato di partecipazione
M3
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
G3 Garanzia Fase 3 Erogazione dei servizi di garanzia per componenti di Fase 3
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.