CAPITOLATO TECNICO

Allegato 1 al Capitolato Speciale D’Appalto

CAPITOLATO TECNICO

CAPITOLATO TECNICO

GARA EUROPEA A PROCEDURA APERTA, AI SENSI DELL’ART. 71 DEL D. LGS. 36/2023 SMI, PER L’AFFIDAMENTO DEL SERVIZIO DI SVILUPPO DI UN APPLICATIVO PER LA GESTIONE INFORMATIZZATA DEL PROCEDIMENTO DI RECUPERO DEI TICKET SANITARI PER UN PERIODO DI 60 MESI.

Il Responsabile Unico del Progetto (RUP), è Xxxxxxx Xxxxxx

Il funzionario istruttore: Xxxxxxxxx Xxxxxxx – xxxxxxxx@xxx-xxxxxx.xx

SC GESTIONE ACQUISTI

CAPITOLATO TECNICO

INDICE

1 DEFINIZIONI, ABBREVIAZIONI E SIGLE 4

1.1 Definizioni generali legate al servizio 4

1.2 Altre definizioni, abbreviazioni e sigle 6

2 PREMESSA 8

2.1 Scopo del documento 8

2.2 Finalità 8

2.3 Ambito della fornitura 8

2.4 Contesto normativo, tecnologico e operativo 11

2.5 Durata del contratto 13

2.6 Titolarità del codice sorgente 13

3 REQUISITI FUNZIONALI 14

3.1 Requisiti generali del servizio 14

3.2 Requisiti specifici del servizio 16

4 REQUISITI NON FUNZIONALI 26

4.1 Requisiti organizzativi 26

4.2 Requisiti di security 27

4.3 Requisiti e vincoli tecnologici e infrastrutturali 29

4.4 Requisiti di usabilità 31

4.5 Requisiti di integrazione 32

4.6 Requisiti di migrazione e gestione del transitorio 33

CAPITOLATO TECNICO

5 PROGETTAZIONE, REALIZZAZIONE E DELIVERY 34

5.1 Responsabilità 34

5.2 Strumenti di project management 34

5.3 Testing, Collaudo ed avvio in produzione 35

5.4 Servizi cloud 36

5.5 Governance e monitoraggio in produzione 37

6 FORMAZIONE UTENTI 37

7 SERVIZI DI ASSISTENZA E MANUTENZIONE 38

7.1 Manutenzione correttiva ed assistenza 38

7.2 Manutenzione normativa 39

7.3 Manutenzione evolutiva 40

8 SLA RICHIESTI E CRITERI DI MISURA 42

9 RIFERIMENTI DOCUMENTALI E NORMATIVI 43

10 APPENDICE 46

10.1 Diagramma Generale 46

CAPITOLATO TECNICO

1 Definizioni, abbreviazioni e sigle

1.1 Definizioni generali legate al servizio

Aggiudicatario	Il Concorrente scelto dalla stazione appaltante per erogare le forniture ed i servizi coperti dal contratto.
ATS	ATS Milano Città Metropolitana, Stazione Appaltante.
Concorrente	Qualsiasi partecipante alla procedura di gara.
Software di base	Per software di base si intende l’insieme dei programmi che consentono ad un utente di eseguire operazioni base come costruire e mandare in esecuzione un programma o gestire una base dati. Tipici esempi di software di base sono il sistema operativo, gli editor, i compilatori ed i sistemi di gestione di basi di dati.
Software d’ambiente	Il software d’ambiente rappresenta l’insieme di programmi specializzati che facilitano la scrittura/gestione di applicazioni. Tipici esempi di software d’ambiente sono gli Application Server.
Software di rete	Il software di rete è inteso come l’insieme di programmi specialistici per la gestione delle comunicazioni. Tipici esempi di software di rete sono i gestori di posta ed i prodotti di gestione e condivisione di risorse distribuite.
Software applicativo	Il programma che utilizza il software di base, d’ambiente e di rete per realizzare funzionalità legate agli scopi dell’organizzazione che lo utilizza.
Software proprietario	Il software privato, non libero di cui è possibile al beneficiario l’utilizzo sotto particolari condizioni (in relazione alla licenza) ma non ne è permessa la modifica, la condivisione, lo studio, la ridistribuzione o il reverse engineering.
Software open source	Altrimenti detto software "libero", "aperto" o "rilasciato sotto licenza aperta”. Un software open source è reso tale per mezzo di una licenza attraverso cui i detentori dei diritti favoriscono la modifica, lo studio, l'utilizzo e la redistribuzione del codice sorgente.
Software verticale	Applicazioni software con funzionalità specifiche di un determinato settore commerciale.
Software orizzontale	Applicazioni software di uso generalizzato (general-purpose) adattabili alle esigenze di diversi settori commerciali.

CAPITOLATO TECNICO

	Si tratta di software commerciali con funzioni di utilità standard quali ad esempio: ERP, CRM, Knowledge and Content Management, Business Intelligence, sistemi di gestione documentale.
Service Level Agreement (SLA)	Sono i Livelli di Servizio minimi contrattualmente richiesti. Definizione ed associato criterio di misura per la valutazione della qualità dei servizi che saranno erogati dall’aggiudicatario.
Malfunzionamento bloccante	Malfunzionamento (difetto, errore, anomalia) che rende totalmente o parzialmente non utilizzabili ad un utente una o più funzionalità del sistema.
Malfunzionamento non bloccante	Malfunzionamento (difetto, errore, anomalia) che non inibisce l’operatività di un utente del sistema; l’utente può ugualmente pervenire ai risultati attesi mediante l’utilizzo di altre funzionalità offerte dal sistema e senza eccessivo aggravio sulla sua operatività.
Sistema di gestione dei ticket e ticket	Il sistema di gestione dei ticket è un tool software che permette di gestire la base dati dei ticket, il flusso di ogni ticket e l'estrazione di misure per la verifica degli SLA. Un ticket contiene una richiesta di assistenza o di manutenzione attraverso una delle modalità di accesso al servizio e ne traccia l’evoluzione
Manutenzione software correttiva	Rimozione di eventuali malfunzionamenti delle procedure applicative segnalati dall’amministrazione o dall’aggiudicatario e verificatisi nell’ambito del corretto utilizzo dei programmi. Per malfunzionamento si intende una non conformità con quanto specificato nei manuali operativi o nelle specifiche tecniche / funzionali consegnate all’ATS.
Manutenzione software normativa	Comprende attività da svolgere per l’adeguamento del software applicativo al fine di adempiere ad obblighi di legge o a fronte di requisiti tecnici, informativi, funzionali e organizzativi che siano definiti da organismi normativi esterni alla struttura dell’ATS (Stato, Ministeri, Regioni, etc.).
Manutenzione software evolutiva	Comprende la modifica / aggiunta di funzioni o la parametrizzazione del software applicativo sulla base di specifici requisiti dell’ATS
Manutenzione preventiva programmata	Comprende interventi periodici e/o programmati per garantire il mantenimento del buon funzionamento del sistema informativo, attraverso il costante aggiornamento del software applicativo e di base.

CAPITOLATO TECNICO

1.2 Altre definizioni, abbreviazioni e sigle

Sistema	Con sistema si intende complessivamente l’insieme dei moduli applicativi, delle basi dati e delle interfacce, grafiche e di comunicazione, che costituiscono l’oggetto del presente Capitolato.
Utente	Con utente si intende un generico utilizzatore del sistema; ogni utente è caratterizzato da un proprio profilo ed ha la visibilità delle sole aree applicative connesse al proprio utilizzo del sistema.
SPOC	Single Point Of Contact. Il referente unico di contatto dell’aggiudicatario per tutta la durata del contratto.
ANAC	Autorità Nazionale Anticorruzione.
GDPR	General Data Protection Regulation (UE) 2016/679.
AgID	Agenzia per l’Italia Digitale.
ACN	Agenzia per la Cybersicurezza Nazionale.
FP	Function Point è una metrica utilizzata per esprimere la dimensione o misura delle funzionalità fornite da un prodotto software (secondo la metodologia IFPUG 4.3 ed eventuali versioni successive).
PA	Con il termine “PA” o “P.A.” va intesa la Pubblica Amministrazione.
Piattaforma Sintel	Piattaforma di e-procurement di Regione Lombardia, istituita con lo scopo di realizzare un sistema di Intermediazione Telematica che supporti la Regione e tutte le PA della Lombardia nella realizzazione delle proprie gare.
OE	Operatore Economico.
RL	Regione Lombardia.
Cloud computing	Si indica un modello di erogazione di servizi offerti on demand da un fornitore ad un cliente finale attraverso la rete Internet.
CSP	Cloud Service Provider
SaaS	Software as a Service.

CAPITOLATO TECNICO

	È un paradigma di servizio cloud attraverso il quale il fornitore di software applicativo sviluppa e gestisce un'applicazione web che mette a disposizione dei propri clienti via Internet.
OWASP	Open Web Application Security Project. Progetto open-source con l'obiettivo di realizzare linee guida, strumenti e metodologie per migliorare la sicurezza delle applicazioni.
AD	Active Directory.
CA	Certification Authority.
HA	High Availability.
SSO	Single Sign On.
QA	Quality Assurance.
VAPT	Vulnerability Assessment & Penetration Test.
SISS	Sistema Informativo Socio-Sanitario di Regione Lombardia.
Ricetta	Prescrizione medica fruita con esenzione da reddito.
TS	Sistema Tessera Sanitaria. Sistema per il monitoraggio della Spesa Sanitaria.
Anno Sanzionabile	Anno di riferimento per applicazione della Sanzione amministrativa.
Anno/i di Controllo	Insieme delle annualità prese in esame per il recupero del Ticket sanitario.
File posizioni debitorie residue	Insieme delle annualità non prese in esame per il recupero del Ticket sanitario.
Lista controlli	Lista controlli autocertificazioni riferita ad una specifica annualità. Elenco degli assistiti con autocertificazione/i negativa/e riferita/e ad una specifica annualità
File TS istruito	Elenco degli assistiti destinatari dei Processi verbali/Diffide.
Combinatore	Algoritmo per la gestione, in un unico atto, per unico codice fiscale: - delle annualità riferite anche a codici di esenzioni differenti; - della differenziazione dell’applicazione della sanzione in base alle diverse annualità.
PND	Piattaforma notifiche digitali degli atti pubblici.

CAPITOLATO TECNICO

2 Premessa

2.1 Scopo del documento

ATS Città Metropolitana di Milano (d’ora in avanti, ATS) intende individuare, un operatore economico (d’ora in avanti Aggiudicatario) a cui affidare i servizi realizzativi e di personalizzazione e quelli aggiuntivi e complementari, nel seguito meglio dettagliati, di un applicativo software web-based erogato in cloud in modalità SaaS e che gestisca in modo informatizzato il recupero di ticket dovuti e non pagati da assistiti non aventi diritto all’esenzione da reddito.

Il sistema TS (Tessera Sanitaria) annualmente pubblica, come previsto dal D.M. 11.12.2009, la Lista controlli di una specifica annualità e file contenenti dati, informazioni e prospetti in formato PDF delle autocertificazioni negative abbinabili alla Lista controlli dell’annualità a cui si riferisce per numero di protocollo.

2.2 Finalità

La soluzione applicativa richiesta da ATS, comprensiva dei servizi realizzativi e aggiuntivi descritti nel presente documento, deve essere garantita dall’aggiudicatario attraverso la seguente modalità:

 realizzazione software ex-novo ovvero sviluppo di software ad hoc e manutenzione dello stesso. Il codice sorgente dell’applicazione sviluppata è da intendersi di proprietà di ATS che ha facoltà di poterla cedere gratuitamente in riuso, incluse le eventuali personalizzazioni, alle PA che lo dovessero richiedere. Le attività di sviluppo riguardano la creazione e la personalizzazione di una soluzione applicativa con l’obiettivo di ottimizzare il processo prevedendo la possibilità di integrare altri sistemi e/o banche dati.

Per la realizzazione della soluzione l’aggiudicatario potrà utilizzare framework di sviluppo purché open source.

La fornitura proposta deve necessariamente includere l’erogazione di servizi aggiuntivi e complementari relativi a: formazione utenti interni, assistenza tecnica e manutenzione correttiva, preventiva programmata, normativa ed evolutiva, hosting ed erogazione dell’applicazione web in cloud in modalità SaaS.

La gestione del repository del codice sorgente dovrà avvenire attraverso gli strumenti DevOps di ATS, secondo le modalità di Quality Assurance del software indicate ed eventualmente integrate da procedure ATS.

2.3 Ambito della fornitura

La fornitura richiesta da ATS prevede integralmente quanto segue:

 predisposizione di una soluzione applicativa web secondo quanto descritto al paragrafo “Finalità”;

CAPITOLATO TECNICO

 copertura di tutti i requisiti funzionali, non funzionali, tecnici, tecnologici ed operativi espressi nel presente documento;

 rispetto dei principi di "Privacy by design". In fase di gara e di progettazione l’OE deve dare evidenza di quelle che sono le soluzioni che intende adottare al fine di garantire:

 una difesa per livelli (cosiddetta “defense in depth”);

 la segregazione dei dati, ovvero componenti infrastrutturali separate (es. DB, logic app, web application server);

 il principio del "least privilege", ovvero minimizzazione dei privilegi di accesso a dati e funzionalità;

 pubblicazione ed erogazione dell'applicazione web su rete pubblica (Internet) attraverso una soluzione di Web Application Firewall che implementi l’ultima versione del set di policy OWASP. Il set di regole e policy dovrà essere mantenuto aggiornato nel tempo, le regole dovranno essere in modalità “block”;

 il monitoraggio da parte di ATS deve essere garantito attraverso:

o accesso in sola lettura alle risorse;

o visibilità dei sistemi di sicurezza (log e regole); la soluzione software deve prevedere la funzionalità di review periodica degli accessi, consentendo agli amministratori delle utenze di verificare puntualmente tutti i soggetti autorizzati e i log di utilizzo (es. suggerimenti di utenti da disattivare in base all’ultimo accesso);

o accesso agli indicatori delle prestazioni infrastrutturali ed applicativi (analisi dei tempi di risposta, del numero di risposte di errore, del workflow di utilizzo dell’applicativo per valutare l’efficacia del flusso di lavoro previsto per l’utente finale;

o verifica delle versioni delle componenti software che devono essere costantemente aggiornate, ovvero adozione delle ultime versioni dei protocolli di cifratura (HTTPS per le pagine web, TLS per comunicazioni con DB, autenticazione o altre risorse) e disabilitazione dei protocolli/versioni non più sicure (soggette a vulnerabilità riconosciute tramite CVE xxxxx://xxx.xxxxx.xxx/). L’aggiudicatario deve assicurare e mantenere il vincolo degli aggiornamenti di tutte le componenti software (es. sistema operativo server, middleware, web server, DBMS, …) per tutta la durata contrattuale.

 attività di formazione all’utilizzo del sistema da parte delle diverse tipologie di utenza previste, sia presso la sede di ATS che eventualmente in modalità da remoto da concordare con ATS;

 attività di assistenza tecnica e manutenzione correttiva, preventiva programmata, normativa ed evolutiva per garantire la continuità operativa a tutti gli utilizzatori del sistema in alta disponibilità, a partire dal rilascio in produzione fino alla scadenza prevista dal contratto;

 a partire dalla data di sottoscrizione del contratto e per tutta la durata contrattuale, produzione di tutti i certificati digitali necessari per la gestione del sistema informativo e validi per tutti gli ambienti operativi messi a disposizione di ATS; tali certificati digitali dovranno

CAPITOLATO TECNICO

essere intestati ad ATS ed emessi da una Certification Authority (CA) italiana pubblicamente riconosciuta;

 a partire dalla data di sottoscrizione del contratto e per tutta la durata contrattuale, servizio di hosting di una infrastruttura in cloud SaaS in linea con la normativa vigente che garantisca almeno due ambienti operativi indipendenti (collaudo, produzione) in Alta Disponibilità (High Availability, HA);

 predisposizione del repository del codice sorgente nella sottoscrizione Microsoft Azure DevOps di ATS e relativo caricamento unitamente a tutta la documentazione di progetto e di esercizio realizzata specificatamente per ATS;

 cessione perpetua del codice sorgente (di cui conseguentemente ATS assume la piena proprietà intellettuale) relativo a tutte le componenti funzionali sviluppate, alle personalizzazioni, alle configurazioni sistemistiche, alla base dati integrale, nonché della documentazione tecnica e di esercizio prodotta per ATS;

 attività connesse alla messa in riuso del codice sorgente realizzato relativo a tutte le personalizzazioni e integrazioni dedicate ad ATS, secondo quanto previsto dalle Linee Guida AgID e dai relativi allegati tecnici; a questo proposito deve essere predisposto un ulteriore repository di codice “pulito” al fine della idonea pubblicazione del codice sorgente sulla piattaforma Developers Italia;

 supporto ad ATS e ai propri fornitori terzi per la messa a punto delle eventuali integrazioni applicative richieste;

 export dell’intera base dati, in un formato standard, aperto e documentato (attraverso metadati), senza oneri deve essere disponibile in ogni momento su richiesta di ATS con contestuali verifiche che attestino l’allineamento di quanto esportato rispetto a quanto presente in produzione per tutte le componenti del sistema. In caso si verifichino problematiche relative a quanto esportato, l’aggiudicatario dovrà garantire, senza oneri aggiuntivi, la coerenza e la consistenza della base dati esportata. In ogni momento su richiesta di ATS i dati sulla piattaforma SaaS dell’aggiudicatario devono essere resi disponibili ad ATS; tale requisito deve sussistere soprattutto alla scadenza del contratto, quando l’aggiudicatario deve garantire ad ATS il necessario supporto all’eventuale migrazione verso una nuova infrastruttura cloud qualificata ACN;

 implementazione di strumenti di test automatici (come Azure Test Plan) per garantire la non regressione delle funzionalità esistenti a fronte delle eventuali attività evolutive;

 attività di integrazione con la piattaforma SISS di Regione Lombardia (e successive evoluzioni legati alla tecnologia di firma remota);

 integrazione con TS;

CAPITOLATO TECNICO

 integrazione con il Portale dei Pagamenti di ATS, per la predisposizione degli avvisi di pagamento;

 integrazione con il sistema di protocollazione dei documenti di ATS;

 integrazione con la Piattaforma notifiche digitali degli atti pubblici (PND);

 integrazione con il sistema di gestione delle Ordinanze ingiunzioni in uso ad ATS;

 integrazione con il Datawarehouse aziendale;

 integrazione con API Firma Remota;

 integrazione con sistema di conservazione.

Nel periodo di vigenza del contratto, ATS predisporrà uno strumento di gestione delle integrazioni applicative (ESB, Enterprise Service Bus) che dovrà pertanto essere utilizzato per la gestione delle integrazioni sopra indicate e per tutte le eventuali ulteriori integrazioni che ATS riterrà utile implementare.

2.4 Contesto normativo, tecnologico e operativo

Il sistema informativo richiesto da ATS prevede che tutte le componenti applicative e dati siano erogate in ambiente cloud, conformemente alla normativa vigente a cui si rimanda per completezza con particolare riferimento ai criteri per la qualificazione dei servizi cloud per la PA.

La soluzione applicativa dovrà essere basata su tecnologie di cloud computing secondo il paradigma SaaS (Software as a Service). A partire dalla data di sottoscrizione del contratto la fornitura richiesta dovrà contemplare il servizio di hosting di una infrastruttura in linea con la normativa vigente (fare riferimento al capitolo “Riferimenti documentali e normativi”). In considerazione delle caratteristiche tecnologiche richieste, la soluzione progettuale dovrà richiedere la disponibilità di risorse o infrastrutture integralmente a carico dell’aggiudicatario. L’aggiudicatario dovrà garantire la produzione di tutti i certificati digitali necessari per la gestione sicura dell’applicazione web erogata.

Con riferimento al Decreto direttoriale prot. N. 29 del 02/01/2023 dell’Agenzia per la Cybersicurezza Nazionale (ACN) è disponibile la procedura di qualificazione dei servizi cloud per la PA. A questo proposito ATS richiede che il servizio SaaS erogato dall’aggiudicatario venga “qualificato” da ACN e pubblicato nel relativo Cloud Marketplace (ACN Cloud Marketplace).

In relazione alla natura dei dati trattati e del servizio digitale erogato, l’aggiudicatario dovrà garantire un servizio qualificato almeno QC1 secondo quanto previsto da ACN.

ATS richiede che l’aggiudicatario sia in possesso della certificazione secondo lo standard ISO/IEC 27001 estesa con i controlli degli standard ISO/IEC 27017 e ISO/IEC 27018. Tale certificazione dovrà essere stata rilasciata da organismi nazionali di accreditamento riconosciuti dalla Unione Europea. Ciò è volto ad assicurare che l’aggiudicatario abbia adottato misure tecniche ed organizzative volte a minimizzare il rischio di perdita di integrità (anche accidentale) dei dati, di accesso non autorizzato,

CAPITOLATO TECNICO

di trasmissione non sicura, di illecita diffusione, di trattamento non consentito o non conforme alle finalità della raccolta. L’aggiudicatario dovrà, in sintesi, mettere a disposizione di ATS una soluzione tecnologica ed operativa che garantisca il rispetto dei previsti obiettivi di sicurezza, dal punto di vista della confidenzialità, integrità e disponibilità dei dati trattati.

L’aggiudicatario dovrà dare evidenza ad ATS di eventuali altri soggetti o subfornitori che concorrano all’erogazione del servizio di cloud hosting e quindi al trattamento dei dati. Il gestore dei servizi cloud (CSP, Cloud Service Provider) scelto dall’aggiudicatario dovrà garantire una infrastruttura qualificata almeno QI1 secondo quanto previsto da ACN. A maggior tutela dei dati personali trattati, ATS richiede che il CSP scelto dall’aggiudicatario garantisca la conservazione dei dati e/o delle relative chiavi di cifratura esclusivamente in data center collocati (region) nel territorio italiano.

È compito di ATS verificare l’effettivo rispetto delle dichiarazioni prodotte in sede di qualificazione dall’aggiudicatario. In caso di servizi non conformi a quanto dichiarato dall’aggiudicatario, ATS è tenuta a segnalare la circostanza ad XxXX e ACN proponendo, in caso di esito confermativo dell’apposita verifica, la revoca della qualificazione.

In relazione agli obblighi e alle responsabilità dell’aggiudicatario relativamente al trattamento dei dati, con particolare riferimento a quelli personali e sensibili, la fornitura prevede la sottoscrizione di una adeguata polizza assicurativa per ottemperare alla responsabilità risarcitoria a fronte di eventuali danni, economici e/o di immagine, causati da violazioni agli obiettivi di sicurezza previsti da ATS, di cui il massimale minimo è pari a 1.000.000 di euro. Occorre fare pertanto riferimento a tale documento per la descrizione esaustiva delle clausole, delle responsabilità e delle azioni contrattuali previste a carico dell’aggiudicatario in relazione alla eventuale perdita, all’illecita diffusione dei dati trattati e gestiti nel cloud ed all’interruzione del servizio erogato. Si ricorda inoltre che nella nomina dell’aggiudicatario a Responsabile al Trattamento Esterno dei dati (Regolamento UE 679/2016) sono già indicati i compiti, gli obblighi e le responsabilità contrattuali dell’aggiudicatario previsti da ATS.

Per una copertura completa dei requisiti richiesti in ambito di servizi cloud occorre fare riferimento alla normativa nazionale vigente ed a quanto indicato al capitolo “Progettazione, realizzazione e delivery” del presente documento.

Al fine di permettere ad ATS di valutare l’efficacia del servizio SaaS erogato, l’aggiudicatario dovrà rendere disponibile ad ATS strumenti idonei di monitoraggio, di audit, di Quality Assurance (QA) e di accesso alle basi dati dell’applicativo, oltre che consentire di effettuare verifiche di conformità alla normativa in materia di privacy, sicurezza e accessibilità.

Si sottolinea che ogni passaggio in produzione di software sviluppato dall’aggiudicatario e di ogni personalizzazione ed evoluzione dedicata ad ATS, dovrà essere necessariamente condiviso e concordato con i referenti di progetto di ATS a cui dovrà essere data evidenza del buon esito dei test automatici di non regressione effettuati.

CAPITOLATO TECNICO

L’utilizzo delle funzionalità del sistema informativo dovrà essere possibile attraverso i più diffusi browser Internet (ad esempio: Microsoft Edge, Google Chrome, etc.), l’accesso alle funzionalità ed ai dati sarà possibile solo agli utenti abilitati in base ai previsti livelli e profili di accesso.

Al fine di permettere l’adeguato dimensionamento delle risorse cloud del sistema in ambito al presente Capitolato Tecnico, di seguito sono forniti alcuni dati indicativi relativi agli utilizzatori ed ai volumi dati previsti:

Tipo	Quantità
Utente Standard	5
Utente Avanzato	3
Posizioni lavorate da TS istruito/anno	8500
Atti creati PV/anno	5000
Atti creati Diffida/anno	3000

Le performance del sistema erogato dovranno in ogni caso essere adeguate all’effettivo numero di accessi concorrenti che si avranno a regime ed all’eventuale aumento dei dati trattati. La soluzione web dovrà prevedere l’espandibilità del numero di utenti e garantire la scalabilità delle risorse cloud per gestire efficacemente anche potenziali condizioni di picco delle attività, degli accessi e del trattamento dei dati.

2.5 Durata del contratto

La durata del contratto è stabilita in 60 mesi come meglio descritto all’art. 2 del Capitolato Speciale d’Appalto.

2.6 Titolarità del codice sorgente

Si ribadisce che tutto il software sviluppato specificatamente per conto di ATS (codice sorgente) e relativo al Contratto , unitamente a tutte le successive modifiche evolutive che verranno introdotte dall’aggiudicatario nel corso del contratto, unitamente a tutta la documentazione tecnica e di esercizio prodotta, dovranno intendersi di proprietà intellettuale di ATS, che avrà facoltà di poter cedere gratuitamente, in riuso, tutto il software sviluppato e le previste personalizzazioni alle pubbliche amministrazioni che lo dovessero richiedere.

Lo stesso software e le personalizzazioni potranno essere segnalati ad AgID e ACN attraverso il repository Developers Italia.

CAPITOLATO TECNICO

3 Requisiti Funzionali

Il sistema, oggetto del presente capitolato tecnico, prevede una serie di funzionalità generali del servizio, nonché aspetti specifici dell’applicativo richiesto.

Si sottolinea che, per completezza, sono da considerarsi parti integranti della presente specifica funzionale tutti i riferimenti tecnici e tecnologici (requisiti non funzionali), bibliografici, documentali e normativi referenziati all’interno del presente documento.

3.1 Requisiti generali del servizio

GEN1

Console di amministrazione

Il sistema deve prevedere una console di gestione dedicata agli amministratori per svolgere le necessarie attività di configurazione lato back-office, in particolare:  creazione, configurazione e profilazione delle diverse tipologie di utenza;  configurazione di tutte le proprietà degli oggetti gestiti dall’applicazione;  configurazione dei vari parametri di calcolo e loro storicizzazione (spese, sanzioni, rate, scadenze, ecc…  configurazione template reportistica (modifica od inserimento di un nuovo template ed associazione del template con il processo di produzione degli atti);  configurazione alert di notifica / comunicazioni di servizio;  consultazione dei log applicativi relativi alle funzioni/attività degli utenti sul software. Si sottolinea che il sistema deve garantire l’integrità e quindi la non modificabilità dei log applicativi per finalità di controllo e di tracciamento delle attività degli utenti da parte di ATS con particolare riferimento agli aspetti di performance dell’applicativo. I dati sopra citati devo essere disponibili con una profondità temporale di almeno sei mesi.

GEN2 Identificazione & Autenticazione degli utenti. Profilazione degli utenti.

GEN3

Single Sign On (SSO)

Il sistema deve permettere ad ogni utente interno di ATS l’accesso alle funzionalità e risorse dell’applicativo in modalità Single Sign On (SSO) ovvero inserendo una sola volta le credenziali di accesso dalla propria postazione di lavoro (PdL), senza richiedere ulteriori richieste di autenticazione nel passaggio da un contesto applicativo all’altro, accedendo a tutte le aree dell’applicativo, ai moduli ed alle funzionalità per cui l’utente stesso è stato autorizzato.

CAPITOLATO TECNICO

La funzionalità di SSO deve essere garantita a tutti gli utenti interni autorizzati di ATS attraverso l’integrazione e la sincronizzazione con i meccanismi di Azure AD del dominio ATS al fine di consentire l’accesso con le stesse credenziali di dominio (fare riferimento al requisito GEN2 “Identificazione & Autenticazione degli utenti”.

GEN4

Stampe, ricerca e reportistica

Il sistema deve implementare le seguenti funzionalità applicate ai diversi contesti d’uso descritti nel documento:  gestione delle stampe;  strumenti e filtri di ricerca;  export dei dati e dei documenti nei formati standard maggiormente diffusi (ad esempio: Excel, PDF, etc.);  generazione report relativi a ciascuna categoria di dati inseriti. In ragione della natura web-based dell’applicazione software richiesta, il sistema deve garantire la possibilità di effettuare stampe ed estrazioni dati da qualunque postazione di lavoro ed in modo autonomo da parte di un generico operatore ATS. Il sistema deve consentire la generazione e l’export di report dedicati. I report devono poter essere estratti in formato standard e aperto (CSV, ODS, PDF elaborabile, etc.).

GEN5

Gestione documentale

Il sistema deve consentire la gestione documentale. La gestione cioè di tutta la documentazione relativa ad ogni procedimento, sia quella prodotta dal sistema (verbali e diffide) che quella acquisita automaticamente o caricata manualmente relativa a ciascuna pratica che formerà il fascicolo. Tutta la documentazione sarà organizzata per essere disponibile su richiesta dal sistema sia per gli interventi sul fascicolo sia per la reportistica e il successivo invio in conservazione attraverso l’integrazione con l’apposito connettore ATS

GEN6	Accesso tramite Azure AD
	Il sistema deve garantire agli utenti di dominio ATS l’accesso attraverso autenticazione di Microsoft Azure AD (conforme alla normativa di sicurezza GDPR).

GEN7 Firma remota

CAPITOLATO TECNICO

Il sistema deve garantire l’integrazione con gli strumenti di firma digitale del SISS (attraverso carta SISS e successive evoluzioni tecnologiche, tecnologia di firma remota).

3.2 Requisiti specifici del servizio

REQ1	Gestione delle pratiche (workflow)
	Il sistema deve consentire la gestione dei Processi Verbali e delle Diffide interfacciandosi anche con altri applicativi (Protocollo Informatico, Portale dei Pagamenti, DWH, TS, ...) secondo quanto indicato tra i requisiti non funzionali di integrazione.

REQ2	Gestione Cruscotto riepilogativo (dashboard)
	Il sistema deve realizzare un cruscotto riepilogativo delle pratiche presenti nei vari stati dettagliandole per tipologia (PV e Diffide) e consentire di visualizzarne puntualmente i dettagli selezionando lo stato pratica.

REQ3	Gestione file posizioni debitorie residue
	Il Sistema deve consentire di gestire e visualizzare le posizioni non oggetto di diffida o di PV.

REQ4

Modulo 2 – Gestione combinazioni e Gestione creazione atti

Acquisito il File TS istruito. Gli atti per il recupero dei ticket si riconducono a due tipologie: 1) Processo Verbale (PV): recupero ticket e relativa sanzione amministrativa (eventuale ulteriore recupero di posizioni debitorie di annualità precedenti). 2) Diffida: recupero solo ticket (eventuale ulteriore recupero di posizioni debitorie di annualità precedenti). Il sistema deve prevedere, nella console di amministrazione, le variabili di calcolo necessarie alla determinazione degli importi, i parametri che attivino e/o consentano:

CAPITOLATO TECNICO

1) la gestione delle rate ed eventuali parametri per il calcolo degli interessi (se previsti)

REQ5

2) le spese da applicare ad ogni atto della combinazione dell’anno/i di controllo selezionato/i (PV pari a € XX,00 per Diffida pari a € XX,00);

3) la scadenza del pagamento degli atti.

Il Sistema deve memorizzare le informazioni relative ai vari importi (ticket, sanzione, spese, interessi, ecc…) in modo da poterli contabilizzare anche separatamente.

Il sistema, acquisito il TS istruito, deve alimentare un’interfaccia che riassuma le posizioni delle diverse annualità riferite ad un medesimo assistito (chiave univoca: Codice Fiscale) “Combinatore”.

Il Sistema deve prevedere la scelta dell’atto da processare:

1) se l’atto è un PV, le combinazioni possibili derivano dall’incrocio delle posizioni del File TS istruito riferito all’anno sanzionabile con le posizioni degli anni precedenti;

2) se l’atto è una Diffida, le combinazioni possibili derivano dall’incrocio delle posizioni degli anni precedenti.

Il risultato deve alimentare una interfaccia che deve contenere le seguenti informazioni, a titolo esemplificativo e non esaustivo:

 descrizione pratica (PV/Diffida);

 anno/i di controllo;

 n. posizioni;

 n. assistiti;

 somma ticket;

 sanzione (se prevista è pari all’importo del ticket dell’anno sanzionabile).

Il sistema deve permettere di selezionare la “combinazione” dell’anno/i di controllo che deve essere processata tramite una check box al lato della tabella riassuntiva con contestuale scelta e caricamento del correlato Template.

Il sistema deve prevedere un elenco – ordinabile - con le seguenti informazioni a titolo esemplificativo e non esaustivo:

 numero progressivo (univoco e auto-generato);

CAPITOLATO TECNICO

 descrizione Pratica (PV/Diffida);

 anno/i di controllo;

 cognome e nome dell’assistito;

 codice fiscale dell’assistito;

 codice della/e esenzione/i;

 somma ticket;

 sanzione (se prevista);

 spese;

 interessi (se previsti);

 rateizzazione (si/no);

 importo dovuto.

Il sistema deve prevedere un “campo di Ricerca” per effettuare ricerche mirate e facilitare la possibilità di selezione singola o massiva di diversi “atti” (selezione con caratteri jolly: immettendo nel campo “Mart%” il sistema proporrà tutti i soggetti che iniziano con “Mart”).

Il sistema deve prevedere l’anteprima degli atti di cui all’elenco sopra, consentendo di procedere con la creazione – singola o massiva - degli atti o la cancellazione con nuova creazione.

La creazione degli l’assemblamento atti deve prevedere dell’atto - secondo un ordine e una modalità che verrà definita con ATS - con i relativi allegati. Il sistema dovrà interfacciarsi con il Portale dei Pagamenti. Si precisa che l’avviso di pagamento deve essere isolato da due pagine bianche dal resto del documento.

Nel caso di pagamenti rateali il sistema deve generare gli avvisi di pagamento PagoPA (sia in soluzione unica che gli avvisi rateali).

REQ5	Gestione RATE
	Il sistema deve permettere nella Gestione delle Rate l’acquisizione documentale GEN5 nelle due modalità previste: la prima modalità è automatizzata secondo una Tabella fornita da ATS per il calcolo delle rate. la seconda è una modalità on demand, la rata/e è concessa da ATS su istanza dell’assistito. Gestione automatizzata della concessione di rate in sede di creazione degli atti:

CAPITOLATO TECNICO

Il sistema deve consentire di valorizzare:

- il numero delle rate che si desidera concedere (secondo i parametri indicati nella consolle di amministrazione);

- la data della scadenza della prima rata;

- calcolare automaticamente tutte le scadenze successive mantenendo la frequenza di un mese;

- acquisire tutti gli avvisi di pagamento generati dal Portale dei Pagamenti, sia l’avviso per il pagamento in un’unica soluzione che le rate generate unendole al documento principale.

Gestione on demand della concessione di rate in sede di Gestione pratiche aperte (RQ8).

Il sistema deve permettere di:

- selezionare la pratica per la concessione delle rate visualizzando tutte le informazioni;

- acquisire la richiesta di rateizzazione inserendola nel fascicolo corrispondente;

- registrare data notifica/ricezione dell’atto;

- inserire il numero delle rate che si desidera concedere;

- inserire la data della scadenza della prima rata;

- calcolare automaticamente gli interessi;

- calcolare automaticamente tutte le scadenze successive mantenendo la frequenza di un mese;

- generare gli avvisi di pagamento multipli per quante sono le rate concesse annullando l’avviso precedentemente generato dell’unica soluzione al pagamento della prima rata;

- creare del template di concessione delle rate, personalizzato;

- firmare digitalmente;

- protocollare;

- fascicolare.

Il sistema deve prevedere il caricamento delle spese sulla prima rata.

Il sistema deve consentire interrogazioni sullo stato dei pagamenti rateali, a titolo esemplificativo e non esaustivo:

- un riepilogo di assistiti beneficiari delle rateizzazioni (che attraverso apposito strumento consentirà di visualizzare l’elenco degli assistiti beneficiari della rateizzazione) completo dei dati finanziari;

- l’elenco di dettaglio per assistito riporterà per ciascuno le seguenti informazioni:

- n. delle rate concesse per ogni beneficiario;

CAPITOLATO TECNICO

- importo rateizzato;

- n. rate pagate con importo complessivo incassato e data di pagamento;

- n. rate non pagate ma scadute con importo residuo;

- n. rate non pagate e non scadute con importo residuo da incassare;

- n. avvisi di pagamento pagati e non.

Il sistema deve consentire in caso di mancato pagamento anche di una sola rata di:

- 1° alert (mail su casella istituzionale) in presenza di mancato pagamento della rata decorsi i giorni definiti nei parametri di amministrazione dalla data di scadenza della stessa (sempre definiti nei parametri) con link alla pratica.

- Modificare lo stato della pratica e visualizzarla in apposito elenco affinché gli operatori possano averne cognizione (oltre il messaggio di alert) e gestirla;

- calcolare l’importo complessivo da recuperare dettagliato;

- annullare gli avvisi di pagamento multipli e non pagati;

- generare un avviso di pagamento per la somma complessiva da recuperare (secondo la scadenza definita da ATS);

- creare il Template di sollecito di pagamento in unica soluzione personalizzato;

- firmare digitalmente;

- protocollare;

- fascicolare.

 L’assistito paga RQ12 e RQ16;

 L’assistito non paga: 2° allert: RQ9;

REQ6

Gestione firma e protocollazione degli atti

Il sistema dovrà interfacciarsi con gli strumenti di firma digitale ed il connettore al protocollo. Il sistema deve consentire la firma digitale di singoli atti, o tramite una selezione massiva, di più atti. Gli atti protocollati, ai quali saranno associati gli avvisi di pagamento, assumono uno stato che consentirà al sistema di inviarli al gestore delle notifiche, attraverso l’integrazione con il connettore PND. Gli atti completi saranno poi inseriti nel corrispondete fascicolo

CAPITOLATO TECNICO

REQ7

Gestione degli atti e Gestione delle distinte

Il sistema deve permettere di selezionare (tramite checkbox) uno o più atti per la stampa degli atti in formato PDF. Il sistema deve: - acquisire in ingresso tutte le informazioni da inserire nella distinta nel formato previsto da Poste Italiane (ora un xls); - consentire di selezionare gli atti per cui si vuole generare e stampare la distinta, secondo il modello elaborato da Poste Italiane (o altro Gestore autorizzato) messo a disposizione da ATS, conservando le macro presenti; - acquisire in una form la distinta lavorata da Poste Italiane (o altro Gestore autorizzato) per agganciare uno o più numeri di raccomandata per ogni atto; - consentire il collegamento al sito di Poste Italiane (o altro Gestore autorizzato) per il tracciamento dell’atto stesso, attraverso il numero della raccomandata. Il Sistema deve consentire di poter scaricare le distinte e gli atti selezionati. Tale funzionalità sarà realizzata, su indicazione ATS, solo se l’integrazione con il connettore PND non fosse ancora disponibile.

REQ8

Gestione pratiche aperte

Tutte le pratiche non archiviate devono poter essere gestibili. Possono pertanto acquisirsi nuovi documenti, informazioni di vario tipo che il sistema deve unire al fascicolo e rendere disponibili agli operatori che necessitano di gestirla. Il sistema deve rendere disponibili tutte le informazioni acquisite e gli atti per la gestione ed il monitoraggio degli stessi. Il sistema deve prevedere la possibilità di registrare le informazioni ricevute telefonicamente – vedi REQ19

REQ9	Gestione pratiche sospese
	Il sistema deve consentire di modificare manualmente lo stato della pratica da in “attesa di pagamento” a “sospeso”. A fine istruttoria l’utente potrà gestire lo stato della pratica. Il Sistema deve sempre consentire: o l’acquisizione dei documenti inseriti o da inserire nel fascicolo; o l’inserimento della data, protocollo della nota di archiviazione

CAPITOLATO TECNICO

e causale di archiviazione (secondo indicazioni concordate con ATS)

L’atto “sospeso” deve essere gestito a titolo esemplificativo e non esaustivo, nelle seguenti casistiche:

 “Deceduto con Eredi”: Il Sistema deve:

o annullare l’avviso di pagamento emesso;

o consentire il ricalcolo dell’importo dovuto dall’erede;

o riemettere l’avviso di pagamento intestato all’erede.

In questo caso il sistema deve prevedere il caricamento dell’anagrafica relativa all’erede, produrre il relativo avviso di pagamento e consentire l’utilizzo di tali nuovi dati anagrafici aggiuntivi per la notifica degli atti senza che la titolarità della posizione debitoria sia modificata.

Se l’erede paga entro la scadenza REQ12 e REQ16; Erede non paga entro la scadenza REQ15.

 “Deceduto senza Eredi”: REQ11 e REQ16.

 “Ricalcolo importo Dovuto”: Il Sistema deve permettere di ricalcolare l’importo delle singole voci (ticket, spese, sanzione e interessi se dovuti):

o consentire il ricalcolo dell’importo dovuto;

o aggiornare l’avviso di pagamento emesso o annullarlo e riemettendone uno nuovo con i nuovi importi;

Il Sistema deve permettere tutte le operazioni citate anche per gli atti per i quali il sistema deve prevedere l’invio, tramite pec, ai messi del comune di residenza dell’assistito, del PV la cui notifica non risulti andata a buon fine, attraverso la scelta dei template di trasmissione (da firmare e protocollare)

 Se l’assistito paga entro la scadenza REQ12 e REQ16;

 Se l’assistito non paga = se presente sanzione REQ14;

assistito non paga = se non presente sanzione REQ15.

REQ10	Gestione pratiche scadute
	Il sistema tramite l’Integrazione con Portale dei Pagamenti ATS deve gestire le scadenze degli atti che a titolo esemplificativo e non esaustivo possono essere:  se l’assistito paga a scadenza =REQ12 e RQ16;  se l’assistito non paga a scadenza: o < xxx gg da scadenza avviso di pagamento = Gestione pratiche scadute;

CAPITOLATO TECNICO

o > xxx gg da scadenza avviso di pagamento:

assistito paga entro la scadenza = REQ12 e REQ16; assistito non paga = se presente sanzione REQ14; assistito non paga = se non presente sanzione REQ15. assistito deceduto = REQ9

In ogni caso il sistema deve tenere conto delle impostazioni predefinite nella

consolle di amministrazione.

REQ11	Gestione archiviazione pratiche
	Il sistema deve consentire di archiviare l’atto acquisendo tutte le informazioni a sistema (REQ16), inserendo, a titolo esemplificativo e non esaustivo, le seguenti informazioni:  data e protocollo della nota di archiviazione;  causale di Archiviazione (secondo indicazioni concordate con ATS)

REQ12

Gestione registrazione pagamenti

Il sistema deve prevedere due modalità per la registrazione dei pagamenti (data di pagamento e acquisizione della ricevuta): 1) la prima modalità viene effettuata automaticamente dal sistema attraverso l’integrazione col Portale dei Pagamenti di ATS; 2) nella seconda modalità, un operatore deve poter registrare manualmente l’avvenuto pagamento tramite la funzione “Gestione manuale da parte di utente di ATS” ed eventualmente caricare la ricevuta di pagamento nel fascicolo. Dopo la registrazione del pagamento REQ16.

REQ13	Gestione storia atto
	Il sistema deve permettere di registrare, selezionare e visualizzarne i passaggi di “stato” di ogni singolo procedimento comprendendo anche tutta la documentazione associata ad esso. Il sistema garantisce che per ciascun procedimento renda disponibile in un’interfaccia tutti gli eventi e i documenti riferiti ad esso in ordine cronologico.

REQ14	Gestione rapporto di mancato pagamento Art. 17 L. 689/81 (Gestione Art. 17)
	Il sistema, acquisite tutte le informazioni necessarie presenti a sistema e nel fascicolo, deve consentire, la selezione del template relativo e:

CAPITOLATO TECNICO

1) selezionare un atto tra quelli presenti REQ9 e REQ10:

2) registrare la data di notifica;

3) generare il rapporto di mancato pagamento;

4) firmare digitale;

5) Protocollare.

Il/i rapporto/i di mancato pagamento e le informazioni ad esso connesse alimenteranno automaticamente il sistema di gestione delle ordinanze ingiunzioni attraverso apposito connettore di ATS, le cui specifiche saranno poi comunicate al fornitore.

A trasmissione avvenuta i rapporti di mancato pagamento alimenteranno il fascicolo

corrispondente

REQ15

Gestione per recupero delle somme di ticket dovute e non riscosse in assenza di sanzione

Il sistema, acquisite tutte le informazioni necessarie presenti a sistema e nel fascicolo, deve consentire, la selezione del template relativo e: 1) selezionare un atto tra quelli presenti REQ9 o REQ10; 2) Registrare la data di ricezione della A/R oppure compiuta giacenza; 3) generare la nota di trasmissione fascicolo; 4) apporre la firma digitale. 5) protocollazione Il Sistema deve consentire di visualizzare i fascicoli. Comprese le informazioni acquisite a sistema.

REQ16	Gestione rendicontazione pratica su TS
	Il sistema deve gestire lo “stato pratica” delle posizioni debitore INT2 sulla base dello stato associato a ciascuna di essa

REQ17	Gestione report
	La gestione dei report deve prevedere la possibilità di realizzare in autonomia della reportistica attraverso la selezione tra un set di attributi e dall’impostazioni delle variabili logiche e di calcolo che consentano anche un eventuale raggruppamento dei dati ed il calcolo e/o il conteggio di valori

CAPITOLATO TECNICO

REQ18	Gestione caricamento dati scaricati da TS
	Il sistema deve disporre di un’area dedicata per il caricamento di file tramite percorsi definiti.

REQ19

Modulo 3 - Gestione sistema di telefonate

Il Sistema di gestione delle telefonate è a supporto degli operatori che hanno il compito di assistere colo che a vario titolo contattano il servizio. L’operatore da un’apposita interfaccia Il sistema deve: - consentire all’utente di registrare le chiamate ricevute dagli assistiti destinatari degli atti e consentire estrazioni di report. - consentire di visionare l’atto e le informazioni acquisite.

REQ19.1

Gestione sistema di telefonate

Il sistema deve permettere: - agli utenti di gestire le telefonate degli assistiti e di seguirne la normale gestione fino alla evasione della richiesta; - una ricerca veloce della posizione dell’assistito e dell’atto (degli atti se presenti altre annualità); - la verifica sullo stato dell’atto con documenti correlati (Gestione documentale); - la consultazione di tutte le chiamate pregresse effettuate a nome dell’assistito; - di registrare eventuali richieste; a titolo esemplificativo e non esaustivo modulo di dettaglio ricette, richiesta di rateizzazione, …; - di verificare lo stato delle richieste (evasa/da evadere); - alert in caso di richiesta non evasa quando > XXX gg dalla data della telefonata.

REQ20

Modulo 1 - Gestione Lista Controlli

Il sistema deve acquisire le Liste controlli autocertificazioni messe a disposizione da ATS. La lista di controllo contiene l’elenco dei codici fiscali dei cittadini oggetto di controllo. Il Sistema deve, interfacciandosi con il DWH di ATS, acquisire dati anagrafici e di residenza, dati sensibili, esistenza in vita dei codici fiscali elencati nella Lista di Controllo associandoli al relativo codice fiscale.

CAPITOLATO TECNICO

Il Sistema deve consolidare/normalizzare i dati acquisiti. A titolo esemplificativo e non esaustivo: es. consolidare luogo di nascita stato estero

da Repubblica Popolare Cinese = Cina.

Il Sistema deve automatizzare “stato di lavorazione” , sulla base delle informazioni e i dati forniti da ATS, il processo di creazione del “file istruito”.

Per le fasi non automatizzabili, il Sistema deve consentire all’utente la gestione della posizione con contestuale cambio di “stato” (verifica – archiviazione con chiusura TS

– da valutare – lavorazione).

Il processo di creazione nello stato di lavorazione, prevede più fasi di verifiche e confronti con dati sensibili, reddituali/civile, normativi e altro, dei cittadini presenti nella lista di controllo.

Il Sistema deve, durante la fase – automatizzata - di lavorazione, gestire i cambi di “stato” secondo le indicazioni fornite da ATS.

Al termine della attività di verifica, il Sistema deve:

1. Inviare a Modulo 2 il file TS istruito previa ulteriore verifica sull’esistenza in vita degli assistiti;

2. Consentire la gestione delle posizioni di cui al punto 1)

L’implementazione del requisito avverrà solo a seguito di conferma della volontà di realizzarlo da parte di ATS, per la realizzazione si utilizzeranno le necessarie giornate di manutenzione evolutiva, secondo le modalità previste per il loro utilizzo descritte nel paragrafo 7.3 Manutenzione evolutiva.

4 Requisiti non funzionali

Si elencano di seguito i requisiti non funzionali, tecnici e tecnologici richiesti al sistema informativo oggetto della presente fornitura.

4.1 Requisiti organizzativi

ORG1 SPOC (Single Point of Contact)

CAPITOLATO TECNICO

Al fine di rendere più efficaci le comunicazioni tra ATS e operatore economico, quest’ultimo dovrà individuare e comunicare ad ATS, fin dalle prime fasi di analisi e durante tutte le fasi operative, un referente unico di contatto (SPOC) per tutta la durata del servizio.

ORG2	Assistenza tecnica qualificata
	A seconda della tipologia di intervento richiesto, l’operatore economico metterà a disposizione di ATS un proprio servizio di assistenza tecnica specialistica in grado di intervenire efficacemente, eventualmente anche attraverso work-around temporanei, nonché tempestivamente in funzione del livello di gravità del malfunzionamento.

ORG3

Quality Assurance del Software

È richiesto che i fornitori dei servizi di erogazione e gestione del software siano in possesso di alcuni requisiti organizzativi attraverso i quali garantire la gestione dei seguenti processi legati all’erogazione del servizio oggetto dell’appalto:  gestione del cambiamento (change management);  gestione delle configurazioni (configuration management);  gestione degli incidenti (incident & problem management).

4.2 Requisiti di security

SEC1

Sicurezza logica, fisica e organizzativa

Dato il grado di confidenzialità delle informazioni gestite dal sistema, l’operatore economico dovrà garantire tutte le misure di sicurezza logica (riservatezza, integrità, disponibilità dei dati) e organizzativa per garantire il rispetto della normativa vigente, tenendo conto delle best practices di sicurezza informatica. A tutela del patrimonio informativo dell’Agenzia e della continuità del servizio, l’aggiudicatario dovrà indicare quali strategie di disaster recovery e quale piano di business continuity intende adottare durante tutto il periodo contrattuale.

SEC2	Privacy
	Fare riferimento alla normativa sulla privacy secondo quanto riportato al capitolo “Riferimenti documentali e normativi” del presente documento.

CAPITOLATO TECNICO

L’operatore economico sarà designato come Responsabile Esterno al trattamento dei dati e conseguentemente assoggettato a tutti gli obblighi previsti dalla normativa di riferimento.

SEC4	GDPR (General Data Protection Regulation) – Regolamento UE 2016/679
	Le prestazioni oggetto della presente fornitura dovranno essere conformi al Regolamento Generale sulla Protezione dei Dati (GDPR, General Data Protection Regulation – Regolamento UE 2016/679) e alla normativa italiana vigente in materia di protezione (D.lgs. n. 101/2018).

SEC5

Protocollo HTTPS

Il software applicativo, oggetto della fornitura, dovrà essere fruibile dai client esclusivamente mediante protocollo HTTPS. L’operatore economico dovrà provvedere alla fornitura ed al rinnovo dei certificati necessari per il corretto funzionamento del sistema. Ogni certificato fornito dovrà essere emesso da una Certification Authority italiana pubblicamente riconosciuta ed essere intestato ad ATS.

SEC6

Accordi di Non Divulgazione (NDA) e di Trattamento dei Dati (DPA)

L’operatore economico dovrà garantire la non divulgazione delle informazioni sensibili trattate dal sistema a cui avrà accesso nel corso delle fasi di progettazione, sviluppo, avviamento e manutenzione del sistema. Tali accordi (Non Disclosure Agreement, NDA) dovranno valere anche dopo la conclusione della presente fornitura. L’operatore economico dovrà garantire il rispetto di accordi specifici sul trattamento e la protezione dei dati (Data Protection Agreement, DPA), personali e sensibili secondo la normativa vigente, con cui verrà in contatto nel corso delle attività.

SEC7	Audit e Monitoraggio
	ATS si riserva la facoltà di sottoporre ad audit e monitoraggio tutte le attività del servizio erogato e in particolare relative al trattamento delle informazioni confidenziali effettuate dall’aggiudicatario e dal personale di cui esso intende avvalersi, per tutta la durata contrattuale. Le attività di audit e monitoraggio potranno riguardare i seguenti processi:

CAPITOLATO TECNICO

 qualità e prestazioni dei servizi erogati dal sistema;

 conformità dei servizi erogati dal sistema alle policy di ATS, riferite nel presente documento;

 vulnerability assessment e relativi penetration test (VAPT) del sistema.

ATS informerà lo SPOC dell’aggiudicatario, con preavviso di almeno 30 giorni, della pianificazione, dei tempi e delle modalità delle sessioni di audit previste.

4.3 Requisiti e vincoli tecnologici e infrastrutturali

TEC1

Accesso web

Le funzionalità messe a disposizione dal sistema dovranno essere raggiungibili dagli utenti utilizzatori attraverso l’accesso alla rete Internet, col solo utilizzo di un browser, senza limitazioni di accessi concorrenti. Si sottolinea quindi che la fruizione delle informazioni tramite Internet non dovrà richiedere l’installazione sui PC dei convenzionati di componenti aggiuntivi oltre ad un web browser. Lato client, il sistema deve essere conforme alle normative nazionali in tema di accessibilità dei sistemi informatici. Il rispetto dei requisiti di accessibilità verrà verificato da ATS in fase di collaudo, riservandosi la facoltà di subordinare la valutazione del progetto al parere di una o più associazioni a tutela di disabilità di vario genere. Il sistema informativo dovrà rispettare in particolare i requisiti tecnici di accessibilità riportati nell’Allegato A del Decreto Ministeriale 8 luglio 2005 e successive modifiche. Una particolare attenzione dovrà essere prestata ai temi di accessibilità, secondo quanto previsto dalle più recenti linee guida AgID in tema di design di siti web. La progettazione del portale deve garantire la conformità massima ai requisiti del W3C (priorità 3, AAA) ed il rispetto delle linee guida W3C. Non deve essere richiesta l'installazione o l'utilizzo di componenti aggiuntivi (come ad esempio: plug-in, componenti ActiveX, java applet, DLL, etc.) né si devono rendere necessarie configurazioni particolari sulle impostazioni dei browser o dei sistemi operativi dei client.

CAPITOLATO TECNICO

TEC2

Interfaccia web

Le funzionalità messe a disposizione dal sistema dovranno poter essere fruibili dagli utenti con tutti i principali browser presenti sul mercato, garantendo sempre la corretta rappresentazione dei contenuti da parte dei motori di rendering utilizzati. La presentazione delle pagine web dovrà essere realizzata in HTML5, dovrà essere omogenea in tutti i contesti con modalità di navigazione quanto più ricorrenti per facilitare l'utente nell'accesso ai contenuti o servizi di interesse. Il sistema nel suo complesso dovrà utilizzare meccanismi di “url rewrite” o implementare un meccanismo di “smart URL” per generare URL di navigazione parlanti.

TEC3

RDBMS, Infrastruttura applicativa e scalabilità

L’aggiudicatario dovrà garantire, nel corso del contratto di manutenzione, l’adeguamento di tutte le componenti applicative e delle relative strutture dati a fronte di eventuali aggiornamenti che si rendano necessari per adeguamenti normativi, di sicurezza o tecnologici. Il sistema dovrà garantire la protezione dei dati memorizzati e gestiti attraverso opportuni meccanismi di backup in sinergia con la infrastruttura cloud utilizzata. Il sistema dovrà essere resiliente rispetto a potenziali rischi di perdita di integrità dei dati trattati anche a fronte di potenziali e imprevisti malfunzionamenti. Il sistema dovrà essere scalabile nella quantità di dati inseriti mantenendo prestazioni inalterate. Il sistema dovrà essere resiliente rispetto a potenziali rischi di degrado delle prestazioni e/o di interruzione, anche temporanea, del servizio erogato onde garantire ad ATS la continuità operativa anche a fronte di potenziali e impreviste attività di picco. Il sistema dovrà essere realizzato preferibilmente con tecnologie a logica micro- servizi, con un sistema di orchestrazione open source e gestione di container (preferibilmente Kubernetes o equivalente).

TEC4	Evoluzioni tecnologiche
	L’aggiudicatario dovrà garantire l’adeguamento del sistema informativo oggetto del presente capitolato anche rispetto a nuove versioni ed aggiornamenti del software utilizzato, di browser, sistemi operativi, software di base, middleware che i vari vendor dovessero rilasciare per tutto il periodo di validità contrattuale. Tali aggiornamenti dovranno essere garantiti entro:

CAPITOLATO TECNICO

 un mese per quanto riguarda il rilascio di patch;

 tre mesi per quanto riguarda il rilascio di nuove release.

TEC6

Performance

Il sistema deve nel suo complesso (application server, database server, backup server, file server, etc.) garantire massimi livelli di scalabilità in termini di risorse di calcolo e banda trasmissiva per far fronte ad eventuali picchi di traffico o per eventuali espansioni future, senza alcun costo aggiuntivo per ATS. L’incremento delle risorse dovrà essere garantito “a caldo”, senza interruzioni di servizio. Il servizio di hosting in modalità cloud SaaS deve prevedere una velocità di trasmissione su connessione di rete Internet di 1 Gbit/sec. La capacità di banda trasmissiva dovrà prevedere una banda minima garantita non inferiore ai 100 Mbit/sec e non dovranno essere posti limiti di traffico. ATS richiede preferibilmente l’utilizzo di strumenti di analisi specifici (ad esempio: Google, GtMetrix, WebPageTest, Pingdom, etc.) per valutare la velocità di caricamento delle pagine del sito e procedere con eventuali ottimizzazioni. ATS richiede che, sia in condizioni nominali che di picco di traffico, una generica pagina web del sito sia caricata indicativamente entro un tempo massimo di 1 secondo (1.000 msec), sia in accesso da desktop che da mobile. Deve essere garantito un efficace monitoraggio, h24 per 365 giorni all'anno, dello stato di disponibilità del servizio di hosting e delle sue componenti (disponibilità del sito web e della banda di connessione) con notifica automatica (e-mail, sms) ad ATS in caso di eventuali disservizi. Il sistema dovrà prevedere la disponibilità di pagine di cortesia o “Landing Page” a cui indirizzare gli utenti del Portale ATS in caso di sua indisponibilità per potenziali disservizi o per attività di manutenzione programmata. La manutenzione programmata dovrà essere sempre condivisa e autorizzata da ATS. Il sistema deve preferibilmente prevedere tecnologie (“agent” Azure Arc o equivalenti) che consentano da parte di ATS il monitoraggio e la corretta applicazione delle policy di sicurezza e infrastrutturali adottate dall’aggiudicatario sulla propria sottoscrizione cloud.

4.4 Requisiti di usabilità

USA1	Facilità d’Uso
	Il sistema dovrà essere progettato e implementato in modo da agevolare ogni categoria di utenza prevista durante le relative fasi operative. L’interfaccia grafica dovrà essere implementata in italiano.

CAPITOLATO TECNICO

USA2	Interfacce Help-On-Line (HOL)
	Il sistema dovrà disporre di una guida in linea delle funzionalità, ad integrazione della documentazione utente e operativa. La guida in linea dovrà essere implementata in italiano. L’accesso ad un HOL attivabile dall’operatore per avere supporto sulle funzionalità degli elementi del servizio ed in particolare di quelli codificati deve essere per ogni scenario funzionale previsto.

USA3	Inserimento dati
	Il sistema dovrà disporre di opportuni controlli per evitare l’inserimento di informazioni errate e/o incomplete, garantendo controlli di congruenza dei dati inseriti dall’utente.

4.5 Requisiti di integrazione

INT1

Scenari di integrazione

Tutti gli interfacciamenti/integrazioni applicative che il sistema prevedrà devono essere sviluppati offrendo integrazioni sia sincrone che asincrone. L’aggiudicatario deve prevedere un’apposita fase di analisi dedicata alla rilevazione delle integrazioni in essere e, concordemente con i desiderata formulati da ATS, procedere con la realizzazione dei flussi di informazioni nel rispetto delle indicazioni sopra menzionate.

INT2	Integrazione con TS
	Il sistema deve interfacciarsi con il Web service – aggiorna stato pratica di TS

INT3	Integrazione con DWH di ATS
	Il sistema deve integrarsi con il DWH sia per l’accesso ai dati anagrafici, sia per l’esposizione di una o più viste materializzate contenenti i “fatti” del gestionale con tutti i valori “parlanti” (già correlati alle eventuali tabelle dimensionali o di supporto).

INT4	Integrazione con Portale dei Pagamenti ATS
	Il sistema deve integrarsi, via web services, con il Portale dei Pagamenti di ATS per la gestione dei pagamenti tramite il circuito PagoPA.

CAPITOLATO TECNICO

INT5	Integrazione con Firma digitale remota
	Il sistema deve garantire la sottoscrizione singola o massiva degli atti attraverso la firma digitale remota che Regione Lombardia rende disponibili ad ATS.
INT6	Integrazione con il connettore al Protocollo Informatico ATS
	Il sistema deve consentire la registrazione sull’apposito registro di protocollo dell’ATS della documentazione in uscita attraverso l’integrazione con il connettore al Protocollo messo a disposizione e secondo le indicazioni di ATS.

INT7	Integrazione con il connettore alla piattaforma digitale per la notificazione (PND) degli atti della PA
	La notifica degli atti, siano essi PV o Diffide, devono essere trasmesse alla Piattaforma Notifiche Digitali attraverso apposito connettore di ATS affinché gli atti raggiungano i destinatari ed il sistema possa acquisire automaticamente tutte le informazioni riguardanti lo stato della notifica del/degli atto/i.

INT8	Integrazione con il connettore della Conservazione
	Il Sistema deve consentire l’automatica o manuale selezione dei fascicoli e dei relativi metadati da trasferire in conservazione integrandosi con il connettore appositamente predisposto da ATS e le cui specifiche saranno indicate successivamente da ATS

4.6 Requisiti di migrazione e gestione del transitorio

MIG1	Porting
	Il Sistema dovrà acquisire tutte le informazioni relative ai procedimenti presenti nell’attuale sistema in uso distribuendo le informazioni in fascicoli corrispondenti e rendendole disponibili agli operatori per la consultazione e gestione. Per tale attività è prevista una sessione di collaudo ad hoc.

CAPITOLATO TECNICO

5 Progettazione, realizzazione e delivery

5.1 Responsabilità

L’aggiudicatario è responsabile di tutte le attività di progettazione, realizzazione, personalizzazione e messa in esercizio delle componenti software e personalizzazioni previste dal presente Capitolato Tecnico.

Per tutto quanto non espressamente menzionato nel presente Capitolato si richiama quanto disciplinato e previsto dal regolamento adottato dall’AgID con Determinazione del 15 dicembre 2021,

n. 628, dalle determine n. 306 e n. 307 del 18 gennaio 2022 dell’ACN e al Decreto direttoriale prot.

N. 29 del 02/01/2023 di ACN e di tutti i relativi allegati.

Sono comprese nella fornitura tutte le attività di predisposizione e caricamento sulla sottoscrizione Microsoft Azure DevOps di ATS del codice sorgente sviluppato per conto di ATS e delle personalizzazioni dedicate ad ATS. Il deployment del software già esistente e degli sviluppi e personalizzazioni dedicate ad ATS deve essere previsto negli ambienti operativi previsti (collaudo, produzione) in cloud in modalità SaaS, servizio gestito in hosting dall’aggiudicatario.

L’aggiudicatario è tenuto a dare evidenza dell’applicazione delle best practices sulla conduzione del progetto, dalla pianificazione, alle scelte organizzative, alle metodologie adottate volte ad assicurare il controllo e la riduzione dei rischi di progetto per tutto il suo ciclo di vita.

Per assicurare ad ATS la supervisione e governance del progetto in tutte le sue fasi, l’aggiudicatario è tenuto a adottare gli strumenti Microsoft Azure DevOps utilizzati da ATS ed applicare la relativa metodologia Agile ed un approccio operativo di Continuous Integration/Continuous Delivery.

5.2 Strumenti di project management

L’aggiudicatario è tenuto ad adottare gli strumenti di project management Azure Boards, nella sottoscrizione Azure DevOps di ATS, per assicurare ad ATS la massima trasparenza e la governance in tutte le fasi del progetto, ivi comprese quelle di manutenzione ordinaria ed evolutiva.

L’utilizzo della piattaforma Azure DevOps da parte dell’aggiudicatario deve prevedere:

 Il repository del codice dove devono essere adottate tutte le best practices, come ad esempio la creazione di un master branch che contiene la versione di rilascio consolidata o comunque il core della soluzione software su cui fare il merge degli altri branch di sviluppo solo tramite pull request

 Il repository del codice non deve contenere password, credenziali o stringhe di connessione cablate nel codice o in file di configurazione. È necessario utilizzare i variable groups e/o i key vault. Questo anche al fine di consentire la corretta pubblicazione nel portale governativo del riuso Developers Italia;

 analisi con strumenti di Quality Assurance delle componenti software utilizzate dal progetto per validare gli aspetti legati alle licenze, aggiornamenti delle librerie ed eventuali loro vulnerabilità, qualità del codice sorgente (es. Whitesource Bolt, Sonarqube);

CAPITOLATO TECNICO

 Pipeline per build e deploy della soluzione software;

 i template di build e deploy dovranno essere realizzati anche in formato compatibile con il cloud di ATS se l’infrastruttura scelta è in un cloud differente da Microsoft Azure. Dovranno essere utilizzati template ARM (Azure Resource Manager) e file YAML.

 definizione di un adeguato staff di risorse (team di progetto), dando evidenza ad ATS della capacity assegnata al progetto per ogni figura professionale prevista, tale da garantire il completamento del progetto nei tempi contrattualmente previsti;

 creazione e pianificazione di tutti task che garantiscono la copertura di tutti i requisiti funzionali (User Story) previsti nel presente Capitolato Tecnico;

 dall’avvio del progetto fino alla messa in esercizio di tutte le componenti tecniche e funzionali previste (Backlog), gestione giornaliera dell’avanzamento dei task (Task Board) per ogni Sprint o Iterazione della pianificazione condivisa con ATS; il piano operativo previsto dall’aggiudicatario deve essere necessariamente previsto su Azure Boards avendo cura di pianificare Sprint della durata massima di due-tre settimane.

L’aggiudicatario, nel caso l’ATS ritenga necessario, dovrà essere disponibile a partecipare ad incontri periodici sull’andamento del progetto.

5.3 Testing, Collaudo ed avvio in produzione

Il sistema oggetto del presente Capitolato Tecnico è vincolato al superamento di un’opportuna procedura di testing e di collaudo, condivisa con ATS, prima dell’effettiva accettazione del sistema e quindi del relativo rilascio in produzione.

Per quanto riguarda la fase di testing, devono essere garantiti i seguenti aspetti:

 test di performance/carico simulando accesso simultaneo pari al doppio del carico previsto;

 esecuzione delle verifiche in ambiente di test o collaudo prima di ogni rilascio in produzione (procedura di test).

Il collaudo dovrà essere effettuato in un ambiente di test dedicato, messo a disposizione in hosting dall’aggiudicatario, idempotente, in termini di risorse cloud, a quello di produzione. In collaudo verranno utilizzate postazioni client coerenti con quanto previsto dal contratto.

Si sottolinea che ogni futura modifica, correttiva o evolutiva o migliorativa, da apportare al sistema dovrà essere anch’essa soggetta a collaudo preventivo prima dell’effettivo rilascio in produzione.

Anche nel contesto di erogazione del servizio SaaS, ATS richiede che ogni eventuale modifica all’ambiente di utilizzo (software d’ambiente, patch, upgrade, etc.) sia soggetta a specifiche procedure di verifica da parte dell’aggiudicatario per garantire la non regressione delle funzionalità applicative, dandone evidenza ad ATS.

CAPITOLATO TECNICO

ATS richiede che l’aggiudicatario garantisca la non regressione delle funzionalità esistenti attraverso l’adozione di specifici strumenti di test automatico (in particolare Azure Test Plan) e di dare ad ATS evidenza del loro utilizzo.

Prima di eventuali sessioni di precollaudo e delle effettive sessioni di collaudo, l’aggiudicatario è tenuto a presentare un’opportuna documentazione (test list di collaudo) soggetta ad eventuali integrazioni ed alla accettazione finale da parte dei referenti di ATS.

In caso di inadempimenti dell’aggiudicatario legati al rilascio in produzione di funzionalità o modifiche non condivise o che non abbiano positivamente superato le procedure di collaudo, ATS si riserva la facoltà di valutare l’applicazione di penali secondo quanto previsto dal contratto.

Nel caso in cui una o più specifiche funzionali, non funzionali e tecniche o altri aspetti rilevanti del servizio, inclusi nel presente Capitolato Tecnico e/o eventualmente forniti come requisiti migliorativi dall’aggiudicatario, non superino il collaudo (requisito non implementato o con gravi mancanze), il collaudo terminerà con esito negativo.

Nel caso in cui il collaudo sia superato solo parzialmente, a causa di problemi minori risolvibili in un tempo stimato limitato, il collaudo terminerà con esito di superamento parziale (con riserve). L’aggiudicatario rilascerà l’elenco dei problemi da risolvere con un piano temporale di risoluzione concordato con ATS. La verifica della risoluzione dei problemi sarà oggetto di una ulteriore sessione di collaudo congiunta.

Al superamento del collaudo, l’effettivo rilascio in produzione avverrà secondo un piano di avviamento che assicuri, al momento dell’apertura del servizio in produzione, la corretta operatività a tutti gli utenti finali del sistema, sia interni che esterni ad ATS.

Una volta rilasciato il sistema in esercizio, ATS si riserva la facoltà di monitorare il corretto andamento del funzionamento a regime del sistema in produzione per un periodo di sei mesi (fase di avvio) allo scopo di valutare l’affidabilità del software introdotto dall’aggiudicatario. In questa finestra temporale il sistema viene ad essere infatti effettivamente misurato nel reale contesto lavorativo dell’utenza in un ambiente “conforme” e rispondente ad impatti di diversa natura, ad esempio, anche solo organizzativi, di processo o sistemistici che non siano emersi in precedenza in un ambiente “omologo” di collaudo o che non abbiano comportato evidenti azioni di relativa e necessaria gestione risolutiva. Durante questo periodo di “osservazione” del sistema, l’aggiudicatario deve garantire affiancamento e supporto costanti, nonché interventi di presa in carico (servizio di help desk) e di attività correttive/migliorative immediati che non vengano valutati alla stregua di “manutenzioni evolutive” ma devono venire considerate comprese all’interno dell’attuale fornitura e senza alcun onere aggiuntivo a carico di ATS.

5.4 Servizi cloud

L’aggiudicatario dovrà erogare i servizi cloud richiesti dalla presente fornitura conformemente ai vincoli e requisiti dettati dalla normativa vigente garantendo in particolare quanto di seguito riportato:

CAPITOLATO TECNICO

 Qualificazione ACN almeno QC1 del servizio digitale erogato.

 Utilizzo di un’infrastruttura CSP qualificata almeno QI1.

 Xxxx’individuazione del CSP, l’aggiudicatario dovrà prendere in considerazione solo fornitori conformi al Regolamento ACN già citato ed alla normativa nazionale ed europea sulla protezione dei dati personali.

 Nell’individuazione del CSP, l’aggiudicatario dovrà prendere in considerazione solo fornitori conformi alle linee guida in materia emanate da AgID e ACN in tema di interoperabilità dei sistemi.

 Xxxx’individuazione del CSP, l’aggiudicatario dovrà prendere in considerazione solo fornitori che garantiscano l’adozione di misure tecniche organizzative di sicurezza a protezione dei dati per tutto il ciclo di vita del trattamento (salvataggio, trasmissione, conservazione, elaborazione, cancellazione), nonché la presenza di politiche di Business Continuity.

 L’aggiudicatario ed il relativo CSP non dovranno utilizzare i dati di ATS per qualsiasi altro scopo secondario non autorizzato.

 L’aggiudicatario dovrà informare tempestivamente ATS di qualsiasi violazione ai propri servizi e/o dati che possa avere un impatto diretto o indiretto su ATS stessa.

 L’aggiudicatario dovrà garantire l’eliminazione completa di qualsiasi traccia di dati e/o informazioni sia al termine del contratto con ATS che durante l’esecuzione dello stesso a richiesta di ATS o secondo tempistiche standard, adottando adeguate pratiche di distruzione e sanificazione.

5.5 Governance e monitoraggio in produzione

In caso di non conformità dell’infrastruttura di erogazione del servizio a carico dell’aggiudicatario, rilevate nel corso delle sessioni di audit periodiche da parte di una commissione ATS, l’Agenzia si riserva la facoltà di valutare l’applicazione di penali secondo quanto previsto dal contratto di Fornitura.

Fare riferimento a quanto indicato nel requisito SEC7 – “Audit e Monitoraggio”.

6 Formazione utenti

L’aggiudicatario dovrà garantire il servizio formativo relativo all’utilizzo del sistema dedicato agli utenti di ATS, sia in presenza che eventualmente in modalità a distanza.

La formazione deve consistere in 5 (cinque) giornate da garantire ad ATS a partire dalla data dell’avvio di produzione della soluzione, entro il primo anno contrattuale. La formazione può essere fruita anche tramite mezze giornate. L’eventuale attività d’aula sarà effettuata presso la sede che verrà indicata da ATS. Tale sede si troverà sul territorio di competenza di ATS. Se concordato con ATS, alcune fasi dell’attività di formazione potranno essere effettuate in teleconferenza.

CAPITOLATO TECNICO

A supporto degli utenti del sistema, l’aggiudicatario dovrà prevedere la produzione, la consegna, il mantenimento di un’adeguata documentazione tecnica ed operativa, comprendendo in generale tutto quanto, anche successivamente, si rendesse necessario produrre per documentare modifiche e/o adeguamenti al sistema in esercizio. In particolare, devono essere messi a disposizione di ATS i seguenti manuali:

 Manuale d’Uso dell’Utente, eventualmente suddiviso in più moduli dedicati alle diverse tipologie di utenti, contenente le informazioni di riferimento necessarie per il corretto uso del sistema in tutti gli scenari di utilizzo previsti.

 Manuale di Amministrazione di Sistema, contenente la descrizione esaustiva di tutte le funzioni specifiche dell’Amministratore di Sistema.

La documentazione tecnica, utente ed operativa deve essere messa a disposizione anche attraverso help-on-line (come specificato tra i requisiti tecnici, in USA2 – “Interfacce Help-On-Line”), con specifici rimandi dalle varie sezioni.

7 Servizi di assistenza e manutenzione

L’aggiudicatario è tenuto a garantire, per tutta la durata contrattuale, la manutenzione e l’assistenza tecnica del sistema tale da assicurare la continuità operativa del servizio.

Le eventuali chiusure aziendali dell’aggiudicatario dovranno essere preventivamente comunicate ad ATS e comunque non dovranno inficiare la normale attività lavorativa (neppure per i mesi di agosto e di dicembre).

7.1 Manutenzione correttiva ed assistenza

La gestione delle prestazioni contrattuali è disciplinata all’interno nel documento “Capitolato Speciale di Appalto” in cui vengono illustrati gli indicatori di qualità e gli SLA del servizio medesimo: occorre fare pertanto riferimento a tale documento per la descrizione esaustiva degli obiettivi e delle azioni contrattuali previsti.

In generale, il servizio di manutenzione correttiva include:

 la correzione di difetti del prodotto software emersi a seguito di malfunzionamenti rilevati durante l'esercizio o individuati anche autonomamente dall’aggiudicatario;

 il rilascio di nuove release del prodotto.

L’individuazione e la correzione di eventuali anomalie devono essere estese a tutto il software esistente ed alle sue successive modifiche correttive ed evolutive, escludendo potenziali regressioni, funzionali e no, che possano impattare le funzionalità e le performance dell’applicativo in produzione.

CAPITOLATO TECNICO

Tutte le attività relative ad aggiornamenti, modifiche, rilascio di nuove release dovranno essere preventivamente condivise con ATS ed opportunamente pianificate e gestite in modo coordinato, al fine di minimizzare i disagi alle attività operative e i blocchi temporanei del servizio.

Il servizio di assistenza tecnica include:

 un servizio di help desk di secondo livello attivabile direttamente dall’Ufficio preposto di ATS o attraverso i servizi di help desk di primo livello di ATS. Il servizio potrà essere richiesto sia a seguito di malfunzionamenti e/o disservizi sia per richiesta di attività di supporto all'operatività. Tutte le attività di help desk di secondo livello hanno carattere esclusivamente informatico.

 Il servizio di help desk dovrà essere garantito nei giorni feriali da lunedì a venerdì, dalle ore 09:00 alle 18:00, secondo quanto specificato nel capitolo “SLA richiesti e criteri di misura”.

 La garanzia di adattamento dell'applicazione (e di conseguente piena e corretta operatività dell'applicazione) alle nuove versioni disponibili di software di base, di ambiente sia server che client (inclusi i più diffusi internet browser quali Microsoft Edge), di RDBMS utilizzati dalla soluzione proposta che saranno rilasciate nel periodo contrattuale.

Il servizio di manutenzione correttiva e assistenza tecnica comprende:

 mano d’opera (illimitata);

 assistenza telefonica (illimitata);

 teleassistenza (illimitata);

 eventuali costi di trasferta del personale dell’aggiudicatario o dei consulenti di cui vorrà avvalersi (illimitati).

L’aggiudicatario dovrà fornire ad ATS idonee e chiare istruzioni operative relative all'attivazione del servizio.

Gli interventi dovranno potersi effettuare sia in loco che a distanza, anche in teleassistenza.

L’aggiudicatario dovrà impegnarsi, nel caso di attivazione del servizio di secondo livello, a dare riscontro ad ATS di tutte le fasi di gestione della richiesta di assistenza (presa in carico, risoluzione, chiusura), attraverso un sistema di gestione dei ticket.

Tutti gli interventi di tipo sistemistico conseguenti alle attività sopra indicate dovranno essere preventivamente pianificati e concordati con ATS.

I servizi di manutenzione correttiva e di assistenza tecnica si applicano negli stessi termini anche alle integrazioni realizzate con altri sistemi.

7.2 Manutenzione normativa

CAPITOLATO TECNICO

L’aggiudicatario s'impegna a fornire, nel periodo contrattuale e senza oneri aggiuntivi per ATS, gli adeguamenti del software applicativo alle intervenute disposizioni legislative, regolamentari, dispositive provenienti a vario titolo dalle Pubbliche Amministrazioni competenti nelle materie riguardanti le informazioni gestite dal sistema oggetto dell’appalto.

Le attività di adeguamento dell’applicazione software ricomprese nel presente articolo riguardano le modifiche e/o gli aggiornamenti e/o evoluzioni di funzionalità presenti, anche solo parzialmente, e gestite nella soluzione applicativa in uso. Le eventuali attività necessarie all’adeguamento normativo che richiedessero la realizzazione di funzionalità totalmente assenti, dunque funzionalità completamente nuove saranno considerate manutenzione evolutive e regolate secondo quanto indicato nel successivo paragrafo 8.3.

Tutte le attività relative ad aggiornamenti, modifiche, rilascio di nuove release dell'applicazione software dovranno essere opportunamente pianificate con ATS e l’avvio in produzione dovrà essere preventivamente autorizzato mediante apposito collaudo funzionale al fine di minimizzare i disagi alle attività operative e/o blocchi temporanei alle procedure.

Le tempistiche di intervento saranno di volta in volta concordate con l’aggiudicatario e comunque non oltre il limite di cinque giorni lavorativi dalla richiesta o entro il limite di applicazione fissato dalla disposizione legislativa, regolamentare, dispositiva intervenuta.

A seguito del rilascio in produzione, una modifica o nuova funzionalità relativa alla manutenzione normativa diventa parte integrante dell'applicazione software e ad essa si applica quanto definito nelle restanti parti del capitolato (ad esempio, manutenzione correttiva).

La manutenzione normativa dell'applicazione software si applica negli stessi termini anche alle integrazioni realizzate con altri sistemi.

7.3 Manutenzione evolutiva

Non essendo identificabili a priori gli interventi evolutivi determinati da necessità non comprese nelle specifiche iniziali del presente documento, la realizzazione di tali attività presuppone la preventiva analisi dei bisogni, la quotazione delle attività, la pianificazione degli interventi, la realizzazione ed il relativo collaudo. Tutte le fasi del processo sopra descritto sono da concordarsi con ATS.

Per lo svolgimento di tali attività, ATS richiede all’aggiudicatario di quotare per lo sviluppo di tali interventi evolutivi, un “pacchetto” di giornate-uomo, da utilizzarsi “a consumo” ovvero l’utilizzo di giornate o anche mezze giornate di attività.

Il pacchetto di giornate-uomo richiesto è stimato fino ad un massimo di 122 (centoventidue) giornate/uomo da cui si attingerà anche per l’eventuale sviluppo del modulo 1.

Tutte le giornate potranno essere utilizzate per tutta la durata contrattuale, eventualmente fruibili anche in 244 (duecentoquarantaquattro) mezze giornate/uomo. Tali giornate potranno anche essere utilizzate solo in parte da ATS; in tal caso ATS corrisponderà all’aggiudicatario solo il costo delle giornate/mezze giornate effettivamente erogate e preventivamente concordate con ATS sulla base

CAPITOLATO TECNICO

di un documento tecnico, redatto dall’aggiudicatario che dia evidenza delle attività effettivamente previste e che dovrà essere approvato da ATS.

L’aggiudicatario è tenuto ad allineare tutta la documentazione tecnica ed operativa del sistema.

A seguito del rilascio in produzione, ogni modifica evolutiva o nuova funzionalità diventa parte integrante del sistema stesso e comporta quanto definito nelle restanti parti del Capitolato Tecnico.

Si sottolinea che ogni futura modifica, correttiva o evolutiva o migliorativa, da apportare al sistema dovrà essere sempre soggetta a collaudo preventivo prima dell’effettivo rilascio in produzione.

Per ogni evolutiva rilasciata in esercizio, ATS si riserva la facoltà di monitorare il corretto andamento del funzionamento del sistema in produzione per un per periodo di due mesi (fase di avvio) per valutare l’affidabilità delle evolutive rilasciate e l’assenza di regressioni sulle funzionalità preesistenti del sistema.

Si ribadisce che tutto il software sviluppato specificatamente per conto di ATS (codice sorgente) ivi comprese le relative modifiche evolutive introdotte dall’aggiudicatario nel corso del contratto, unitamente a tutta la documentazione tecnica e di esercizio prodotta, dovranno intendersi di proprietà intellettuale di ATS, che avrà facoltà di poter cedere in riuso tutto il software sviluppato agli Enti Pubblici che lo dovessero richiedere.

Il software integralmente e le relative componenti evolutive potranno essere segnalati ad AgID e pubblicati sul repository Developers Italia.

CAPITOLATO TECNICO

8 SLA richiesti e criteri di misura

La gestione delle prestazioni contrattuali è disciplinata all’interno nel documento “Capitolato Speciale di Appalto” in cui vengono illustrati gli indicatori di qualità e gli SLA del medesimo servizio: occorre fare pertanto riferimento a tale documento per la descrizione esaustiva degli obiettivi e delle azioni contrattuali previsti.

Dato l’impatto che tale applicativo ha sulla immagine e operatività di ATS, un importante elemento di valutazione è la qualità del servizio offerto agli utenti del sistema, con particolare riferimento ai tempi di risoluzione di eventuali problematiche o anomalie o difetti che dovessero emergere e verificarsi in esercizio, considerando soprattutto che la stragrande maggioranza di utenti fruitori sono esterni ad ATS e distribuiti in modo eterogeneo.

L’aggiudicatario è tenuto a garantire il servizio di manutenzione ed assistenza tecnica secondo la seguente copertura oraria:

Giorno	Copertura
Lunedì	dalle 9:00 alle 18:00
Martedì	dalle 9:00 alle 18:00
Mercoledì	dalle 9:00 alle 18:00
Giovedì	dalle 9:00 alle 18:00
Venerdì	dalle 9:00 alle 18:00

Negli stessi orari devono essere garantiti i seguenti servizi:

 help desk;

 raccolta, registrazione e instradamento delle richieste di intervento in caso di xxxxxx;

 verifica dell’esecuzione dell’intervento riparatore e registrazione della conclusione del ticket.

Il sistema di tracciatura utilizzato dall’aggiudicatario deve permettere ad ATS la ricezione di notifiche o comunicazioni relative ad ogni cambio di stato delle segnalazioni effettuate fino alla chiusura dei ticket da parte dei gruppi tecnici preposti.

CAPITOLATO TECNICO

9 Riferimenti documentali e normativi

Accessibilità Il portale dovrà rispondere ai requisiti tecnici di accessibilità definiti nei seguenti atti normativi e di indirizzo: 1. Linee Guida AgID per l’Accessibilità degli strumenti informatici. 2. Legge 4 del 9 gennaio 2004, (Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici) e successivo D.M. 8 luglio 2005 (Regolamento di attuazione della Legge 4 del 9 gennaio 2004, per favorire l’accesso dei soggetti disabili agli strumenti informatici) aggiornato con 3. D.M. del 20 marzo 2013. 4. Decreto Legislativo 82/2005 (Codice dell'Amministrazione Digitale); 5. Decreto del Presidente della Repubblica 75/2005 Regolamento di attuazione della Legge 4/2004, per favorire l'accesso dei soggetti disabili agli strumenti informatici. 6. Decreto del Ministro per l'Innovazione e le Tecnologie 8 luglio 2005 recante "Requisiti tecnici e diversi livelli per l’accessibilità agli strumenti informatici". 7. Direttiva 27 luglio 2005 della Presidenza del Consiglio dei Ministri - Dipartimento per l’Innovazione e le Tecnologie Qualità dei servizi Online e misurazione della soddisfazione degli utenti. 8. Direttiva n. 8/2009 - Ministro per la pubblica amministrazione e l'innovazione relativa alla riduzione dei siti web delle P.A. e per il miglioramento della qualità dei servizi e delle informazioni on line al cittadino. 9. Linee Guida per i siti web delle P.A. (previste dalla Direttiva 10. n. 8/09 - Ministro per la pubblica amministrazione e l'innovazione). 11. Decreto Legislativo 33/2013 Riordino della disciplina riguardante gli obblighi di pubblicità, trasparenza e diffusione di informazioni da parte delle pubbliche amministrazioni (pubblicato sulla Gazzetta Ufficiale della Repubblica Italiana 12. n. 80 del 5 aprile 2013) e s.m.i. 13. Decreto Legislativo recante revisione e semplificazione delle disposizioni in materia di prevenzione della corruzione pubblicità e trasparenza, correttivo della Legge 6 novembre 2012, n. 190 e del decreto legislativo 14 marzo 2013, n. 33, ai sensi dell'articolo 7 della legge 7 agosto 2015, n. 124, in materia di riorganizzazione delle amministrazioni pubbliche.

CAPITOLATO TECNICO

	14. Circolare n. 61/2013 del 29 marzo 2013 dell'Agenzia per l'Italia Digitale in materia di accessibilità dei siti web delle pubbliche amministrazioni; 15. Delibera CIVIT N. 50 del 4 luglio 2013, “Linee guida per l'aggiornamento del Programma triennale per la trasparenza e l'integrità 2014-2016”.
Data Center e cloud	Indicazioni di AgID: Circolare n. 2 del 24/06/2016, “Piano triennale per l’informatica nella pubblica amministrazione” previsto dalle disposizioni della legge n. 208 del 28/12/2015 - Legge di stabilità 2016. Circolare n.5 del 30 novembre 2017 relativa agli obiettivi e alle linee guida per la PA rispetto al risparmio di spesa ICT e al consolidamento dei data center. Regolamento per i servizi cloud, pubblicato da AgID a dicembre 2021 con determinazione 628/2021. Indicazioni di ACN: Decreto direttoriale prot. N. 29 del 02/01/2023 dell’Agenzia per la Cybersicurezza Nazionale. Determine 306 e 307 di gennaio 2022 pubblicate dalla Agenzia per la Cybersicurezza Nazionale e relativi allegati.
Privacy e Security	D.Lgs. 196/2003 (“Codice in materia di protezione dei dati personali”) Misure di sicurezza e modalità di scambio dei dati personali tra amministrazioni pubbliche - 2 luglio 2015 GDPR (General Data Protection Regulation), Regolamento UE 2016/679 Linee guida AgID in merito alla misure minime di sicurezza ICT per la PA (Circolare n. 1 del 17.3.2017 pubblicata in GU del 4.4.2017) Misure Minime di Sicurezza AgID (circolare n. 2 del 18/4/2017) Indicazioni di ACN: Decreto direttoriale prot. N. 29 del 02/01/2023 dell’Agenzia per la Cybersicurezza Nazionale. Determine 306 e 307 di gennaio 2022 pubblicate dalla Agenzia per la Cybersicurezza Nazionale e relativi allegati.

CAPITOLATO TECNICO

	Fare riferimento a best practices e standard proposti nell’ambito del progetto OWASP (Open Web Application Security Project) e consultabili al seguente link: xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxx_Xxxx
Proprietà intellettuale	L. 633/41 (“Protezione del diritto d'autore e di altri diritti connessi al suo esercizio”).

CAPITOLATO TECNICO

10 Appendice

10.1 Diagramma Generale

Nello schema generale seguente sono indicati tre moduli separati del nuovo gestionale, questo al fine di dare una visione globale del processo.

CAPITOLATO TECNICO

MODULO 1

CAPITOLATO TECNICO

MODULO 2