Disciplinare Tecnico - Provincia di Benevento
Transcript
Disciplinare Tecnico - Provincia di Benevento
DISCIPLINARE TECNICO Procedura aperta per la fornitura di beni e servizi hardware e software per la realizzazione del sistema di protocollo elettronico e del sistema di gestione documentale informatizzata degli atti deliberativi ed amministrativi della Provincia di Benevento 1 Indice 1. Premessa...........................................................................................................................................3 1.1 Riferimenti Legislativi ...............................................................................................................4 1.1.1. Dematerializzazione...........................................................................................................4 1.1.2. Protocollo Informatico .......................................................................................................5 1.1.3. Gestione Flussi Documentali .............................................................................................6 1.1.4. Conservazione Documenti Informatici ..............................................................................6 1.1.5. Accessibilità .......................................................................................................................7 2. Oggetto della Fornitura ....................................................................................................................8 3. Descrizione delle Preesistenze .......................................................................................................11 3.1 Infrastruttura di rete .................................................................................................................11 3.2 Macchine di classe server ........................................................................................................12 3.3 Applicativi Riusabili ................................................................................................................14 3.3.1 Protocollo informatico - EGrammata................................................................................14 3.3.2 DDD - Delibere Decreti Determine - E-Praxi...................................................................14 3.4 Archivio atti pregressi..............................................................................................................15 4. Requisiti Funzionali del Software..................................................................................................17 4.1 Funzioni Utente Esterno...........................................................................................................18 4.2 Funzioni Operatore Protocollo.................................................................................................19 4.3 Funzioni Operatore Ente ..........................................................................................................20 4.4 Funzioni Operatore Archiviazione documenti.........................................................................21 4.5 Funzioni Amministrazione.......................................................................................................22 4.6 Protocollazione.........................................................................................................................22 4.7 Delibere....................................................................................................................................23 4.8 Determinazioni.........................................................................................................................25 4.9 Digitalizzazione .......................................................................................................................26 5. Componenti principali dell'architettura..........................................................................................28 5.1 Portale applicativo....................................................................................................................28 5.2 Document Management ...........................................................................................................29 5.3 Workflow Mangement .............................................................................................................31 5.4 Help Desk.................................................................................................................................33 6. Requisiti non Funzionali ................................................................................................................35 6.1 Sicurezza ..................................................................................................................................35 6.1.1 Infrastruttura di rete ..........................................................................................................35 6.1.2 Infrastruttura software.......................................................................................................35 6.1.3 Applicazioni ......................................................................................................................36 6.2 Scalabilità.................................................................................................................................37 6.3 Estendibilità .............................................................................................................................37 7. Fornitura hardware.........................................................................................................................39 8. Disposizioni Finali .........................................................................................................................41 2 1. Premessa La Provincia di Benevento intende realizzare un sistema informativo per la gestione digitale degli atti amministrativi e deliberativi con i seguenti obiettivi: • migliorare la qualità dei servizi finali erogati a cittadini ed imprese e ad altri enti locali; • garantire la trasparenza amministrativa; • riorganizzare e ottimizzare il processo di back-office interno all’Ente; • garantire servizi di interoperabilità con gli altri enti. Per quanto concerne gli atti amministrativi, il sistema dovrà prevedere la centralizzazione del protocollo informatico secondo quanto decretato dal DPR 445/2000 consentendo: • ai vari settori della Provincia di protocollare la documentazione in entrata ed uscita direttamente dai propri centri operativi e seguire il processo amministrativo legato a ciascuna pratica istruita; • ai cittadini ed alle imprese di raggiungere direttamente le informazioni di interesse presso i settori amministrativi competenti nell’ottica della piena trasparenza degli atti. Il sistema dovrà inoltre offrire la possibilità di mappare ogni processo amministrativo nei suoi passaggi fondamentali per consentire il controllo dell’avanzamento di una qualsivoglia pratica.. Per quanto concerne gli atti deliberativi, il sistema dovrà coprire interamente il ciclo di formazione, gestione e pubblicazione sia degli atti di indirizzo politico (Delibere di Consiglio e di Giunta) sia dei successivi atti di gestione operativa (Determine Dirigenziali e relativi allegati), garantendo la piena trasparenza dell’azione amministrativa. Il presente documento costituisce il Disciplinare Tecnico per la fornitura del sistema informativo per la gestione digitale degli atti amministrativi e deliberativi della Provincia di Benevento sopra descritto. La fornitura dovrà comprendere sia gli applicativi software sia l’hardware necessario per la piena funzionalità del sistema, come dettagliato nelle sezioni seguenti. 3 Tale fornitura è parte integrante del progetto GIADA – “Gestione Informatizzata degli Atti Deliberativi e Amministrativi”, finanziato dalla Regione Campania (Ob. Operativo 5.1 eGovernment ed eInclusion FESR 2007-2013). 1.1 Riferimenti Legislativi La legge sulla trasparenza amministrativa (Legge 241/90), insieme alla validità giuridica del documento elettronico sancita dalla Legge 59/1997, ha dato l’avvio ad una radicale rivoluzione digitale nella Pubblica Amministrazione. Tale rivoluzione trova il suo fondamento legislativo in una serie di norme che regolano la dematerializzazione, il protocollo informatico, la gestione dei flussi documentali, la conservazione dei documenti informativi, e l’accessibilità. Nel seguito si richiamano le principali norme che costituiscono il quadro legislativo cui dovrà uniformarsi la fornitura in oggetto. Il riferimento principale è sicuramente il Codice dell'Amministrazione Digitale, emanato con Decreto legislativo del 7 marzo 2005, n. 82, e pubblicato sulla Gazzetta ufficiale n. 112 del 16 maggio 2005. Il Codice ha lo scopo di assicurare e regolare la disponibilità, la gestione, l’accesso, la trasmissione, la conservazione e la fruibilità dell’informazione in modo digitale utilizzando con le modalità più appropriate le tecnologie dell’informazione e della comunicazione all'interno della pubblica amministrazione e nei rapporti tra amministrazioni, cittadini ed imprese. La seduta del Consiglio dei Ministri del 19 Febbraio 2010 ha approvato un Decreto Legge che definisce il nuovo Codice dell’Amministrazione Digitale, in attuazione dei criteri di delega contenuti nell’articolo 33 della legge n. 69 del 2009. 1.1.1. Dematerializzzione Il termine “dematerializzazione” identifica il processo di sostituzione della documentazione amministrativa, solitamente cartacea, in favore del documento informatico. Nell’ultimo decennio il termine è entrato nel lessico della gestione documentale e nella normativa, che gli ha conferito pieno valore giuridico. Di seguito si richiamano le principali norme in materia: 4 • Deliberazione CNIPA 19 febbraio 2004, n. 11, recante le regole tecniche per la riproduzione e conservazione di documenti su supporto ottico idoneo a garantire la conformità dei documenti agli originali • Decreto del Presidente del Consiglio dei Ministri 13 gennaio 2004 - “Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la validazione, anche temporale, dei documenti informatici.” • Codice dei beni culturali e del paesaggio (D. lgs. 22 gennaio 2004, n. 42) • Testo unico delle disposizioni legislative e regolamentari in materia di documentazione amministrativa (DPR 28 dicembre 2000, n. 445) 1.1.2. Protocollo Informatico Il Legislatore (DPR 445/2000, artt.1) definisce il protocollo informatico come “l'insieme delle risorse di calcolo, degli apparati, delle reti di comunicazione e delle procedure informatiche utilizzati dalle amministrazioni per la gestione dei documenti”, ovvero tutte le risorse tecnologiche necessarie alla realizzazione di un sistema automatico per la gestione elettronica dei flussi documentali. Segue la normativa di riferimento: • Direttiva del Ministro per l’innovazione e le tecnologie 4 gennaio 2005, punto 2 - “Linee guida in materia di digitalizzazione dell’amministrazione.” • Direttiva del Ministro per l’innovazione e le tecnologie 18 dicembre 2003, punto 3, lett. c) - “Linee guida in materia di digitalizzazione dell’amministrazione per l’anno 2004.” • Circolare AIPA 21 giugno 2001, n. 31 - "Art. 7, comma 6, del decreto del Presidente del Consiglio dei Ministri del 31 ottobre 2000, recante 'Regole tecniche per il protocollo informatico di cui al decreto del Presidente della Repubblica 20 ottobre 1998, n. 428'Requisiti minimi di sicurezza dei sistemi operativi disponibili commercialmente." • Circolare AIPA 7 maggio 2001, n. 28 - “Art. 18, comma 2, del decreto del Presidente del Consiglio dei Ministri 31 ottobre 2000, pubblicato nella Gazzetta Ufficiale 21 novembre 2000, n. 272, recante regole tecniche per il protocollo informatico di cui al decreto del Presidente della Repubblica 28 dicembre 2000, n. 445 - Standard, modalità di trasmissione, formato e definizioni dei tipi di informazioni minime ed accessorie comunemente scambiate tra le pubbliche amministrazioni e associate ai documenti protocollati.” 5 • Decreto del Presidente della Repubblica 28 dicembre 2000 n. 445 “Testo unico delle disposizioni legislative e regolamentari in materia di documentazione amministrativa.” • Decreto del Presidente del Consiglio dei Ministri 31 ottobre 2000 - “Regole tecniche per il protocollo informatico di cui al decreto del Presidente della Repubblica 20 ottobre 1998, n. 428.” • Legge 15 marzo 1997, n. 59, art. 15, comma 2 - “Delega al Governo per il conferimento di funzioni e compiti alle regioni ed enti locali, per la riforma della Pubblica Amministrazione e per la semplificazione amministrativa.” 1.1.3. Gestione Flussi Documentali I sistemi di gestione dei flussi documentali coordinano tutte le operazioni che riguardano l’elaborazione e la trasmissione dei documenti, specificando le attività ed i ruoli di tutti gli appartenenti al processo di lavoro. Un tale sistema segue un documento durante tutto il suo ciclo di vita, fornendo un’azione di controllo costante per il suo trattamento. I principali riferimenti normativi sono: • Direttiva del Ministro per l’innovazione e le tecnologie 9 dicembre 2002 - “Trasparenza dell’azione amministrativa e gestione elettronica dei flussi documentali.” • Direttiva del Ministro per l’innovazione e le tecnologie 21 dicembre 2001 - “Linee guida in materia di digitalizzazione dell’amministrazione.” • Decreto del Presidente della Repubblica 28 dicembre 2000, n. 445 - “Testo unico delle disposizioni legislative e regolamentari in materia di documentazione amministrativa (Testo A).” • Direttiva del Presidente del Consiglio dei Ministri 28 ottobre 1999 - “Gestione informatica dei flussi documentali nelle pubbliche amministrazioni.” 1.1.4. Conservazione Documenti Informatici Come richiamato in precedenza, la Legge 59/1997 riconosce per la prima volta piena validità giuridica al documento informatico; successive modifiche ed integrazioni hanno poi puntualizzato il concetto, stabilendo che il documento informatico ha efficacia probatoria, ma la provenienza delle dichiarazioni ivi contenute è provata solo se sottoscritto con firma digitale ed è prodotto secondo specifiche prescrizioni tecniche. Le caratteristiche principali di un documento informatico valido, 6 sono l'immodificabilità e la leggibilità nel tempo, indipendentemente dal software utilizzato per produrlo. Seguono i principali riferimenti normativi: • Decreto legislativo 22 gennaio 2004 - “Codice dei beni culturali e del paesaggio, ai sensi dell’articolo 10 della legge 6 luglio 2002, n. 137.” • Decreto del Presidente del Consiglio dei Ministri 13 gennaio 2004 - “Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione e la validazione, anche temporale, dei documenti informatici.” 1.1.5. Accessibilità Il termine accessibilità fa riferimento alla possibilità di rendere fruibili i contenuti e servizi dei siti Web ad utenti disabili o con dotazioni tecnologiche ristrette. Il riferimento normativo principale per la costruzione di siti accessibili è la cosiddetta legge Stanca (Legge n. 4 del 2004 - “Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici.”) cui fanno seguito due decreti attuativi: • Decreto del Ministro per l’innovazione e le tecnologie 8 luglio 2005 - “Requisiti tecnici e i diversi livelli per l’accessibilità agli strumenti informatici.” • Decreto del Presidente della Repubblica 1 marzo 2005, n. 75 - “Regolamento di attuazione della legge 9 gennaio 2004, n. 4 per favorire l’accesso dei soggetti disabili agli strumenti informatici.” 7 2. Oggetto della Fornitura Il presente documento costituisce il Disciplinare Tecnico per la fornitura “chiavi in mano” del sistema di gestione documentale e del protocollo informatico della Provincia di Benevento. La fornitura comprende: • l’analisi, la modellazione e l’ottimizzazione dei flussi documentali relativi agli atti amministrativi e deliberativi dell’Ente Provincia di Benevento; • la progettazione e realizzazione del sistema di gestione del flusso documentale (servizi di document e content management); • la progettazione e realizzazione del sistema di gestione del protocollo elettronico (comprendendo l’acquisizione e la digitalizzazione del documento cartaceo); • la fornitura e l’installazione (comprensiva dell’integrazione con le infrastrutture preesistenti) dell’hardware necessario alla piena funzionalità del sistema; • l’installazione e la messa in esercizio dell’intero sistema; • la garanzia di tutte le componenti hardware e software del sistema per 12 mesi a partire dal positivo collaudo finale dell’intera fornitura; • la manutenzione ordinaria, correttiva e migliorativa, di tutte le componenti software del sistema per 12 mesi a partire dal positivo collaudo finale della fornitura; • almeno 150 ore di addestramento del personale della Provincia di Benevento utilizzatore del sistema. Le pagine seguenti forniscono una descrizione dei principali requisiti del sistema. La realizzazione dei componenti software dovrà comunque essere fondata su un’attività di analisi e definizione dei requisiti di dettaglio che la ditta aggiudicataria dovrà condurre in collaborazione con il personale della Provincia di Benevento. Il sistema descritto in questo disciplinare dovrà essere fornito chiavi in mano, completo di tutto quanto necessario al suo corretto ed efficiente funzionamento. Oltre a realizzare i requisiti software descritti nel seguito del presente documento, la soluzione proposta dovrà essere aperta all’integrazione di applicativi software cosiddetti verticali, ossia che risolvono problematiche specifiche dell’Ente, allo scopo di permettere il massimo sfruttamento dell’investimento facendo evolvere gradualmente il sistema informativo nel tempo. 8 La progettazione del sistema dovrà essere ispirata a criteri di scalabilità e modularità, ciò al fine di consentire non solo il soddisfacimento delle esigenze attuali ma anche la semplice adattabilità alle esigenze future. Dal punto di vista dell’utente, la soluzione proposta dovrà garantire servizi facili da usare ed accessibili e dovrà essere affidabile, mentre dal punto di vista della conduzione e gestione, è richiesto che essa sia sicura e facile da gestire. La soluzione proposta dovrà integrarsi con le preesistenze infrastrutturali di rete, al fine di salvaguardare gli investimenti fatti in passato. Le infrastrutture di rete dell’Ente Provincia di Benevento, da considerare nella definizione della soluzione da proporre, saranno dettagliate nel successivo paragrafo del presente disciplinare tecnico. Il riuso del software ha assunto negli ultimi anni una rilevanza crescente nell’ambito della pubblica amministrazione quale strumento per massimizzare il ritorno degli investimenti attraverso la valorizzazione del vasto patrimonio applicativo di cui dispongono le amministrazioni sia centrali che locali. Coerentemente a tale indirizzo, la progettazione del sistema dovrà integrare, laddove possibile, componenti applicative disponibili attraverso il catalogo del riuso della Regione Campania. Un’analisi preliminare ha portato all’individuazione di due componenti rilevanti per la presente fornitura, il sistema di protocollo informatico Egrammata ed il modulo di gestione delibere, decreti, e determine - E-Praxi. Pertanto, la soluzione proposta dovrà prevedere l’integrazione di tali applicativi. Una breve descrizione degli stessi è fornita nel paragrafo successivo. Resta inteso che le ditte proponenti avranno la possibilità di integrare ulteriori applicativi riusabili. La Provincia di Benevento ha avviato un processo di digitalizzazione ed indicizzazione degli atti amministrativi e deliberativi pregressi. La fornitura oggetto del presente disciplinare tecnico dovrà prevedere l’integrazione della base dati relativa a tale digitalizzazione al fine di favorire l’integrazione della tradizionale gestione cartacea con quella digitale. In particolare, il sistema dovrà garantire che le funzioni di ricerca siano applicabili in maniera trasparente sia ai nuovi documenti sia a quelli preesistenti. Il paragrafo successivo fornirà le caratteristiche essenziali della base documentale da integrare nell’ambito della presente fornitura. 9 L’utilizzo di software open-source, insieme al riuso, è considerato un fattore abilitante per la riduzione dei costi IT nella pubblica amministrazione. La soluzione proposta dovrà essere fondata, laddove possibile, su componenti software sia infrastrutturali sia applicative open-source. 10 3. Descrizione delle Preesistenze In questa sezione vengono descritte le preesistenze da integrare nella progettazione del sistema oggetto della fornitura. Allo scopo, la sezione è suddivisa in 3 parti: la prima illustra l’infrastruttura di rete sia locale a ciascuna sede sia per il collegamento delle diverse sedi della Provincia di Benevento; la seconda richiama la dotazione dei server del centro di elaborazione dati della Provincia; la terza parte descrive in modo sintetico due applicativi software offerti nella bacheca del riuso della Regione Campania, candidati all’integrazione nel sistema oggetto della fornitura. Le sedi fisiche della Provincia di Benevento sono le seguenti: • Via N. Calandra • Via Santa Colomba • Piazza Castello • Via XXV Luglio • Via Ricci • Viale Mellusi 3.1 Infrastruttura di rete Le reti locali presso le diverse sedi sono realizzate con cavi di piano in categoria 5E, e 2/3 punti connessione per stanza. Fa eccezione la sede presso la Rocca dei Rettori che, per difficoltà legate a vincoli strutturali che impattano sia sul cablaggio che sulla propagazione wireless, ha visto l’installazione di una tecnologia Cisco (LRE) per consentire lo sfruttamento dell’impianto telefonico come infrastruttura di base su cui veicolare il traffico dati in aggiunta a quello telefonico. I dispositivi attivi (switch, router, hub, …) sono dotati spesso di interfaccia SNMP o equivalente. Il numero totale di punti di accesso è circa 600, mentre il numero delle macchine connesse, dotate di indirizzo IP fisso, è circa 300. La connessione verso l’esterno (Internet) è gestita da Telecom Italia con due uscite (ridondate) da 2 Mbps ciascuna con centro stella presso la sede di via Calandra. Tra le diverse sedi è usata la tecnologia VoIP con centrali telefoniche Philips collocate presso la sede di viale Mellusi (come descritto in maggiore dettaglio nelle sezioni che seguono). 11 Per l’erogazione dei servizi di base, è presente un server per l’autenticazione e l’accesso alle risorse con 200 profili configurati, un server di posta elettronica interna (su tecnologia Lotus notes) con due domini (uno esterno, provinciabenevento.it, l’altro interno, provbn.it) e un file server. Sono operative le seguenti tipologie di servizio di accesso IP: • Formula Flat Office 2Mbps, realizzata su linea HDSL a 2 Mbps con banda minima garantita (BMG) pari a 1 Mbps in entrambe le direzioni. • Formula Wide Office Plus: accesso realizzato su linea ADSL 2Mbps/512Kbps, con banda minima garantita (BMG) di 512Kbps in entrambe le direzioni. In alcune sedi è attivo un doppio accesso configurato in Load Balancing. Le sedi dotate di doppio accesso sono quelle di Via Calandra, Via XXV Luglio, via Ricci, Rocca dei Rettori di Piazza Castello. 3.2 Macchine di classe server Di seguito si elencano i sistemi di elaborazione e le principali applicazioni installate presenti presso il centro elaborazione dati della Provincia di Benevento. La possibilità di riutilizzare, anche parzialmente, tali risorse per la realizzazione della fornitura oggetto del presente disciplinare tecnico va verificata dalle ditte proponenti mediante l’inoltro di specifici e circostanziati quesiti al responsabile del procedimento del presente bando. RACK 1 – Armadio Rack Sistema Sistema Operativo Server HP proliant DL380 Windows 2003 Server 3 HD 36,4 GB RAID 5 Unità di Backup DDS4 Server HP proliant DL380 Windows 2003 Server 3 HD 36,4 GB RAID 5 Unità di Backup DDS4 Server HP proliant DL380 Windows 2003 Server 3 HD 36,4 GB RAID 5 Unità di Backup DDS4 Server Fujitsu Siemens Sco Open Server 6.0 HD 300 GB RAID 5 DVD CDRW 12 RACK 2 – Armadio Rack Sistema Sistema Operativo Server HP proliant DL380 3 HD 146,8 GB RAID 5 Server HP proliant DL380 Windows 2003 Server 3 HD 36,4 GB RAID 5 Unità di Backup DDS4 Server Siemens fujitsu Linux RACK 3 – Armadio Rack Sistema Sistema Operativo Server HP proliant DL380 3 HD 36,4 GB RAID 5 Unità di Backup DDS4 Server HP proliant DL380 Linux RED HAT ES4 3 HD 36,4 GB RAID 5 Unità di Backup DDS4 Server HP proliant DL380 Windows 2003 Server 3 HD 36,4 GB RAID 5 Unità di Backup DDS4 Server Fujitsu Siemens Windows 2003 Server HD 300 GB RAID 5 DVD CDRW Unità singole Sistema Sistema Operativo Server IBM Net Finity 5500 Sco Unix Open server 5 HD 4,495 GB RAID 5 Unità di Backup DDS4 Server IBM xSeries 225 Windows 2003 Server HD 72,794 GB RAID 5 Unità di Backup: CDROM PC - 1 HD Sco Unix Open server 5 PC - 1 HD Sco Unix Open server 5 PC - 1 HD Sco Unix Open server 5 13 3.3 Applicativi Riusabili In questa sezione di fornisce una breve descrizione di due applicativi disponibili attraverso il portale del riuso della Regione Campania per i quali è richiesta l’integrazione nel sistema oggetto del presente disciplinare tecnico. 3.3.1 Protocollo informatico - EGrammata E-Grammata è l'applicativo della Regione Campania per la gestione del Protocollo Informatico presso gli enti pubblici. Nel completo rispetto della normativa vigente, consente l'intera gestione dei documenti nel loro formato tradizionale - cartaceo - e informatico, attraverso: • l'acquisizione e spedizione in modalità più o meno decentrata • il collegamento tra documenti per monitorarne lo spostamento all'interno dell'ente (flusso documentale) • l’individuazioni delle informazioni anche con ricerche full- text • l'interoperabilità (XML) e la posta certificata • la classificazione e gestione degli archivi (corrente, deposito, storico) • la gestione del documento elettronico (scanner, fax server e file) • l’integrazione con sistemi documentali • l’integrazione con firma digitale • l’integrazione con i sistemi di Workflow per la gestione dei procedimenti 3.3.2 DDD - Delibere Decreti Determine - E-Praxi Descrizione: Delibere, Determine e Decreti (DDD). E-Praxi è l'applicativo per la gestione degli atti amministrativi che consente la formazione, la validazione e l'adozione degli atti di governo direttamente in formato digitale grazie alla integrazione con la firma digitale forte e/o debole. Il sistema gestisce i seguenti flussi: • Delibere di Giunta • Delibere di Consiglio • Determinazioni • Decreti 14 3.4 Archivio atti pregressi La provincia di Benevento ha avviato un processo di digitalizzazione ed indicizzazione degli atti amministrativi e deliberativi preesistenti. Il processo prevede: • la produzione di documenti digitali con risoluzione non inferiore ai 400 dpi in formato PDF/A; • il trattamento O.C.R. dell’intero testo contenuto nell’atto; • l’ottimizzazione dimensionale del file per una migliore e più veloce visione; • la verifica del risultato per singola scansione. La base documentale prodotta da tale processo di digitalizzazione dovrà essere integrata nell’ambito della fornitura oggetto del presente disciplinare tecnico. In particolare, dovrà essere possibile applicare le funzioni di ricerca descritte nel seguito del presente documento in maniera trasparente ai nuovi documenti e a quelli oggetto del processo di digitalizzazione delle preesistenze. A tal fine, oltre alla base documentale, fatta dai documenti ottimizzati in formato PDF/A ricercabile, alla ditta aggiudicataria verrà una tabella MySql contenente i record indicizzati per: • Tipo Atto; • Anno; • Numero; • Oggetto; • Data; • File (percorso); • due campi automaticamente compilati "time_date" e "internal_id" valevole come chiave primaria. Si riporta di seguito il frammento SQL per la creazione della tabella. CREATE TABLE `jos_fabrik_formdata_2` ( `fabrik_internal_id` int(11) NOT NULL AUTO_INCREMENT, 15 `time_date` varchar(255) DEFAULT NULL, `elemento` text, `data` datetime DEFAULT NULL, `numero` varchar(255) DEFAULT NULL, `oggetto` text, `file_upload` varchar(255) DEFAULT NULL, `anno` varchar(255) DEFAULT NULL, PRIMARY KEY (`fabrik_internal_id`) ) 16 4. Requisiti Funzionali del Software I requisiti funzionali che saranno descritti in questa sezione fanno riferimento a diverse tipologie di utenti del sistema (stakeholders), sia interni all'organizzazione dell'Ente che esterni. Le tipologie di utenti previste, e quindi i relativi profili, sono cinque: utente esterno, operatore protocollo, operatore ente, operatore archiviazione documenti, amministratore. Come stabilito dalla normativa vigente, le amministrazione devono individuare al proprio interno un insieme di Aree Organizzative Omogenee (AOO) ciascuna dotata di un sistema di protocollo informatico. L’utente esterno rappresenta il cittadino, un’impresa, oppure un’altra amministrazione locale, regionale o nazionale, che abbia necessità di accedere al portale per interagire con l’Ente Provincia al fine di usufruire di un particolare servizio, tra quelli consentiti per questo tipo di profilo. L’operatore del protocollo rappresenta un addetto dell’Ente Provincia responsabile dell’esecuzione delle procedure di protocollazione dei documenti cartacei e digitali. Tra questi sarà identificato anche un responsabile di protocollo per ogni AOO. L’operatore ente rappresenta un addetto dell’Ente, che però può avere diverse tipologie di permessi rispetto alle procedure. Rientrano, infatti, in tale categoria sia coloro che hanno la responsabilità di definire e sovrintendere le procedure dell’Ente (per esempio i dirigenti ed i responsabili di AOO), sia coloro che hanno la responsabilità di eseguire le procedure dell’Ente o parti di esse (per esempio gli impiegati, i tecnici e gli amministrativi). L’operatore archiviazione documenti è responsabile della corretta archiviazione della documentazione digitale e cartacea, preservandone la consistenza e la coerenza. Gli operatori sono raggruppati in classi corrispondenti alle AOO di appartenenza. L’amministratore è responsabile dell’amministrazione dell’infrastruttura IT, dell’assegnazione di permessi e privilegi sulla base delle indicazioni fornite dal dirigente responsabile dell’Ente. 17 Per ognuno di questi profili d’uso vengono di seguito descritte le funzioni previste. Tutte le funzioni sono accedute tramite un portale Web e l'accesso deve essere controllato da un'adeguata procedura di autenticazione. 4.1 Funzioni Utente Esterno F.1 Registrazione utente. L’utente si registra, inserendo i dati necessari alla sua identificazione. Il sistema genera un messaggio che viene inviato via e-mail all’utente registrato, con le credenziali ed un link di attivazione per abilitare definitivamente l'account. F.2 Immissione richieste ed informative. L'utente esterno può inserire una specifica richiesta o un’informativa indirizzata ad una AOO, oppure, nel caso non dovesse conoscere l’AOO competente per l’evasione di una specifica richiesta, può inviare la richiesta senza ulteriori dettagli per l'instradamento. Una richiesta completa dovrà essere caratterizzata almeno dalle seguenti informazioni: data di apertura, AOO di competenza, parole chiave, utente che ha immesso la richiesta, numero identificativo della richiesta, oggetto, testo. Una richiesta non completa sarà priva delle informazioni relative all'ufficio di competenza. L’utente potrà poi verificare la risposta alla sua richiesta nella propria casella di posta elettronica. La risposta dovrà essere caratterizzata almeno dalle seguenti informazioni: data di apertura, data di chiusura, operatore che ha prodotto la risposta, numero identificativo della richiesta, oggetto, numero identificativo della richiesta, testo della risposta, allegati alla risposta. F.3 Ricerca e visualizzazione dello stato delle proprie richieste. L'utente esterno che ha effettuato una richiesta, in ogni momento deve poter visualizzare lo stato di avanzamento delle richieste che egli ha immesso ed una ipotesi sulla data di chiusura. Gli stati di avanzamento previsti per una richiesta sono: aperta,immessa dall’utente, ma non ancora presa in carico dall’operatore in lavorazione, presa in carico dall’operatore ma non ancora risolta risolta, la richiesta è stata risolta chiusa, dopo la notifica del risultato all’utente che aveva fatto la richiesta, questa viene chiusa. F.4 Navigazione del portale nelle aree libere. Il portale deve prevedere delle aree libere, cioè accessibili senza richiesta di autenticazione. In tali aree deve essere possibile accedere ad informazioni di pubblica utilità, sotto forma sia di contenuti nelle pagine 18 html, che di risorse in file di formato adeguato, quali rapporti (pdf, word, TeX, zip, ed altri), immagini (jpeg, png, gif, ed altri), video (avi ed altri). F.5 Navigazione del portale nelle aree protette. Accesso all’area riservata del portale per accedere alle applicazioni specifiche. Il portale deve fornire la possibilità di accedere ad applicazioni specifiche, che saranno dettagliate nel seguito del documento, le quali però richiedono permessi specifici. 4.2 Funzioni Operatore Protocollo F.6 Utilizzo funzioni di protocollo elettronico. L’utente autorizzato ad utilizzare le funzioni del componente di protocollo, di cui si tratterà nel seguito del documento, deve accedere al menù delle funzioni per la gestione del protocollo elettronico. Le informazioni che il protocollo deve contenere sono quelle previste dalla normativa corrente: numero di protocollo, generato automaticamente dal sistema e registrato in forma non modificabile data di registrazione di protocollo assegnata automaticamente dal sistema e registrata in forma non modificabile mittente per i documenti ricevuti o, in alternativa, destinatario per i documenti spediti, registrati in forma non modificabile; oggetto del documento, registrato in forma non modificabile; data e protocollo del documento ricevuto, se disponibili impronta del documento informatico se trasmesso per via telematica, costituita dalla sequenza di simboli binari in grado di identificarne univocamente il contenuto, registrata in forma non modificabile. codice identificativo dell’amministrazione e dell’AOO. F.7 Protocollazione di documenti ricevuti e inviati mediante Posta Elettronica Certificata. Similmente a quanto detto per i documenti cartacei, il sistema deve consentire la protocollazione dei documenti ricevuti o inviati mediante Posta Elettronica Certificata. F.8 Identificazione del documento protocollato, in caso di documento cartaceo, l’operatore di protocollo deve poter stampare un’etichetta identificativa (codice a barre) da associare al documento originale. F.9 Ricerca e visualizzazione dei documenti protocollati. L’operatore del protocollo deve poter effettuare ricerche fra i documenti protocollati usando differenti criteri di ricerca, 19 fra cui: numero di protocollo, data di registrazione, mittente, destinatario, oggetto, codice identificativo dell’amministrazione, codice identificativo dell’AOO, testo libero, operatore incaricato. F.10 Gestione digitalizzazione documenti. L’utente autorizzato ad utilizzare le funzioni del componente di digitalizzazione dei documenti, di cui si dettaglierà nel seguito del documento, deve accedere al menù delle funzioni per la gestione della digitalizzazione dei documenti per trasformare il documento cartaceo in una rappresentazione elettronica. F.11 Gestione richieste sottomesse dagli utenti esterni attraverso il portale. Ogni richiesta la cui AOO di competenza sia stata indicata dall’utente che l’ha immessa (o individuata dal sistema sulla base delle keyword), viene indirizzata all’operatore preposto. Tale operatore, dopo aver accettato di prendere in consegna la richiesta, si occupa di rispondere adeguatamente alla richiesta. La risposta alla richiesta dovrà essere inviata alla casella di posta elettronica dell’utente che aveva immesso la richiesta. Nel caso non dovesse essere immessa la competenza della richiesta questa verrà inviata ad un operatore incaricato di assegnare la competenza ed inviarla all’operatore più adeguato. F.12 Ricerca e visualizzazione dello stato delle richieste. L’operatore del protocollo deve poter ricercare una possibile richiesta usando differenti criteri di ricerca (data di immissione, data di chiusura, operatore incaricato, ufficio di competenza, parole chiave, utente che ha immesso la richiesta, oggetto della richiesta) e visualizzarne lo stato di avanzamento. 4.3 Funzioni Operatore Ente F.13 Gestione procedimenti. Per ciascun procedimento deve essere possibile definire il flusso delle attività di lavoro, assegnando a queste il responsabile della corretta esecuzione, i documenti previsti in ingresso e quelli attesi come prodotti dell’attività. Deve essere possibile definire le relazioni tra le diverse attività sia in termini di sequenza logica che temporale. F.14 Gestione richieste assegnate. Per ogni richiesta di competenza l’operatore Ente riceve una notifica corrispondente alla richiesta. L’operatore prende in consegna la richiesta attraverso l’accettazione. L’operatore, una volta risolta la richiesta, la chiude. L’operazione di chiusura della richiesta si conclude con l’invio della risoluzione della richiesta all’utente che aveva eseguito l’immissione della richiesta. Se una richiesta è 20 stata presa in consegna ma non chiusa dovrà essere messa in uno stato di lavorazione. Ogni richiesta potrà rimanere in uno stato di lavorazione in un tempo massimo definito dall’operatore responsabile della procedura, allo scadere del quale dovrà essere inviata una notifica all’operatore assegnato. F.15 Ricerca e visualizzazione dello stato delle richieste. L’operatore ente deve poter ricercare e visualizzare lo stato delle richieste con le funzioni descritte in F.10. 4.4 Funzioni Operatore Archiviazione documenti F.16 Gestione digitalizzazione cartacei. L’operatore attraverso questa funzione potrà accedere al menu delle funzioni per la gestione della digitalizzazione dei documenti cartacei. Tali funzioni sono illustrate in dettaglio nel seguito del documento. F.17 Gestione titolario: L’operatore attraverso questa funzione potrà gestire il ciclo di vita (inserimento, modifica, cancellazione di singoli record) del titolario e visualizzarlo. Un titolario di classificazione permette all'amministrazione di archiviare i documenti protocollati a seconda della funzione o attività cui essi fanno riferimento. Ogni AOO è correlata ad uno specifico titolario. Il titolario di archivio si presenta, generalmente, come uno schema generale di voci logiche rispondenti ai bisogni funzionali e articolate tendenzialmente in modo gerarchico, al fine di identificare, secondo uno schema logico, che va dal generale al particolare, l’unità di aggregazione di base dei documenti all’interno dell’archivio (ad esempio, il fascicolo). F.18 Stampa etichette per faldoni. L’operatore può definire il testo per l’etichetta di un faldone, successivamente potrà salvarla in un’apposita repository e inviarla in stampa. Tale funzione deve prevedere diversi formati delle etichette, corrispondenti ai formati che utilizza l’amministrazione dell’ente. F.19 Etichettatura documenti non protocollati. Per i documenti non soggetti a protocollazione, il sistema deve consentire la stampa di etichette identificative (codici a barre) da associare ai documenti archiviati per semplificare il successivo ritrovamento. F.20 Ricerca e visualizzazione dei documenti digitali. Ciascun documento digitale potrà essere ricercato e quindi visualizzato utilizzando differenti chiavi di ricerca, fra cui: numero di protocollo del documento, data di creazione del documento, oggetto, parole chiave, tipologia del documento, testo libero. F.21 Stampe e riepiloghi per funzioni di controllo. Deve essere possibile realizzare funzioni di stampa e di riepilogo per i documenti digitalizzati. 21 4.5 Funzioni Amministrazione F.22 Gestione profili di gruppi e utenti e relative autorizzazioni per ogni applicazione. L’amministratore può visualizzare, modificare ed eliminare i dati dei profili sia dei singoli utenti che dei gruppi di utenza. Ogni profilo sarà associato ad una lista di permessi su risorse e funzioni del sistema. L’amministratore potrà modificare tali associazioni. F.23 Registrazione utenti interni e assegnazione automatica delle credenziali di accesso. L’amministratore potrà effettuare la registrazione degli utenti ed assegnare ad essi le credenziali di accesso. Questa operazione, che è comunque fatta (per gli utenti esterni) in modo automatico dal sistema secondo le procedure già esposte, potrà essere realizzata o modificata manualmente anche dall’amministratore soprattutto per gli utenti interni. F.24 Gestione applicazioni integrate nel portale applicativo. L’amministratore potrà gestire le proprietà delle applicazioni nel portale applicativo, quali per esempio la loro disponibilità, visibilità ed accessibilità. F.25 Gestione dinamica del menù delle applicazioni disponibili per profilo di autorizzazione. L’amministratore potrà comporre il menù delle applicazioni disponibili per profilo di autorizzazione dinamicamente sulla base delle assegnazioni di ciascuna funzione a ciascun permesso, per cui, a seconda del permesso associato a ciascun profilo, sarà possibile vedere uno specifico menu. Nel seguito si dettagliano i requisiti nelle 4 funzioni principali: protocollazione, gestione delibere, gestione determine, digitalizzazione dei documenti. 4.6 Protocollazione Il processo di protocollazione prevede i seguenti passi principali: • Acquisizione del documento da protocollare. Si verifica che il documento sia da protocollare, dal momento che vi sono documenti esclusi dalla registrazione di protocollo, e, in caso di documento cartaceo, si effettua la scansione del documento. 22 • Classificazione. Si applica il metodo di classificazione adottato per definire Titolo, Classe e Fascicolo. • Registrazione del protocollo. Dopo aver definito se il protocollo è in entrata o in uscita, si inseriscono i dati obbligatori ed il sistema inserisce automaticamente la data, il numero di protocollo e l’impronta del documento informatico (se vi sono allegati). • Segnatura di un protocollo. Al termine di ogni registrazione il sistema fornisce il numero di protocollo assegnato che va apposto o associato all’originale del documento. In aggiunta a quando visto sino ad ora, il componente di protocollazione dovrà fornire le seguenti funzioni aggiuntive: PR.1 Acquisizione in digitale dei documenti in ingresso e protocollati. Il sistema deve consentire l’acquisizione del documento in ingresso in formato digitale e produrre il protocollo corrispondente. PR.2 Distribuzione dei documenti protocollati in ingresso agli utenti destinatari. Il sistema deve instradare i documenti protocollati di ingresso agli utenti destinatari e deve avviare i relativi procedimenti di gestione tramite il modulo di workflow management. PR.3 Distribuzione dei documenti protocollati in uscita dai settori dell’Ente. Il sistema deve consentire la distribuzione dei documenti protocollati in uscita dai settori dell’Ente Provincia agli utenti interessati, siano essi interni o esterni all’Ente. Qualora il documento protocollato in uscita rappresenti il risultato finale di un procedimento, all’atto della protocollazione farà riscontro la chiusura del procedimento nel modulo di workflow management. 4.7 Delibere Per delibera si intende la decisione di un organo collegiale all’interno dell’Ente, in particolare la Giunta. La delibera viene emanata dall’organo collegiale, eventualmente sotto forma di bozza o proposta; il sistema dovrà tracciare tutto il suo ciclo di vita fino alla sua approvazione e quindi pubblicazione sulla rete intranet e sul portale. DL.1 Gestione delle proposte e/o bozze degli atti. Il sistema deve consentire di gestire il ciclo di vita delle proposte o delle bozze degli atti. Ogni proposta o bozza di atto deve essere registrata in un apposito archivio, corredata di informazioni relative a: numero 23 identificativo, titolo, autore della proposta, data di creazione, oggetto. Il sistema deve offrire la possibilità di rinvenire una proposta o una bozza attraverso la ricerca per: titolo, autore, data di creazione, oggetto, testo libero. Quindi deve offrire la possibilità di modificarla, eliminarla o visualizzarla, tracciando in maniera non ripudiabile ogni cambiamento. DL.2 Consultazione della disponibilità di bilancio. Per le delibere che comportano impegni di spesa, il sistema deve offrire la possibilità di valutare la disponibilità di specifiche voci di bilancio. DL.3 Gestione dei pareri delle proposte. Il sistema deve fornire la possibilità di esprimere pareri sulle proposte, tenendo traccia della corrispondenza parere-proposta alla quale si riferisce. Sia i pareri che le proposte potranno essere inseriti in accordo ai privilegi e permessi assegnati dall’amministratore e l’accesso ai singoli pareri e proposte deve essere protetto da password. I pareri devono essere corredati da: autore, numero identificativo, data di creazione, proposta a cui si riferisce. DL.4 Controllo scadenze termini di esecutività, pubblicazione, invio e risposta ordinanze: il sistema deve dare la possibilità di gestire i termini (identificazione del termine, notifica del termine e sua scadenza) relativamente ad esecutività, pubblicazione e invio di ordinanze e risposta delle ordinanze. DL.5 Gestione delle sedute. Il sistema deve consentire la gestione di: convocazioni, avvisi, brogliacci, inviti, comunicazioni alle forze dell'ordine. Il sistema deve fornire la possibilità di inserire gli estremi di seduta, le presenze e tutte le informazioni relative alle singole sedute definite dall’Ente. Ciascun modulo relativo alle sedute deve essere corredato delle funzionalità di: stampa, modifica, archiviazione, eliminazione, protezione con password. DL.6 Notifica convocazioni. Il sistema deve consentire l’invio delle convocazioni, e dei relativi allegati, ai consiglieri mediante Posta Elettronica Certificata. DL.7 Resoconti di presenza e dei relativi gettoni. Il sistema deve gestire l’assegnazione delle presenze e dei relativi gettoni, unitamente alle funzionalità di stampa e ricerca per data, persona fisica, ed altre chiavi di ricerca indicate dall’Ente. DL.8 Gestione di tutte le informazioni riguardanti le Delibere. Il sistema deve fornire la possibilità di inserire gli estremi delle Delibere, i relativi documenti e gli allegati: numero, data, tipo, legami con la seduta, estremi di protocollo, revoca, oggetto, settore, ufficio, capitoli, presenze, pareri, immediata eseguibilità, estremi di esecutività, estremi dettagliati di ordinanza. Ciascun modulo relativo alle sedute deve 24 essere corredato delle funzionalità di: stampa, modifica, archiviazione, eliminazione, protezione con password. DL.9 Stampa delibere. Stampa di proposte e delibere, sia in modalità originale, sia in copia. DL.10 Firma Elettronica delle delibere. Il sistema deve fornire la possibilità di apporre una firma elettronica ai documenti deliberativi da parte degli attori coinvolti nel processo di produzione e approvazione degli stessi. DL.11 Pubblicazione sulla rete Intranet interna all’Ente e su Internet. Il sistema deve consentire di pubblicare (e quindi anche rimuovere) gli atti sulla Intranet interna e su Internet, disponendole in apposite sezioni del portale. DL.12 Acquisizione documenti digitalizzati legati all’atto. Il sistema deve consentire l’acquisizione digitale dei documenti relativi all’atto da elaborare. 4.8 Determinazioni La determinazione è un atto decisionale di un funzionario preposto, tipicamente finalizzata alla pratica realizzazione di un indirizzo politico contenuto in un atto deliberativo. Il sistema deve consentire di gestire l’evoluzione delle determinazioni dalla loro lavorazione alla loro approvazione e pubblicazione finale su Intranet e su Portale. DT.1 Gestione di tutti i dati riguardanti le determinazioni dirigenziali, nonché i relativi documenti ed allegati. Il sistema deve offrire le funzionalità di: stampa, modifica, archiviazione, eliminazione, protezione con password, unitamente alle specifiche funzionalità definite dall’Ente. DT.2 Determina generale e di settore. Il sistema deve offrire la capacità di gestire il ciclo di vita delle determinazioni generali e di settore. DT.3 Gestione di prospetti, registri, elenchi di trasmissione, accompagnatorie. Il sistema deve offrire le funzionalità di: stampa, modifica, archiviazione, eliminazione, protezione con password, unitamente alle specifiche funzionalità definite dall’Ente. DT.4 Ricerche parametriche su tutti i dati gestiti. Il sistema deve fornire la possibilità di eseguire ricerche sulle determinazioni rispetto a tutti i dati necessari alla caratterizzazione ed identificazione del documento e per testo libero. DT.5 Verifica ed aggiornamento delle varie scadenze. Il sistema deve fornire un sistema di monitoraggio, verifica, aggiornamento, allerta e notifica relativamente allo scadenziario. 25 DT.6 Gestione dell' indirizzario. Il sistema deve gestire l’indirizzario offrendo le funzionalità di: inserimento, modifica, eliminazione, stampa e ricerca secondo diverse chiavi, corrispondenti ai parametri identificativi degli elementi costituenti l’indirizzario e testo libero. DT.7 Stampa testi delle determinazioni. Stampa di determinazioni, sia in modalità originale, sia in copia. DT.8 Blocco dei documenti. Il sistema deve fornire, ai ruoli abilitati dall’amministratore il blocco dei documenti, es. a seguito dell'esecutività. DT.9 Firma Elettronica delle determinazioni. Il sistema deve fornire la possibilità di apporre una firma elettronica alle determinazioni da parte degli attori coinvolti nel processo di produzione e approvazione delle stesse. DT.10 Pubblicazione sulla Intranet ed Internet. Il sistema deve consentire di pubblicare (e quindi anche rimuovere) gli atti su Intranet interna e su Internet, disponendole in apposite sezioni del portale. DT.11 Acquisizione documenti digitalizzati legati all’atto. Il sistema deve consentire l’acquisizione digitale dei documenti relativi all’atto da elaborare. 4.9 Digitalizzazione Per “digitalizzazione” si intende il processo di produzione della versione digitale di un documento cartaceo. Le funzionalità di questa sezione sono finalizzate a collegare la documentazione resa digitale alle funzionalità offerte dall’intero sistema. D.1 Scansione dei documenti e trasformazione in immagini digitali. Questa funzionalità consentirà di trasformare i documenti ricevuti in formato cartaceo in opportuni formati digitali quali Tiff, jpg, Pdf, Pdf/A ed alti formati. D.2 Indicizzazione e classificazione dei documenti resi digitali: i documenti digitali dovranno essere corredati da informazioni utili alla loro classificazione ed indicizzazione, in accordo alle procedure dell’Ente. D.3 Scansione O.C.R.: il sistema dovrà prevedere funzioni di tipo O.C.R. per il riconoscimento del contenuto testuale dei documenti digitalizzati, al fine di abilitare la ricerca per testo libero indipendentemente dal modo in cui il documento è stato prodotto. 26 D.4 Funzionalità di ricerca dei documenti. I documenti digitalizzati devono essere rintracciati attraverso tutti gli indici utilizzati per la loro classificazione e, laddove possibile, deve essere supportata la ricerca per testo libero. Tali funzioni di ricerca devono essere invocabili sia dagli utenti del portale, in accordo ai loro permessi, sia dalle altre funzioni e componenti del sistema. D.5 Funzionalità di report di dettaglio e riepilogativi. Il sistema deve produrre report di dettaglio e di riepilogo relativamente ai documenti digitalizzati. D.6 Gestione titolario di archivio e di classificazione dei documenti. Devono essere gestiti i processi di acquisizione e catalogazione del titolario relativamente ai documenti digitalizzati e la corrispondente classificazione in accordo alle procedure dell’Ente. D.7 Stampa etichette di classificazione. Deve essere possibile definire il testo da stampare sulle etichette di classificazione in accordo a tutti i formati previsti dall’Ente. D.8 Gestione scannerizzazione e memorizzazione documenti. Il sistema deve consentire di gestire i parametri di scansione del documento, la tipologia e le proprietà del file digitale, e la memorizzazione dello stesso nell’archivio preposto. D.9 Stampa riepiloghi ed elenchi documenti per diversi livelli di ricerca. Il sistema deve consentire la stampa di gruppi di documenti organizzati secondo la ricerca effettuata dall’utente in accordo al requisito D.3. D.10 Ricerca documenti con campi chiave di classificazione. Il sistema deve consentire la ricerca anche attraverso il campo identificativo utilizzato come chiave per la classificazione. D.11 Riproduzione ed invio documenti digitali a mezzo e-mail. Il sistema deve consentire la visualizzazione del documento digitale e deve consentire il suo invio tramite posta elettronica. 27 5. Componenti principali dell'architettura Lo scopo di questa sezione è quello di individuare sin da questa fase un insieme di componenti software ben note previste dall'architettura le cui caratteristiche funzionali oltre a soddisfare i requisiti funzionali specifici di questo capitolato sono utili anche in altri contesti applicativi mentre le caratteristiche non funzionali ne caratterizzano i livelli di qualità. 5.1 Portale applicativo Il Portale costituisce il punto d’accesso a tutti i servizi previsti nella piattaforma. Attraverso il portale, gli utenti potranno autenticarsi e potranno così avere accesso ai servizi per i quali sono autorizzati. Per la realizzazione del portale, pertanto, la Provincia di Benevento richiede che vengano rispettate le normative per la Pubblica amministrazione e gli standard più diffusi per favorire l’accessibilità e l’usabilità. Il portale deve godere, inoltre di due ulteriori caratteristiche essenziali: l'estendibilità e l'integrabilità con altre applicazioni che saranno sviluppate in futuro. Essendo, infatti, esso il punto di accesso al sistema di tutti gli utenti, esso deve essere progettato in modo da poter essere, in un prossimo futuro, esteso con altre funzionalità che potranno essere necessarie successivamente alla messa in esercizio del portale per far fronte alle esigenze che man mano saranno manifestate dagli utenti. Per le stesse ragioni il portale deve essere integrabile con altre applicazioni che potranno aggiungersi a quelle previste nel sistema descritte nel presente capitolato. Per i motivi su esposti, si richiede di impiegare un portal server (preferibilmente open source) ampiamente diffuso, robusto, e che supporti tecnologie d'integrazione rapida quali quelle specificate dalle JSR 168 e JSR 286. In particolare, il portale dovrà: • essere progettato in modo da enfatizzare gli aspetti di usabilità, caratteristica trattata più ampiamente nel seguito del documento. Si consideri che al portale dovranno accedere migliaia di utenti, tutti con livelli di alfabetizzazione informatica estremamente variegati, 28 da un lato, e dall’altro, tutte le utenze devono essere messe in grado di accedere a tali servizi. • prevedere la suddivisione delle funzioni e dei contenuti in aree differenti, a seconda del ruolo con il quale si accede e le viste sulle differenti funzionalità dovranno essere specifiche della categoria di utente che sta realizzando l'accesso. • prevedere accessi controllati da autenticazione per le diverse aree in accordo alle indicazioni fornite nel paragrafo “Autenticazione” del presente documento. • consentire una agevole navigabilità al suo interno. Questo implica che, da un lato, qualunque risorsa deve essere raggiunta con il minimo numero di passaggi possibile a partire dalla home page. Dall’altro, deve essere possibile sapere esattamente in quale parte del sito ci si trovi, in ogni momento, attraverso un’indicazione evidente, completa e comprensibile della posizione della risorsa acceduta. • essere agevolmente rintracciabile dai più comuni motori di ricerca (google, msn, yahoo), digitando un insieme di parole chiave correlate all’Ente Provincia (es: Provincia Benevento, Portale della Provincia di Benevento). 5.2 Document Management L’introduzione di un sistema di gestione dei documenti migliora la qualità delle informazioni a supporto dei processi decisionali ed operativi. Ciò viene ottenuto sia migliorando la qualità intrinseca dei documenti, attraverso un migliore controllo dei relativi processi redazionali, sia migliorandone la reperibilità e la rintracciabilità. Da non trascurare, infine, la possibilità offerta dai sistemi di gestione dei documenti di operare in modalità collaborativa sullo stesso documento, migliorando in tal modo l'efficienza (si riducono i tempi di produzione) e l'efficacia (si riesce a raggiungere più velocemente un output condiviso o a produrre output difficilmente producibili senza questo supporto). La fornitura oggetto del presente disciplinare tecnico dovrà prevedere un componente di document management in grado di: • migliorare il controllo dei processi redazionali, con funzionalità relative non solo alla creazione, strutturazione ed archiviazione dei documenti, ma anche alla gestione di legami logici fra documenti diversi; 29 • migliorare la qualità dei documenti, anche attraverso la definizione di template di riferimento; • migliorare i livelli di reperibilità dei documenti di interesse. La flessibilità del reperimento dovrà essere garantita sia mediante approcci basati sulle interrogazioni, tipici dei sistemi di database e degli strumenti di information retrieval, che con approcci fondati sulla navigazione, che caratterizzano i sistemi ipertestuali. Inoltre, nel rispetto dei vincoli di visibilità e di sicurezza relativi alle categorie di utenti interne ed esterne all’Ente, la reperibilità dovrà essere estesa ai cittadini mediante opportune funzionalità, da prevedere nella definizione del portale Internet; • abilitare un modello di sicurezza molto robusto, con stretto controllo delle autorizzazioni e prevedere la possibilità di definire classi di documenti su cui gruppi di utenti esercitino diritti particolari. In particolare, una classe di documenti potrà riferirsi non solo agli utenti che operano in una delle unità organizzative previste dall’ordinamento amministrativo provinciale, ma dovrà anche prevedere la possibilità di creare classi di documenti che fanno riferimento ad attività che coinvolgono più unità, nel rispetto dei rapporti sia gerarchici che di appartenenze che il modello organizzativo definisce. Tipicamente un sistema di document management è costituito dai seguenti sotto-sistemi: (1) un repository di documenti; (2) un motore di information retrieval; (3) applicazioni client; (4) tool di amministrazione. Ognuno di questi componenti deve essere personalizzato o esteso per supportare le funzionalità richieste. Il repository dovrà consentire la memorizzazione dei documenti e la loro lavorazione. Le operazioni possibili sui documenti cambiano a seconda che i documenti siano non aggiornabili (si pensi ad un bando di gara già pubblicato) o in lavorazione (ad esempio, l’ordine del giorno di una prossima seduta di giunta). Per i documenti aggiornabili, il repository deve prevedere sia la gestione di operazioni di aggiornamento concorrente, attraverso opportuni meccanismi di sincronizzazione, sia operazioni di check-in/out di un documento o di un gruppo di documenti. La prima soluzione potrà essere utilizzata particolarmente per supportare piccole operazioni di editing “on line” mentre la seconda è essenziale ai fini della realizzazione di modifiche estese “off-line”. Si richiede che il repository preveda primitive per la categorizzazione dei documenti, per la gestione delle configurazioni e del versioning. 30 Il motore di ricerca dovrà consentire la ricerca dei documenti di interesse sulla base del contenuto con tecniche che vanno dalle semplici query basate su parole chiave (per documenti categorizzati) a query full-text e booleane. La componente client del sistema di document management dovrà consentire: • l’acquisizione di documenti. L’acquisizione dovrà riguardare sia documenti disponibili in formato cartaceo, che documenti elettronici in vari formati. Si ipotizza che gli utenti continuino ad utilizzare i normali strumenti di office automation in dotazione all’Ente. La conversione verso il formato di memorizzazione nel server dovrà avvenire in maniera automatica attraverso opportuni filtri; • la definizione di legami logici fra i documenti. Ad esempio, tali legami potrebbero collegare un bando di gara al relativo disciplinare tecnico ed alla delibera di approvazione. I legami logici serviranno a supportare la navigazione ipertestuale. E’inteso che solo utenti con diritti particolari (utenti privilegiati) dovranno avere la possibilità di definire legami visibili globalmente; in ogni caso, ogni utente dovrà avere la possibilità di creare legami privati, anche temporanei; • la definizione di nuove categorie di documenti, delle relative proprietà caratteristiche, e dei template di riferimento. La definizione di tali categorie è riservata ad utenti privilegiati. La definizione della forma template di una classe di documenti dovrà poter avvenire in maniera grafica; • il reperimento dei documenti di interesse. La ricerca dovrà avvenire sia attraverso la formulazione di interrogazioni che in maniera navigazionale, sfruttando i legami logici definiti fra i documenti. La ricerca e la navigazione dovranno poter essere ristrette a determinate categorie di documenti. I documenti d’interesse dovranno poter essere visualizzati, stampati o memorizzati localmente secondo uno o più stili di rappresentazione scelti dall’utente; • il check-in/out di documenti aggiornabili ai fini della creazione di un nuova versione, mediante l’interazione con le funzionalità di versioning del server; • l’editing on line di documenti aggiornabili. 5.3 Workflow Mangement 31 Il Workflow Management consiste nell’automazione di procedure o flussi di lavoro che vengono condivisi fra più partecipanti, in accordo a regole ben definite, documenti, compiti da svolgere, informazioni ed altri tipi di risorse sia umane che strumentali. Uno degli obiettivi fondamentali legati all’introduzione di un sistema di workflow è migliorare l’efficacia e l’efficienza dei processi amministrativi e decisionali: idealmente, un processo dovrebbe fluire dall’inizio alla fine nel minor tempo possibile, col minimo sforzo, passando da un attore al successivo fino al completamento. Nel caso di un Ente pubblico, inoltre, assumono particolare importanza i requisiti di tracciabilità e di trasparenza, che fanno riferimento alla possibilità da un lato di identificare in ogni istante lo stato di avanzamento di un processo, dall’altro di ricondurre ogni azione ad un responsabile nonché di rendere esplicite e controllabili le regole che guidano l’avanzamento dei processi e l’assunzione delle relative decisioni. Il sistema proposto dovrà supportare la gestione e l’automazione dei processi (documentali) nel rispetto della struttura organizzativa dell’Ente. In particolare, la soluzione dovrà rivolgersi non solo ai processi che si sviluppano all’interno di ognuna delle unità organizzative, siano esse, settori o servizi, ma dovrà anche prevedere l’integrazione fra i processi delle varie unità nel rispetto dei rapporti sia gerarchici che di appartenenze che il modello organizzativo definisce. Gli specifici processi da gestire ed automatizzare, le attività, ed i relativi flussi, dovranno essere identificati e definiti mediante una fase di analisi e definizione dei requisiti che la ditta aggiudicataria condurrà in collaborazione con il personale dell’Ente. La soluzione per la definizione, l’aggiornamento e la cancellazione dei processi dovrà consentire, attraverso notazioni grafiche intuitive e di semplice apprendimento, la rappresentazione delle componenti di un processo: azioni, persone e ruoli, flussi di controllo, messaggi ed informazioni, eventi esterni, decisioni che è necessario prendere e conseguenze. In particolare, la soluzione dovrà prevedere la descrizione dei processi secondo quattro punti di vista: • il flusso di controllo; • le persone che partecipano e il ruolo che rivestono; • le decisioni che sono prese nel processo e come condizionano il flusso; • le informazioni che sono prodotte/richieste dai partecipanti. 32 Per quanto concerne il controllo sull’esecuzione dei processi e l’automazione, si richiede che la soluzione proposta integri gli approcci fondati su un motore di processo con quelli basati su moduli elettronici e sistemi di messaggistica. In particolare, la soluzione progettuale proposta dovrà prevedere, oltre all’utilizzo dell’applicazione client, le seguenti possibilità: • i partecipanti ad un processo dovranno poter utilizzare il loro Web browser favorito per interagire con il workflow engine attraverso forms; l’interazione attraverso Web dovrà essere sempre possibile all’interno della rete Intranet e, per processi/utenti/task selezionati dovrà poter avvenire anche sulla rete pubblica Internet; • la notifica dei task ai partecipanti ad un processo e la distribuzione delle informazioni relative dovrà poter avvenire anche attraverso l’utilizzo degli strumenti di comunicazione che gli utenti utilizzano abitualmente nella loro postazione di lavoro. La soluzione proposta dovrà prevedere strumenti ed operazioni specificamente orientate al controllo ed al tracciamento dello stato di differenti istanze di workflow. Il sistema dovrà prevedere meccanismi per il controllo della corretta esecuzione delle procedure definite, consentendo sia la sincronizzazione delle attività, sia attuando un sistema di notifica che permetterà di ricordare le scadenze relative alle differenti attività. Il sistema di workflow dovrà provvedere a far pervenire i documenti dal protocollo elettronico ed avviare le adeguate procedure, in accordo a una accurata fase di valutazione, classificazione ed assegnazione. Al termine di ciascuna procedura, il documento così lavorato dovrà essere inviato nuovamente al protocollo elettronico. 5.4 Help Desk Tramite questo componente sarà possibile fruire delle funzioni di servizio a supporto degli utenti del sistema interni alla Provincia (Help Desk di II livello). Le funzioni disponibili saranno rivolte alla gestione delle richieste e alla loro trattazione secondo un procedimento che risponda al minimo alla seguente struttura: 33 • inserimento richiesta • presa in carico della richiesta • lavorazione • risposta Il sistema dovrà prevedere di comunicare con i soggetti utilizzatori secondo due modalità: attraverso le funzionalità web del portale e attraverso strumenti alternativi di comunicazione (e_mail, sms,…). 34 6. Requisiti non Funzionali Il sistema dovrà assicurare adeguati livelli di sicurezza, scalabilità ed estendibilità. 6.1 Sicurezza Per quanto riguarda la sicurezza, si possono individuare diversi livelli di intervento: infrastruttura di rete, infrastruttura software, applicazione. In questo modo, gli utenti possono accedere solo a specifiche infrastrutture software (es. web server, portal server), bloccando gli accessi mediante l'ausilio di un firewall; una volta giunti all'infrastruttura software devono autenticarsi per essere autorizzati ad usare una specifica applicazione e le relative funzioni. Alcune applicazioni (es. Protocollo elettronico), richiedono infine ulteriori interventi durante il loro uso per la protezione dei dati. Nel seguito sono descritti i diversi livelli di intervento. 6.1.1 Infrastruttura di rete Il livello infrastruttura di rete è assicurato dal fornitore di connettività dell’Ente Provincia, che garantisce funzioni di Intrusion Detection ed un’architettura che separa l'accesso ai server pubblici (es. Web server) dalle altre macchine private in uso presso le strutture della Provincia. Lo stesso fornitore di connettività garantisce il log del traffico TCP/IP in ingresso ed in uscita dalla rete provinciale, attraverso il router di frontiera. Per il sistema oggetto del presente disciplinare tecnico, tali informazioni di log degli accessi dovranno essere registrate, a cura della ditta aggiudicataria, in un data-base relazionale interrogabile via SQL in modo da poter effettuare su di esse opportune analisi statistiche. In fase di collaudo dovrà essere prevista un’adeguata attività di penetration testing, al fine di garantire che il portale non presenti vulnerabilità attraverso cui si rende possibile la realizzazione di una intrusione o di un attacco. 6.1.2 Infrastruttura software Il sistema dovrà essere dotato di un meccanismo di autenticazione che, tra le altre cose, garantisca almeno tre proprietà del sistema: 35 • integrità dei dati, ovvero le informazioni ed i processi devono essere protetti da modifiche accidentali o non autorizzate; • riservatezza, le informazioni ed i processi non devono essere consultabili da parte di utenti/ processi non autorizzati; • non ripudiabilità, è sempre nota l’identità di chi realizza un’azione nel sistema. Allo scopo il sistema dovrà prevedere meccanismi di Single Sign On (SSO) al fine di facilitare la transizione tra applicazioni diverse attraverso il portale anche quando il loro accesso richiede l'autenticazione specifica. Il SSO infatti consente di effettuare l'autenticazione esplicita una sola volta, demandando il sistema per le successive autenticazioni. La scelta di ricorrere al SSO è motivata dalla presenza di una moltitudine di funzionalità (spesso offerte da componenti software diversi). Il SSO ha il vantaggio di semplificare l’operazione di autenticazione e al tempo stesso di renderla più sicura. La sicurezza diviene più robusta proprio grazie alla centralizzazione della gestione delle password. La distribuzione della stessa, infatti, aumenta sia il numero di vulnerabilità che le probabilità di un attacco e di una conseguente breccia, diminuendo la capacità di controllo sull’infrastruttura. 6.1.3 Applicazioni Con la legge 196/2003 sono state introdotte precise direttive di privacy e di tenuta di dati personali con strumenti elettronici. Si riporta, nella fattispecie l’articolo 34: il trattamento di dati personali effettuato con strumenti elettronici e’ consentito solo se sono adottate le seguenti misure minime: • autenticazione informatica; • adozione di procedure di gestione delle credenziali di autenticazione; • sistema di autorizzazione; • aggiornamento periodico dell’individuazione dell’ambito del trattamento consentito ai singoli incaricati e addetti alla gestione o alla manutenzione degli strumenti elettronici; • protezione degli strumenti elettronici e dei dati rispetto a trattamenti illeciti di dati, ad accessi non consentiti e a determinati programmi informatici; • adozione di procedure per la custodia di copie di sicurezza, il ripristino della disponibilità dei dati e dei sistemi; • tenuta di un aggiornato documento programmatico sulla sicurezza. 36 Nel caso specifico del protocollo elettronico si richiede che: • le registrazioni non debbano essere modificabili; • i sistemi operativi devono essere adeguati alla identificazione ed autenticazione degli utenti; • gli accessi devono essere differenziati e controllabili; • le modifiche effettuate devono essere tracciabili. 6.2 Scalabilità Il sistema deve essere progettato e realizzato in modo da scalare facilmente e con costi contenuti all'aumentare sia del numero degli utenti (esterni o interni) che del volume dei dati che saranno trattati. Inoltre, si richiede di dimensionare inizialmente l'hardware da utilizzare per l'esecuzione del sistema e per gestire i dati in funzione: (1) del numero di operatori interni che lavoreranno tramite il sistema, (2) del volume di dati che essi producono e si scambiano per la gestione dei flussi documentali, (3) e del numero stimato di utenti esterni che accederanno ai servizi pubblici del portale per l'accesso agli atti. 6.3 Estendibilità Il sistema deve avere un'elevata propensione alla evoluzione, per cui oltre ad essere opportunamente documentato deve essere progettato e sviluppato con un approccio modulare. In particolare, l’architettura software richiesta deve seguire i dettami architetturali per i sistemi a tre livelli, prevedendo una netta separazione dell’interfaccia utente dalla logica funzionale e dei dati. Questa architettura ha enormi vantaggi in fatto di flessibilità ed evoluzione della soluzione dal punto di vista della scalabilità delle prestazioni e della garanzia del servizio (load-balancing e failover clustering). Inoltre per favorire l'integrazione con altre componenti software e per future evoluzioni dello stesso sistema si richiede che il sistema presenti elevate possibilità di integrazione sia con le applicazioni esistenti che con le applicazioni che dovranno essere installate in futuro e quindi: • basi di dati accessibili dall’esterno attraverso: l’uso di linguaggi di interrogazione standard, quali SQL; 37 • api sviluppate per l’integrazione in applicazioni esterne che consentano di effettuare le operazioni CRUD e l’accesso ai metadati della base di dati; • visibilità della struttura della base di dati anche attraverso programmi che non siano propri di specifiche piattaforme; • disposizione di funzionalità di dump; • sviluppo di specifiche API che possono essere richiamate da applicazioni esterne • scambio di dati mediante file XML; • manuale utente ed help on line completi e facili da navigare. Infine, per motivi di facile estendibilità del sistema si richiede di impiegare per quanto possibile componenti applicative open source stabili e di successo. In particolare per: • la realizzazione del portale, un portal server open source in grado di ospitare portlet e che si compliant con le specifiche JSR 168 e JSR286 (es. LifeRay, JetSpeed) • la gestione dei contenuti e i flussi documentali, un content management system evoluto e compliant con le specifiche JSR 170 (es. Alfresco, Magnolia); • il supporto della logica applicativa delle diverse componenti software un application server JEE ( es. JBoss, GlasFish). 38 7. Fornitura hardware La Provincia di Benevento poiché intende ospitare internamente le attrezzature e il software necessari per la fornitura dei servizi descritti in questo disciplinare e pertanto renderà disponibili, sulla base di una propria proposta, i locali dove installare le apparecchiature ed ospitare il personale operativo. Data la complessa articolazione dei servizi previsti nel sistema, è richiesto che le componenti software siano distribuite, anche per ragioni di sicurezza, su macchine server diverse. Nella proposta tutti i server dovranno essere opportunamente dimensionati in numero, nella potenza elaborativa, nella memoria centrale, nella memoria di massa e nelle soluzioni architetturali per sostenere il carico dell’intero sistema garantendo livelli di servizio adeguati alle caratteristiche funzionali delle applicazioni in termini di tempi di risposta, quantità di dati gestita, affidabilità, scalabilità, continuità del servizio, sicurezza, etc. Nella tabella seguente sono espresse le componenti hardware necessarie alla realizzazione della soluzione con le caratteristiche minime richieste. Le apparecchiature dovranno essere di primaria marca mondiale. Le apparecchiature individuate ed indicate in tabella sono, a solo titolo esemplificativo, della “Tipologia” individuata e richiesta per la fornitura. N. Descrizione Q.tà 1 Rack –19’’ completi di monitor, tastiera e master switch 2 2 Macchine di classe Server per Web Server, Application Server, e 6 DB Server 3 Unità rack storage – almeno 9 TB - montabile in rack - Serial ATA 1 - RAID 0, 1, 5, 6 4 Macchine di classe Server per protocollo elettronico 2 5 UPS con supporto SNMP 8 6 Switch – 48 porte 10/100 POE + 4 porte SFP + IPB image in 2 7 PC DESKTOP – CORE 2 DUO – RAM 4 GB – HDD 250 GB Serial 17 ATA – Monitor LCD almeno 19’’ 8 Personal computer workstation - Quad-Core Xeon – RAM 8 GB - 4 HDD 500 GB - DVD±RW (±R DL) / DVD-RAM - Gigabit 39 Ethernet - completi di monitor 22” Widescreen flat 9 Stampanti etichetta per protocollo 21 10 Stampanti Laser A4 a colori 21 11 Scanner A3/A4 con ADF 5 12 Scanner A0 3 13 Scanner A4 con ADF 14 Tutte le caratteristiche riportate precedentemente per l'attrezzatura hardware, devono intendersi come caratteristiche minime richieste. Nel caso in cui le attrezzature con le caratteristiche tecniche richieste al momento della fornitura non fossero più reperibili sul mercato, dovranno essere forniti modelli equivalenti o immediatamente superiori con prestazioni con lo stesso valore di mercato al momento della stipula del contratto e, di conseguenza, dovranno essere fornite apposite certificazioni attestanti il possesso delle suddette caratteristiche. In fase di presentazione dell’offerta tecnica dovrà essere predisposto un documento di dettaglio del dimensionamento della fornitura hardware, anche mediante soluzioni di virtualizzazione, tenendo conto dei requisiti generali del sistema, delle caratteristiche minime sopra riportate e delle preesistenze in essere presso la Provincia di Benvento, descritte nella sezione 3 del presente documento. Tutte le apparecchiature devono rispettare le normative vigenti, con particolare riferimento a quelle sulla sicurezza elettrica, sull'emissione di radiazioni e sulla rumorosità (direttiva 90/ 270/CEE), alle specifiche MPRII TCO ISO 9241-3, alle norme tecniche CEI 74-2/EN 60950 e IEC 950 e, relativamente ai monitor, al protocollo SWDAC MPR-I MPR-II. A tal fine con particolare riferimento alla specifica fornitura, le attrezzature devono essere munite di certificazione I.M.Q. o altro ente riconosciuto, in originale o copia autenticata. 40 8. Disposizioni Finali Il sistema descritto in questo allegato dovrà essere fornito chiavi in mano, completo di tutto quanto necessario al suo corretto ed efficiente funzionamento. La progettazione esecutiva dovrà essere basata su un processo preliminare di analisi e modellazione dei flussi documentali relativi agli atti amministrativi e deliberativi dell’Ente Provincia di Benevento. Tale processo dovrà essere condotto dalla ditta aggiudicataria in stretta collaborazione con il personale dell’Ente e dovrà produrre un documento di mappatura ed ottimizzazione dei flussi documentali dell’Ente Provincia di Benevento. Il software di base dei server dovrà essere fornito con un numero di licenze d’uso adeguato (le licenze dovranno essere fornite anche nel caso di prodotti open source, unite ad una dichiarazione di non violazione delle regole specificate nelle licenze dei prodotti di origine) e dovrà essere in grado di sostenere il carico dell’intero sistema garantendo livelli di servizio adeguati alle caratteristiche funzionali delle applicazioni ed alla tipologia e dimensioni dell’utenza, in termini di tempi di risposta, quantità di dati gestita, scalabilità, affidabilità, continuità del servizio, sicurezza; dovrà inoltre essere conforme a standard de facto o de iure e dovrà essere in grado di interoperare sui sistemi di rete previsti in tale allegato. I livelli di servizio relativi ai punti precedentemente illustrati devono essere specificati in fase di proposizione dell'offerta. La Ditta aggiudicataria si impegna a fornire tutta la documentazione tecnica originale relativa all’ hardware ed al software sia di base che applicativo di cui al presente disciplinare tecnico. Detta documentazione dovrà essere, ove esistente, in italiano e in formato sia cartaceo che elettronico. Da essa dovranno risultare con chiarezza le modalità di utilizzazione, le specifiche tecniche, le modalità di installazione e, specificatamente per l'hardware, le modalità operative minimali di manutenzione preventiva da effettuare e le condizioni ambientali ottimali di utilizzazione. In caso tali elementi non risultassero dai manuali forniti dalle case costruttrici delle apparecchiature, la Ditta aggiudicataria dovrà sopperire con apposita relazione tecnica dettagliata. In particolare, per i prodotti open source utilizzati, si richiede di fornire un manuale sulle funzionalità usate per la realizzazione del sistema. 41 In fase di presentazione dell’offerta, si richiede, la definizione da parte della ditta fornitrice, di un piano di qualità, secondo il modello di qualità ISO 9000. Le attrezzature dovranno essere installate e messe in esercizio dalla ditta fornitrice nei settori indicati dall'Amministrazione Provinciale: Sede Setture/Ufficio Piazza Castello Presidenza; Segreteria Generale; Presidenza del consiglio Largo Giosuè Carducci Centro Elaborazione Dati, Avvocatura Edilizia e Patrimonio; Finanza e Controllo Economico; Mobilità Infrastrutture ed Energia; e Viabilità; Pianificazione Territoriale Piazzale Gramazio Risorse Umane; Servizi al Cittadino Via XXV Luglio e via Ricci Politiche Attive del lavoro; Agricoltura e Alimentazione Viale Mellusi Polizia Provinciale In fase di presentazione dell’offerta tecnica, la ditta dovrà predisporre un opportuno piano per le attività d’installazione e configurazione delle apparecchiature. Tutte le procedure di installazione, messa in esercizio, configurazione dei parametri operativi ed assistenza all'avviamento dovranno essere effettuate dalla ditta fornitrice. Eventuali guasti o malfunzionamento sia hardware che software che si dovessero manifestare durante l'installazione, dovranno essere risolti dalla data di accertamento, anche con la sostituzione integrale dell'elemento, senza nessun aggravio per l'Amministrazione. La fornitura delle componenti richieste sarà sottoposta a collaudo da parte dell'Amministrazione. Sono a carico della ditta fornitrice le spese inerenti eventuali esami tecnici che l’Amministrazione potrà effettuare in sede di collaudo sui beni oggetto della fornitura per accertarne la rispondenza con le caratteristiche dichiarate e sopra descritte. Preliminarmente alle operazioni di collaudo, la ditta aggiudicataria dovrà fornire il piano dei test effettuati internamente e la documentazione relativa ai risultati di tali test. Restano a carico della ditta fornitrice tutte le spese, oneri, diritti, 42 formalità, permessi, licenze, visti e quant'altro necessario per il collaudo. La ditta dovrà prestare assistenza all'operazione di collaudo. Tutte le attrezzature fornite sono soggette a garanzia di 12 mesi a decorrere dalla data di collaudo. La Ditta si obbliga in detto periodo ad eseguire a sua cura e spese presso le sedi indicate dall'Amministrazione, gli interventi di trasporto, montaggio e collocazione, riparazione, ripristino, sostituzione delle parti o del tutto che comunque presentasse imperfezioni per qualità di materiali e/ o di funzionamento anche se non rilevanti all'atto del collaudo e della presa in carico. L'assistenza, prevista per il primo anno, dovrà contemplare un numero di interventi senza limite, ritiro della macchina guasta entro 24 (ventiquattro) ore dalla chiamata e sostituzione della stessa con modulo di back-up uguale o similari, ferme restando le condizioni di garanzia. Qualora l'impresa non ottemperasse tale condizione di assistenza sarà applicata una penale. La fornitura prevede inoltre che la ditta si faccia carico della manutenzione ordinaria, correttiva e migliorativa, di tutti i componenti software applicative del sistema per 12 mesi a partire dal positivo collaudo finale della fornitura. In fase di presentazione dell’offerta dovrà essere predisposto un apposito piano di manutenzione, che definiscano le responsabilità della manutenzione, le modalità di intervento ed i relativi processi. Il processo di manutenzione definito dal suddetto piano dovrà essere conforme allo standard ISO/IEC12207. L’offerta dovrà contenere un opportuno piano di addestramento all’uso ed alla gestione del sistema per il personale dell’Ente. Il piano dovrà indicare il numero di ore di addestramento previste, non inferiore ad 150, e le modalità di svolgimento. Infine, l’offerta dovrà contenere il piano di sviluppo dell’intera fornitura, con il cronogramma completo di tutte le fasi e le attività previste. 43