dell’Avvocatura dello Stato
N.458
Il Segretario Generale
dell’Avvocatura dello Stato
VISTE le disposizioni vigenti in materia di appalti, contratti pubblici e spesa delle pubbliche amministrazioni, ed in particolare il d.lgs. 18 aprile 2016, n. 50, e successive modifiche ed integrazioni, “Codice dei contratti pubblici”;
VISTO l’art. 32, comma 2 del predetto decreto legislativo, il quale dispone che prima dell’avvio delle procedure di affidamento dei contratti pubblici, le amministrazioni decretano o determinano di contrarre, in conformità ai propri ordinamenti;
VISTO il D.lgs. 14 marzo 2013, n. 33 recante “Riordino della disciplina riguardante gli obblighi di pubblicità, trasparenza e diffusione d’informazioni da parte delle pubbliche amministrazioni”;
VISTO il d.p.r. 5 luglio 1995, n. 333, “Regolamento recante norme per l'adeguamento dell'organizzazione e del funzionamento delle strutture amministrative dell'Avvocatura dello Stato alla disciplina prevista dall'art. 2 della legge 23 ottobre 1992, n. 421”;
VISTI la legge 7 agosto 1990 n. 241; il D.P.R. 28 dicembre 2000 n. 445; il d.lgs. 30 marzo
2001 n.165; la legge 13 agosto 2010 n. 136; la legge 6 novembre 2012 n. 190; il piano triennale di prevenzione della corruzione e della trasparenza 2017-2019 approvato con D.A.G. 30 gennaio 2017
n. 8, nonché il piano della performance della struttura amministrativa dell’Avvocatura dello Stato per il triennio 2017-2019 approvato con D.A.G. 06 luglio 2017 n. 77;
VISTI gli artt. 15 e 16 del d.lgs. 30 marzo 2001, n. 165;
VISTO il D.A.G. del 18.11.2016 n. 13036 con il quale è stato istituito l’Ufficio Contratti dell’Avvocatura dello Stato;
VISTA la nota in data 6 novembre 2017 con la quale l’Ufficio X C.E.D. rappresenta la necessità di provvedere all’adeguamento di alcune procedure in uso e alla realizzazione di nuovi moduli per l’evoluzione di applicazioni già presenti all’interno del sistema denominato “NSIWeb2” ed in particolare, per la realizzazione di automatismi nel protocollo delle PEC;
VERIFICATO che non è attualmente attiva una convenzione Consip per l’acquisizione dei suddetti servizi;
RITENUTO che i servizi oggetto della fornitura dovranno essere erogati dalla data di stipula del relativo contratto e fino al 30 giugno 2018, così come disciplinato nel capitolato tecnico amministrativo;
CONSIDERATO che la spesa complessiva da impegnare per il servizio richiesto e per il suddetto periodo, è presuntivamente pari ad € 134.000,00 (I.V.A. esclusa), e che la stessa graverà per € 19.143,00 (I.V.A. esclusa) sul capitolo 7895 tabella 2, del bilancio di previsione dello Stato
N.458
Il Segretario Generale
dell’Avvocatura dello Stato
per l’anno finanziario 2017 e per la somma di € 114.857,00 (I.V.A. esclusa) sul corrispondente capitolo esercizio finanziario 2018;
RITENUTO OPPORTUNO il ricorso alla procedura negoziata ai sensi dell’art. 36 co. 2 lett
b) del D.Lgs 18/4/2016 n. 50, previa consultazione di 5 operatori economici individuati, sulla base di indagine di mercato, nell’ambito del Mercato Elettronico della Pubblica Amministrazione (MePA);
DATO ATTO che l’affidatario dovrà rispettare i requisiti richiesti dal Piano triennale di prevenzione della corruzione e della trasparenza 2017-2019 approvato con D.A.G. del 30 gennaio 2017;
DATO ATTO che l’affidatario dovrà rilasciare la dichiarazione di cui all’art. 80, d.lgs. 18 aprile 2016 n. 50, come previsto dal piano triennale della prevenzione della corruzione e della trasparenza 2017-2019 dell’Avvocatura Generale dello Stato;
Determina
- di procedere con ricorso alla procedura negoziata ex art. 36 co. 2 lett. b) del D.Lgs n. 50 del 18/4/2016, previa consultazione di cinque operatori economici, individuati nell’ambito del MePA, per l’affidamento di un servizio di sviluppo di nuove funzionalità del sistema “NSIWeb2” per automazione protocollo e MEV;
- di adottare, ai fini dell’espletamento della procedura, il capitolato tecnico amministrativo in allegato - che costituisce parte integrante e sostanziale del presente provvedimento - nel quale sono indicati i requisiti tecnico-professionali richiesti agli operatori invitati a partecipare alla procedura e gli elementi essenziali dello stipulando contratto;
- di nominare quale responsabile del procedimento la dott.ssa Xxxxxxx Xxxxxxxxx, in qualità di Preposto all’Ufficio X – CED – Centro Elaborazione Dati - di questa Avvocatura Generale;
Gli oneri derivanti dalla sottoscrizione del contratto oggetto della presente determina, graveranno sul capitolo 7895 del bilancio dello Stato – esercizi finanziari 2017 e 2018.
Documento firmato da:
XXXXXXX XX XXXXXXX
AVVOCATURA GENERALE DELLO STATO/80224030587 13/11/2017
IL SEGRETARIO GENERALE
Avv. Xxxxxxx Xx Xxxxxxx
AVVOCATURA GENERALE DELLO STATO
CENTRO ELABORAZIONE DATI
Nuove funzionalità NSIWeb2 per Automazione Protocollo e MEV
Capitolato tecnico amministrativo
AVVOCATURA GENERALE DELLO STATO
CENTRO ELABORAZIONE DATI
1 Premessa 5
1.1 Scopo del presente documento 5
1.2 Definizioni 5
2 Contesto 5
2.1 Funzioni dell’Avvocatura dello Stato 5
2.2 Le criticità 6
2.3 Il contesto applicativo 7
3 Il sistema informatico di AGS 7
3.1 Il Sistema NSI 7
3.2 Il Nuovo Sistema NsiWeb2 9
3.3 Sistema Documentale 11
3.4 Comunicazione Telematica 11
3.5 Flussi operativi 11
4 Oggetto e durata della fornitura 13
4.1 Oggetto 13
4.2 Durata della fornitura 14
5 Descrizione dei servizi 14
5.1 Contesto architetturale e vincoli tecnologici 14
5.2 Servizi di sviluppo e manutenzione evolutiva 15
5.2.1 Manutenzione evolutiva del sistema NSI e NsiWeb 15
5.2.2 Sviluppo nuove applicazioni per il sistema NsiWeb2 16
AVVOCATURA GENERALE DELLO STATO
CENTRO ELABORAZIONE DATI
5.2.1 Piano di lavoro 17
5.2.2 Contenuto dei deliverable 20
5.3 Servizio di Manutenzione correttiva 26
1 Descrizione delle figure professionali richieste 27
2 Gestione del servizio 28
2.1 Luogo di lavoro 28
2.2 Comunicazioni 29
2.3 Livelli di servizio 29
2.4 Modalità di esecuzione 30
2.5 Penali 31
3 Informazioni generali sulla procedura 31
3.1 Formulazione e valutazione dell'offerta 32
3.2 Offerta tecnica 32
3.3 Offerta economica 32
3.4 Procedura di valutazione 32
3.5 Criteri di aggiudicazione delle offerte 33
3.6 Aggiudicazione delle offerte 33
3.7 Decadenza dell'aggiudicazione 33
3.8 Trattamento dei dati 34
4 Altre condizioni amministrative 34
4.1 Diritti di proprietà 34
4.2 Responsabilità e garanzie 34
4.3 Controversie 35
AVVOCATURA GENERALE DELLO STATO
CENTRO ELABORAZIONE DATI
4.4 Spese contrattuali 35
4.5 Riservatezza e pubblicità 35
4.6 Modalità di pagamento 35
4.7 Risoluzione anticipata del contratto 35
4.8 Responsabile del procedimento 36
4.9 Osservanza di leggi, regolamenti e norme 36
4.10 Verifica dei requisiti 36
4.11 Codici di comportamento 36
AVVOCATURA GENERALE DELLO STATO
CENTRO ELABORAZIONE DATI
1 Premessa
L’Avvocatura Generale dello Stato, (di seguito AGS) ha necessità di adeguare le procedure ora in uso e di realizzare nuovi moduli al fine di far evolvere applicazioni già presenti all’interno dell’applicativo denominato “NSIWeb2”.
1.1 Scopo del presente documento
Il presente documento è mirato allo svolgimento di una procedura negoziata, non vincolante per l’AGS, allo scopo di individuare l'offerta economicamente più vantaggiosa per la fornitura di cui al punto precedente e meglio specificato nel seguito. Per lo svolgimento della presente indagine di mercato l’AGS si avvale della procedura di richiesta di offerta (R.d.O.) prevista dal mercato elettronico della Pubblica Amministrazione (MePA) e ad essa rimanda per tutto quanto non previsto nel presente documento
1.2 Definizioni
Ai fini del presente capitolato: per “Fornitore” o “Aggiudicatario” si intende l’impresa aggiudicataria della fornitura. Con il termine “Committente” o “Amministrazione” si intende l’AGS. Quando non diversamente specificato, con “Capitolato” si intende il presente documento, con “Gara” si intende la gara da effettuare a fronte del Capitolato, con “Contratto” si intende il contratto che verrà sottoscritto a seguito dell’aggiudicazione della gara, con “Fornitura” si intende il complesso delle attività e dei prodotti che il Fornitore è chiamato a compiere e a fornire per onorare il contratto.
2 Contesto
2.1 Funzioni dell’Avvocatura dello Stato
L'Avvocatura dello Stato assicura, in via esclusiva, la consulenza, la rappresentanza e difesa in giudizio delle Amministrazioni statali, anche quelle a ordinamento autonomo, nonché altri soggetti pubblici non statali (tutte le Regioni a statuto speciale e diverse a statuto ordinario) o Enti sovvenzionati. Garantisce, altresì, le Amministrazioni estere (come le rappresentanze diplomatiche) e le Organizzazioni internazionali sia davanti ai giudici nazionali sia davanti alle Corti internazionali – nelle quali rappresenta il Governo italiano. Per ulteriori dettagli sul complesso delle funzioni pubbliche affidate all’Avvocatura dello Stato, si rinvia al relativo sito web istituzionale.
Al fine di mantenere livelli di servizio ottimali e di assicurare livelli qualitativi adeguati alla complessa e delicata attività defensionale affidata all’Avvocatura dello Stato con immediati riflessi sui bilanci delle amministrazioni patrocinate, è indispensabile fornire strumenti di innovazione tecnologica che consentano di migliorare la gestione dei processi
interni e l’interoperabilità con le Amministrazioni patrocinate e con gli organi giudiziari, conformemente alle esigenze del processo telematico.
2.2 Le criticità
Per i compiti e le proprie attività istituzionali, l’AGS ha necessità di scambiare documenti con tutte le Amministrazioni difese e con le Autorità Giudiziarie. Riceve giornalmente e invia un elevato numero di documenti che sono trasmessi utilizzando vari canali di trasmissione di cui alcuni telematici: posta ordinaria, PEC, fax, Porta di Dominio, mail ecc.
Esiste, inoltre, una forte interazione e comunicazione interna, cioè tra l’Avvocatura Generale con sede in Roma e le 25 Avvocature Distrettuali distribuite sul territorio nazionale.
L’AGS nel suo complesso riceve ogni anno la notifica di centinaia di migliaia di atti giudiziari che, attualmente, vengono lavorati dal personale dell’AGS. Tali atti, scansiti, vengono trasmessi alle Amministrazioni patrocinate, al fine di richiedere la documentazione necessaria per predisporre le difese in giudizio.
La lavorazione di tutti i documenti avviene principalmente in forma cartacea, solo da poco tempo l'AGS si è dotata di un sistema di gestione documentale ed ha iniziato un lungo percorso di integrazione tecnologica ed organizzativa di una gestione non cartacea dei documenti. Molti documenti afferiscono in AGS in forma elettronica e vengono lavorati, almeno inizialmente, in tale forma.
La lavorazione in forma cartacea determina oggi le seguenti criticità:
- appesantimenti burocratici (ad es. per ciò che concerne la predisposizione delle fotocopie degli atti), collegati sia alla movimentazione interna dei fascicoli, sia alla gestione del personale;
- possibili disguidi connessi al rischio di smarrimento dei documenti cartacei;
- conseguenti ritardi nella analisi da parte del personale dell’AGS;
- possibili ritardi nella trasmissione degli atti giudiziari alle Amministrazioni difese, che non sempre sono in grado di avere, in tempo utile, l’atto giudiziario e, quindi, predisporre la necessaria relazione informativa, con possibili esiti negativi sui giudizi;
- problemi connessi alla gestione della carta che, con l’aumentare esponenziale del carico di lavoro avvenuto negli ultimi anni, sta letteralmente “sommergendo” l’Amministrazione; situazione che ha reso necessario anche il ricorso a servizi esterni di custodia dei fascicoli cartacei.
2.3 Il contesto applicativo
Il sistema informatico (ed anche quello informativo) è basato su un complesso insieme di applicativi, ottenuti attraverso una considerevole attività di realizzazione (ed in alcuni casi di re-ingegnerizzazione).
Il sistema informatico dell'AGS è diviso logicamente in quattro aree:
1. Il sistema gestionale NSI basato su applet;
2. Il sistema gestionale NsiWeb2;
3. Il sistema documentale;
4. Il sistema di comunicazione telematica con gli enti esterni (Amministrazione difese).
Attualmente il sistema risulta ancora composto da un insieme molto eterogeneo di soluzioni e architetture, dato che l’attività di re-ingegnerizzazione e trasformazione del sistema NsiWeb2 ancora non è completata (i.e. sono presenti ancora diverse vecchie funzionalità realizzate tramite applet Java).
Nei seguenti paragrafi si illustrano le principali componenti applicative presenti presso AGS.
3 Il sistema informatico di AGS
3.1 Il Sistema NSI
Il Sistema NSI è stato introdotto presso l’Amministrazione (su tutto il territorio nazionale) nell’anno 2003. NSI ha offerto un fondamentale supporto alle attività istituzionali interne dell’Amministrazione. Tale sistema di gestione integra l’iter dei documenti e degli atti collegati ad affari legali con l’iter delle pratiche che coinvolge i diversi uffici dell’Avvocatura.
Le attività automatizzate sono volte alla gestione delle informazioni collegate ai documenti in arrivo e in partenza e ai procedimenti seguiti dagli avvocati (affari legali) a partire dalla fase iniziale di impianto sino alla fase conclusiva di richiesta di liquidazione delle spese legali e relativa contabilizzazione dei pagamenti.
Le funzionalità si possono raggruppare in due macro-aree:
• Area dell’Affare Legale che comprende:
- l’associazione dei documenti in arrivo e in partenza agli affari legali di pertinenza con contestuale protocollazione che risponde ai requisiti minimi previsti dalla normativa;
- la gestione delle scadenze e delle udienze legate agli affari legali che costituisce un supporto per l’avvocato nella gestione dell’agenda;
- la gestione di tutte le informazioni anagrafiche degli affari legali, classificate secondo criteri differenziati utili a successive attività di ricerca ed elaborazioni di tipo statistico;
- funzioni a disposizione dei funzionari per effettuare ricerche anche complesse sulle informazioni contenute nella base dati sia per uso interno sia in risposta alle amministrazioni assistite o al cittadino;
• Area della Liquidazione che comprende:
- Gestione delle sentenze, che costituiscono la conclusione dell’iter dell’affare legale;
- Gestione contabile di cassa dell’Avvocatura e la gestione contabile dei pagamenti in relazione alle somme richieste ai debitori;
- Calcolo della parcella. Attività eseguita solo in caso di spese compensate. La parcella è determinata in riferimento ad un tariffario (selezionato in base all’importo della causa e all’autorità giudiziaria) e ad un modello di parcella. Tariffari e modelli di parcella sono gestiti da NSI.
- Imputazione e suddivisione del debito. Un AL è strutturato in più gradi di giudizio. Per ciascuno di essi è presente al più un’unica sentenza che attiva la fase liquidatoria. Attraverso la fase di imputazione e suddivisione del debito viene calcolato l’importo che ciascuna parte dovrà corrispondere all’Avvocatura dello Stato in ciascuna fase di giudizio, in base a quanto il giudice di ciascun grado ha disposto nella relativa sentenza.
- Calcolo del debito complessivo. Nella storia di un singolo AL le parti coinvolte possono subentrare o ritirarsi in una qualsiasi fase di giudizio. Pertanto non tutte le parti di un AL sono necessariamente coinvolte in tutte le fasi di giudizio. Nella fase di calcolo del debito è determinato l’importo complessivamente dovuto da ciascuna parte coinvolta.
- Stampa delle lettere di richiesta pagamento. Il sistema NSI permette di generare le lettere che saranno inviate alle parti coinvolte per invitarle a pagare le somme dovute. Tali lettere sono inviate a mezzo R/R e costituiscono un primo bonario un avviso di pagamento. (I pagamenti dei debitori vengono ricevuti dall’Avvocatura dello Stato attraverso quietanze di pagamento. Le quietanze consentono di registrare i pagamenti in NSI al fine di aggiornare lo stato del debito di ciascuna parte.)
- Notifica della richiesta di pagamento. Trascorsi 60/90 giorni dalla ricezione della cartolina di ritorno relativa alle lettere di richiesta (punto 5) è avviata una richiesta formale, attraverso la notifica della sentenza alle parti che non hanno proceduto al pagamento.
- Elaborazione dei rendiconti contabili quadrimestrali e annuali;
- Gestione degli enti facoltativamente difesi.
Il sistema è strutturato ad applet richiamabili da un menu. Le applet possono essere accedute in relazione alle autorizzazioni dell'utente. L'autenticazione viene fatta attraverso un challenge http di tipo basic.
3.2 Il Nuovo Sistema NsiWeb2
All'inizio del 2009 l’Amministrazione ha avviato un progetto con lo scopo di riuscire a “reingegnerizzare” il sistema NSI rendendo il suo ambiente di esecuzione più moderno.
Sull’applicativo gestionale NSI (successivamente rinominato in NsiWeb2) è stata svolta una prima attività di reingegnerizzazione. Tale attività si è resa necessaria a fronte di una situazione divenuta di difficile gestione a causa dell'obsolescenza del software di base. A titolo di esempio, solo per far comprendere l'entità dell'intervento, si riportano alcuni elementi: macchine virtuali costrette ad emulare un sistema non certificato e non più supportato da anni (cambio sistema operativo), codice sorgente disallineato ed inaffidabile (recupero il sorgente mediante decompiling), data base Oracle 8.0.2 dichiarato dalla Oracle “end of life” (passaggio inizialmente alla 10g e successivamente alla 11g), applet in grado di essere eseguite correttamente solo utilizzando la versione Microsoft di java (eliminati i vincoli), sistema di workflow con un costo annuale non irrilevante e del tutto inutile all'economia del sistema stesso (eliminato modificando il sistema), nessun sistema di compilazione e deploy centralizzato del software (sistema compilazione realizzato con l'uso di prodotto open-source).
Partendo dalla situazione qui descritta l’AGS ha commissionato un primo intervento di ingegnerizzazione (e non reingegnerizzazione) di quanto esistente, iniziando dalla produzione dei sorgenti con un processo di reverse engineering, sostituendo ed adeguando il software di base (Oracle, java, browser, eliminazione motore di workflow Floware) e realizzando un sistema di compilazione e deploy automatizzato anche su tutte le sedi distrettuali.
Il passo successivo è attualmente in corso ed ha, come obiettivo a lungo termine, la modernizzazione del sistema NSI tramite trasformazione in quello denominato NsiWeb2, cioè la trasformazione delle applet in un sistema web-based moderno basato sulle tecnologie web 2.0.
Le principali funzionalità realizzate in questo ambito, sono:
- Impianto nuovo affare legale. Questo primo passo (in ordine cronologico) di trasformazione è stato complesso in quanto ha richiesto non solo uno sforzo informatico ma anche uno sforzo di riprogettazione dell'interfaccia utente e quindi un nuovo “training on the job” del personale.
- Protocollo in arrivo.
- Ricerca protocolli in ingresso da completare. La funzionalità permette di ricercare i protocolli in ingresso che non sono ancora completati e selezionarne uno per procedure al completamento dello stesso.
- Completamento protocollo in ingresso. Rappresenta la funzione di caratterizzazione di un documento di tipo Atto. L’attività che è peculiare dell’Istituto viene svolta successivamente alla fase di protocollo.
- Protocollo in uscita. La funzione di spedizione ha lo scopo di eseguire il protocollo in partenza e permettere la selezione di uno dei canali di invio telematico
disponibile. L’invio viene eseguito in modalità asincrona. In questa funzionalità è stata fatta confluire anche la generazione di documenti a partire da template da utilizzare come documenti associati alla comunicazione; tipico utilizzo sono i documenti di richiesta rapporto. Sempre in essa sono state inserite le funzioni di “risposta a nota” e “seguito nota” che permettono un reale incremento dell’efficienza organizzativa.
- Completamento protocollo in uscita. Trattasi della funzione analoga a quella di completamento in ingresso.
- Console di monitoraggio e lavorazione delle spedizioni. Dopo una protocollazione di un documento in uscita e dopo la richiesta di spedizione, si rende necessario poter monitorare la spedizione. E’ stata quindi realizzata una console di monitoraggio dalla quale è anche possibile eseguire delle operazioni specifiche (annullamento, modifica indirizzo destinatario, completamento protocollo, etc.) su una singola spedizione.
- Protocollo in ingresso da mail. Questa funzionalità permette di snellire il protocollo dei documenti pervenuti in Avvocatura attraverso I canali telematici. Specifici accorgimenti di individuazione del mittente permettono anche la minimizzazione degli errori. Inoltre vi è il grande vantaggio del popolamento del repository documentale senza alcun intervento utente.
- Spedizione di un documento protocollato. Grazie a questa funzionalità è possibile rispedire un protocollo, quindi tutti i documenti ad esso relativi, a seguito di un qualsiasi evento eccezionale possa verificarsi. Uno tra i tanti possibili esempi è quello della spedizione ad un nuovo indirizzo telematico a seguito di rapporti informali con il destinatario.
- Stampa barcode e caricamento immagini. Trattasi di una funzione di supporto atta al caricamento differito delle immagini documentali. Il suo utilizzo è previsto per la sola gestione di flussi documentali eccezionali.
- Spedizione doc. a Giustizia Amministrativa. Questa funzionalità si è resa necessaria a seguito delle specifiche tecniche dettate da Giustizia Amministrativa per il deposito nell’ambito del PAT (Processo Amministrativo Telematico).
- Gestione automatizzata dei depositi verso Giustizia Civile. Si tratta di un sistema di protocollazione e caratterizzazione automatica di un deposito a valle dell’effettivo avvenuto deposito attraverso il sistema messo a disposizione dal punto di accesso.
- Gestione semiautomatica dei depositi verso Corte dei Conti. Si tratta di un sistema di protocollazione di un deposito presso le varie cancellerie dalla Corte dei Conti.
- Biglietti di cancelleria. Il recapito dei biglietti di cancelleria da parte della giustizia civile è diventato da tempo solo di tipo PEC verso gli indirizzi registrati in Reginde. Grazie allo studio del contenuto delle mail ed ad un’azione di concerto tra i sistemi interni dell’AGS ed il portale Lextel, è stato realizzato un sistema in grado di protocollare automaticamente tali biglietti e, a valle della stessa, rende disponibili agli operatori le comunicazioni in oggetto unitamente alle loro immagini documentali per la successive lavorazioni (integrazione o completamento).
- Integrazione Lettera Legale in uscita (utilizzata solo in relazione ai biglietti di cancelleria). Questa funzionalità mira alla minimizzazione degli errori di associazione di un biglietto di cancelleria all’Affare Legale corretto. Utilizzando tale funzionalità l’utente procede automaticamente alla fascicolazione nella fase di giudizio indicata dall’Autorità Giudiziaria tramite il numero di ruolo
3.3 Sistema Documentale
Il sistema documentale scelto dall'AGS è Alfresco. Il sistema è stato personalizzato mediante la realizzazione di specifici servizi, denominati webscript, per permettere un interfacciamento applicativo semplice e che possa trascurare una serie di particolari implementativi. In termini più informatici i webscript implementati permettono di realizzare una sorta di information hiding nascondendo tutta una serie di dettagli implementativi di Alfresco e della struttura organizzativa dei documenti che è stata scelta.
Attualmente il sistema documentale è consultabile solo a partire delle interfacce del sistema NsiWeb2. È in via di realizzazione anche una nuova interfaccia che permette di cercare i documenti all'interno del sistema documentale utilizzando la ricerca full-text sui documenti elettronici indicizzati. La ricerca full-text è permessa dal fatto che tutti i documenti che nascono in formato cartaceo vengono resi ricercabili mediante un sistema di OCR ed una memorizzazione in formato PDF/A.
Il sistema documentale, oltre ad interagire con NsiWeb2, interagisce anche con i sistemi di ricezione e spedizione telematici dei documenti e con i flussi automatizzati di acquisizione dei documenti (scansione massiva).
Il sistema documentale si sta affermando come il sistema centrale di memorizzazione delle informazioni dell'AGS alla stessa stregua del sistema di RDBMS (Oracle).
Tutte le parti degli sviluppi richiesti che interagiranno con il sistema documentale (per la registrazione o il recupero di documenti) dovranno mantenere un interfacciamento in piena armonia con quanto già predisposto per evitare ulteriori modifiche sul SW già presente.
3.4 Comunicazione Telematica
Nell'ambito di quest’area i principali sistemi sono relativi ad una rubrica informatica centralizzata, alla gestione dell’invio e della ricezione dei documenti tramite PEC in alternativa all'invio cartaceo, al servizio centralizzato di invio fax, al sistema di protocollazione e caratterizzazione automatica di un deposito verso Giustizia Civile, al sistema protocollazione automatica in ingresso dei biglietto di cancelleria ed, infine, al Sistema A@A che è il sistema che implementa il concetto di Porta Delegata e Porta Applicativa secondo le regole tecniche di AgID.
Tutti i sistemi di comunicazione sopra menzionati si interfacciano con il sistema documentale per la creazione o il prelievo di documenti.
3.5 Flussi operativi
I flussi operativi gestiti dal sistema informativo presentano una complessità tale da non poter essere dettagliata esaurientemente nello spazio concesso dal presente documento.
Scopo del presente paragrafo è quindi quello di fornire un’idea di massima riguardo ruolo e caratteristiche delle applicazioni e servizi costituenti il sistema informativo e le relative interazioni, tra loro stessi e con i sistemi informativi delle altre amministrazioni. A tale scopo si introduce lo schema logico sottostante, raffigurante l’architettura del sistema informativo, con una spiegazione dettagliata dei suoi elementi costituenti.
La figura precedente descrive sinteticamente ad un alto livello di astrazione il complesso sistema di ingresso ed uscita dei documenti in forma telematica, specificando le macro aree funzionali e i relativi canali di ingresso/uscita utilizzati.
Le principali aree di ingresso sono: la cooperazione telematica, la PEC di privati, la PEC da amministrazioni e il processo civile telematico. Le principali aree di uscita sono: la cooperazione telematica, la PEC verso privati e verso amministrazioni ed un primo livello di interazioni per il Processo Civile Telematico.
La cooperazione telematica è frutto di un accordo di servizio tra le amministrazioni in cui si scambiano documenti corredati da un file XML (busta e-gov) che ne descrive dettagliatamente il contenuto. La presenza del file XML permette all'AGS di eseguire una serie di operazioni automatiche di alimentazione sia del sistema NsiWeb2 sia del sistema documentale. La cooperazione telematica è di tipo bidirezionale per cui gestisce sia gli ingressi sia le uscite. A fronte di una comunicazione in ingresso vi è sempre una comunicazione in uscita che, come minimo, contiene le informazioni sull'esito delle operazioni eseguite.
La PEC viene utilizzata sia in ingresso che in uscita. Se la PEC è corredata da opportuno allegato XML (busta e-gov) si eseguono le operazioni automatiche possibili in
relazione alle informazioni contenute. Se la PEC non contiene alcuna busta di e-gov sarà necessario lavorare la comunicazione manualmente.
Per quanto riguarda la lavorazione dei documenti esistono sostanzialmente due tipologie distinte:
1. acquisizione contestuale al protocollo in ingresso;
2. acquisizione differita.
Il primo caso viene realizzato mediante la funzione di protocollo in ingresso del sistema NsiWeb2. Mediante questa funzione è possibile caricare, contestualmente all’operazione di protocollazione, anche una serie di file. Tra i file inviati deve essere indicato quale di questi è il documento primario e, di conseguenza, quali sono gli allegati.
L'acquisizione differita consiste in un meccanismo di trasformazione di un documento cartaceo automatizzato. La tecnica, in breve, è la seguente: si procede alla protocollazione senza alcun caricamento documentale. Come prodotto della protocollazione viene stampato un codice a barre che viene apposto sul documento cartaceo. Il documento cartaceo viene inviato al sistema di acquisizione massiva il quale esegue:
1. scansione del documento;
2. OCR del testo e salvataggio in PDF/A con testo selezionabile; il nome del documento viene attributo nella forma <AOO>--<ANNO>-<NUMERO PROTOCOLLO>.pdf. Il nome al documento viene assegnato in automatico mediante interpretazione del codice a barre apposto in fase di protocollo;
3. il documento viene salvato in una directory dipendente dalla AOO
4. un sistema automatico preleva i file dalle directory di ogni AOO e si occupa di inserirli nel sistema documentale. Il sistema automatico provvede anche a controllare, mediante invocazione di un opportuno web service, se il documento è stato associato ad un Affare Legale, e, in tal caso, provvede a fascicolare il documento nell'opportuno affare legale.
4 Oggetto e durata della fornitura
4.1 Oggetto
La presente fornitura, che ha come obiettivo ultimo l’adeguamento del sistema NSI2Web, è strutturata nella richiesta dei seguenti servizi:
- Sviluppo e Manutenzione evolutiva (MEV) di NSIWeb2;
- Manutenzione correttiva;
- Supporto per il rilascio, la messa in esercizio e la gestione operativa del software sviluppato.
4.2 Durata della fornitura
I servizi inclusi nella presente fornitura dovranno essere erogati dalla data di stipula del contratto e fino al 30 giugno 2018.
5 Descrizione dei servizi
5.1 Contesto architetturale e vincoli tecnologici
Il sistema NSIWeb2 e tutte le successive attività manutentive ed evolutive sono state progettate e realizzate avendo come riferimento guida un’architettura generale che esalta principi di modularità e di modificabilità che sono certamente di importanza inderogabile. Questa architettura viene comunemente denominata SOA (Service Oriented Architecture). In altre parole, si tratta di “frammentare” le funzionalità necessarie al funzionamento dell'Ente in “servizi” elementari che si occupano di assolvere solo ad un compito semplice, circoscritto e significativo. Questi servizi nulla devono conoscere degli altri per svolgere il proprio compito. Al di sopra di questi servizi si pone un sistema (software) denominato Orchestrator, che decide di volta in volta, di caso in caso, quali servizi devono essere utilizzati, in quale ordine, con quali relazioni di dipendenza funzionale.
I vantaggi di questa strutturazione sono che ogni servizio è confinato alla sua attività, per cui eventuali modifiche operative, correzioni, cambi normativi possono avere delle ripercussioni nulle sul resto del sistema fino a che il “contratto di servizio” non viene cambiato. Il contratto di servizio è rappresentato dall'insieme delle modalità che devono essere rispettate per invocare il servizio e per interpretarne la risposta.
La complessità concettuale del sistema è demandata quasi esclusivamente all'Orchestrator il quale contiene il cuore dei processi amministrativi ed operativi dell'ente. Nessuna di queste informazioni deve risiedere al livello dei servizi.
Tale visione architetturale dovrà essere mantenuta nella progettazione e nello sviluppo del software realizzato nell’ambito della presente fornitura.
Nell’ottica di armonizzazione dei nuovi sviluppi con l’attuale piattaforma tecnologica, si richiede che il software realizzato rispetti i seguenti vincoli:
• Il software realizzato deve essere in tecnologia Web 2.0 e realizzato utilizzando java e i suoi framework server side (Jboss Seam). La versione di java attualmente in uso è la 1.7.x.
• Il codice sorgente deve essere consegnato mediante commit nel server subversion dell'AGS e deve essere distribuibile attraverso i tools messi a disposizione da SVN e compilabile tramite ANT.
• Il build di ANT deve essere opportunamente parametrizzato in modo da poter configurare i path di input e di output. Deve essere realizzato un build che permetta la compilazione ed il deploy sia in produzione sia in test/sviluppo mediante opportune etichette da passare sulla command line.
• Il database di riferimento è Oracle 11G. Se saranno necessari database relativi alle funzioni da realizzare questi dovranno essere discussi con il responsabile di progetto dell'AGS e comunque dovranno essere schema di Oracle.
5.2 Servizi di sviluppo e manutenzione evolutiva.
Nel presente paragrafo sono descritti in dettaglio i contenuti e gli obiettivi sia del servizio di manutenzione evolutiva delle funzionalità esistenti di NSI e di NSI2Web, sia del servizio di sviluppo di nuove funzionalità. Il fornitore, nell’erogazione di tali servizi, dovrà attenersi al piano di lavoro descritto al paragrafo 5.2.1 e al rilascio dei deliverable descritti al paragrafo 5.2.2.
5.2.1 Manutenzione evolutiva del sistema NSI e NsiWeb
Per quanto riguarda la manutenzione evolutiva, il team di sviluppo si dovrà occupare, dei seguenti aspetti di particolare rilievo:
1. Procedure relative all’area della Liquidazione.
• Adeguamento di alcuni Applet, per i quali non è ancora prevista la migrazione a sistema Web2, a fronte di adeguamenti normativi ed allineamento con le funzionalità NsiWeb2. I riferimenti normativi riguardano la variazione delle quote per la distribuzione delle competenze agli Avvocati per le rendicontazioni del quadrimestre 2016. Di conseguenza le liquidazioni calcolate in precedenza dovranno essere eliminate e sostituite con le rendicontazioni della nuova elaborazione.
2. Procedure relative all’area dell’Affare Legale:
• “Smistare Documenti”, in relazione alla gestione delle parti in causa;
• “Disassociare Affare Legale da protocollo in ingresso”, per la quale è richiesta anche l’analisi dell’impatto e l’eventuale progettazione della sua migrazione verso il sistema NsiWeb2;
• “Annullamento protocollo in ingresso”, per la quale è richiesta l’analisi, la progettazione e la migrazione verso il sistema NsiWeb2.
3. Processi batch per l’ottimizzazione delle operazioni sul sistema ed il conseguente miglioramento della “operatività” degli utenti finali.
Gli interventi sui processi di batch possono prevedere nuove implementazioni o modifiche su quelli attuali. In particolare riguardano:
• controllo delle email non segnalate come lette dal fornitore del servizio di PEC e, per queste, generazione di avvisi agli utenti finali e, contemporaneamente, al personale che effettua il controllo dei sistemi per le opportune verifiche;
• implementazione di una nuova versione del processo di elaborazione della posta elettronica in arrivo (in particolare EML e MSG) che renda immediatamente disponibile all’utente finale i contenuti di un messaggio, senza costringere quest’ultimo al recupero ed all’apertura del file originale. Tale funzionalità dovrà coesistere, per un periodo di tempo, con quella
attualmente presente nel sistema e dovrà gestire gli eventuali problemi di concorrenza al fine di evitare possibili duplicati (processo P2);
Il processo dovrà, inoltre, eseguire automaticamente il protocollo minimo in ingresso, al verificarsi di una delle seguenti condizioni:
o indirizzo di posta elettronica del mittente censito all’interno dell’applicazione (sia di amministrazioni difese dall’Avvocatura che di altri enti o privati)
o presenza di una PEC (previo controllo formale) che contenga il file segnatura.xml (secondo le specifiche riportate nella circolare 60 del 2013, emessa da Agenzia per l’Italia Digitale)
• automazione per il riavvio dei processi di comunicazione verso Agenzia delle Entrate sulla porta di dominio.
5.2.2 Sviluppo nuove applicazioni per il sistema NsiWeb2
Sul sistema sono necessari alcuni interventi di carattere grafico e di ottimizzazione applicativa su alcune funzionalità e la realizzazione di nuove funzioni che andranno a sostituire quelle realizzate con tecnologie obsolete o che andranno a soddisfare i nuovi requisiti espressi dagli utenti. Le nuove funzionalità dovranno essere progettate in maniera tale da poter coesistere con le implementazioni esistenti.
• Nuova interfaccia grafica per la gestione delle email in ingresso generate dalla nuova versione del processo di elaborazione della posta elettronica in arrivo, in particolare:
o Funzione di ricerca email da protocollare e funzioni di filtro sui gruppi assegnati da processo P2 con passaggio, degli elementi trovati, a fase di protocollo minimo in ingresso;
o Funzione di ricerca email da completare (distinguendo quelle protocollate in automatico e quelle protocollate da altri utenti) che permetta, per gli elementi che soddisfano i criteri impostati, il passaggio diretto alla funzione di Completamento protocollo in ingresso.
• Nuove funzionalità sulla funzione di Completamento Protocollo in Ingresso:
o Annullamento di un completamento, o ripristino della situazione precedente;
o Modifiche evolutive sulle operazioni di completamento di un protocollo in ingresso per cui sono richieste le funzioni di:
- ricerca di affari legali a cui associare il protocollo attraverso un codice fiscale;
- modifica attribuzione dell’ufficio di destinazione segnalato durante la fase di protocollo minimo;
- possibilità di modificare lo stato di urgenza imposto in fase di protocollo minimo;
- possibilità di digitazione del protocollo mittente (al momento impostabile solo in fase di protocollo minimo)
- adeguamenti dell’interfaccia grafica per la visualizzazione dei contenuti delle email, a fronte dalla nuova versione del processo di elaborazione della posta elettronica in arrivo.
• Modifiche alla funzione di visualizzazione documentale, per adeguarla alla nuova versione del processo di elaborazione di posta elettronica in arrivo, garantendo il recupero dei dati preesistenti anche dall’archivio documentale.
• Revisione della funzione di protocollo minimo in ingresso, per la quale si rendono necessarie, oltre ad alcuni interventi grafici, modifiche funzionali, per:
o permettere l’inserimento della la data e della fascia oraria di arrivo di un elemento in fase di protocollo;
o permettere la visualizzazione dei documenti di un protocollo, in qualsiasi posizione siano presenti in funzione della e del processo che li ha trattati;
o consentire all’utente la classificazione di un documento come principale.
• La funzione di impianto affare legale dovrà suddividere la lista di materie in gruppi e sottogruppi di appartenenza, garantendo la possibilità di selezionare la materia.
• Migrazione dell’applet per disassociare affare legale a funzionalità NsiWeb2.
• Generazione del file metadati segnatura.xml (secondo le specifiche riportate nella circolare 60 del 2013 emessa da Agenzia per l’Italia Digitale) per tutti i protocolli in uscita da Avvocatura dello Stato.
• Nuove funzioni statistiche per il sistema NsiWeb2 relative alle PEC in ingresso al sistema con funzionalità gerarchiche di selezione.
• Modifiche sulla interfaccia grafica per la visualizzazione dei dettagli di protocollo della funzione del Nuovo Affare Legale Integrale.
5.2.1 Piano di lavoro
Le attività erogate nell’ambito dei servizi di sviluppo e MEV di NSI2Web dovranno seguire il ciclo di vita descritto nella Tabella 1, con i relativi deliverable e condizioni di uscita.
Tabella 1
Fase | Deliverable | Condizione di uscita |
Definizione | Specifica dei requisiti Piano di lavoro | Approvazione di AGS |
Analisi e Progettazione | Specifica dell’intervento Piano di test v.1 Documentazione dati | Approvazione di AGS |
Realizzazione | Codice sorgente Piano di test v.2 Documentazione utente Documentazione delle procedure batch Baseline Function Point | Consegna |
Collaudo | Accettazione di AGS |
Eventuali modifiche dal ciclo di vita sopra descritto dovranno essere concordate con il Responsabile di Progetto AGS.
Di seguito viene indicato l’obiettivo di ciascuna fase.
5.2.1.1 Definizione
La fase di definizione è volta a identificare e dettagliare le effettive esigenze dell’utente, con riferimento ai processi ed alle funzioni che le compongono, al fine di giungere alla definizione dell’ipotesi di soluzione ed alla pianificazione dei tempi di realizzazione.
Gli scopi principali della fase di definizione sono:
• descrivere formalmente il sistema attuale e individuare problemi, vincoli, carenze e peculiarità di ogni funzione analizzata;
• definire un modello del sistema da realizzare che rappresenti la struttura logica in termini di comportamento complessivo, informazioni da trattare, funzioni da svolgere o a cui fornire supporto;
• concordare le modalità tecniche di realizzazione;
• definire l’infrastruttura del sistema e la soluzione tecnologica;
• proporre la pianificazione delle attività, in termini di stima di tempi, risorse e gestione del rischio;
• realizzare i prodotti di fase.
La fase può avere in input documenti preesistenti quali studi di fattibilità, verbali di riunioni, bozze di requisiti, nonché, se applicabile, la documentazione dei sistemi
esistenti.
La fine della fase è rappresentata dall’approvazione di tutti i documenti di fase.
5.2.1.2 Analisi e progettazione
La fase di “analisi e progettazione” è volta a definire in modo completo ed esaustivo l’applicazione da realizzare, sia per quanto riguarda gli aspetti funzionali che tecnici.
La fine della fase è definita dall’approvazione di tutti i documenti di fase.
La successiva fase di realizzazione potrà comunque iniziare all’avvenuta approvazione anche del solo documento di specifiche dell’intervento.
5.2.1.3 Realizzazione
La fase di realizzazione è volta a generare i componenti software e la base dati che realizzano il sistema, verificando inoltre la loro correttezza e funzionalità.
Essa potrà comunque iniziare all’avvenuta approvazione anche del solo documento di specifiche dell’intervento.
Gli scopi principali della fase di realizzazione sono:
• effettuare l’implementazione del sistema, producendo il codice sorgente;
• eseguire i test e relativo codice di test;
• realizzare i prodotti di fase;
• aggiornare, in caso di modifiche intercorse, i prodotti delle fasi precedenti;
• predisporre l’ambiente di collaudo, effettuando le opportune attività per verificarne la correttezza.
• Supportare l’esecuzione dei test di sicurezza.
La fine della fase è definita dalla consegna dei prodotti di fase, sottolineando che l’avvenuta consegna non implica di per sé accettazione.
5.2.1.4 Collaudo
La fase di collaudo del software realizzato è di responsabilità dell’Amministrazione che agirà come unica interfaccia nei confronti del Fornitore.
Saranno oggetto di verifica durante il periodo di collaudo tutti i prodotti delle fasi precedenti.
La fase di collaudo comprende, da parte del fornitore, il supporto al collaudo stesso, la rimozione delle anomalie fino al momento dell’accettazione, il supporto all’installazione delle procedure realizzate negli ambienti di esercizio e manutenzione (definizione e caricamento della base dati, installazione del software applicativo, personalizzazione del software di base, ecc) ed il supporto alla ri-esecuzione dei test automatizzati.
La fase si conclude con l’accettazione del software da parte del Responsabile di
progetto AGS.
5.2.2 Contenuto dei deliverable
5.2.2.1 Specifica dei requisiti
È un documento che contiene la descrizione dei requisiti, funzionali e non, emersi nella fase di definizione delle esigenze utente.
5.2.2.2 Piano di lavoro di obiettivo
Il Piano di lavoro di obiettivo contiene il dettaglio delle attività di ogni singola fase del singolo obiettivo, la relativa tempificazione e le stime di impegno.
L’aggiornamento dello stato di avanzamento delle attività, su richiesta dell’Amministrazione, non determina una nuova versione del documento.
Il Piano di lavoro di obiettivo riporterà:
• il nominativo del capo progetto;
• codice, nome, descrizione dell’obiettivo e, se significativo, relativo stato (sospeso, cancellato, ecc.);
• Il Gantt delle attività, contenente:
o elenco delle fasi e delle singole attività con relative date di inizio e fine, previste ed effettive;
o prodotti di fornitura delle singole fasi e prodotti intermedi delle singole attività, anche semilavorati, con le relative date di consegna, previste ed effettive.
• il Gantt dovrà contenere anche l’attività di approvazione dei prodotti di fase, ove prevista, riportando le date di inizio e fine concordate con l’Amministrazione. Pertanto le date finali delle varie fasi devono essere comprensive anche dell’eventuale tempo di approvazione dei prodotti;
• all’interno del Gantt dovranno essere esplicitate le seguenti attività:
o attività di test (o verifica, validazione, review);
o attività di predisposizione e relativa verifica degli ambienti di collaudo ed esercizio;
o attività di trasferimento del know-how al gruppo di gestione applicativa;
o attività per il passaggio di conoscenze ai referenti di aree integrate, ove l’obiettivo abbia ripercussioni sulle funzionalità di altre aree applicative.
• Per la parte di stato di avanzamento le informazioni da riportare riguardano:
o percentuale di avanzamento delle singole attività;
o data a cui si riferisce lo stato di avanzamento;
o razionali di ripianificazione;
o scostamento eventuale delle date, dell’impegno e del volume;
o vincoli/criticità e relative azioni da intraprendere e/o intraprese.
5.2.2.3 Specifica dell’intervento
Il documento “specifica dell’intervento” conterrà sia gli aspetti funzionali sia gli aspetti tecnici, pertanto comprenderà:
• l’analisi dei requisiti sia relativamente ai processi ed alle modalità con cui tali processi risulteranno visibili agli utenti finali, sia al disegno logico dei dati secondo il modello relazionale, sia per quanto riguarda gli aspetti non funzionali (architettura, sicurezza, accessibilità, vincoli, prestazioni, ecc.), sia alla documentazione delle interfacce (includere esempi di layout delle principali schermate utente, ecc.);
• la documentazione del disegno logico e fisico dei dati; Per ogni modulo, dovrà essere presente:
• descrizione delle funzioni svolte;
• tipologia (on-line, batch, etc.);
• indicazioni sulla riutilizzabilità del componente;
• parametri scambiati con altri componenti;
• parametri di attivazione;
• accessi agli archivi/base dati;
• controlli e diagnostica;
• algoritmi di calcolo per ciascuna entità.
Per quanto riguarda il disegno logico dei dati, la tecnica di rappresentazione può variare in funzione del DBMS utilizzato.
In ogni caso dovranno essere prodotte le matrici d’uso (o matrici CRUD) degli archivi da parte dei moduli software (concettualmente simili alle matrici Funzioni/Entità).
Nei casi critici, per dimensioni delle basi dati e/o frequenza di utilizzo, deve essere indicata la frequenza prevista per il tipo d’uso che il modulo fa degli archivi/basi dati, le frequenze totali per tipo d’uso relative a ciascun archivio/tabella della base dati, le frequenze totali per tipo d’uso per ciascun componente.
Per quanto riguarda il caricamento iniziale dei dati, dovranno essere indicati:
• gli archivi fisici/basi dati da dove prendere i dati e il loro tracciato;
• i tracciati dei dati da caricare manualmente;
• le relazioni tra archivi fisici/basi dati e schemi logici;
• i volumi trattati, con dettaglio sulla occupazione di memoria e spazio disco;
• le modalità di inizializzazione degli archivi/basi dati.
Il livello di completezza richiesto deve essere tale da consentire la produzione del Piano di test senza necessità di ulteriori approfondimenti.
5.2.2.4 Piano di Test
Il Piano di Test è un documento che accompagna ogni obiettivo lungo tutto il ciclo di vita, ed è pertanto un documento che si evolve nel tempo.
Ha lo scopo di definire test specifici, tramite i quali, saranno sottoposti a verifica i prodotti della realizzazione, con particolare riguardo alla loro validazione rispetto ai requisiti dell’utente, nonché documentare il loro esito.
Nel Piano di Test devono essere necessariamente compresi i test relativi alla verifica della corretta predisposizione dell’ambiente di collaudo.
Il piano di test deve essere redatto seguendo la logica dei test per scenario, derivandoli quindi dai documenti di specifica dei casi d’uso (“Use case specification”, contenuto nella Specifica dei requisiti). Un piano di test di tale tipologia, ove approvato da parte del Responsabile di Progetto dell’AGS, è da ritenersi sufficiente ai fini della verifica finale funzionale.
Nell'ambito dello sviluppo mediante il framework JBoss-Seam saranno realizzati test automatici di unità per tutte quelle funzioni di complessità tale da giustificarne la realizzazione.
I test saranno scritti utilizzando gli ambienti open source Junit oppure TestNG.
Il fornitore avrà cura di rilasciare la versione preliminare del piano dei test a conclusione della fase di Analisi e Progettazione (Piano di test v.1, come indicato in Tabella 1), mentre la versione finale del piano di test sarà rilasciata al termine della fase di realizzazione (Piano di test v.2).
5.2.2.5 Documentazione dati
La documentazione dati contiene la descrizione e la rappresentazione della base dati dell’area, esplicita eventuali collegamenti con la base dati di altre aree o le regole tecniche con cui l’applicazione scambia flussi informativi di dati con altre applicazioni.
La documentazione dati è obbligatoriamente articolata nelle seguenti componenti:
• Modello dei dati;
• Dizionario dati.
1. MODELLO DEI DATI
Il modello dei dati è composto da:
• Glossario che dovrà contenere:
o descrizione di tutti gli oggetti degli schemi concettuali;
o descrizione di tutti gli oggetti degli schemi logici;
o mapping schema concettuale- logico.
• schema concettuale e logico su tool di modellazione dati (ad esempio Xxxxx); I file dovranno essere forniti in formato ER1.
I modelli dati contenuti nei file dovranno comprendere:
• Diagramma E/R;
• Nome e Descrizione delle Entità;
• Nome e Descrizione degli Attributi;
• Mapping Entità/Tabella e Attributo/Xxxxxxx.
• mapping concettuale-logico: su tool di modellazione dati Xxxxx o su documento;
• schema fisico: su tool di modellazioni dati Xxxxx;
• dizionario dati: inserito negli opportuni campi dei DBMS.
Lo schema concettuale dovrà contenere le seguenti informazioni:
• schema grafico rappresentante le entità e l’associazione tra esse intercorrenti;
• nome (e/o codice) e descrizione del significato delle entità;
• nome (e/o codice) e descrizione del significato delle associazioni intercorrenti tra le entità;
• nome (e/o codice) e descrizione del significato degli attributi appartenenti alle singole entità e associazioni.
Lo schema logico dovrà contenere:
• Schema grafico rappresentante le relazioni;
• Vincoli di integrità;
• Relazioni fondamentali;
• Relazioni associative;
• Chiavi primarie e secondarie.
Il mapping concettuale-logico dovrà contenere la corrispondenza tra le entità e associazioni descritte nello schema concettuale e le relazioni descritte nello schema logico.
Lo schema fisico dovrà contenere:
• indicazione del metodo di accesso utilizzato;
• bloccaggio di ciascun data-set;
• clausole di storage;
• descrizione dei dati interni del DBMS (tabelle, indici, ecc.) che realizzano la struttura prevista.
2. DIZIONARIO DATI
Il dizionario dati dovrà contenere:
• Nome della tabella;
• Nome dell’attributo;
• Indicazione della chiave primaria;
• Indicazione di eventuale chiave esterna;
• Tipo e dimensione dell’attributo (char, number, date ecc.);
• Descrizione dell’attributo;
• Dominio;
• nel caso di campi calcolati l’algoritmo che valorizza il campo;
• riferimenti a controlli applicativi (anche a mezzo di trigger) che insistono sul campo
• descrizione dei codici di errore di tutti i controlli.
5.2.2.6 Documentazione utente
La documentazione utente, rivolta all’utente finale delle applicazioni, è composta dal Manuale utente e dall’help on line (rilasciato con il codice sorgente).
Manuale utente
Il manuale utente deve fornire una descrizione generale dell’applicazione e una guida operativa all’utilizzo delle singole funzionalità utilizzabili.
La descrizione deve contemplare:
• la tipologia di utenza cui è destinata e le funzioni abilitate per ciascuna tipologia;
• gli eventuali flussi di dati scambiati con altri sistemi informativi o con specifiche tipologie di utenze;
• le modalità di attivazione e chiusura della “sessione di lavoro”;
• descrizione delle funzioni e della navigazione tra di esse;
• la spiegazione dettagliata dell’uso delle singole funzioni di interfaccia utente (comprensiva della funzione di richiamo dell’help);
• la descrizione degli algoritmi di calcolo utilizzati;
• la descrizione dei contenuti degli output della applicazione (es. stampe).
La descrizione delle funzionalità disponibili deve essere completa dell’elenco di tutti i codici d’errore previsti, della messaggistica ad essi associata e delle azioni da intraprendere a fronte di ciascuna segnalazione.
Nel caso in cui l’applicazione preveda un utilizzo diretto dei dati da parte dell’utente, deve essere inserita anche la descrizione dettagliata della struttura dei dati interessati.
Help on line
Tutte le applicazioni interattive devono prevedere le funzioni di help on line.
5.2.2.7 Piano di lavoro di obiettivo
Il Piano di lavoro di obiettivo contiene il dettaglio delle attività di ogni singola fase del singolo obiettivo, la relativa tempificazione e le stime di impegno.
L’aggiornamento dello stato di avanzamento delle attività, su richiesta
dell’Amministrazione, non determina una nuova versione del documento.
Il Piano di lavoro di obiettivo riporterà:
• il nominativo del capo progetto;
• codice, nome, descrizione dell’obiettivo e, se significativo, relativo stato (sospeso, cancellato, ecc.);
• Il Gantt delle attività, contenente:
o elenco delle fasi e delle singole attività con relative date di inizio e fine, previste ed effettive;
o prodotti di fornitura delle singole fasi e prodotti intermedi delle singole attività, anche semilavorati, con le relative date di consegna, previste ed effettive.
• il Gantt dovrà contenere anche l’attività di approvazione dei prodotti di fase, ove prevista, riportando le date di inizio e fine concordate con l’Amministrazione. Pertanto le date finali delle varie fasi devono essere comprensive anche dell’eventuale tempo di approvazione dei prodotti;
• all’interno del Gantt dovranno essere esplicitate le seguenti attività:
o attività di test (o verifica, validazione, review);
o attività di predisposizione e relativa verifica degli ambienti di collaudo ed esercizio;
o attività di trasferimento del know-how al gruppo di gestione applicativa;
o attività per il passaggio di conoscenze ai referenti di aree integrate, ove l’obiettivo abbia ripercussioni sulle funzionalità di altre aree applicative.
• Per la parte di stato di avanzamento le informazioni da riportare riguardano:
o percentuale di avanzamento delle singole attività;
o data a cui si riferisce lo stato di avanzamento;
o razionali di ripianificazione;
o scostamento eventuale delle date, dell’impegno e del volume;
o vincoli/criticità e relative azioni da intraprendere e/o intraprese.
5.2.2.8 Documentazione delle procedure batch/DTS
La documentazione delle procedure off line (batch, job, stored procedure, DTS, script ecc.) è destinata ai gruppi di gestione applicativa quale supporto alle loro attività ordinarie.
È un documento di area.
Si articola nei componenti di seguito riportati:
1. ELENCO DELLE PROCEDURE;
L’elenco delle procedure fornisce una descrizione generale delle procedure e una guida operativa per la loro schedulazione, ordinaria e straordinaria.
La descrizione deve contemplare:
• codice identificativo della procedura;
• descrizione sintetica;
• puntamento al manuale utente;
• evento per l’attivazione della schedulazione (ad es. calendario, richiesta utente ecc.);
• ambiente;
• vincoli procedurali;
• periodicità;
• note eventuali;
• puntamento al documento di procedura.
2. DOCUMENTO DI PROCEDURA;
Il documento di procedura deve fornire la descrizione operativa di ogni procedura, in particolare deve riportare:
• elenco di tutti i componenti che la costituiscono (job, Stored procedure, DTS ecc);
• diagramma di flusso dei componenti (flow chart);
• matrice componenti/base dati;
• per ogni componente, eventuali parametri da fornire in input per l’esecuzione, l’elenco di tutti gli output e del loro significato (file, stampe ecc), l’elenco dei codici di errore, vincoli fisici di schedulazione e le istruzioni operative in caso di malfunzionamento (es. job di recovery, possibilità di eliminazione, ecc.).
5.2.2.9 Baseline Function Point
È il documento in cui sono contenute le informazioni relative al conteggio dei punti funzione affidati al servizio di Manutenzione Correttiva.
Il report deve riportare almeno le seguenti informazioni:
• baseline di partenza;
• baseline aggiornata;
• identificativo ed estremi degli obiettivi di sviluppo che hanno determinato la variazione della baseline, con i relativi punti funzione.
5.3 Servizio di Manutenzione correttiva
Si intende per manutenzione correttiva l’insieme delle attività volte alla diagnosi e alla rimozione delle cause e degli effetti dei malfunzionamenti del software, assicurando il tempestivo ripristino dell'operatività.
Nell’ambito dell’attività in oggetto, il Fornitore si attiverà per provvedere quanto segue:
• la determinazione delle cause dei malfunzionamenti;
• la redazione di una relazione tecnica descrittiva dell’errore, delle relative cause e delle modalità di risoluzione prospettate;
• l’analisi, la realizzazione ed il test dell’azione correttiva, con verifica che all’intervento non sia conseguita regressione del prodotto;
• la richiesta di rilascio in esercizio dell’azione correttiva del malfunzionamento;
• l’intervento sui sistemi in esercizio e, se necessario, il ripristino dei dati;
• l’aggiornamento della documentazione ove necessario.
Ogni intervento di Xxxxxxxxxxxx Xxxxxxxxxx dovrà essere pianificato ed eseguito in accordo con AGS.
Il Committente ordinerà specifici interventi di Manutenzione Correttiva sulla base delle esigenze che si manifesteranno a partire dalla data di verifica finale del prodotto.
5.4 Servizio di Supporto per il rilascio, la messa in esercizio e la gestione operativa
L’azienda aggiudicataria dovrà garantire per tutta la durata della fornitura il supporto necessario al rilascio, configurazione, messa in esercizio e ogni altra attività riferibile alla gestione operativa del software prodotto.
I componenti forniti devono essere installati a cura del fornitore negli ambienti resi disponibili dal Committente.
L’AGS mette altresì a disposizione un server SVN in cui allocare tutte le versioni di software e documentazione, sia quelle sviluppate dall’aggiudicatario, sia quelle sviluppate in house da personale AGS. L’aggiudicatario dovrà aggiornare il repository SVN ad ogni incontro presso l’AGS, per quanto di sua competenza, risolvendo eventuali conflitti, in accordo con Responsabile di Progetto dell’AGS.
È in corso una attività di migrazione delle attività di gestione del data-center verso Corte dei conti; tale attività potrebbe, nel prossimo futuro, comportare una modifica alle attuali procedure di rilascio e installazione del software che verranno tempestivamente comunicate al fornitore.
1 Descrizione delle figure professionali richieste
Per lo svolgimento delle attività sopra descritte è richiesto un team di sviluppo composto da quattro figure professionali specialistiche che abbiano competenze specifiche sulle tecnologie utilizzate presso Avvocatura dello Stato.
il gruppo di lavoro dovrà essere composto dalle seguenti quattro figure professionali:
- un progettista;
- un analista;
- un analista programmatore;
- un programmatore.
Ciascuna componente dovrà possedere le seguenti competenze/conoscenze:
- ottima competenza nello sviluppo di applicazioni Web2 che restituiscano output sia di tipo HTML4 che HTML5;
- conoscenza approfondita del framework Jboss-Seam (a partire dalla versione 2.2);
- conoscenza approfondita delle librerie javascript per applicazioni web2 e, in particolare, utilizzo di Ajax, Boostrap e Jquery
- conoscenza approfondita dei tools di sviluppo per Oracle 11g e, in particolare con esperienze maturate:
o su qualsiasi istruzione SQL di base e/o complesse
o linguaggio PL/SQL con capacità di sviluppo di componenti quali Function, Procedure e package complessi
- conoscenza approfondita del linguaggio Java e ottima capacità di interfacciamento per la realizzazione di siti web basati sulle quattro tecnologie sopra citate.
Durante la durata dell’attività di sviluppo dovrà essere assicurato un presidio per la risoluzione dei malfunzionamenti (vedi paragrafo 5.3) dalle ore 9,00 alle ore 17,00, dal lunedì al venerdì.
2 Gestione del servizio
Dopo la stipula del contratto l’AGS indicherà al Fornitore un proprio referente (indicato nel presente capitolato come Responsabile di progetto per l’AGS) che curerà i rapporti con il Fornitore per l’esecuzione del contratto, con funzioni d'interfaccia per il rispetto delle esigenze e delle priorità dell’AGS. L’AGS si riserva il diritto dell’eventuale sostituzione del suo referente.
Gli approfondimenti necessari alla realizzazione dell'analisi e le scelte sia di progetto che di realizzazione devono essere assunte in accordo con il responsabile di progetto dell'AGS.
La redazione del progetto, della sua analisi e della sua implementazione possono essere realizzati anche nei propri uffici, ma l'AGS non intende sopportare i costi di costruzione di un ambiente di realizzazione adatto alle necessità presso la sede dell'azienda aggiudicatrice. In questo caso non verranno tollerati ritardi, rispetto alle pianificazioni concordate, dovuti a difficoltà di realizzazione dei suddetti ambienti per lo sviluppo.
Nel caso in cui si scelga di operare presso l'AGS, questa fornirà il supporto logistico alle attività: scrivania, sedia e connettività. Le necessità dello sviluppatore in termini di supporti hardware e software per lo sviluppo sono interamente a carico dell'azienda aggiudicataria.
2.1 Luogo di lavoro
Il luogo di esecuzione del contratto è previsto sia presso le sedi del Fornitore, che
presso le sedi del Committente.
Le attività relative a incontri, collaudi, consegna dei prodotti saranno svolte presso le sedi del Committente.
Le altre attività saranno svolte in parte presso la sede del Fornitore e in parte presso la sede del Committente.
2.2 Comunicazioni
Per quanto riguarda iterazioni e fasi di progetto, la modalità usuale di comunicazione formale prevede l’utilizzo di documentazione in formato digitale.
La consegna degli oggetti di fornitura va effettuata riversandoli su repository SVN messo a disposizione dal committente e con una lettera di accompagnamento, anche via e-mail, con ricevuta o comunicazione di accettazione, indirizzata al Responsabile di Progetto.
2.3 Livelli di servizio
L’attività di presidio che si occuperà della gestione dei malfunzionamenti dovrà fornire le informazioni relative all’AGS.
Queste informazioni dovranno essere strutturate nelle modalità di seguito descritte.
Si considera la seguente suddivisione dei malfunzionamenti:
• Bloccanti: impediscono l'operatività anche parziale del sistema. Tali malfunzionamenti impediscono o ritardano lo svolgimento dell’attività istituzionale dell’Avvocatura dello Stato.
• Non bloccanti: non hanno un impatto immediato, evidente e generalizzato sulle attività istituzionali dell’Avvocatura dello Stato.
I livelli di servizio richiesti sono quelli riportati nella Tabella 1, dove con Tempo di intervento si intende il tempo di presa in carico del problema e con Tempo di ripristino si intende il tempo di ripristino dell’operatività del servizio.
Qualora l’aggiudicatario, nel rispondere alla chiamata, riscontri che la stessa è relativa a fatti che esulano dal rapporto di Garanzia-Manutenzione, è tenuto ad evidenziare il tipo di intervento che si rende necessario e l’eventuale spesa preventivata per la rimozione del malfunzionamento.
Sarà cura dell’AGS verificare la validità e la congruità di quanto indicato dall’aggiudicatario e, quindi fornire alla stessa, informazioni sulle conseguenti determinazioni dell’AGS.
Tipo difetto | Indicatore | Livello di servizio |
Bloccante | Tempo di Intervento (presa in carico) | 4 ore nel 90% dei casi |
6 ore nel 10% dei casi | ||
Tempo di ripristino | 8 ore nel 90% dei casi | |
24 ore nel 5% dei casi | ||
Tasso di risoluzione | 100% | |
Non Bloccante | Tempo di Intervento (presa in carico) | 24 ore nel 90% dei casi 36 ore nel 10% dei casi |
Tempo di ripristino | 48 ore nel 90% dei casi | |
72 ore nel 5% dei casi | ||
Tasso di risoluzione | 99% |
Per quanto concerne le attività di sviluppo e manutenzione evolutiva del software (vedi paragrafo 5.2.1), il livello di servizio da rispettare è il seguente:
- Rispetto della scadenza temporale dell’obiettivo definita nel piano di lavoro approvato (o analogo documento).
Pertanto, per ciascuna scadenza prevista dall’obiettivo, dovrà essere rilevata la Data prevista e la Data effettiva e la differenza tra le due date dovrà essere pari a zero.
2.4 Modalità di esecuzione
Il Committente si riserva di chiedere al Fornitore di utilizzare prodotti o modulistica specifica per il controllo e la gestione delle attività della fornitura. Il Fornitore può presentare una propria proposta in merito. Il Committente si riserva di avvalersi di terzi per il supporto allo svolgimento di attività di propria competenza, ferma restando la responsabilità globale del Committente nello svolgimento di tali attività. Tutti i documenti del prodotto dovranno, nella loro versione finale, essere approvati dal Responsabile di Progetto di AGS.
Salvo quanto diversamente concordato fra le due parti, l’AGS si impegna a comunicare la propria valutazione dei documenti finali, con eventuali modifiche/integrazioni e osservazioni, entro 15 giorni solari dalla loro consegna e l’aggiudicatario si impegna a recepire le richieste della AGS entro i 15 giorni solari successivi.
2.5 Penali
Le penali sono applicabili per mancato rispetto delle condizioni di fornitura previste nel presente capitolato. Tali condizioni possono riferirsi a mancato svolgimento delle attività o ritardo nella loro esecuzione. Per mancato svolgimento delle attività o ritardo nella loro esecuzione si intendono quelli non giustificati e non sanati con sospensioni o proroghe accordate dalla AGS ed esclusivamente imputabili a cause dovute alla ditta o da essa provocate.
L’AGS si riserva di applicare o no le penali risultanti dal calcolo basato sui livelli di servizio a suo insindacabile giudizio, basato sull’effettiva analisi delle circostanze verificatesi e di eventi contingenti.
Verranno in ogni caso applicate le penali relative alla mancata presenza del personale; per ogni giorno di assenza ingiustificata e non approvata preventivamente da AGS, è prevista una penale di € 300,00 (trecento/00).
A tal fine il fornitore si impegna a predisporre un documento in cui verranno riportate le presenze del proprio personale che sarà consegnato mensilmente ad AGS entro 5 giorni dalla fine del mese.
Ogni sostituzione del personale dovrà essere preventivamente comunicata ad AGS.
Relativamente ai servizi di sviluppo e manutenzione evolutiva, è prevista una penale stabilita in € 200,00 (duecento/00) per ogni giorno lavorativo di ritardo rispetto ai termini previsti nei piani di lavoro approvati da AGS.
Relativamente al servizio di manutenzione correttiva, si prevede una penale di € 50,00 (cinquanta/00) per ogni ora di ritardo, nel trimestre, di ciascuna delle soglie di qualità definite nel paragrafo 5.3 (Livelli di servizio).
Le penalità applicate saranno scalabili dalle fatture emesse.
In ogni caso, le penali non potranno superare il limite del 10% del valore dell'intera fornitura. Al superamento del limite del 10% l'AGS ha il diritto di risolvere il contratto ed eseguire la procedura in danno prevista.
Nel caso di risoluzione del contratto per incapacità ad eseguirlo, per negligenza nell'effettuare la fornitura, oppure per mancata rispondenza della fornitura ai requisiti funzionali prescritti nel presente capitolato, viene esperita l'azione in danno nelle forme prescritte, per cui la ditta è tenuta al pagamento dell'eventuale maggiore spesa che l'AGS dovesse sostenere per l'acquisto presso altre imprese delle prestazioni oggetto della fornitura.
3 Informazioni generali sulla procedura
Premesso che tutta la documentazione relativa alla presente indagine di mercato è pubblicata sul MePA, per ogni eventuale chiarimento attinente aspetti amministrativi e tecnici, le ditte invitate potranno rivolgersi direttamente al Responsabile del procedimento.
3.1 Formulazione e valutazione dell'offerta
Le offerte dovranno pervenire entro il termine specificato nella relativa procedura RdO pubblicata sul MePA.
Le offerte tecniche pervenute saranno valutate da un’apposita commissione nominata ai sensi dell’art. 77 del D.lgs 18 aprile 2016 n. 50, sulla base dei criteri e secondo le modalità di seguito esposte.
3.2 Offerta tecnica
La relazione tecnica dovrà contenere la descrizione dettagliata del servizio proposto e di tutte le attività offerte. All’interno di tali sezioni dovrà essere spiegato con chiarezza come la soluzione risponda a tutte le esigenze espresse nel presente capitolato.
Il Fornitore, nel redigere la propria Offerta Tecnica, dovrà attenersi all’indice descritto nella tabella 2, a pena di esclusione.
I curriculum del personale che formerà il gruppo di lavoro dovranno essere prodotti in forma anonima.
Tabella 2
Capitolo | Paragrafo | |
1 | Introduzione | |
2 | Descrizione della fornitura | |
2.1 | Descrizione delle soluzioni proposte per il raggiungimento degli obiettivi della fornitura. | |
2.2 | Descrizione delle caratteristiche e delle modalità di lavoro, metodi e tecniche adottati al fine di assicurare la corretta realizzazione della fornitura. | |
3 | Organizzazione del lavoro | |
3.1 | Gruppo di lavoro | |
3.2 | Profili professionali | |
3.3 | Curriculum | |
4 | Informazioni sul Fornitore | |
4.1 | Il Fornitore | |
4.2 | Esperienza sull’ambiente tecnico operativo del sistema NSI o in servizi analoghi. | |
4.3 | Proposte migliorative per la gestione dei malfunzionamenti e la manutenzione correttiva. |
3.3 Offerta economica
L’offerta economica, di cui al presente capitolato, non può superare il limite massimo di
Euro 134.000,00 (centotrentaquattromila/00) al netto dell’IVA.
3.4 Procedura di valutazione
Le offerte presentate sono esaminate in modo comparativo ed inserite in una graduatoria finale. Le fasi di valutazione e di aggiudicazione non comportano per l’AGS alcun obbligo nei confronti dei soggetti concorrenti, né può sorgere in capo ai concorrenti alcun diritto a qualsivoglia prestazione da parte della AGS stessa.
3.5 Criteri di aggiudicazione delle offerte
All’esito della procedura di valutazione, l’AGS dispone l’aggiudicazione con il criterio dell’offerta economicamente più vantaggiosa; sono escluse le proposte non rispondenti a tutti i requisiti indicati nel presente capitolato; l’aggiudicazione ha luogo ai sensi dell'art. 95 del Decreto legislativo 18 aprile 2016 n. 50, sulla base dei criteri di valutazione descritti nella tabella 3.
Tabella 3
DESCRIZIONE CRITERI | Punteggio max | Punteggio totale | |
1) Offerta tecnica | Soluzioni proposte per il raggiungimento degli obiettivi e modalità di lavoro e tecniche adottati al fine di assicurare la corretta realizzazione della fornitura. | 20 | 60 |
Caratteristiche professionali delle risorse coinvolte (es.: formazione, certificazioni, esperienze, ecc…) e del fornitore. | 16 | ||
Esperienza sull’ambiente tecnico operativo del sistema NSI o in servizi analoghi. | 14 | ||
Proposte migliorative per la gestione dei malfunzionamenti e la manutenzione correttiva. | 10 | ||
2) Offerta economica | Importo | 40 | |
Totale | 100 | ||
Il punteggio relativo alle offerte economiche viene calcolato dal sistema MePA con la formula a proporzionalità inversa, ed è compreso fra zero e quaranta.
3.6 Aggiudicazione delle offerte
L’AGS si riserva di non procedere all’aggiudicazione se nessuna delle offerte presentate risulta idonea; di procedere all’aggiudicazione anche in presenza di una sola offerta valida; di sospendere o non aggiudicare il servizio.
L’AGS si riserva comunque il diritto di non procedere alla stipula del contratto.
L’AGS si riserva la facoltà di apportare un aumento o una diminuzione delle prestazioni oggetto del contratto fino alla concorrenza di un quinto ai sensi dell’art. 106 del d.lgs 18/11/2016 n. 50.
3.7 Decadenza dell'aggiudicazione
Il soggetto aggiudicatario decade dall’aggiudicazione in caso di mancata stipula del contratto, salva l’impossibilità derivante da causa al medesimo non imputabile, ove debitamente documentata.
Il soggetto aggiudicatario decade inoltre dall’aggiudicazione nel caso in cui l’AGS accerti, nei confronti del medesimo:
• La sussistenza di una delle cause impeditive di cui agli articoli 83 e 84 del D lgs n.
159 del 6/9/2011 e successive modificazioni e integrazioni in tema di
documentazione antimafia;
• La sussistenza di una delle cause di esclusione di cui all’art. 80 del D. Lgs n. 50 del 18/4/2016 e successive modifiche e integrazioni, o di altra causa di esclusione prevista nel presente capitolato;
• La violazione delle disposizioni in materia di assunzioni obbligatorie, di cui alla Legge n. 68/1999.
Laddove ricorra una delle cause ostative di cui al precedente periodo, l’AGS procederà alla stipula del contratto secondo l’ordine di graduatoria.
3.8 Trattamento dei dati
Il trattamento dei dati dei concorrenti, con particolare riguardo agli eventuali dati “sensibili”, è effettuato ai sensi del Decreto legislativo n. 196 del 2003 e successive modifiche e integrazioni in modo da garantire la sicurezza e la riservatezza; tale trattamento può essere attuato mediante strumenti manuali, informatici e telematici idonei a memorizzarli, gestirli e trasmetterli.
La ditta concorrente può specificare, nell’offerta tecnica, se ritiene la documentazione presentata, e quale parte, coperta da riservatezza, con riferimento a comprovati diritti relativi a marchi, know-how, brevetti ecc.
4 Altre condizioni amministrative
4.1 Diritti di proprietà
Tutto ciò che viene prodotto nell’esecuzione delle attività contrattuali (analisi di dettaglio, applicazioni, codice sorgente, documentazione, test-suite ecc.) è da intendersi di esclusiva proprietà dell’AGS che, in base alle vigenti norme di legge, può avvalersi della facoltà di riutilizzarlo in tutto on in parte.
L’AGS mantiene la proprietà su tutti i dati e artefatti (inclusi il codice sorgente, la documentazione, l’analisi dei processi ecc.) forniti nell’ambito del contratto.
L’aggiudicataria si obbliga a:
• consegnare all’AGS il codice sorgente dell’applicativo fornito;
• cedere irrevocabilmente all’AGS tutti i diritti sul codice stesso, se prodotto ex novo;
• consegnare tutta la documentazione utile.
Si precisa infine che ogni utilizzo o riuso, da parte di terzi, di tutto o parte del prodotto software sviluppato deve essere esplicitamente autorizzato dall’AGS.
4.2 Responsabilità e garanzie
L’aggiudicataria dichiara che nell’offerta economica sono compresi tutti i diritti e le eventuali indennità relative all’impiego di metodi, dispositivi e materiali eventualmente coperti da diritti di brevetto, d’autore e, in genere, da altri diritti di privativa.
L'AGS non assume in ogni caso alcuna responsabilità per l’ipotesi in cui
l’aggiudicataria abbia usato dispositivi, soluzioni tecniche o altro di cui terze parti siano titolari di brevetto o privativa.
L’aggiudicataria è tenuta alle garanzie per le difformità e i vizi come previsto dagli articoli 1667 e 1668 del Codice Civile.
L’aggiudicataria risponde penalmente e civilmente dei danni di qualsiasi genere che dovessero derivare a persone o cose durante lo svolgimento delle attività oggetto dell’appalto.
4.3 Controversie
In caso di controversie relative all’interpretazione e/o all’esecuzione del contratto, viene esperito un tentativo di conciliazione finalizzato alla relativa, immediata soluzione in via amministrativa.
In ipotesi di mancato accordo è competente in via esclusiva il Foro di Roma.
4.4 Spese contrattuali
Sono a carico dell’aggiudicatario tutte le spese contrattuali e tutti gli oneri fiscali relativi al presente atto, fatto salvo l’eventuale diritto di rivalsa, laddove previsto espressamente dalla legge.
4.5 Riservatezza e pubblicità
L’aggiudicataria si impegna a mantenere strettamente riservate tutte le informazioni relative all’AGS di cui dovesse venire in possesso nel corso dell’esecuzione del contratto e si dichiara sin da ora disponibile a sottoscrivere tutte le clausole di riservatezza specifiche che dovessero occorrere.
L’aggiudicataria, senza venir meno all’impegno di riservatezza di cui al punto precedente ed alle eventuali clausole di riservatezza specifiche, può avvalersi del presente contratto con finalità di eventuali referenze verso terzi.
4.6 Modalità di pagamento
I pagamenti in favore dell’aggiudicatario sono effettuati secondo le norme di legge in vigore e fanno seguito alla presentazione di regolari fatture per le quali siano state positivamente superate le rituali verifiche.
In attuazione del Decreto del Ministro dell’Economia e delle finanze 3 aprile 2013,
n.55 ai sensi dell’articolo 1, commi da 209 a 213, della legge 24 dicembre 2007, n. 244, le fatture in formato elettronico dovranno essere inviate al “Sistema di Interscambio” gestito dall’Agenzia delle Entrate che poi le renderà disponibili all’amministrazione. Il codice IPA, che andrà riportato sulla fattura, per l’Ufficio X – CED dell’Avvocatura Generale dello Stato è: OGQALD.
4.7 Risoluzione anticipata del contratto
Fatta salva ogni altra disposizione che autorizzi il committente alla risoluzione anticipata del contratto, tale facoltà è prevista esplicitamente per la AGS nei seguenti, specifici casi:
▪ applicazione di penali come previsto all'apposito paragrafo oltre il valore del 10% dell'intera fornitura;
▪ inadempienze gravi degli obblighi contrattuali che si protraggano oltre il termine perentorio assegnato dalla AGS alla ditta per porre fine all’inadempimento;
▪ violazione dei brevetti industriali e diritti d’autore;
▪ subappalto;
▪ cessione del contratto
▪ cessazione dell'attività;
▪ fallimento o concordato preventivo.
In caso di risoluzione anticipata del contratto, al fine di valutare l’entità degli eventuali danni subiti, l’AGS procede ad una stima dei beni e servizi forniti e da fornire.
4.8 Responsabile del procedimento
L'unità organizzativa competente per il presente procedimento è l'Ufficio X – Centro Elaborazione Dati; responsabile del procedimento, per quanto attiene alla fase di progettazione ed esecuzione, è la dott.ssa Xxxxxxx Xxxxxxxxx, in qualità di preposto all'Ufficio suddetto; per la fase di relativo affidamento, responsabile del procedimento è la dott.ssa Xxxxx Xxxxxx, in qualità di preposto all’Ufficio Contratti.
4.9 Osservanza di leggi, regolamenti e norme
L'aggiudicatario, sotto la sua esclusiva responsabilità, deve osservare le disposizioni legislative vigenti, come pure tutti i regolamenti, le norme e le prescrizioni delle competenti Autorità in materia di contratti di lavoro e sicurezza.
In particolare gli operatori economici invitati a partecipare alla presente procedura devono dichiarare di non trovarsi in alcuna delle condizioni ostative di cui all’art. 80 del d.lgs. n. 50/2016.
4.10 Verifica dei requisiti
L’AGS si riserva di procedere, nei confronti dell’aggiudicataria, alla verifica dei requisiti di carattere generale, tecnico-professionale ed economico-finanziario avvalendosi del sistema AVCPASS.
4.11 Codici di comportamento
In caso di prestazioni da eseguirsi presso l’amministrazione, l'aggiudicatario è tenuto al rispetto dei Codici di comportamento e dei codici etici di cui all’art. 54 del d.lgs. n. 165/2001 fornendo specifica accettazione.