Embed Size (px)
Citation preview
1
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
2
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�
3
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.
4
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:
5
• 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.”
6
• 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,
7
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.”
8
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.
9
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.
10
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.
11
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).
12
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
3 HD 36,4 GB RAID 5
Unità di Backup DDS4
Windows 2003 Server
Server HP proliant DL380
3 HD 36,4 GB RAID 5
Unità di Backup DDS4
Windows 2003 Server
Server HP proliant DL380
3 HD 36,4 GB RAID 5
Unità di Backup DDS4
Windows 2003 Server
Server Fujitsu Siemens
HD 300 GB RAID 5
DVD CDRW
Sco Open Server 6.0
13
RACK 2 – Armadio Rack
Sistema Sistema Operativo
Server HP proliant DL380
3 HD 146,8 GB RAID 5
Server HP proliant DL380
3 HD 36,4 GB RAID 5
Unità di Backup DDS4
Windows 2003 Server
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
3 HD 36,4 GB RAID 5
Unità di Backup DDS4
Linux RED HAT ES4
Server HP proliant DL380
3 HD 36,4 GB RAID 5
Unità di Backup DDS4
Windows 2003 Server
Server Fujitsu Siemens
HD 300 GB RAID 5
DVD CDRW
Windows 2003 Server
Unità singole
Sistema Sistema Operativo
Server IBM Net Finity 5500
HD 4,495 GB RAID 5
Unità di Backup DDS4
Sco Unix Open server 5
Server IBM xSeries 225
HD 72,794 GB RAID 5
Unità di Backup: CDROM
Windows 2003 Server
PC - 1 HD Sco Unix Open server 5
PC - 1 HD Sco Unix Open server 5
PC - 1 HD Sco Unix Open server 5
14
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
15
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,
16
`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`)
)
17
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.
18
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
19
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,
20
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 è
21
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.
22
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.
23
• 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
24
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
25
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.
26
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.
27
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.
28
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,
29
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;
30
• 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.
31
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
32
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.
33
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:
34
• 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,…).
35
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:
36
• 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.
37
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;
38
• 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).
39
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
DB Server
6
3 Unità rack storage – almeno 9 TB - montabile in rack - Serial ATA
- RAID 0, 1, 5, 6
1
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
ATA – Monitor LCD almeno 19’’
17
8 Personal computer workstation - Quad-Core Xeon – RAM 8 GB -
HDD 500 GB - DVD±RW (±R DL) / DVD-RAM - Gigabit
4
40
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.
41
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.
42
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; Infrastrutture e Viabilità;
Mobilità ed Energia; 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,
43
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.
