UNIONE EUROPEA REPUBBLICA ITALIANA

UNIONE EUROPEA REPUBBLICA ITALIANA

Direzione Generale degli Affari Generali e Riforma della Regione Servizio dell’innovazione, progettazione, gare e contratti in ambito ICT

PROCEDURA APERTA PER LA REALIZZAZIONE DI UNA PIATTAFORMA INFORMATICA INTEGRATA PER LA GESTIONE DEL PROCESSO DI REDAZIONE DEL BOLLETTINO UFFICIALE DELLA REGIONE AUTONOMA DELLA SARDEGNA – DIGITAL BURAS

DISCIPLINARE TECNICO APPROVATO CON DETERMINAZIONE N. 38/XX.XX. DEL 10.02.2010

Indice

1 Acronimi e definizioni 3

2 Finalità dell’intervento e contesto di riferimento 3

2.1 Riferimenti normativi 4

3 Il Buras 5

3.1 Organizzazione e principali attività del Buras 6

3.2 Generazione e distribuzione del Bollettino: situazione attuale 6

4 Descrizione del sistema 8

4.1 Architettura generale 8

4.2 Requisiti funzionali 10

4.2.1 Autenticazione 10

4.2.2 Autorizzazione 10

4.2.3 Consultazione e ricerca 11

4.2.4 Gestione del processo redazionale 12

4.2.5 Acquisto e gestione dei pagamenti 13

4.2.6 DeskTop Publishing 14

4.2.7 Gestione delle notifiche e della distribuzione 15

4.2.8 Logging 16

4.3 Requisiti non funzionali 16

4.3.1 Scalabilità, portabilità e interoperabilità 16

4.3.2 Accessibilità, usabilità e rispetto dell’identità visiva della Regione Sardegna 16

4.3.3 Sicurezza del sistema e accesso alle informazioni 17

4.4 Dimensionamento 18

4.5 Vincoli tecnologici 18

4.5.1 Integrazione con il modulo di Identity Management regionale 18

4.5.2 Integrazione con il modulo di gestione dei pagamenti regionale 19

5 Forniture e Servizi 19

5.1 Servizi di sviluppo software. 19

5.1.1 Analisi e Business Process Reengineering 19

5.1.2 Disegno 20

5.1.3 Realizzazione 20

5.2 Fornitura postazioni di DTP e servizi accessori 21

5.3 Servizio di manutenzione adeguativa e correttiva 21

5.4 Installazione e configurazione della soluzione 22

5.5 Servizio di assistenza in remoto 22

5.6 Servizio di supporto per l’acquisizione della capacità d’uso 23

6 Modalità di esecuzione 24

6.1 Documenti di progetto 24

7 Livelli di servizio e commisurazione penali 26

7.1 Servizio di assistenza in remoto 26

7.2 Servizio di manutenzione adeguativa e correttiva 26

7.3 Presentazione di documenti di progetto 28

1 Acronimi e definizioni

Acronimo/definizione	Significato
IdM-RAS	Sistema di Identity Management della Regione Sardegna
DTP	Acronimo per DeskTop Publishing; indica i sistemi informatici dedicati alla creazione, impaginazione e produzione di materiale stampato dedicato alla produzione editoriale.
BPR	Acronimo per Business Process Reengineering; indica l’attività di reingegnerizzazione dei processi amministrativi.
Workflow	Insieme dei ruoli e dei processi che costituiscono un flusso di lavoro per la realizzazione di un prodotto- servizio a partire dalle fasi iniziali fino al suo completamento.
CSR	Acronimo per Centro Servizi Regionali; è la struttura tecnica che assicura il funzionamento dei diversi sistemi informatici dell'Amministrazione regionale e dei suoi Enti secondo precise modalità operative.
SIP	Acronimo per Sistema Integrato Portali.
Aggiudicatario	Impresa o RTI che si aggiudica l’appalto.
Buras	Acronimo per Bollettino Ufficiale della Regione Autonoma della Sardegna.
RSS	Acronimo per Really Simple Syndication; formato per la distribuzione di contenuti (detti “feed RSS”), leggibile attraverso l’uso di opportuni software “feed reader”.

2 Finalità dell’intervento e contesto di riferimento

In linea con la normativa nazionale e con le strategie di sviluppo comunitarie e nazionali, nel corso degli ultimi anni l’amministrazione regionale ha intrapreso il cammino verso la dematerializzazione dei propri documenti e atti, sostituiti da documenti informatici, firmati digitalmente o scansionati.

L’introduzione di strumenti che consentono la gestione documentale informatizzata all’interno dell’amministrazione ha richiesto e richiede il necessario ripensamento delle regole organizzative e procedurali. Il conseguimento degli obiettivi di miglioramento dell’efficienza e della qualità dei processi presuppone, infatti, una semplificazione degli stessi e dei relativi flussi informativi.

Il presente intervento è volto alla dematerializzazione del Bollettino Ufficiale della Regione Autonoma della Sardegna (BURAS), con sua produzione unicamente in formato digitale e conseguente abbattimento dei costi di produzione e distribuzione del Bollettino cartaceo.

Oggetto dell’appalto è l’attività di analisi e sviluppo di un sistema informativo per la gestione del ciclo di vita del Buras, che consenta l’inserzione on line delle pubblicazioni, l’informatizzazione del processo di redazione, la distribuzione e la consultazione tramite web. Transitoriamente e per un periodo non superiore a sei mesi la gestione avverrà con il sistema del doppio binario, in modalità mista cartacea e informatica.

Parallelamente l’amministrazione regionale adotterà i necessari provvedimenti per l’adeguamento delle norme e regole vigenti in materia di pubblicazione del Bollettino.

2.1 Riferimenti normativi

La redazione del bollettino ufficiale è disciplinata dalle seguenti fonti:

− Statuto speciale della Regione art. 33, comma 4;

− D.P.R. 19/05/1949, n. 250 “Norme di attuazione dello Statuto speciale della Regione Autonoma della Sardegna” art. 15;

− L.R. 10/12/1971, n. 32 “Pubblicazione obbligatoria per estratto nel Bollettino Ufficiale della Regione autonoma della Sardegna - Parte prima - di tutti i decreti del Presidente della Giunta regionale e degli Assessori”;

− D.P.G.R. 31/10/1986, n. 139 “Norme per la pubblicazione del Bollettino Ufficiale della Regione”;

− D.P.G.R. 29/12/1987, n. 149 “Modifica al decreto del Presidente della Giunta regionale 31 ottobre 1986, n. 139, recante: “Norme per la pubblicazione del Bollettino Ufficiale della Regione”;

− D.P.G.R. n. 354 del 21/11/1995 “Tariffe di vendita e di abbonamento, delle inserzioni negli annunzi legali e disposizioni varie nel Bollettino Ufficiale della Regione. Nuovo regolamento”;

− Art. 9, comma 12, della L.R. 29 maggio 2007, n.2 “Disposizioni per la formazione del bilancio annuale e pluriennale della Regione (legge finanziaria 2007)”;

− Deliberazione della Giunta regionale n. 49/8 del 5/12/2007 “Individuazione dei destinatari del Bollettino Ufficiale della Regione Autonoma della Sardegna in formato cartaceo”.

Sono inoltre di riferimento per la realizzazione del sistema Digital Buras le seguenti norme:

− Dlgs. 30 giugno 2003, n. 196 “Codice in materia di protezione dei dati personali”;

− Legge 9 gennaio 2004, n. 4 “Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici” (cd. Legge Stanca);

− Dlgs. 7 marzo 2005, n. 82 “Codice dell’amministrazione digitale”;

− Legge 18 giugno 2009, n. 69 “Disposizioni per lo sviluppo economico, la semplificazione, la competitività nonché in materia di processo civile” e s.m.i.;

− D.M. 8 luglio 2005, “Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici”

Affinché il sistema Digital Buras possa operare, l’Amministrazione adotterà le opportune azioni per l’aggiornamento dei regolamenti e delle leggi che disciplinano il Buras.

3 Il Buras

Il Buras è lo strumento legale di conoscenza delle leggi, dei regolamenti e degli atti in esso contenuti la cui pubblicazione si presume conforme all’originale e ne costituisce testo legale. È pubblicato in via ordinaria, ogni 10 giorni esclusi i festivi; ove la data di scadenza coincida con un giorno festivo la pubblicazione è anticipata al giorno precedente non festivo. La pubblicazione del bollettino può avvenire anche in supplementi ordinari e straordinari, strumento prescelto nel caso di testi molto lunghi, ad esempio leggi regionali o delibere di approvazione di circolari, o in ragione di scelte connesse alla trattazione omogenea di tipologie particolari di atti.

Il bollettino è suddiviso in tre parti principali i cui contenuti sono riassunti nella tabella che segue:

Parte I	Parte II	Parte III
Leggi e regolamenti regionali	Leggi e decreti dello Stato che interessano la Regione	Annunci e avvisi di cui era obbligatoria la pubblicazione nei F.A.L. (Fogli Annunzi Legali)
Decreti del Presidente della Regione	Circolari la cui divulgazione sia ritenuta opportuna	Annunzi e avvisi liberamente chiesti dagli interessati
Decreti assessoriali: in forma integrale o per estratto, che possono interessare la generalità dei cittadini	Annunci e avvisi prescritti da leggi e regolamenti vigenti nella Regione	Annunzi e avvisi prescritti da leggi dello Stato
Comunicati e disposizioni del Presidente della Regione, del Consiglio regionale e degli Assessori		Statuti comunali
Determinazioni dirigenziali		Altre tipologie di inserzioni
Sentenze

Tabella 1: La strutturazione del Buras

Le parti I e II costituiscono un unico fascicolo mentre la parte III è oggetto di separata pubblicazione, nella quale sono contenute anche le inserzioni dei soggetti privati.

Con riferimento alla tipologia di inserzionisti la principale differenziazione è tra soggetti pubblici e soggetti privati, i primi a loro volta distinguibili in interni, ovvero altre strutture dell’amministrazione regionale, ed esterni, ossia enti e agenzie regionali, Asl e aziende ospedaliere, pubbliche amministrazioni locali, organismi di diritto pubblico ed enti pubblici economici. I privati che procedono alla richiesta di pubblicazione sono principalmente società concessionarie di servizi pubblici, avvocati, curatori fallimentari.

Per quanto attiene alle tipologie di inserzioni si rinvia all’Allegato 3 - Esempi tipologie di inserzione.

3.1 Organizzazione e principali attività del Buras

L’Ufficio incaricato alla gestione del bollettino è il settore del Servizio Affari legislativi e del Buras – Direzione generale dell’area legale, che dispone di 10 dipendenti così distribuiti per qualifica funzionale:

− dipendenti in classe D: 3;

− dipendenti in classe C: 5;

− dipendenti in classe A: 2.

Sono assenti figure professionali con profilo informatico.

Le attività principali attualmente svolte all’interno del servizio sono di tipo gestionale (cura abbonamenti, ricezione inserzioni, vendita dei bollettini, funzioni contabili e gestione magazzino) e di tipo redazionale, finalizzate alla verifica e validazione delle richieste di inserzione.

In particolare, il servizio riceve gli atti da pubblicare trasmessi da soggetti interni ed esterni all’Amministrazione regionale. Qualora la pubblicazione sia a pagamento, previamente accerta il corretto versamento dei diritti, salvo le ipotesi di pubblicazione “a credito” che avvengono senza previo versamento delle somme, ma con regolarizzazione successiva.

Attualmente, nello svolgimento delle proprie competenze, il servizio interagisce con una pluralità di utenti: inserzionisti, abbonati e RTI aggiudicatario dell’appalto per l’esecuzione dei servizi di pubblicazione, stampa, consegna, spedizione del Buras e di creazione dei file destinati alla pubblicazione sul sito. Alla spedizione delle copie agli abbonati provvede Poste Italiane spa, con restituzione della documentazione attestante l’avvenuta spedizione e addebito sui libretti di spedizione intestati all’amministrazione.

Il Servizio interagisce, infine, con Poste Italiane spa per la tenuta del conto corrente intestato al Bollettino, al momento ancora attivo.

3.2 Generazione e distribuzione del Bollettino: situazione attuale

Con riguardo alla preparazione delle singole edizioni del Bollettino, l’attività si articola in varie fasi:

− il Servizio pianifica il calendario delle pubblicazioni e per ogni edizione predispone un fascicolo cartaceo, o in formato elettronico, che viene ritirato dal RTI incaricato del servizio di pubblicazione, stampa, consegna e spedizione;

− il RTI sopra citato, compone il testo rispettando il layout grafico del Bollettino, esegue l’impaginazione e trasmette la bozza al funzionario competente per le opportune verifiche;

− la positiva conclusione delle verifiche (“visto si stampi”) consente il passaggio alla fase di stampa, rifinitura e incellophanatura dei fascicoli da spedire;

− il RTI fornisce un documento in formato PDF che contiene il bollettino in formato elettronico. Il file viene inserito nel portale della regione, nella sezione relativa al Buras, dal Servizio Comunicazione e Trasparenza della Direzione generale della Presidenza. La copia presente

nel sito istituzionale attualmente non ha valore legale e nell’eventualità di discordanza tra il testo cartaceo e quello digitale prevale il primo;

− il RTI provvede, infine, alla consegna delle copie al magazzino, alla distribuzione all’ufficio postale interno ed alla consegna a Poste Italiane spa delle copie in spedizione agli abbonati, sulla base dell’indirizzario fornito dalla Regione, gestito mediante apposito programma elaborato dall’amministrazione.

Nel rinviare all’analisi organizzativa a carico dell’aggiudicatario in fase esecutiva, per chiarire il processo attualmente in uso presso il Servizio Affari legislativi e del Buras in Figura 1 è riportato lo schema del flusso di lavoro.

Figura 1: Attuale flusso del processo di redazione del Bollettino

4 Descrizione del sistema

L’offerente dovrà proporre e realizzare una soluzione atta a consentire l’inserzione on line delle pubblicazioni, previo pagamento del costo di inserzione ove previsto. Le inserzioni dovranno essere collezionate e composte all’interno del Buras, tramite idoneo software di DeskTop Publishing (DTP). Il bollettino così formato dovrà essere inserito in un apposito portale, con modalità tali da consentirne la navigabilità e distribuito in formato digitale agli abbonati.

Nei paragrafi seguenti sono descritti in dettaglio l’architettura del sistema di cui è richiesta la realizzazione e le funzionalità che esso dovrà fornire.

4.1 Architettura generale

L’offerente dovrà realizzare un sistema integrato basato su piattaforma web che includa le seguenti componenti:

- un sistema di gestione e produzione dei contenuti (CMS), composto almeno dai seguenti moduli:

o un portale accessibile dalla rete internet, che consenta la consultazione dei bollettini, da rendere disponibili anche in formato navigabile, e che metta a disposizione funzionalità avanzate di ricerca all’interno dell’archivio. Attraverso il portale, previa registrazione e autenticazione dell’utente (privato cittadino o dipendente di un ente pubblico), sarà possibile inserire un annuncio utilizzando appositi form che consentano anche il pagamento online dell’inserzione. L’utente dovrà poter accedere allo storico delle inserzioni da lui inviate, con viste elenco e di dettaglio;

o un modulo di gestione del processo di redazione, accessibile dalla rete interna da parte dei dipendenti del Servizio Affari Legislativi e del Buras. Il modulo dovrà gestire il workflow approvativo delle inserzioni e della pubblicazione del bollettino. Al modulo confluiranno le inserzioni inviate tramite il portale sopra citato;

o un modulo per la gestione delle notifiche e della distribuzione, che dovrà gestire l’invio, mediante sistemi di mailing-list e newsletter, della versione elettronica del bollettino (o di estratti di esso) agli utenti registrati che ne facciano richiesta, e permettere l’acquisto di singoli numeri o di abbonamenti in formato cartaceo.

- un sistema di DeskTop Publishing (DTP), che sarà impiegato per la composizione grafica e la produzione finale del bollettino. Il sistema dovrà permettere la gestione di più layout grafici consentendo anche la composizione dei diversi supplementi;

- un repository nel quale dovranno essere archiviati, tramite opportuni automatismi, i contenuti di ogni numero del bollettino e il file PDF di ogni bollettino pubblicato.

Il portale accedendo al repository e ai dati in esso contenuti fornirà all’utente la possibilità di consultare i bollettini, e di effettuare ricerche avanzate sull’archivio. Il sistema di DTP sarà alimentato attraverso uno spazio di lavoro (ad es. cartella condivisa o FTP) dove confluiranno le inserzioni approvate per la pubblicazione.

Con riferimento alle necessarie integrazioni con i sistemi attualmente esistenti e nella disponibilità dell’amministrazione, nel rinviarne la trattazione ai relativi paragrafi, si anticipa quanto segue.

Il sistema dovrà integrarsi con il modulo di Identity Management della Regione (IdM-RAS), per la registrazione degli utenti e la gestione delle autenticazioni; dovrà inoltre integrarsi con il sistema di gestione delle transazioni finanziarie della Regione per il pagamento delle inserzioni e degli abbonamenti.

A fini meramente illustrativi si riporta in Figura 2 un possibile schema del sistema Digital Buras; lo stesso non costituisce un vincolo architetturale o progettuale per le imprese concorrenti.

Figura 2: Schema architetturale esemplificativo del sistema Digital Buras

Nel seguito sono descritti i principali requisiti che dovranno essere soddisfatti dal sistema.

4.2 Requisiti funzionali

In questa sezione sono descritti i requisiti funzionali minimi, aggregati per aree di funzionalità omogenee, che l’applicazione software dovrà soddisfare. Nell’offerta tecnica dovranno essere specificati i dettagli della soluzione proposta e le eventuali caratteristiche migliorative.

Come specificato nel paragrafo 5.1.1 l’aggiudicatario, in fase di analisi, dovrà comunque rilevare eventuali altre esigenze di dettaglio, per la definizione di ulteriori requisiti funzionali.

Al fine di consentire un semplice utilizzo del sistema da parte degli utenti, tutte le pagine web dovranno essere corredate di opportuni testi esplicativi e introduttivi delle funzionalità offerte con eventuali rimandi ad altre pagine per ulteriori informazioni. Per ognuna delle funzionalità dovrà essere prevista una apposita sezione di aiuto (c.d. help in linea contestuale). Dell’intera soluzione offerta, dovrà essere fornita adeguata documentazione tecnica, oltre alla necessaria manualistica di utilizzo del prodotto.

4.2.1 Autenticazione

L’applicazione, in ragione del differente utilizzo da parte degli utenti, dovrà gestire sia l’accesso anonimo sia l’accesso autenticato a seguito di registrazione.

Per la registrazione e l’autenticazione degli utenti dovrà essere impiegato il modulo di Identity Management della Regione Sardegna (IdM-RAS). Si precisa che il sistema IdM-RAS è in corso di evoluzione e potrebbe subire delle modifiche, ancorché limitate, rispetto alla versione attuale. È a carico dell’aggiudicatario l’integrazione con il modulo IdM-RAS secondo le specifiche di integrazione allegate al presente documento (Allegato 1 - Manuale di integrazione IdM-RAS).

4.2.2 Autorizzazione

L’applicazione dovrà consentire l’accesso differenziato sulla base del ruolo dell’utente, cui dovrà essere abbinato un sottoinsieme delle funzioni complessive del sistema. Sarà onere dell’aggiudicatario sviluppare le funzioni di autorizzazione degli utenti, attualmente non gestite dal modulo IdM-RAS.

A titolo non esaustivo si chiarisce sin d’ora che dovrà essere consentito l’accesso differenziato, al back-office (solo da rete interna) e al front-office del sistema, almeno in base alle seguenti tipologie di utente con descrizione delle azioni eseguibili:

front-office

- utente base: accesso anonimo in sola consultazione. Può effettuare ricerche, navigare e consultare i bollettini Buras;

- utente registrato: oltre alle funzionalità dell’utente base può iscriversi a mailing list personalizzate, acquistare bollettini singoli o in abbonamento, ecc.;

- inserzionista: oltre alle funzionalità previste per le precedenti tipologie di utente può inserire e gestire gli annunci.

back-office

- redattore: verifica e valida le inserzioni. In via transitoria carica a sistema le inserzioni pervenute per via tradizionale (fax, RR, a mano).

- impaginatore: operatore DeskTop Publishing per impaginazione grafica. Dispone di una postazione dedicata alla produzione editoriale e interviene nella parte finale del ciclo redazionale per l’impaginazione del bollettino.

- caporedattore: oltre alle funzionalità previste per il redattore autorizza la pubblicazione/distribuzione del bollettino.

- amministratore: gestisce il sistema attraverso una interfaccia grafica web-based con la possibilità di impostarne i parametri di funzionamento (profilazione utenti, configurazione modulo notifiche, pagamenti etc.).

L’applicazione dovrà gestire l’eventualità che un utente abbia più ruoli, dando la possibilità di selezionare quello con cui si desidera accedere al sistema.

4.2.3 Consultazione e ricerca

L’applicazione software dovrà consentire l’archiviazione dei bollettini per la loro successiva consultazione via web. I bollettini dovranno essere consultabili mediante funzionalità di ricerca per tipo e contenuto dell’inserzione.

Per questa area di funzionalità, il sistema dovrà prevedere in particolare:

- la consultazione dei bollettini in formato navigabile mediante link ipertestuali. Dovrà essere implementata la cd. “faceted navigation” dei bollettini che, quindi, dovranno essere opportunamente strutturati;

- il download dei bollettini in formato PDF (firmato digitalmente).

- la ricerca di base ed avanzata sull’archivio dei bollettini. I filtri di ricerca dovranno prevedere ricerche a testo libero, utilizzando i connettori logici di vario tipo, sui campi che caratterizzano l’annuncio e dovranno essere preventivamente concordati con la committenza;

- la vista “a calendario” per accedere all’archivio dei bollettini.

Dovrà essere caricato sull’archivio anche lo storico dei bollettini, che sono disponibili in formato PDF (dal 2004) e attualmente consultabili sul portale della Regione Sardegna all’indirizzo:

xxxx://xxx.xxxxxxx.xxxxxxxx.xx/xxxxxxx/xxxxxxxxx/xxxxx/

Per ogni bollettino storico l’aggiudicatario dovrà indicizzare il solo sommario, al fine di garantire l’utilizzo di funzioni di ricerca a testo libero sui contenuti e per range di date.

Sarà positivamente valutata, come elemento migliorativo dell’offerta, la trasformazione dei bollettini storici per consentirne la navigazione secondo il metodo “faceted navigation” e rendere disponibili le funzionalità di ricerca avanzata.

Per fornire ad eventuali applicazioni e sistemi informativi regionali esterni al sistema Digital Buras un accesso alle opzioni di ricerca ed alle inserzioni contenute nel repository, tutte le funzionalità garantite dal motore di ricerca dovranno essere esposte tramite un opportuno web service in standard SOAP.

4.2.4 Gestione del processo redazionale

In questa area di funzionalità ricadono le funzioni per la composizione del bollettino in termini di contenuti, dalla raccolta delle inserzioni caricate dagli utenti tramite form on-line alla produzione del bollettino definitivo. Dovranno essere implementate le funzioni tipiche di un CMS allo scopo di gestire l’intero ciclo redazionale di generazione, approvazione e pubblicazione degli annunci.

Il presente paragrafo descrive le principali funzionalità di redazione suddivise per front-office e back-office, lo stato delle inserzioni e le funzionalità correlate che il sistema dovrà includere e gestire.

Front-office:

- Creazione guidata (wizard), secondo schemi predefiniti delle inserzioni e loro inoltro al sistema. L’aggiudicatario dovrà realizzare i wizard secondo le tipologie di inserzioni e gli esempi di annunci specificati nell’Allegato 3 - Esempi tipologie di inserzione. Costituirà elemento migliorativo dell’offerta la possibilità per l’utente amministratore di configurare i wizard a fronte di nuove tipologie di inserzioni.

- Creazione libera delle inserzioni mediante l’inserimento di testo non strutturato in un form generico.

- Classificazione delle inserzioni in base alla tipologia, in base ad una tassonomia concordata con la committenza.

- Cruscotto informativo da cui l’utente potrà accedere a tutte le informazioni sulle sue inserzioni quali lo stato, la data di presentazione, il bollettino di riferimento, l’importo corrisposto, etc.

- Gestione dello storico di tutte le inserzioni presentate con viste elenco e di dettaglio per gli utenti inserzionisti.

- Modifica o annullamento delle inserzioni entro una data configurabile a sistema e comunque non successivamente alla sua approvazione.

Back-office

- Implementazione del workflow approvativo delle inserzioni e del processo di redazione (in base al ruolo e/o all’utente). Dovranno essere previsti meccanismi di notifica agli utenti coinvolti nel workflow redazionali sulle modifiche di stato. Il workflow preimpostato dovrà essere comunque configurabile e personalizzabile da parte dell’utente amministratore.

- Gestione della scrivania dei singoli utenti coinvolti nel processo di redazione. Il sistema dovrà fornire un cruscotto riepilogativo evidenziando attività, scadenze e stato.

Il sistema dovrà prevedere e gestire almeno i seguenti stati dell’inserzione:

- presentata: l’utente ha caricato con successo l’inserzione nel sistema;

- accettata: la redazione ha approvato il testo dell’inserzione per la sua pubblicazione;

- rifiutata: la redazione non ha approvato il testo dell’inserzione per la sua pubblicazione;

- in revisione: l’inserzionista potrà richiedere di rettificare la propria inserzione, purché questa non sia già nello stato “pubblicata”;

- annullata: l’inserzione è stata annullata da parte dell’inserzionista;

- pubblicata: l’inserzione è pubblicata sul bollettino. La pubblicazione dell’inserzione potrà essere vincolata al suo pagamento.

Per quanto riguarda lo stato “in revisione”, il sistema deve consentire, fino alla pubblicazione dell’inserzione, una rettifica della stessa. A seguito di ogni modifica, l’inserzione sarà assoggettata nuovamente all’intero iter approvativo. Dovrà essere previsto un periodo temporale entro il quale la modifica dell’inserzione non comporta un cambiamento della data di pubblicazione prevista. Nel caso la modifica avvenga oltre tale termine, il sistema dovrà mostrare automaticamente all’inserzionista un messaggio di avviso opportuno.

Per quanto riguarda invece lo stato “annullata”, l’inserzionista deve poter richiedere l’annullamento dell’inserzione entro un termine temporale configurabile. L’annullamento dovrà comunque poter essere effettuato solamente prima di aver effettuato il pagamento, per quanto riguarda le inserzioni non gratuite e non “a credito”.

A seguito della presentazione dell’inserzione, l’utente dovrà confermare la richiesta di pubblicazione, selezionando l’apposito link inserito in una mail inoltrata automaticamente dal sistema.

L’applicazione dovrà inviare una e-mail di notifica all’inserzionista ad ogni cambiamento di stato, e con l’indicazione, al termine del processo di approvazione, del numero/data del bollettino di pubblicazione.

4.2.5 Acquisto e gestione dei pagamenti

L’applicazione software dovrà consentire il pagamento on-line del costo dell’inserzione e l’acquisto di singoli numeri del bollettino ufficiale e di abbonamenti in formato cartaceo.

Per quanto riguarda la gestione delle transazioni finanziarie l’applicativo dovrà integrarsi con il modulo di pagamento della RAS, le cui specifiche sono riportate nell’ Allegato 2 - Manuale di integrazione Sistema di Pagamento JPayGate-RAS.

In linea generale, l’applicazione dovrà permettere di effettuare gli acquisti dei bollettini cartacei e il pagamento delle inserzioni implementando le funzionalità tipiche di un sito di e-commerce, quali la gestione del carrello della spesa, del catalogo dei prodotti e dello storico degli acquisti per ogni utente.

Il sistema dovrà prevedere le seguenti funzionalità:

- Gestione dell’anagrafe degli inserzionisti e degli abbonati, attraverso una base dati opportuna. Gli inserzionisti e gli abbonati riceveranno, in automatico, il bollettino ed altre informazioni (reminder di scadenza dell’abbonamento, conferma dell’acquisto, etc.) per posta elettronica.

- Acquisto da parte degli utenti registrati di singoli numeri, singoli fascicoli, e di abbonamenti.

- Calcolo automatico (mediante algoritmo che conta righe e parole) del costo dell’inserzione. L’utente potrà attivare questa funzionalità per conoscere in anticipo quali sono i costi dell’inserzione che intende pubblicare.

- Gestione del carrello della spesa e implementazione di tutte le funzionalità tipicamente impiegate dai negozi on-line (Gestione catalogo, listini, recapiti, etc.).

- Gestione dello storico dei pagamenti effettuati.

- Produzione di report statistici e resoconti economici con informazioni quali numero abbonati/copie distribuite/annunci, entrate/uscite, etc.

Il sistema dovrà, inoltre, prevedere la possibilità per alcune tipologie di inserzione, c.d. “a credito”, di procedere alla regolarizzazione del pagamento in epoca successiva rispetto all’invio dell’inserzione stessa.

4.2.6 DeskTop Publishing

Il sistema dovrà consentire l’impaginazione grafica del bollettino a partire dagli annunci creati dagli inserzionisti e approvati nel workflow redazionale. Il processo di redazione prevede l’intervento dell’utente “impaginatore” per la composizione grafica del bollettino.

A tale scopo, dovranno essere fornite delle postazioni di DeskTop Publishing con software opportuno preinstallato per la composizione grafica del bollettino. Il software dovrà disporre di tutte le funzionalità necessarie alla impaginazione ed alla redazione.

Il software di DTP dovrà garantire che il documento finale del bollettino, in formato PDF, sia predisposto secondo modalità tali da rendere lo stesso rispondente alle regole tecniche in materia di conservazione sostitutiva dei documenti.

Unitamente al software di DTP, dovranno essere forniti dall’aggiudicatario layout pre-configurati per le tre parti del bollettino, che consentano l’impaginazione automatica o semi-automatica delle stesse. L’aggiudicatario dovrà proporre un layout che consenta una facile lettura e consultazione del Buras; tali layout saranno oggetto di approvazione, in corso di esecuzione del contratto, da parte del Servizio Affari Legislativi e del Buras.

Il dettaglio della fornitura hardware e software è definito al paragrafo 5.2.

4.2.7 Gestione delle notifiche e della distribuzione

Come accennato precedentemente l’applicazione software dovrà includere tutte le funzionalità per la notifica degli eventi a tutti gli utenti registrati nel sistema.

Dovranno essere inoltrate agli utenti, via e-mail, almeno le seguenti tipologie di notifica:

- richiesta di conferma sulla volontà di pubblicare l’inserzione;

- informazioni sullo stato delle loro inserzioni;

- conferma sull’avvenuta iscrizione alla mailing list;

- informazioni su eventuali interruzioni del servizio;

- ricevute di acquisto di abbonamenti o di singoli numeri;

- ricevute di pagamento delle inserzioni.

La distribuzione telematica delle copie del bollettino, in formato PDF firmato digitalmente1, agli abbonati e/o agli utenti che acquistano singoli numeri, avverrà via posta elettronica. Per evitare problemi di banda potrà essere impostato l’invio di mail contenenti unicamente il link da cui sarà possibile effettuare il download del bollettino.

L’applicazione software dovrà inoltre consentire, per gli utenti registrati, la sottoscrizione di una mailing list per la distribuzione dei bollettini o di singole categorie di inserzione. Gli utenti che aderiranno al servizio riceveranno il titolo degli annunci presenti nelle categorie che hanno selezionato, con l’indicazione del numero di bollettino in cui sono presenti, ed il link relativo.

Nell’interfaccia di amministrazione del sistema dovrà essere prevista una apposita sezione da cui sia possibile configurare i parametri di funzionamento per la gestione delle notifiche e della distribuzione (server di posta, abilitazione notifiche, nuove notifiche, etc.).

Dovranno inoltre essere garantite le seguenti funzionalità:

- servizio di newsletter e feed RSS;

- predisposizione di sondaggi agli utenti mediante semplici quesiti con risposte a scelta multipla. I sondaggi saranno mostrati nella home page del portale e/o in sezioni apposite.

Tra gli oneri a carico del Servizio affari legislativi e del Buras vi è l’inoltro, mediante FTP, al Servizio Trasparenza della Presidenza, delle Leggi Regionali pubblicate nel bollettino con supplemento ordinario. Il sistema dovrà implementare la funzionalità di inoltro automatico delle leggi a tale Servizio con le stesse modalità, o eventualmente con altri meccanismi da concordare con la committenza.

1 Il Direttore del servizio dispone di un kit di firma digitale.

4.2.8 Logging

Tutte le operazioni svolte dagli utenti dovranno essere opportunamente registrate su file per successive attività di audit. Si dovrà prevedere un processo di tracciamento multi-livello dei messaggi di sistema (logging) da concordare in corso d'opera.

4.3 Requisiti non funzionali

L’architettura e i linguaggi di programmazione da impiegare nella realizzazione dell’applicazione software sono rimessi alla scelta dell’offerente. Saranno, tuttavia, valutate positivamente soluzioni che utilizzino software Open Source in accordo con le linee guida definite dal Ministero per l’Innovazione e le Tecnologie ed in considerazione degli obiettivi generali di contenimento dei prezzi, trasparenza e sicurezza, indipendenza dal fornitore e riusabilità.

In questa sezione sono brevemente descritti i requisiti non funzionali del sistema che riguardano aspetti di tipo qualitativo, organizzativo e di sicurezza.

4.3.1 Scalabilità, portabilità e interoperabilità

Il sistema dovrà essere scalabile per consentire un eventuale incremento del numero e della tipologia di utenze. Anche il numero e la tipologia di servizi potranno, in futuro, variare; pertanto si dovrà progettare un sistema modulare che faciliti l’implementazione di nuove funzionalità e l’adeguamento del software alle variazioni normative che potrebbero verificarsi. L’aggiudicatario è comunque tenuto ad adeguare il sistema alle modifiche normative o organizzative che dovessero verificarsi nel periodo di vigenza del contratto.

La soluzione dovrà, altresì, essere indipendente dalla sottostante piattaforma applicativa per garantire la sua portabilità in altri ambienti operativi.

Infine, considerato che il sistema potrà in futuro dover interagire con altri sistemi informativi regionali, saranno valutate positivamente architetture applicative orientate “al servizio” e facilmente integrabili in nuovi contesti.

4.3.2 Accessibilità, usabilità e rispetto dell’identità visiva della Regione Sardegna

La soluzione offerta dovrà rispettare la normativa vigente in materia di accessibilità dei contenuti, con particolare riferimento alla Legge n. 4 del 9 gennaio 2004 (cd. “Legge Stanca”) ed al D.M. 8 luglio 2005. I documenti PDF eventualmente generati in automatico dal sistema dovranno essere accessibili anch’essi, secondo le indicazioni contenute nella manualistica sull’accessibilità dei documenti elettronici pubblicata nel sito XxxxxxXxxxxxx.xxx.xx ed in particolare nella pagina:

xxxx://xxx.xxxxxxxxxxxxx.xxx.xx/xxxxxxxxxx/xxxxxxxxxxxx/xxxxx.xxx#xxxxxxxxxxxx

Con riferimento alla usabilità dei siti web, la soluzione offerta dovrà soddisfare i requisiti relativi a

- percezione: le informazioni e i comandi necessari per l'esecuzione delle attività devono essere sempre disponibili e percettibili;

- comprensibilità: le informazioni e i comandi necessari per l'esecuzione delle attività devono essere semplici da capire e da usare;

- operabilità: le informazioni e comandi devono essere tali da consentire una scelta immediata della azione adeguata per raggiungere l'obiettivo voluto;

- coerenza: i simboli grafici, i messaggi e le azioni devono avere gli stessi significati in tutto il sistema;

- trasparenza: il sistema deve comunicare chiaramente il suo stato e gli effetti delle azioni compiute. All'utente devono essere comunicate le necessarie informazioni per la corretta valutazione della dinamica delle azioni intraprese;

- apprendibilità: il sistema deve essere progettato perché l'apprendimento del suo utilizzo da parte dell'utente possa avvenire in tempi brevi e con minimo sforzo;

- aiuto e documentazione: le pagine web devono contenere opportuni testi esplicativi e introduttivi delle funzionalità offerte, per ognuna delle quali dovrà essere prevista una apposita sezione di aiuto (help in linea contestuale).

- tolleranza agli errori: il sistema deve prevenire gli errori e, qualora questi accadano, devono essere forniti appropriati messaggi che indichino chiaramente il problema e le azioni necessarie per recuperarlo;

- celerità nei tempi di risposta: il sistema deve garantire la riduzione al minimo dei tempi di latenza tra l’interrogazione e la produzione del corrispondente output, a tal fine la soluzione dovrà essere sviluppata disaccoppiando opportunamente le varie parti che lo compongono (ad es.: separazione tra front-office e back-office; motore di ricerca separato dal resto dell’applicativo) per evitare che un eccessivo carico di lavoro rallenti la navigazione sul portale.

Infine, la soluzione offerta dovrà, per quanto concerne il portale accessibile dalla rete internet, rispettare i canoni grafici e stilistici dei portali regionali.

4.3.3 Sicurezza del sistema e accesso alle informazioni

Il sistema dovrà rispettare le pratiche comuni e consolidate in materia di sicurezza delle applicazioni web. In particolare, devono essere rispettati i requisiti di:

- riservatezza: le informazioni gestite dall’applicativo web devono essere accessibili direttamente e indirettamente solo agli utenti che ne hanno diritto e che sono espressamente autorizzati a conoscerle;

- integrità: le informazioni gestite dall’applicativo web devono essere protette da alterazioni (modifiche, danneggiamenti o cancellazioni improprie) ad opera di utenti non autorizzati;

- disponibilità: le informazioni gestite dall’applicativo web devono essere sempre accessibili agli utenti che ne hanno diritto, nei tempi e nei modi previsti.

Per la verifica delle caratteristiche di sicurezza dell’applicazione, dovranno essere concordati con la committenza dei test di “penetrazione” intesi a verificare la solidità e la vulnerabilità dell’applicazione.

Per quanto riguarda i dati sensibili eventualmente gestiti dall’applicazione si dovrà fare riferimento alle norme in materia di trattamento dei dati personali, in particolare il Decreto legislativo 30 giugno 2003, n. 196 e s.m.i..

4.4 Dimensionamento

Al fine di una valutazione di massima del sistema e delle funzionalità che dovranno essere implementate e gestite, l’offerente dovrà considerare anche i seguenti aspetti:

- i potenziali inserzionisti sono circa un migliaio, mentre il numero di inserzioni che annualmente sono pubblicate sul Buras non superano le quattromila unità;

- gli utenti che potrebbero richiedere l’iscrizione alla mailing list, in base alle diverse categorie, sono stati stimati in circa 20.000 unità;

- l’ufficio Buras, che si occuperà della redazione del bollettino, è attualmente costituito da 10 dipendenti per cui si prevede che gli utenti che accederanno al back office del sistema con ruoli di redazione siano circa una decina;

- la sezione dedicata al Buras del Portale Regionale, nel corso del 2009, ha registrato circa 220.000 accessi;

- il numero di ricerche che si stima saranno effettuate è mediamente di 5/minuto con picchi di accessi contemporanei potenzialmente elevati.

4.5 Vincoli tecnologici

In questa sezione sono presentati i vincoli di natura tecnologica di cui l’offerente dovrà tener conto nella formulazione dell’offerta. Tali vincoli derivano da consolidate infrastrutture software, nonché dal modello organizzativo adottato presso la Regione Sardegna. In corso di esecuzione dell’appalto, per tutte le integrazioni di seguito specificate l’amministrazione regionale, per il tramite della propria società in house, Sardegna IT, garantirà il necessario supporto tecnico.

4.5.1 Integrazione con il modulo di Identity Management regionale

La Regione Sardegna dispone di un proprio sistema per la gestione delle identità digitali degli utenti (Identity Management - IdM) con funzionalità di “single sign-on”, basato sullo standard SAML

2.0. Il sistema gestisce l’anagrafe degli utenti e implementa le funzionalità di autenticazione per i servizi ad accesso non anonimo; non dispone invece di funzionalità di autorizzazione e gestione dei ruoli, funzionalità che, come descritto nei paragrafi precedenti, dovrà avere il sistema oggetto del presente appalto.

Il sistema Digital Buras dovrà integrarsi con il modulo di autenticazione sia per accedere al front- office sia al back-office.

Le specifiche tecniche di integrazione con il modulo IdM regionale sono contenute nel documento Allegato 1 - Manuale di integrazione IdM-RAS.

4.5.2 Integrazione con il modulo di gestione dei pagamenti regionale

La Regione Sardegna ha acquisito un proprio sistema di gestione delle transazioni finanziarie lato back-office, che supporta molteplici modalità di pagamento. Il modulo gestisce solo le transazioni finanziarie e non fornisce alcuna funzionalità di e-commerce quali la gestione del carrello, dei cataloghi e lo storico degli acquisti.

Le funzionalità del Digital Buras, che prevedono acquisti on line (abbonamenti e pagamento inserzioni) dovranno utilizzare tale modulo per l’effettuazione dei pagamenti.

5 Forniture e Servizi

In questo capitolo sono descritte con maggiore dettaglio le forniture e i servizi oggetto del presente appalto e necessari alla realizzazione e conduzione del sistema.

5.1 Servizi di sviluppo software

L’aggiudicatario dovrà realizzare il sistema richiesto attraverso lo sviluppo di un applicativo software ad-hoc, nell’offerta dovranno essere descritte le tecnologie software da utilizzare come middleware (DBMS, application server, etc.), il S.O. e la metodologia di sviluppo proposta.

In considerazione degli obiettivi generali di contenimento dei prezzi, sostenibilità dell’intervento, trasparenza e sicurezza, indipendenza dal fornitore e riusabilità, sarà valutata positivamente la scelta di tecnologie software open-source per i software di base (S.O., DBMS, application server, etc.).

L’attività di sviluppo software dovrà comprendere le fasi di:

- analisi e reingegnerizzazione di processo (Business Process Reengineering)

- progettazione esecutiva

- realizzazione

meglio dettagliate nei paragrafi seguenti. Per l’espletamento delle attività l’aggiudicatario dovrà avvalersi di un team composto da analisti, progettisti e sviluppatori con adeguate competenze maturate sulle tecnologie utilizzate.

5.1.1 Analisi e Business Process Reengineering

In corso di esecuzione l’aggiudicatario dovrà completare e integrare l’analisi preliminare contenuta nel presente documento, con particolare riferimento alla situazione organizzativa ed ai processi attualmente adottati dal Servizio Affari Legislativi e del Buras per la redazione del bollettino. A seguito di questa attività e sulla base delle informazioni raccolte, l’aggiudicatario dovrà presentare un piano riorganizzativo dei processi interni (Business Process Reengineering) che sia funzionale all’aumento dell’efficienza e dell’efficacia dell’azione del Servizio, e che costituirà la base per le successive fasi di progettazione e realizzazione del sistema Digital Buras.

In particolare, l’aggiudicatario dovrà definire in dettaglio:

- il workflow approvativo, dalla raccolta delle inserzioni all’autorizzazione alla stampa della bozza finale del bollettino;

- i ruoli all’interno del sistema;

- le azioni previste per ciascun ruolo, con il dettaglio delle informazioni in input e in output;

tenendo anche conto delle competenze e mansioni attuali del personale del Servizio ed evidenziando i fabbisogni formativi derivanti dalla riorganizzazione.

Il documento finale di analisi avente ad oggetto la riorganizzazione dovrà essere approvato dal Servizio Affari Legislativi e del Buras.

All’interno dell’offerta tecnica dovranno essere descritti gli strumenti e le metodologie che si propone di utilizzare per l’esecuzione delle attività sopra indicate.

5.1.2 Disegno

Ultimata l’analisi e ridefiniti i processi, l’aggiudicatario dovrà predisporre la documentazione di disegno della soluzione software da realizzare.

L’aggiudicatario dovrà produrre una serie di documenti tecnici di dettaglio sull’architettura e il funzionamento della soluzione software, inclusi diagrammi redatti secondo il linguaggio di modellazione UML, diagrammi E-R, ecc.

5.1.3 Realizzazione

A seguito della approvazione da parte della stazione appaltante dei documenti di disegno prodotti, l’aggiudicatario dovrà predisporre le attività di realizzazione della soluzione software.

Durante questa fase il team di sviluppo dovrà implementare quanto dettagliato nella documentazione di disegno. Il codice sorgente sviluppato dovrà essere adeguatamente commentato e documentato (es. mediante javadoc nel caso di linguaggio Java), e per ogni “unità” di codice dovranno essere predisposti dei test unitari per la verifica del suo corretto funzionamento.

Al termine della fase di realizzazione dovranno essere rilasciati:

- il codice sorgente;

- la documentazione del codice sorgente;

- gli script per la configurazione delle basi di dati;

- i report con gli esiti dei test unitari;

- il manuale utente in formato PDF, corredato di screen-shot illustrativi, per gli utenti interni (dipendenti del Servizio Affari Legislativi e del Buras);

- il manuale utente in formato PDF, corredato di screen-shot illustrativi, per gli utenti esterni (inserzionisti e abbonati).

La società aggiudicatrice dovrà coinvolgere la committenza mediante il rilascio periodico di prototipi e/o versioni parziali del sistema in corso di sviluppo.

Il codice sorgente dell’applicazione dovrà essere ceduto all’Amministrazione regionale che ne acquisirà tutti i diritti di utilizzo. I file che compongono l’applicazione dovranno essere raccolti in una struttura di facile comprensione.

5.2 Fornitura postazioni di DTP e servizi accessori

Per consentire al personale del Servizio Affari Legislativi e del Buras di realizzare autonomamente il bollettino, l’aggiudicatario dovrà fornire 3 postazioni di Desk-Top Publishing, ciascuna composta da:

- Licenza d’uso di un software di Desk-Top Publishing che risponda ai requisiti di cui al paragrafo 4.2.6;

- PC di prestazioni adeguate al funzionamento del software di cui sopra, fornito con mouse, tastiera e monitor da 16,7 milioni di colori di dimensione non inferiore a 24 pollici e aspect ratio pari a 16:9 o 16:10.

Le postazioni devono essere fornite pienamente operative con il software già installato e configurato.

Per una durata di 24 mesi i prodotti componenti la postazione di DTP dovranno essere forniti in garanzia. Sarà positivamente valutato l’ampliamento del periodo di garanzia.

In caso di guasto gli apparati dovranno essere ritirati presso la sede di installazione entro un giorno lavorativo dalla data di segnalazione.

Infine, l’aggiudicatario dovrà garantire, durante l’intera esecuzione del contratto, il servizio di assistenza in remoto, avvalendosi dell’help desk di cui al paragrafo 5.5.

5.3 Servizio di manutenzione adeguativa e correttiva

L’aggiudicatario dovrà prestare, durante l’intera esecuzione del contratto,, il servizio di manutenzione adeguativa e correttiva (MAC) sulla piattaforma software sviluppata, avvalendosi di personale qualificato e con tempi di intervento definiti nel seguito.

Il servizio dovrà garantire

- la diagnosi e la rimozione delle cause e degli effetti dei malfunzionamenti delle applicazioni sviluppate (manutenzione correttiva), per ripristinarne le caratteristiche di esercizio venute meno a seguito di difetti manifestatisi dopo il rilascio o per correggere malfunzionamenti del sistema o comportamenti non rispondenti alle specifiche funzionali;

- l’attività di manutenzione volta ad assicurare la costante aderenza delle procedure e delle applicazioni realizzate alla evoluzione dell’ambiente tecnologico del sistema informativo e dei requisiti organizzativi e normativi, fermi restando gli iniziali requisiti di progettazione (manutenzione adeguativa). Si precisa che tale servizio non copre la realizzazione di nuove funzionalità.

Il servizio sarà garantito attraverso appositi strumenti di bug tracking e da un help desk di secondo livello interfacciato con l’help desk di primo livello di cui al paragrafo 5.5.

5.4 Installazione e configurazione della soluzione

La soluzione sviluppata dovrà essere installata e configurata, a cura dell’aggiudicatario, sugli apparati presso il data center della Regione. Le modalità esecutive di questa attività saranno meglio dettagliate in fase esecutiva.

La soluzione dovrà essere compatibile con la tecnologia di virtualizzazione VMWare ESX3.5 (xxxx://xxx.xxxxxx.xxx/xxxxxxxxx/xxxxxxxxxxxxx/xxxxxx.xxx).

L’aggiudicatario dovrà garantire le necessarie attività di trasferimento delle competenze al fine di consentire l’esecuzione di tutte le attività di gestione della soluzione da parte dell’amministrazione regionale.

5.5 Servizio di assistenza in remoto

L’aggiudicatario dovrà attivare un servizio di help desk di primo livello dedicato al supporto del personale del Servizio Affari Legislativi e del Buras nelle attività di redazione del bollettino con l’applicazione software realizzata. Il servizio dovrà prevedere la ricezione, il tracciamento e la gestione delle chiamate per:

- segnalazione di malfunzionamenti;

- richiesta di chiarimenti sul funzionamento del sistema;

riguardante le funzionalità di back-office degli applicativi sviluppati ed il software di DTP fornito.

Alla data di messa in produzione del sistema, l’aggiudicatario dovrà comunicare un numero telefonico e un indirizzo di posta elettronica dedicati a questo servizio. Tali riferimenti dovranno essere indicati sul sito web dell’applicativo ed in calce ad ogni comunicazione scritta, via e-mail o lettera, del servizio di help-desk verso gli utenti interni del sistema.

Gli orari di ricezione delle segnalazioni telefoniche saranno i seguenti: dal lunedì al venerdì dalle

09.00 alle 18.00. Dopo tali orari dovrà essere attiva una segreteria telefonica che registrerà le chiamate, che dovranno intendersi ricevute alle ore 09.00 del giorno lavorativo successivo.

Nell’offerta dovrà essere descritto il modello di funzionamento dell’help desk, inclusivo delle modalità di attivazione dell’help desk di secondo livello in presenza di malfunzionamenti.

Una volta completate le procedure risolutive dei malfunzionamenti e dopo aver aggiornato il sistema in produzione, il personale dell’help desk di primo livello dovrà comunicare all’utente autore della segnalazione la risoluzione del malfunzionamento riscontrato.

L’aggiudicatario dovrà rendere disponibili, per l’effettuazione di verifiche e controlli sull’erogazione del servizio da parte dell’Amministrazione, i seguenti dati:

- chiamate telefoniche o segnalazioni via e-mail ricevute, con indicazione del numero progressivo e l’identificativo della richiesta di intervento (ticket);

- data e ora di ricezione della richiesta;

- la classe di rischio e la descrizione del malfunzionamento;

- data e ora della risoluzione del malfunzionamento segnalato (chiusura del ticket).

Sulla base delle segnalazioni ricevute, il servizio di help desk dovrà elaborare e mantenere costantemente aggiornate le risposte alle domande frequenti (FAQ), le quali dovranno essere rese accessibili dal lato back-office dell’applicazione web.

5.6 Servizio di supporto per l’acquisizione della capacità d’uso

Per consentire l’acquisizione, da parte del personale del Servizio Affari Legislativi e del Buras, delle competenze necessarie per il corretto utilizzo del sistema informatico Digital Buras, l’aggiudicatario dovrà fornire un adeguato supporto. In particolare, l’attività di supporto dovrà riguardare sia l’applicativo Digital Buras, che il sistema di DTP fornito a suo corredo.

Ai fini sopra esposti l’aggiudicatario dovrà predisporre un piano di addestramento con l’indicazione delle giornate erogate (con un minimo di 50 ore) e del materiale didattico fornito a supporto. Dovranno essere preparate delle “quick-guide” (guide brevi di rapida consultazione), in formato PDF, una per ciascun “ruolo” previsto dall’applicativo, con una descrizione puntuale dei passi da seguire per l’espletamento delle varie attività e funzioni previste per il ruolo. Dovrà inoltre essere preparata una quick-guide, sempre in formato PDF, che descriva l’utilizzo delle funzioni principali del sistema di DTP. Il calendario delle giornate di addestramento dovrà essere concordato con il Servizio Affari Legislativi e del Buras.

L’aggiudicatario dovrà, inoltre, garantire l’affiancamento on site ai dipendenti del Servizio Affari Legislativi e del Buras per la composizione grafica del bollettino (DTP) per le prime dieci uscite a partire dalla messa in produzione del sistema. A tale scopo l’offerente dovrà predisporre un piano di affiancamento da descrivere nell’offerta tecnica. Costituirà elemento migliorativo dell’offerta l’estensione del periodo di affiancamento.

6 Modalità di esecuzione

L’aggiudicatario potrà svolgere le attività di realizzazione della soluzione proposta presso la propria sede, fatte salve quelle che presuppongono interazione con il personale dell’amministrazione (come ad esempio, analisi organizzativa, test di verifica, raccolta dei requisiti, dimostrazioni, ecc).

Per tutte le fasi del ciclo di sviluppo della soluzione dovrà essere garantita la predisposizione, e successiva condivisione, della documentazione.

Dovranno utilizzati ambienti distinti (almeno sviluppo, test e produzione), con opportuno tracciamento delle attività e dei versionamenti, gli ambienti dovranno essere accessibili al personale individuato dall’amministrazione regionale anche al fine di verificare in corso d’opera le prestazioni realizzate.

Dovranno essere predisposti opportuni user acceptance test, che dovranno in ogni caso precedere la messa in produzione di ogni rilascio.

L’attività di addestramento si dovrà svolgere presso gli uffici del Servizio affari legislativi e Buras o presso diversi locali, in Cagliari, la cui individuazione è a carico della stazione appaltante.

Il sistema dovrà essere realizzato e messo in produzione entro il termine massimo di 6 mesi dalla data di stipulazione del contratto. I servizi di Manutenzione adeguativa e correttiva e Assistenza in remoto saranno avviati a partire dalla data di messa in produzione del sistema e dureranno per il periodo di esecuzione del contratto.

6.1 Documenti di progetto

Ai fini della rendicontazione dei servizi erogati l’aggiudicatario dovrà presentare con periodicità trimestrale uno stato di avanzamento, con descrizione delle attività svolte.

Nell’esecuzione dell’appalto l’aggiudicatario dovrà creare e mantenere aggiornata la documentazione operativa e tecnica di progetto, da redigere in lingua italiana e da rendere costantemente accessibile all’amministrazione. La documentazione dovrà essere firmata digitalmente.

La documentazione comprende:

- glossario e FAQ delle segnalazioni ricorrenti registrate dall’help desk, con indicazione delle soluzioni;

- documenti per il monitoraggio delle segnalazioni e delle soluzioni;

- registro dei malfunzionamenti e reportistica;

- documenti tecnici descrittivi dell’architettura di sistema, dei prodotti, degli applicativi, delle funzionalità, con evidenza delle modifiche introdotte a seguito degli interventi manutentivi (da codificare anche con segnalazione delle date);

- codici sorgenti e ulteriore documentazione delle specifiche di funzionamento della soluzione;

- manuali operativi e materiale per l’addestramento all’utilizzo dell’applicativo per tutti gli utenti (back-office e front-office);

- documentazione di misurazione dei servizi resi;

- piano di verifica delle prestazioni rese;

- ogni altro documento proposto in sede di offerta.

Ai fini della valutazione il concorrente dovrà indicare in apposita tabella i documenti e i prodotti offerti, da descrivere sinteticamente, con indicazione della data di emissione e della periodicità di aggiornamento.

Tutti i documenti dovranno essere trasmessi via PEC all’amministrazione dalla casella di posta elettronica certificata dell’aggiudicatario, consegnati su supporto DVD non riscrivibile.

7 Livelli di servizio e commisurazione penali

L'aggiudicatario, durante l’intera esecuzione del contratto, dovrà garantire un adeguato livello dei servizi offerti secondo i parametri qualitativi e prestazionali e le modalità definite di seguito. A tal fine, l’aggiudicatario dovrà effettuare una continua rilevazione dei livelli di servizio offerti con la produzione della relativa documentazione di reporting e monitoraggio delle attività, da presentare trimestralmente all’Amministrazione.

Il responsabile del contratto si riserva la facoltà di verificare, in ogni momento, il rispetto dei livelli essenziali di servizio (SLA); a tal fine l’aggiudicatario è tenuto a presentare unitamente agli stati di avanzamento i report descrittivi dell’andamento dell’erogazione dei servizi, con misurazioni e controlli.

In particolare i report che l’aggiudicatario ha l’onere di produrre dovranno contenere tutte le informazioni necessarie alla verifica del rispetto degli SLA di seguito indicati, e dovranno essere consegnati sia in formato elettronico PDF firmato digitalmente che in foglio di calcolo.

Per tutti gli SLA il periodo di riferimento è trimestrale.

In caso di mancato rispetto dei livelli di servizio l’Amministrazione si riserva la facoltà di applicare le corrispondenti penali.

L’offerente dovrà descrivere all’interno dell’offerta tecnica il sistema di controllo e rendicontazione dei servizi erogati, per rendere evidente il rispetto o meno degli SLA. a titolo esemplificativo il sistema dovrà prevedere indicatori, cruscotti, raccolta dati, istogrammi, diagrammi, carte di controllo.

7.1 Servizio di assistenza in remoto

Per l’intera durata del contratto, l’aggiudicatario dovrà rispettare i seguenti SLA:

Definizione	Risposta alla chiamata
Soglia	<20% di chiamate non risposte
Periodo di osservazione	Trimestre
Penale	40€ per ogni punto % (o frazione di esso) di scostamento in aumento

7.2 Servizio di manutenzione adeguativa e correttiva

Per l’intera durata dell’appalto, l’aggiudicatario dovrà rispettare gli SLA illustrati di seguito.

Per quanto riguarda la manutenzione correttiva, sono individuati i seguenti livelli di gravità dei problemi:

- 1 - problema grave: l’intera applicazione è indisponibile agli utenti o un problema di sicurezza imputabile all’applicazione compromette l’integrità e l’autenticità delle informazioni;

- 2 - problema medio: funzionalità critiche della applicazione sono indisponibili agli utenti;

- 3 - problema semplice: funzionalità non critiche della applicazione sono indisponibili agli utenti.

In base al livello di gravità, saranno validi i seguenti SLA:

Definizione	Tempestività di risoluzione dei problemi – manutenzione correttiva
Livello di gravità del problema	1 – problema grave
	Indicatore	Percentuale di interventi eseguiti entro 4 ore	di	ripristino
	Soglia	98%
	Periodo di osservazione	Trimestre
	Penale	200€ per ogni punto % (o frazione di esso) di scostamento in diminuzione rispetto alla soglia
Livello di gravità del problema	2 – problema medio
	Indicatore	Percentuale di interventi eseguiti entro 8 ore	di	ripristino
	Soglia	97%
	Periodo di osservazione	Trimestre
	Penale	150€ per ogni punto % (o frazione di esso) di scostamento in diminuzione rispetto alla soglia
Livello di gravità del problema	3 – problema semplice
	Indicatore	Percentuale di interventi eseguiti entro 36 ore	di	ripristino
	Soglia	96%
	Periodo di osservazione	Trimestre
	Penale	100€ per ogni punto % (o frazione di esso) di scostamento in diminuzione rispetto alla soglia

Per quanto riguarda la manutenzione adeguativa, le tempistiche di intervento saranno concordate di volta in volta con la committenza. Gli interventi dovranno osservare i seguenti SLA:

Definizione	Rispetto delle tempistiche concordate – manutenzione adeguativa
Soglia	2gg lavorativi oltre i tempi concordati per l’intervento
Periodo di osservazione	Ciascun intervento di manutenzione adeguativa
Penale	100€ per ogni giorno lavorativo di ritardo oltre la soglia

7.3 Presentazione di documenti di progetto

Con riferimento alla produzione dei documenti richiesti nei paragrafi precedenti, inclusi quelli indicati nell’offerta tecnica, l’aggiudicatario dovrà rispettare gli SLA illustrati.

Definizione	Rispetto delle tempistiche di presentazione dei documenti
Periodo di osservazione	Intera durata contrattuale
Penale	200€ per ogni settimana lavorativa di ritardo nell’emissione o nell’aggiornamento dei documenti