Capitolato Tecnico
Capitolato Tecnico
PROCEDURA APERTA SOTTO SOGLIA COMUNITARIA PER L’ACQUISIZIONE DI UN APPLICATIVO, E RELATIVA ASSISTENZA TECNICA E MANUTENZIONE, PER LA GESTIONE INFORMATIZZATA DEL PATRIMONIO IMMOBILIARE DELL’ATS DELLA CITTÀ METROPOLITANA DI MILANO.
INDICE
1 DEFINIZIONI, ABBREVIAZIONI E SIGLE 4
1.1 Definizioni generali legate alla Fornitura 4
1.2 Altre definizioni, abbreviazioni e sigle 5
2.4 Contesto tecnologico ed operativo 7
2.5 Titolarità del codice sorgente 8
3.1 Caratteristiche generali del servizio 9
3.2 Caratteristiche relative al fascicolo dell’immobile 11
3.3 Caratteristiche relative alla gestione contabile 13
4.1 Requisiti organizzativi 20
4.3 Requisiti e vincoli tecnologici e infrastrutturali 21
6 PROGETTAZIONE, REALIZZAZIONE E DELIVERY 24
9 SERVIZI DI ASSISTENZA E MANUTENZIONE 28
9.1 Manutenzione correttiva ed assistenza 28
10 DURATA DEL CONTRATTO E MODALITÀ DI CONCLUSIONE ERRORE. IL SEGNALIBRO
NON È DEFINITO.
11 LIVELLI DI SERVIZIO MINIMI RICHIESTI E CRITERI DI MISURA 31
12 RIFERIMENTI DOCUMENTALI E NORMATIVI 32
1 Definizioni, abbreviazioni e sigle
1.1 Definizioni generali legate alla Fornitura
Fornitore | Il Concorrente che sarà scelto per erogare le forniture ed i servizi coperti dal contratto. |
ATS | ATS Milano Città Metropolitana rappresenta l’Ente appaltante ed il Cliente per il presente contratto. |
Concorrente | Qualsiasi partecipante alla Gara di appalto di questo contratto. |
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 | Programma che utilizza il software di base, d’ambiente e di rete per realizzare funzionalità legate agli scopi dell’organizzazione che lo utilizza. |
Service Level Agreement (SLA) | Definizione ed associato criterio di misura per la valutazione della qualità dei servizi che saranno erogati dal Fornitore. |
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 | Un ticket contiene una richiesta di assistenza o di manutenzione attraverso una delle modalità di accesso al servizio e ne traccia la storia. 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. |
Manutenzione software correttiva | Rimozione di eventuali malfunzionamenti delle procedure applicative segnalati dal Cliente o dal Fornitore 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 al Cliente. |
Manutenzione software normativa | Comprende attività da svolgere per l’adeguamento del software applicativo al fine di adempiere obblighi di legge o a fronte di requisiti tecnici, informativi, funzionali e organizzativi che siano definiti da organismi normativi esterni alla struttura del Cliente (Stato, |
Ministeri, Regioni...). | |
Manutenzione software evolutiva | Comprende la modifica / aggiunta di funzioni o la parametrizzazione del software applicativo sulla base di specifici requisiti del Cliente. |
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. |
1.2 Altre definizioni, abbreviazioni e sigle
Software “orizzontale” | Applicazioni software di uso generalizzato (general-purpose) adattabili alle esigenze di diversi settori commerciali. 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. |
Software “verticale” | Applicazioni software con funzionalità specifiche di un determinato settore commerciale. |
Software proprietario | 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. |
FP | Function Point è un'unità di misura utilizzata per esprimere la dimensione 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 della Regione Lombardia, istituita con lo scopo di realizzare un sistema di Intermediazione Telematica che supporti la Regione e tutte le Pubbliche Amministrazioni della Lombardia nella realizzazione delle proprie gare. |
Cloud computing | Si indica un modello di erogazione di servizi offerti on demand da un fornitore ad un cliente finale attraverso la rete Internet. |
SaaS | Software as a Service. È 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. |
2 Premessa
2.1 Scopo del documento
ATS Città Metropolitana di Milano (d’ora in avanti, ATS) ha l’esigenza di individuare, tramite apposita Gara di Appalto, un operatore economico al quale affidare i servizi realizzativi e aggiuntivi di un sistema informativo web-based che assicuri la gestione del fascicolo dell'immobile e della contabilità relativa al patrimonio da reddito e delle sedi istituzionali di ATS, inclusa l'archiviazione della documentazione amministrativa, contabile e tecnica. La fornitura riguarda le attività di sviluppo di personalizzazioni di una soluzione applicativa esistente disponibile in licenza open source e dei relativi servizi di formazione, assistenza e manutenzione (ordinaria e straordinaria) e hosting dell’applicazione web in cloud.
Il sistema informativo richiesto deve implementare la gestione del fascicolo dell’immobile e del patrimonio immobiliare garantendo in particolare la copertura delle seguenti macro-aree funzionali:
• inventario degli asset immobili (edifici, infrastrutture sul territorio, terreni…): è inclusa la possibilità di aggiungere annotazioni, di suddividere gli immobili per Distretti ATS, di attribuire all’immobile una pluralità di servizi e/o destinazioni d’uso, di indicare il titolo di godimento di ciascun immobile e di poter filtrare la ricerca e la visualizzazione degli stessi, anche su mappa, con una pluralità di criteri, inclusi quelli sopra menzionati;
• inventario degli asset mobili (dispositivi di sicurezza utilizzati, …);
• gestione finanziaria dei budget, dei fornitori, dei contratti e dei documenti di acquisto;
• georeferenziazione degli asset su planimetrie e mappe territoriali;
• console di amministrazione;
• integrazioni con applicativi CAD (AutoCAD di Autodesk) e documentali (Microsoft SharePoint);
• reportistica e cruscotti gestionali.
2.2 Modalità acquisitiva
ATS intende individuare un Fornitore che possa garantire servizi realizzativi e aggiuntivi di una soluzione applicativa dedicata ad ATS attraverso le seguenti modalità:
• personalizzazione di una soluzione applicativa esistente sul mercato e disponibile con licenza open source;
• erogazione di servizi aggiuntivi relativi a: formazione utenti, assistenza e manutenzione correttiva, normativa ed evolutiva, hosting dell’applicazione web in cloud.
A questo proposito ATS ha individuato, tra le soluzioni di mercato con maggiore grado di copertura dei requisiti funzionali e tecnici/tecnologici indicati nel presente documento, il prodotto open source openMAINT, distribuito sul repository SourceForge al seguente indirizzo Internet:
xxxxx://xxxxxxxxxxx.xxx/xxxxxxxx/xxxxxxxxx/xxxxx/0.0/Xxxx%00xxxxxxx/xxxxxxxxx-0.0- 2.5.1_with_DB.zip/download
Nella Busta Tecnica, ogni Concorrente dovrà indicare il proprio piano operativo delle attività, precisando con che tempi, eventualmente migliorativi rispetto a quelli massimi previsti nel presente documento, intende rispondere ad ATS adottando il prodotto open source suddetto. Si ribadisce che nell’offerta tecnica non dovranno essere previsti costi di licenza di alcun tipo se non inclusi nella fornitura stessa.
2.3 Ambito della fornitura
La fornitura deve prevedere quanto segue:
• attività di sviluppo di personalizzazioni di un’applicazione software esistente, disponibile in licenza open source, che garantisca la copertura di tutti i requisiti funzionali, non funzionali e tecnologici espressi nel presente documento;
• attività di formazione all’utilizzo del sistema per le diverse tipologie di utenza previste;
• attività di assistenza e manutenzione correttiva, normativa ed evolutiva per garantire la continuità operativa a tutti gli utilizzatori del sistema;
• produzione di tutti i certificati digitali necessari per la messa in esercizio del sistema informativo e che andranno intestati ad ATS;
• servizio di hosting, in linea con la normativa vigente, di una infrastruttura che garantisca almeno due ambienti operativi indipendenti (test/collaudo, produzione), non necessariamente in alta disponibilità;
• eventuale supporto a terzi per la messa a punto delle integrazioni applicative richieste;
• cessione perpetua di copia del codice sorgente relativo a tutte le componenti funzionali sviluppate e delle personalizzazioni, della base dati nonché della documentazione tecnica e di esercizio prodotta;
• attività di messa a riuso del software commissionato o di una sua parte, per conto di ATS e secondo quanto definito nelle Linee Guida AgID;
• garanzia di 12 mesi riferita alla manutenzione correttiva. Tale garanzia decorrerà dall’avvio
del sistema in esercizio, a valle del buon esito delle procedure di collaudo di ATS;
• attività di manutenzione evolutiva a consumo, inclusa nel prezzo offerto; a questo proposito si segnala la possibilità di progettare e sviluppare, con riconoscimento a consumo, ulteriori report rispetto a quelli già previsti all’interno del presente capitolato.
2.4 Contesto tecnologico ed operativo
Il sistema informativo richiesto da ATS prevede che le componenti relative all’applicazione web ed ai dati siano collocate in ambiente cloud, conformemente alle Linee Guida di AgID per la PA.
La soluzione progettuale dovrà essere basata su tecnologie di cloud computing secondo il paradigma SaaS (Software as a Service).
Con riferimento alle due circolari AgID n. 2 e n. 3 del 9 aprile 2018, l’acquisizione dei servizi in hosting dovrà soddisfare quanto indicato: “A decorrere dal 1 aprile 2019, le Amministrazioni Pubbliche potranno acquisire esclusivamente servizi IaaS, PaaS e SaaS qualificati da AgID e pubblicati nel Cloud Marketplace” (xxxxx://xxxxx.xxxxxx.xx/xxxxxxxxxxx/xxxxxxxx/xxxxxx/xxxxx.xxxx).
Per permettere ad ATS di valutare l’efficacia del servizio SaaS erogato, il Fornitore dovrà rendere disponibile, durante il periodo contrattuale, ad ATS strumenti idonei di monitoraggio e di Quality Assurance al fine di poter effettuare verifiche di conformità alla normativa in materia di privacy e sicurezza.
L’utilizzo delle funzionalità del sistema informativo dovrà essere possibile attraverso i più diffusi browser Internet, l’accesso ai dati sarà possibile solo agli utenti abilitati in funzione dei previsti livelli e profili di accesso.
Ai fini del corretto dimensionamento del sistema, di seguito sono forniti alcuni dati relativi agli utilizzatori, agli asset e ai volumi documentali previsti:
• utenti interni ATS: al massimo 50;
• utenti esterni ad ATS: al massimo 50;
• numero immobili gestiti: indicativamente tra i 100 e i 150, considerate sedi istituzionali, sedi di continuità assistenziale, immobili da reddito (edifici e terreni);
• volumi documentali previsti: non è possibile fornire una quantificazione a priori.
Al di là dei limiti dimensionali suddetti, l’applicazione web dovrà prevedere l’espandibilità del numero di utenti interni ed esterni e la possibilità di variare indefinitamente il numero degli immobili gestiti mantenendo lo storico di quelli non più in gestione.
2.5 Titolarità del codice sorgente
Si ribadisce che tutto il software sviluppato e relativo alla presente fornitura, unitamente a tutte le successive modifiche (correttive e/o evolutive e/o migliorative) che verranno introdotte dal Fornitore, unitamente a tutta la documentazione tecnica e di esercizio prodotta, dovranno intendersi di proprietà di ATS.
ATS avrà la possibilità di cedere in riuso le eventuali personalizzazioni ad altri Enti Pubblici che lo dovessero richiedere. Le stesse personalizzazioni potranno essere segnalate ad AgID per essere rese disponibili in modalità open source sul repository Developers Italia.
3 Requisiti Funzionali
Si sottolinea che, per completezza, sono da considerarsi parti integranti della presente specifica funzionale tutti i riferimenti bibliografici, documentali e normativi referenziati all’interno del presente documento.
3.1 Caratteristiche 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-end, in particolare: • creazione, configurazione e profilazione delle diverse tipologie di utenza; • configurazione di tutte le proprietà degli oggetti gestiti dall’applicazione; • configurazione template reportistica; • configurazione alert di notifica; • consultazione dei log applicativi. |
GEN2 | I&A utenti |
Il sistema deve consentire l’identificazione e l’autenticazione (I&A) di tutti gli utenti, sia interni che esterni ad ATS. Deve essere prevista la funzionalità di Single Sign On (SSO) per gli utenti interni che appartengono all’Active Directory di ATS e che accedono al sistema attraverso una postazione di lavoro in dominio ATS con le relative credenziali di dominio. Tutti gli altri utenti del sistema devono poter essere identificati e autenticati attraverso credenziali personali (username e password). |
GEN3 | Gestione credenziali utenti |
Il sistema deve consentire la creazione, il recupero delle credenziali, la modifica della password a tutti gli utenti esterni (gli utenti interni appartenenti all’Active Directory di ATS possono modificare la propria password attraverso i meccanismi di dominio AD/LDAP). Il sistema deve implementare / supportare opportune policy, tecniche e procedurali, di robustezza delle password (lunghezza minima, caratteri speciali, password aging, cambio password al primo accesso, …), generate automaticamente o manualmente dall’utente stesso. Più nel dettaglio, il sistema deve garantire: • adeguata complessità delle password (almeno otto caratteri, uso di caratteri alfanumerici, lettere maiuscole e minuscole, caratteri estesi); • obbligo di modifica password al primo accesso e ogni tre mesi, impedendo il riuso delle ultime tre password; • blocco utenza a fronte di ripetuti tentativi falliti di autenticazione; • tracciamento dei tentativi falliti di autenticazione degli amministratori; • disattivazione automatica delle credenziali non utilizzate per 6 mesi. |
GEN4 | Stampe, ricerca e reportistica |
Il sistema deve implementare le seguenti funzionalità applicate ai diversi contesti |
d’uso (tecnico, amministrativo, contabile) descritti nel documento: • gestione delle stampe; • strumenti e filtri di ricerca; • navigazione e consultazione nel rispetto dei diritti di accesso attribuiti ai singoli utenti; • export dei dati e dei documenti nei formati standard maggiormente diffusi (ad esempio: Excel, PDF, …); • generazione report relativi a ciascuna categoria di dati inseriti (quali ad esempio: fascicoli degli immobili, contabilità, elenco degli immobili, elenco dei distretti, …); • composizione e aggiornamento di check-list degli adempimenti normativi per l’individuazione della documentazione tecnico-amministrativa prodotta e ancora da produrre per ciascun immobile; • creazione, manuale e/o automatica di “alert” (per la notifica di scadenze relative a certificati, pagamenti, adempimenti in genere, …). |
GEN5 | Integrazione con Microsoft SharePoint |
Il sistema deve permettere l'integrazione con i sistemi documentali che supportano lo standard CMIS (Content Management Interoperability Services), in particolare con Microsoft SharePoint, sistema documentale adottato da ATS per finalità archivistiche. Oltre alla rappresentazione logica “embedded” legata all’applicativo software utilizzato, il sistema deve permettere anche una rappresentazione gerarchica che faciliti la consultazione e la condivisione dei documenti da parte di un utente finale. La struttura gerarchica che permette di suddividere e organizzare i dati e i documenti soggetti all’archiviazione su SharePoint deve essere personalizzabile da parte degli amministratori. |
GEN6 | Integrazione con Autodesk AutoCAD |
Il sistema deve permettere in maniera automatica (sincronizzazione applicativa) o eventualmente semiautomatica (su richiesta dell’operatore) il primo caricamento ed i successivi aggiornamenti dei file in formato DWG elaborati con AutoCAD, l’applicazione CAD utilizzata da ATS. Si stabilisce che il sistema debba importare e gestire correttamente planimetrie vettoriali 2D a partire dai seguenti vincoli e/o prerequisiti: • ogni piano dell'edificio deve occupare un file distinto (DWG, DXF); • la planimetria deve essere georeferenziata tramite AutoCAD (latitudine, longitudine, orientamento, scala, sistema di riferimento adottato,…); • gli elementi di superficie (ad esempio: stanze, locali, …) devono essere rappresentate con poligonali chiuse; • gli eventuali asset da recuperare in automatico (ad esempio: arredi, impianti, …) devono essere censiti con simboli appartenenti a layer distinti e devono essere dotati di un codice di identificazione univoco (impostato come “extended data” in AutoCAD). |
GEN7 | Verifica integrità del software |
Il sistema deve implementare opportuni meccanismi (ad esempio: checksum) per la verifica e la visualizzazione della release del software rilasciato in produzione in modalità SaaS e la sua corrispondenza con la baseline software corrente consegnata ad ATS sul proprio repository Microsoft DevOps. |
3.2 Caratteristiche relative al fascicolo dell’immobile
FIM1 | Inventario |
Il sistema deve consentire il salvataggio di file nonché la registrazione, la ricerca e la consultazione delle informazioni tecnico descrittive relative a: • immobili interamente di proprietà ATS; • singole unità immobiliari di proprietà ATS situate in edifici in compresenza con terzi (ad esempio: appartamenti/negozi in Condominio); • immobili in cui ATS è presente a titolo diverso; • parti comuni; • terreni di proprietà. Il software deve consentire una pluralità di criteri di ricerca, filtro e consultazione, tra cui almeno i seguenti: • ricerca, filtri multipli relativi ai campi dati compilati, visualizzazione sulla mappa; • ricerca per singola parola (es. via, nominativo inquilino, ente gestore, nominativo proprietà, …); • ricerca per intero edificio o per piano; • ricerca per dati catastali edificio/unità immobiliare; • ricerca per data. Il sistema deve inoltre prevedere la possibilità di: • aggiungere annotazioni (campo note, oppure file Word/PDF da allegare come promemoria); • suddividere gli immobili per Distretti ATS; • consultare e visualizzare lo storico dell’elenco immobili e lo storico delle modifiche effettuate, secondo la data selezionata o il periodo selezionato; • attribuire all’immobile una pluralità di servizi e/o destinazioni d’uso (es. inserimento dei mq elaborati da file DWG, inserimento manuale di dati e annotazioni); • indicare il titolo di godimento di ciascun immobile (in cui sia possibile visualizzare/allegare PDF oltre che impostare alert automatici per le scadenze); • poter filtrare la ricerca e la visualizzazione degli immobili e delle unità immobiliari, anche su mappa, con una pluralità di criteri, inclusi quelli menzionati all’elenco precedente. Le informazioni tecnico descrittive nonché amministrative e di altro genere dovranno comprendere, tra l’altro, tutti i campi necessari per l’acquisizione dei dati previsti dalla normativa vigente per la composizione del fascicolo dell’immobile. |
FIM2 | Documenti Tecnici |
Il sistema deve consentire l’acquisizione di tutte le informazioni necessarie conformemente alle indicazioni del presente Capitolato Tecnico e ai seguenti riferimenti normativi: • Circolare del Ministero dell’Economia e delle Finanze n. 16063 del 9/7/2010 “Valorizzazione immobili pubblici. Linee guida generali per la costituzione del fascicolo immobiliare”, che si richiama integralmente; • Regolamento Edilizio vigente del Comune di Milano; • altra normativa vigente se applicabile ai dati da elaborare tramite il software oggetto del presente Capitolato Tecnico. Il sistema deve consentire la gestione delle seguenti tipologie documentali, nei formati standard in uso (nell’elenco sotto riportato se ne menzionano alcuni, a titolo |
indicativo): • documenti (circolari, regolamenti edilizi, …) riguardanti la compilazione del fascicolo; • planimetrie dello stato di fatto (in formato PDF, DWG, DXF, BIM); • planimetrie catastali (in formato PDF); si sottolinea che non è necessario l’interfacciamento con gli applicativi dell’Agenzia del Territorio; • visure catastali aggiornate (in formato PDF, JPEG); si sottolinea che non è necessario l’interfacciamento con gli applicativi dell’Agenzia del Territorio; • titoli di provenienza che attestino la proprietà dell’immobile (in formato PDF, JPEG); • documenti relativi al diritto di proprietà comprese le eventuali limitazioni (in formato PDF, JPEG); • dichiarazioni urbanistiche (data di costruzione, in formato PDF, JPEG); • regolarità contributiva e titoli edilizi (in formato PDF, JPEG); • attestazioni sullo Stato di Fatto dal punto di vista edilizio-urbanistico (in formato PDF, JPEG); • dati relativi ai fabbricati soggetti al vincolo del Decreto N. 42 del 22/01/2004 (in formato PDF, JPEG); • polizze globali (in formato PDF, JPEG); • relazione su stima di mercato dell’immobile (in formato PDF, JPEG); • denunce dei cementi armati al collaudo statico dell’immobile con elaborati grafici (in formato PDF, JPEG); • elaborati (ultimo aggiornamento) degli impianti comuni (in formato PDF, JPEG). |
FIM3 | Certificazioni |
Il sistema deve consentire la gestione dei seguenti certificati: • certificazione urbanistica della presenza dei vincoli (in formato PDF, JPEG); • certificazione di agibilità/abitabilità (in formato PDF, JPEG); • certificazione energetica (in formato PDF, JPEG); • certificazione di conformità degli impianti; • atti destinati a, rilasciati da e di competenza dei Vigili del Fuoco con elaborati grafici (in formato PDF, JPEG); • certificazione di idoneità statica con elaborati grafici (in formato PDF, JPEG). Per ogni certificazione deve essere possibile inserire il relativo alert (anche con avvisi multipli). |
FIM4 | Censimento Stato Manutentivo |
Il sistema deve consentire la gestione dei dati relativi: • agli interventi di manutenzione risalenti ad almeno gli ultimi 5 anni (in formato PDF) e creazione di un elenco sintetico delle manutenzioni in oggetto; • alle manutenzioni dei dispositivi di sicurezza utilizzati (in formato PDF) e creazione di un elenco sintetico delle manutenzioni in oggetto. |
FIM5 | Contratti |
Il sistema deve consentire la gestione dei contratti di locazione ai fini del monitoraggio di rinnovi, disdette, scadenze e della verifica della regolarità dei pagamenti. Le specifiche di ogni contratto di locazione devono poter essere gestite sia per unità immobiliare (subalterno) sia per nominativo (titolare del contratto). |
FIM6 | Modifiche Strutturali |
Il sistema deve consentire la gestione delle modifiche strutturali (compresi i sopralzi) con elaborati grafici dello stato di fatto (in formato PDF, DWG, DXF, BIM). |
FIM7 | Acquisizioni e Scambi |
Il sistema deve consentire la gestione delle eventuali acquisizioni e scambi dei diritti edificatori (in formato PDF, JPEG). |
FIM8 | Corrispondenza |
Il sistema deve consentire il salvataggio di e-mail e la loro archiviazione nelle varie sezioni dell’applicativo, a seconda della pertinenza, da software tipo Outlook o da servizi web mail. |
3.3 Caratteristiche relative alla gestione contabile
GES1 | Tabelle millesimali |
Il sistema deve consentire la creazione e l’utilizzo di tabelle millesimali applicandole ai bilanci ai fini della ripartizione delle spese globali sulle singole unità immobiliari. Tali tabelle devono essere composte da: una colonna che riporti tutte o solo alcune unità immobiliari a cui associare un valore e un’altra che riporti il valore stesso; per l’inserimento dei dati che andranno a comporre la colonna delle unità immobiliari, il sistema deve attingere dall’anagrafe del singolo edificio, mostrando tutte le singole anagrafiche: l’utente deve avere la possibilità di selezionare tutte o solo alcune delle unità immobiliari che compongono il condominio. I numeri che compongono la colonna dei valori devono essere inseribili manualmente dall’utente. Il campo che riporta l’unità di misura utilizzata deve essere editabile, di modo che l’utente possa creare più tabelle per lo stesso edificio considerando diversi parametri di ripartizione. Il sistema deve permettere l’inserimento e la gestione di una o più tabelle millesimali per ciascun immobile o parte di immobile, con la possibilità di utilizzare diverse unità di misura (millesimi, metri quadri, metri cubi, …). |
GES2 | Anagrafe del Patrimonio |
Il sistema deve permettere l’inserimento e la gestione dell’anagrafica degli edifici e l’articolazione degli stessi in unità immobiliari, ognuna con i propri dati, sia per i riferimenti tecnici e catastali (indirizzo, foglio, mappale, subalterno, planimetria catastale, DWG, metri quadri reali), sia per quanto riguarda i dati degli inquilini (dati anagrafici, codice fiscale, numero di telefono, mail ed ogni altro riferimento utile). Creazione dell’immobile • DENOMINAZIONE: inserimento della denominazione dell’immobile e sua ubicazione; • STRUTTURA: definizione del numero e delle relative tipologie di unità immobiliari presenti, con la possibilità di suddividere il condominio in scale o palazzine; • DATI CATASTALI: inserimento di codice catastale del comune in cui è ubicato, indicazione catasto terreni o urbano, immobile intero o porzione, categoria catastale, sezione urbana, foglio, particella, subalterno (non è necessaria l’interfacciamento con l’Agenzia del Territorio). |
Occorre inoltre che siano presenti un campo note in cui poter riportare informazioni aggiuntive e un campo per l’inserimento di eventuali altri allegati (es. polizze assicurative, numero di c/c, contratti di fornitura, utenze, …). Il sistema deve consentire la creazione di condominii/edifici da poter articolare in unità immobiliari, che possono essere, a titolo esemplificativo, appartamenti, box, magazzini, negozi, cantine, etc. L’anagrafe dell’immobile/condominio è composta dalle unità immobiliari inserite. Dal menù deve quindi poter essere selezionato l’elenco di tutti gli immobili/condominii che verranno creati. Articolazione del immobile/condominio e relativa anagrafe Dal menù deve essere selezionabile la voce che riporti all’anagrafe condomini. Il sistema deve proporre tutti gli edifici creati per poterne selezionare uno in cui inserire tutti i dettagli delle singole unità immobiliari. Selezionando l’immobile/condominio deve comparire un elenco con un numero di unità immobiliari pari a quello indicato nel campo STRUTTURA del Condominio. Ogni riga dell’elenco deve quindi essere compilata con i dati riferiti alla singola unità immobiliare. L’utente deve poter compilare, filtrare e ricercare i seguenti campi: • Proprietà: nome e cognome o ragione sociale, codice fiscale e/o partita Iva, contatti (indirizzo, telefono, fax, mail, PEC, …); • Inquilino: nome e cognome o ragione sociale, codice fiscale e/o partita Iva, contatti (indirizzo, telefono, fax, mail, PEC, …), eventuali indirizzi di contatto diversi da quello in cui lo stesso risiede; • Dati catastali dell’unità, ovvero indirizzo, foglio, mappale, subalterno, categoria catastale, metri quadri reali, codice catastale comune, piano, immobile intero o porzione, con possibilità di inserire allegati (es. visura castale in PDF, planimetria unità immobiliare in formato PDF e/o DWG); • Estremi del contratto di locazione (numero del contratto, data di registrazione, decorrenza, scadenza, canone annuo, importo spese condominiali presenti nel testo del contratto) con la possibilità di allegare il contratto in formato PDF e creare degli alert per monitorare le scadenze; • Certificati di conformità degli impianti e pratiche relative alla prevenzione incendi con possibilità di creare degli alert per monitorare le scadenze; • Subentri: in caso di vendite, rilasci o cambi inquilino deve esistere la possibilità di registrare un subentro, di modo da poter registrare l’unità a nome del nuovo locatario, senza però perdere traccia degli occupanti precedenti. Nel campo subentri deve essere quindi possibile visualizzare l’elenco e il periodo temporale di chi è stato in affitto presso la singola unità immobiliare. |
GES3 | Documenti Contabili |
Creazione bilanci: per ogni immobile deve essere possibile creare bilanci preventivi e consuntivi in cui inserire spese di varia natura ai fini della rendicontazione e ripartizione spese. Selezionando dal menù la tipologia di bilancio, il sistema deve proporre l’elenco degli immobili/condominii e, una volta selezionatone uno, l’elenco delle annualità da consultare o da creare all’inizio di ogni esercizio. Ai fini della creazione del bilancio preventivo deve essere possibile: • definire la durata dell’anno gestionale, che per alcuni immobili/condominii può coincidere con l’anno solare e per altri può essere a cavallo di due annualità (es. anno gestionale 01.06.18/31.05.19); • creare dei capitoli di spesa, articolabili in sub-capitoli, ad ognuno dei quali deve essere associabile una tabella millesimale, selezionabile da un elenco composto da tutte le tabelle millesimali inserite per quell’immobile/condominio, in modo che vada poi a definire il criterio di ripartizione dei diversi capitoli di spesa. Per ogni voce di bilancio deve essere possibile inserire l’importo stimato per la tipologia di spesa (es. Capitolo di |
spesa 1: “utenze” – sub-capitolo 1.1: “luce” e sub-capitolo 1.2 “acqua”). L’operatore quantifica l’importo di euro 200 per la luce ed euro 300 per l’acqua, seleziona i sub-capitoli e inserisce l’importo. Il preventivo deve mostrare l’importo totale del capitolo “utenze”, pari ad euro 500, e all’interno dello stesso l’elenco dei sub-capitoli con il dettaglio degli importi; • definire il numero di rate annuali, relative scadenze e percentuali di ripartizione del totale del preventivo (es. 4 rate, scadenze 01.01/01.04/01.07/01.10 ognuna 25% del totale del preventivo). Ai fini della creazione del bilancio consuntivo, il sistema deve: • riportare tutti i capitoli e sub-capitoli di spesa inseriti in preventivo, con le relative tabelle millesimali associate e con i campi in cui sono stati inseriti gli importi previsti a zero, in quanto, in questo bilancio, devono essere inserite le spese effettivamente sostenute. Il sistema deve riportare di default in consuntivo quanto già inserito nel preventivo, mantenendo comunque la possibilità di modificare il suddetto consuntivo (ad esempio, nel caso in cui si dovessero presentare delle spese che non erano state previste al momento della stesura del bilancio di previsione); • permettere l’inserimento delle spese: all’interno di ogni sub-capitolo deve essere possibile registrare le fatture correlate ad esso. Al momento della registrazione della spesa l’utente deve poter inserire il numero e la data del documento, i dati del fornitore che l’ha emesso, la descrizione della spesa e l’importo, che può essere in positivo (fatture) o in negativo (note di credito) oltre che lo stato del pagamento (pagata/da pagare). Esempio di inserimento bolletta luce: capitolo utenze, sub-capitolo luce, opzione “inserimento nuova spesa” Fattura numero xxxx del yyyy fornitore zzzz descrizione “spese luce mese di gennaio 2019” importo euro 200,00. Si sottolinea che il sistema deve permettere di inserire un numero illimitato di fatture/bollette. Entrambi i bilanci devono poter essere modificati/integrati in qualsiasi momento. Ogni sub-capitolo di spesa deve avere inoltre un campo in cui sia possibile inserire una percentuale e un campo in cui si possa selezionare la voce proprietario o inquilino ai fini dell’imputazione della voce di spesa (es. 100% sulla proprietà, 50% sulla proprietà, 100% sull’inquilino). Oltre all’associazione dei capitoli di spesa alle tabelle millesimali, deve essere possibile inserire, sia in fase di previsione che di rendicontazione, una voce che riguarda le spese individuali, ossia un capitolo in cui si andranno a registrare le spese imputabili ad una o solo ad alcune unità immobiliari. Al momento della creazione della spesa l’utente deve essere in grado di inserire l’ammontare totale della stessa e la relativa imputazione all’/agli inquilino/i. Per garantire questo deve esistere un campo “dettaglio addebiti” che, quando selezionato, proponga tutto l’elenco delle unità immobiliari inserite nell’anagrafe del condominio. Da tale elenco l’utente deve poter selezionare uno o più nominativi, inserendo la relativa cifra da imputare ad ognuno di essi. Esempio: nel capitolo “Spese individuali” viene inserita la spesa “tinteggiatura balconi” il cui totale ammonta ad euro 300,00. Si consideri che tale intervento riguardi soltanto 3 unità immobiliari su un totale di 10. L’utente deve poter registrare, nel campo di inserimento della fattura, la spesa integrale e nel campo “dettaglio addebiti” selezionare, da elenco, gli appartamenti a cui imputare la spesa e il relativo importo. Il sistema deve permettere l’inserimento e la gestione delle seguenti tipologie di documenti contabili: • canoni di locazione, scadenze, rinnovi, disdette, verbali di condivisione, verbali di rilascio/modifica aree (metri quadri) di utilizzo per le sedi istituzionali utilizzate in condivisione; • registrazione subentri in modo da mantenere le anagrafiche aggiornate |
senza perdere traccia degli occupanti precedenti; • spese di varia natura (utenze, manutenzioni, assicurazioni,…) per finalità di rendicontazione; • bilanci sia preventivi che consuntivi. |
GES4 | Ripartizione Spese |
Il sistema deve permettere la ripartizione delle spese inserite sulle singole unità immobiliari, con possibilità di raggruppare i costi per nominativo o divise per dato catastale. Elaborando i dati inseriti sia a preventivo che a consuntivo, il sistema deve ripartire in automatico le spese su tutte le unità immobiliari presenti nell’anagrafe del singolo immobile/condominio, incrociando i seguenti dati: • Importo totale dei singoli capitoli; • Tabelle millesimali; • Importi addebitati ad personam nella sezione spese individuali; • Percentuali di ripartizione proprietario/inquilino inserite in bilancio; • Percentuali di ripartizione del totale del preventivo. |
GES5 | Calcolo dei Canoni |
Il sistema deve permettere l’inserimento dei valori del canone puro, ISTAT (in modalità manuale, senza necessità di interfacciamento con la rete per recepire il valore dell’adeguamento), delle spese condominiali, conguagli anni precedenti, ai fini del calcolo dei canoni da emettere. Oltre alla redazione dei bilanci, il sistema deve prevedere un’ulteriore sezione dedicata all’inserimento degli importi dei canoni di locazione: il sistema deve proporre l’elenco di tutte le unità immobiliari inserite, alle quali l’utente possa attribuire manualmente l’importo del canone annuo e la percentuale di rivalutazione secondo i parametri ISTAT. È necessario che, sulla base di questi dati, il sistema calcoli il nuovo canone applicando l’adeguamento, in modo tale che vi sia: • ripartizione del canone annuo da contratto di locazione (inserimento manuale del canone annuale di locazione e suddivisione automatica per trimestri); • riparametrazione degli oneri accessori (spese condominiali) a carico del singolo inquilino con rimando alle spese condominiali dell’interno immobile; • calcolo dell’importo degli avvisi di pagamento complessivo da emettere (nominativo inquilino, canone annuo da contratto, oneri accessori, conguagli, aggiornamento ISTAT, spese bancarie, causale da inserire negli avvisi di pagamento) con possibilità di inserire delle note in un campo note apposito; • alert automatico per emissione degli avvisi di pagamento; • alert automatico per rinnovi, disdette e scadenze; • verifica della regolarità dei pagamenti. Si sottolinea che le specifiche di ogni contratto di locazione devono poter essere gestite sia per unità immobiliare (subalterno) sia per nominativo (titolare del contratto) con la possibilità di estrarre report della singola posizione e/o relativo all’intero edificio. |
GES6 | Avvisi di Pagamento |
Il sistema deve permettere la predisposizione di avvisi di pagamento; il sistema deve |
essere predisposto per una prossima integrazione tramite servizi web con il Portale dei Pagamenti di ATS, integrato nel portale web di ATS e di prossima attivazione, per consentire anche la modalità di pagamento elettronica tramite pagoPA. Il sistema deve essere predisposto pertanto per la trasmissione degli avvisi di pagamento pagoPA sia per posta elettronica che per posta tradizionale cartacea (raccomandata A/R) interfacciandosi con un sistema di postalizzazione esterno. Le eventuali spese di spedizione devono rientrare in quelle da contabilizzare. Il sistema deve permettere la predisposizione di avvisi di pagamento da trasmettere al Portale dei Pagamenti di ATS affinché a sua volta li trasmetta alla Ragioneria per la predisposizione (attraverso Banca Tesoreria) degli avvisi di pagamento da inviare agli inquilini. Gli avvisi devono riportare il nominativo/ragione sociale dell’inquilino, l’indirizzo di spedizione, l’importo da pagare dettagliato (come indicato nel terzo punto di elenco del requisito funzionale GES5, la causale di riferimento (es. I rata anno 2019) e la scadenza. Nel caso di pagamento tramite pagoPA la determinazione del codice IUV è in carico al Portale dei Pagamenti di ATS. |
GES7 | Calcolo Scadenze |
Il sistema deve permettere la ripartizione dei bilanci e dei canoni da richiedere agli inquilini con possibilità di inserire manualmente le scadenze. Il sistema deve prevedere la possibilità di impostare alert automatici (anche multipli rispetto alla medesima scadenza) per: • scadenza avvisi di pagamento; • scadenze contratti; • scadenze certificazioni energetiche; • scadenze certificazioni degli impianti; • ogni altra scadenza che possa essere impostata dall’utilizzatore del sistema. |
GES8 | Registrazione Incassi |
Il sistema deve permettere la registrazione degli incassi tramite una sezione incassi, nella quale verranno riportate tutte le unità immobiliari inserite in anagrafe e, per ognuna di esse, le rate attribuite, sia per quanto riguarda le spese condominiali (attingendo dagli importi inseriti nel bilancio preventivo), sia per quanto riguarda i canoni di locazione (attingendo alla sezione dedicata all’inserimento dei canoni), con le relative scadenze. Nel campo di registrazione dell’incasso deve essere possibile inserire la data del pagamento e l’importo versato. Nel caso di pagamenti elettronici effettuati tramite pagoPA (fare riferimento a quanto indicato al requisito GES6 “Avvisi di pagamento”), la riconciliazione dei pagamenti e la verifica dei dovuti deve essere effettuata attraverso l’integrazione con il Portale dei Pagamenti di ATS, integrato nel sito web istituzionale di ATS e di prossima attivazione: in questo caso il sistema deve essere predisposto per l’interfacciamento tramite servizi web con tale Portale dei Pagamenti che a sua volta ha in carico l’interfacciamento con i servizi di Ragioneria di ATS per quanto concerne i pagamenti elettronici all’Ente tramite il circuito pagoPA. Nel caso di pagamenti elettronici effettuati tramite avvisi di pagamento, la riconciliazione dei pagamenti e la verifica dei dovuti deve essere effettuata attraverso l’integrazione con il Portale dei Pagamenti di ATS: anche in questo caso il sistema deve essere predisposto per l’interfacciamento tramite servizi web con tale Portale dei Pagamenti che a sua volta ha in carico l’interfacciamento con i servizi di Ragioneria di ATS per quanto concerne i pagamenti all’Ente tramite avvisi di pagamento. |
Il sistema, tramite opportuna sezione, deve pertanto permettere la consultazione dello stato dei pagamenti attraverso molteplici criteri di ricerca e filtro dei dati. |
GES9 | Ripartizione Costi |
Il sistema deve permettere l’inserimento dei criteri e delle percentuali ai fini delle ripartizione dei costi proprietario/inquilino. |
3.4 Reportistica
REP1 | Report |
Tutti i documenti di reportistica che verranno creati dal sistema devono poter includere dati selezionabili apponendo dei flag relativi alle voci sottostanti (imputabili e aggiornabili dall’utente tramite appositi campi): • data e luogo di produzione del documento; • logo dell’Ente; • denominazione dell’Ente, ragione sociale, indirizzo, codice fiscale e partita IVA; • denominazione dell’ufficio che produce il report; • eventuale indirizzo di recapito, nel caso in cui il report rappresenti un documento in uscita; • campo firma in cui sia possibile indicare il nominativo di chi firmerà il documento. Il sistema deve permettere di modificare la formattazione dei report, di produrne un’anteprima ed esportarli in: • versione editabile (Word, Excel); • versione PDF. I dati che si intendono estrapolare, ove non diversamente specificato, devono essere restituiti in formato tabellare. Si sottolinea che l’appalto cui si riferisce il presente Capitolato Tecnico deve includere la predisposizione report, programmati e formattati dal Fornitore secondo le indicazioni che verranno fornite dal personale della UOC Gestione Patrimonio e Progetti di Investimento di ATS. Si riporta l’elenco di tali report: • Canoni e Spese: per ogni condominio/edificio deve essere possibile estrarre, per singole o più unità immobiliari, l’importo del solo canone, delle sole spese condominiali o di entrambi. Tale estrapolazione deve poter essere fatta per singolo/gruppo di subalterni o per singolo/gruppo di nominativi degli inquilini. • Morosità Inquilini: elenco degli inquilini morosi in base ai dati che verranno inseriti nella sezione incassi. • Bilanci preventivi e bilanci consuntivi: bilanci preventivi e consuntivi, con le voci divise per capitoli e sub-capitoli di spesa e/o con i soli totali dei capitoli. • Ripartizioni dei preventivi e ripartizioni dei consuntivi: estrazione delle ripartizioni del preventivo e consuntivo in base a criteri di ripartizione impostati (es. percentuali, tabelle millesimali). In caso di inquilini occupanti più unità immobiliari deve essere possibile stabilire se nel report i dati contabili relativi allo stesso debbano essere restituiti scissi per unità immobiliare o cumulativi, raggruppati su tutte le unità immobiliari utilizzate dal medesimo soggetto. • Prospetto delle Rate: il prospetto delle rate, di uno o più inquilini, raggruppato per annualità o diviso secondo le scadenze impostate nel bilancio. • Introiti e Morosità per unità immobiliare: per le posizioni attive, creazione di un report che individui l’importo della rata emessa e l’incasso registrato, al fine di monitorare gli introiti/morosità degli appartamenti. |
• Fascicolo dell’Immobile e Compliance Tecnico-Amministrativa: report degli adempimenti tecnico-amministrativi (es. certificazioni energetiche, pratiche di prevenzione incendi, …) in scadenza e/o da rinnovare, individuabili per singolo edifico o per più edifici. • Anagrafica della singola unità immobiliare: estrazione layout da Autocad e anagrafica unità (indicazione di dove si trova, chi la occupa, a che titolo la occupa, planimetria catastale, storico manutenzioni, …). • Contratti Immobiliari: report per tipologia di contratto (contratti di locazione, comodati, convenzioni, …) con rimando all’inquilino ivi abitante e alla sua posizione contabile. • Avvisi di pagamento: estrazione avvisi di pagamento per intero edificio, singolo nominativo, singola unità immobiliare. • Posizione contabile: report della posizione contabile per singolo subalterno oppure per intero edificio (somma di canoni, somma di spese, morosità, …) in un arco temporale definito. • Stato manutentivo: report relativo al numero di manutenzioni effettuate sulle unità immobiliari e tipologia (numero di interventi per singola unità immobiliare/edificio e rimando ai flussi contabili in entrata e in uscita). • Planimetria di azzonamento degli immobili: report che consenta di: o filtrare gli immobili presenti in database secondo una pluralità di criteri; o selezionare l’area territoriale da includere nella stampa; o selezionare se includere una tabella a margine con eventuali dati già presenti a sistema (come ad esempio: indirizzo, proprietà, …); o selezionare le colonne da includere nella suddetta tabella; o selezionare il formato di stampa (devono essere inclusi tutti i formati carta UNI, almeno A4, A3, A2 e A0, con la possibilità di creare un formato carta personalizzato); o esportare un file, risultante dalle suddette configurazioni, in formato standard (almeno in: PDF, PNG, JPG, principali formati GIS). |
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) |
Al fine di rendere più efficaci le comunicazioni tra ATS e Fornitore, 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, il Fornitore 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. |
4.2 Requisiti di security
SEC1 | Sicurezza logica, fisica e organizzativa |
Dato il grado di confidenzialità delle informazioni gestite dal sistema, il Fornitore 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. |
SEC2 | Privacy |
Fare riferimento alla normativa sulla privacy secondo quanto riportato al capitolo “Riferimenti documentali e normativi” del presente documento. Il Fornitore sarà designato come Responsabile Esterno al trattamento dei dati. |
SEC3 | GDPR (General Data Protection Regulation) – Regolamento UE 2016/679 |
Le prestazioni oggetto della presente fornitura dovranno essere conformi al nuovo Regolamento Generale sulla Protezione dei Dati (GDPR, General Data Protection Regulation – Regolamento UE 2016/679). In linea con i principi del GDPR (privacy by design, privacy by default), le modalità di accesso alle basi dati in generale devono prevedere un livello minimo di accesso ai dati; data la impossibilità di procedere all’anonimizzazione dei dati personali e sensibili, nella gestione e trasmissione dei dati personali e sensibili si rende necessaria l’applicazione delle cosiddette tecniche di “pseudonimizzazione” (tabelle associative, meccanismi crittografici, …). |
SEC4 | Protocollo HTTPS |
Il software applicativo, oggetto della fornitura, dovrà essere fruibile dai client |
esclusivamente mediante protocollo HTTPS. Il Fornitore 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 pubblicamente riconosciuta ed intestato ad ATS. |
SEC5 | Accordi di Non Divulgazione (NDA) e di Trattamento dei Dati (DPA) |
Il Fornitore 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. Il Fornitore 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à. |
SEC6 | Audit e Monitoraggio |
ATS si riserva la facoltà di sottoporre ad audit e monitoraggio tutte le attività del servizio e in particolare relative al trattamento delle informazioni sensibili effettuate dal Fornitore e dal personale di cui esso intende avvalersi, per tutta la durata del contratto di fornitura. |
4.3 Requisiti e vincoli tecnologici e infrastrutturali
TEC1 | Accesso web |
Le funzionalità messe a disposizione dal sistema dovranno essere raggiungibili dagli utenti, sia interni che esterni ad ATS, attraverso l’accesso alla rete Internet, col solo utilizzo di un browser, senza limitazioni di accessi concorrenti. L’accesso web deve essere possibile senza dover installare componenti esterni (plug- in). Lato client, il sistema deve essere conforme alle normative nazionali in tema di accessibilità dei sistemi informatici. L’applicazione deve poter essere utilizzata anche in mobilità, attraverso tablet e smartphone. |
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 la corretta rappresentazione dei contenuti da parte dei motori di rendering utilizzati. Più nel dettaglio, a seconda del dispositivo operativo utilizzato dall’utente, dovrà essere garantita la compatibilità con i seguenti sistemi operativi e browser: • piattaforma desktop: Windows, OS X, Linux; • piattaforma mobile: IOS e Android; • Internet Explorer, Mozilla Firefox, Edge, Chrome; nelle versioni che i rispettivi vendor garantiranno dal punto di vista del supporto per tutto il periodo della validità contrattuale del presente capitolato. Per una rapida visualizzazione delle pagine web, il sistema dovrà garantire un peso |
pagina web ottimizzato dal punto di vista della dimensione. La presentazione delle pagine web dovrà essere realizzata in HTML5. |
TEC3 | Infrastruttura applicativa e scalabilità |
Il Fornitore 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 scalabile nella quantità di dati inseriti mantenendo prestazioni inalterate. |
TEC4 | Evoluzioni tecnologiche |
Il Fornitore dovrà garantire l’adeguamento del sistema informativo oggetto del presente capitolato anche rispetto a nuove versioni ed aggiornamenti del software open source utilizzato, di browser, sistemi operativi, software di base, middleware che i vari vendor dovessero rilasciare per tutto il periodo di validità contrattuale. |
TEC5 | Identificazione & Autenticazione degli utenti |
Il sistema dovrà utilizzare le seguenti soluzioni tecnologiche di I&A: • Microsoft Azure Active Directory (conforme alla normativa di sicurezza GDPR) per gli utenti interni ad ATS e per gli utenti amministratori (sia essi interni ad ATS che del Fornitore); l’accesso dovrà essere possibile in SSO (Single Sign On); • database relazionale, interno alla soluzione applicativa, dedicato agli utenti esterni ad ATS. |
TEC6 | Integrazione con strumenti documentali aziendali |
Il sistema dovrà permettere l’archiviazione di tutti i file caricati anche attraverso l’integrazione con Microsoft SharePoint, il sistema CMS (Content Management System) adottato da ATS, compatibile con lo standard CMIS (Content Management Interoperability Services). La consultazione dei documenti depositati in SharePoint dal sistema è subordinata ad una gestione dei privilegi utente a cura dell’amministratore del CMS. |
TEC7 | Caricamento dei documenti |
Il sistema deve permettere il caricamento di documenti nei formati più diffusi, comprendendo anche file firmati digitalmente e cartelle compresse. Tutti i file di produzione “esterna” del software (ad esempio: report, tabelle, fogli di calcolo, …) dovranno essere compatibili con i software open source più in uso (ad esempio: Open Office) nella versione più aggiornata disponibile. |
TEC8 | Integrazione con strumenti CAD aziendali |
Il sistema dovrà garantire l’integrazione con l’applicazione AutoCAD di Autodesk per permettere il caricamento e l’aggiornamento automatico o semiautomatico dei file |
in formato DWG. Il sistema dovrà includere eventuali moduli per la conversione dal formato DWG al formato vettoriale (Shape). |
4.4 Requisiti normativi
REG1 | Normative edilizie |
Il sistema dovrà consentire la gestione del fascicolo dell’immobile in conformità con le seguenti normative edilizie: • Circolare n.16063 del 09/07/2010 “Linee guida generali per la costituzione di un fascicolo immobiliare”. • Regolamento edilizio del Comune di Milano. • Altre normative vigenti in materia edilizia. |
REG2 | Hosting dei servizi cloud |
Con riferimento alle due circolari AgID n. 2 e n. 3 del 9 aprile 2018, l’acquisizione dei servizi in hosting dovrà soddisfare quanto indicato: “A decorrere dal 1 aprile 2019, le Amministrazioni Pubbliche potranno acquisire esclusivamente servizi IaaS, PaaS e SaaS qualificati da AgID e pubblicati nel Cloud Marketplace” (xxxxx://xxxxx.xxxxxx.xx/xxxxxxxxxxx/xxxxxxxx/xxxxxx/xxxxx.xxxx). |
4.5 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. |
USA2 | Interfacce Help-On-Line |
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. |
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. |
6 Progettazione, realizzazione e delivery
Il Fornitore è responsabile delle attività di progettazione, realizzazione e messa in esercizio del sistema informativo oggetto del presente Capitolato Tecnico. Sono comprese nella fornitura tutte le attività relative alla predisposizione degli ambienti in cloud SaaS e di deployment del software negli ambienti operativi previsti (collaudo, produzione).
Il progetto esecutivo del Fornitore deve 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, dalla progettazione, allo sviluppo, alla manutenzione del sistema in esercizio.
ATS intende cooperare con il Fornitore per garantire il corretto andamento ed avanzamento delle attività di progettazione e di realizzazione del sistema informativo.
Nel suo ruolo di responsabilità del contratto e di gestione del rapporto di fornitura, si richiede al Fornitore la massima trasparenza e tracciabilità delle attività svolte in tutte le fasi del progetto, nel rispetto degli obiettivi e dei vincoli contrattuali previsti. A questo proposito il progetto esecutivo del Fornitore deve definire le modalità, le fasi e le date (milestone) di condivisione con ATS dei previsti deliverable di progetto.
La gestione del progetto da parte del Fornitore deve consentire ad ATS di disporre e verificare la documentazione di progetto comprendente la pianificazione di dettaglio (piano di progetto, piano di qualità), i documenti di analisi funzionale di dettaglio (comprendente il disegno dei mockup delle UI) e di specifica architetturale (comprendente le modalità di realizzazione delle integrazioni applicative), la strategia di integrazione e di test, la documentazione di collaudo, la strategia di importazione dei dati documentali preesistenti, la manualistica operativa da utilizzare anche nel corso delle attività di formazione dell’utenza di ATS.
Anche in fase di manutenzione, correttiva o evolutiva, il Fornitore è tenuto a produrre l’analisi dell’intervento richiesto ed alla determinazione dell’effort tecnico secondo la metrica dei Function Point adottata da ATS.
Sono da considerarsi inclusi nella prestazione oggetto del presente Capitolato Tecnico e non oggetto di ulteriori spettanze da parte del Fornitore, tutti gli oneri e gli adempimenti da sostenere per la progettazione e lo sviluppo del sistema nella sua globalità ed in particolare per le attività legate alla reportistica. A titolo puramente esemplificativo e non esaustivo devono considerarsi incluse a corpo tutte le seguenti attività:
• riunioni e comunicazioni tramite posta elettronica in particolare per la definizione dei format dei report previsti a capitolato (fare riferimento al requisito funzionale REP1 “Report”);
• preparazione prototipi, mockup di interfacce grafiche, bozze di report e relative revisioni, integrazioni e/o modifiche secondo quanto richiesto da ATS.
7 Formazione utenti
Il servizio deve comprendere la formazione all’utilizzo del sistema dedicato agli utilizzatori interni ad ATS.
La formazione dovrà consistere in almeno 5 giornate. La formazione potrà essere fruita anche tramite mezze giornate. L’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.
L’attività formativa dovrà essere pianificata in accordo con ATS in modo da non intralciare,
rallentare o impedire la normale operatività degli utenti coinvolti.
Il Fornitore dovrà mettere a disposizione di ATS un'attività di assistenza continuativa nelle fasi di avvio del sistema per tutti gli operatori impegnati sul campo.
A supporto degli utenti del sistema, il Fornitore deve prevedere la produzione, la consegna, il mantenimento di un’adeguata documentazione tecnica ed operativa, in generale di tutto quanto, anche successivamente, si rendesse necessario produrre per documentare modifiche e/o adeguamenti al sistema in esercizio. In particolare devono essere resi 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.
• Documento Tecnico di Dettaglio, contenente tutte le informazioni tecniche di dettaglio relative al sistema ed alla propria base dati.
La documentazione tecnica, utente e 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.
8 Collaudo e Avviamento
Il sistema oggetto del presente Capitolato Tecnico è vincolato al superamento di una opportuna procedura di collaudo, condivisa con ATS, prima dell’effettiva accettazione e quindi del rilascio in produzione.
Tutte le funzionalità richieste da ATS nel presente Capitolato Tecnico ed in particolare quanto previsto per la reportistica (requisito funzionale REP1) devono essere sviluppate necessariamente prima del collaudo del sistema da parte dei competenti uffici di ATS.
Il collaudo deve essere effettuato in un ambiente di test dedicato il più vicino possibile, in termini di risorse cloud, a quello di produzione. In collaudo verranno utilizzate postazioni client coerenti con quanto previsto dal Contratto d’Appalto.
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.
Ogni eventuale modifica all’ambiente di utilizzo (software d’ambiente, patch, …) è soggetta anch’essa a specifiche procedure di verifica onde garantire la non regressione delle funzionalità applicative.
Prima di eventuali sessioni di pre-collaudo e delle effettive sessioni di collaudo, il Fornitore è tenuto a presentare un’opportuna documentazione (check list di collaudo) soggetta ad eventuali integrazioni ed alla accettazione finale da parte di ATS.
In caso di inadempimenti del Fornitore 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. Ogni procedura di collaudo deve essere completata con esito positivo entro 30 giorni solari dall’avvio della specifica procedura di collaudo. La mancata osservanza di tali vincoli temporali comporterà la risoluzione del contratto, oltre all’applicazione delle penalità previste.
Si sottolinea che il Fornitore è tenuto a consegnare ad ATS, preventivamente alle procedure di collaudo, una specifica documentazione (test list e test report funzionali) che dia evidenza dell’adeguata copertura delle funzionalità e del buon esito delle verifiche funzionali effettuate internamente durante lo sviluppo del sistema. Dalle verifiche funzionali previste verranno selezionati gli scenari di collaudo.
Durante il collaudo e/o gli eventuali pre-collaudi saranno verificate punto per punto tutte le funzionalità indicate nelle procedure stesse (check list collaudo) condivise con ATS. Al termine delle fasi di collaudo sarà redatto un verbale corredato da un opportuno documento (test report di collaudo) attestante l'esito delle verifiche effettuate.
Nel caso in cui una o più specifiche funzionali, non funzionali e tecniche o altri aspetti rilevanti della Fornitura inclusi nel presente capitolato e/o eventualmente forniti come requisiti migliorativi dal Fornitore non superino il collaudo (requisito non implementato o con gravi mancanze), il collaudo terminerà con esito negativo.
Nel caso 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 e 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 un ulteriore collaudo da parte di ATS.
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 del sistema, interni ed esterni ad ATS. La messa in esercizio del sistema è quindi vincolata al completamento delle seguenti attività:
• predisposizione dei database interni del sistema (import di anagrafiche, …) e importazione
dei dati documentali preesistenti;
• sessioni di formazione per le diverse tipologie di utenti, secondo un piano condiviso con ATS.
Una volta rilasciato il sistema in esercizio, ATS si riserva la facoltà di monitorare il corretto funzionamento del sistema in produzione per un per periodo di due mesi (fase di avvio) per valutare l’affidabilità e la maturità del software.
9 Servizi di assistenza e manutenzione
Il Fornitore è tenuto a garantire, per tutta la durata del periodo contrattuale, la manutenzione e
l’assistenza del sistema tale da assicurare la continuità operativa dell’applicativo.
9.1 Manutenzione correttiva ed assistenza
Il servizio di manutenzione correttiva includerà:
• la correzione di difetti del prodotto software emersi a seguito di malfunzionamenti rilevati durante l'esercizio o individuati anche autonomamente dal Fornitore;
• il rilascio di nuove release del prodotto.
L’individuazione e la correzione di eventuali anomalie devono essere estese a tutto il software preesistente ed alle sue modifiche correttive ed evolutive, escludendo potenziali regressioni, funzionali e non, che possano impattare le funzionalità e le performance dell’applicativo in produzione.
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.
Il servizio di assistenza includerà:
• un servizio di help desk di secondo livello attivabile direttamente dall’Ufficio preposto dell’ATS o attraverso i servizi di help desk di primo livello della 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 “Livelli di servizio minimi richiesti e criteri di misura”.
La fornitura di manutenzione correttiva e assistenza dovrà comprendere:
• la mano d’opera (illimitata);
• l'assistenza telefonica (illimitata);
• la teleassistenza (illimitata);
• eventuali costi di trasferta del personale del Fornitore o di suo consulente di cui vorrà avvalersi.
L’aggiudicatario dovrà fornire ad ATS idonee e chiare istruzioni operative per l'attivazione del
servizio.
Gli interventi dovranno potersi effettuare sia in loco che a distanza, anche in teleassistenza.
Il Fornitore 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.
La manutenzione correttiva dell'applicazione software e assistenza si applica negli stessi termini anche alle integrazioni realizzate con altri sistemi.
L’aggiudicatario è tenuto a dare evidenza ad ATS, attraverso il buon esito delle procedure di collaudo, di ogni modifica correttiva apportata all’applicazione. Le procedure di collaudo dovranno essere sempre preventivamente condivise e approvate da ATS.
9.2 Manutenzione evolutiva
Non essendo identificabili a priori gli interventi evolutivi determinati da necessità non comprese nelle specifiche iniziali del presente Capitolato Tecnico, 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’operatore economico un “pacchetto” di giornate- uomo, da utilizzarsi “a consumo” ovvero l’utilizzo di giornate o anche mezze giornate di attività per lo sviluppo di tali interventi evolutivi.
Il pacchetto di giornate-uomo richiesto è stimato fino ad un massimo di 10 giornate/uomo all’anno anche in 20 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 di un documento tecnico, redatto dal Fornitore, che dia evidenza delle attività effettivamente previste.
Il prezzo del “pacchetto” deve comprendere:
• le attività di analisi e sviluppo degli adeguamenti richiesti con la fornitura delle professionalità necessarie;
• la documentazione tecnica e operativa, eventualmente attraverso l’integrazione della documentazione già rilasciata dall’aggiudicatario;
• gli eventuali costi di trasferta del personale dell’aggiudicatario da garantire in caso di esplicita richiesta da parte di ATS.
Lo sviluppo delle modifiche dovrà essere validato sulla base di specifiche di collaudo concordate con ATS. Si ribadisce che ogni intervento evolutivo deve essere sempre preventivamente approvato da ATS sulla base di un documento tecnico di dettaglio dell’aggiudicatario, comprendente la valutazione dell’impegno richiesto secondo la metrica dei Function Point. In base alla documentazione prodotta, ATS effettuerà una valutazione indipendente dell’impegno richiesto per valutare l’adeguatezza dell’impegno economico.
A seguito del rilascio in produzione, una modifica o nuova funzionalità diventa parte integrante dell'applicazione software e ad essa si applica quanto definito nelle restanti parti del contratto.
10 Consegna della soluzione e conclusione contrattuale
La durata nominale del contratto previsto dalla presente fornitura è di 60 mesi a partire dalla data di sottoscrizione del contratto. L’opzione di cui all’art. 106, comma 11, del D. Lgs. 50/2016 è disciplinata dall’art. 2 del Capitolato Speciale d’Appalto.
Il Fornitore è tenuto a consegnare e a collaudare la soluzione in tutte le parti specificate nel presente Capitolato Tecnico entro un massimo di 180 giorni solari dalla data di sottoscrizione del contratto. Ogni procedura di collaudo deve essere completata con esito positivo entro 30 giorni solari dall’avvio della specifica procedura di collaudo. La mancata osservanza di tali vincoli temporali comporterà la risoluzione del contratto, oltre all’applicazione delle penalità previste.
Si precisa che il servizio di manutenzione correttiva comprende un periodo di garanzia di 12 mesi a partire dalla data di avvio del sistema in produzione; il servizio di manutenzione correttiva proseguirà, dopo il periodo di garanzia, fino alla decorrenza dei 60 mesi del contratto. Pertanto, il corrispettivo per il servizio di manutenzione correttiva verrà riconosciuto al Fornitore soltanto allo scadere del periodo di garanzia.
Il Fornitore dovrà garantire ad ATS un adeguato passaggio di consegne alla conclusione naturale del contratto. Le stesse modalità dovranno essere assicurate dall’aggiudicatario in caso di eventuale conclusione anticipata del servizio.
In linea con la normativa vigente, in particolare con le circolari AgID n.2 e n. 3 del 9 aprile 2018 e relativi allegati (fare riferimento al capitolo “Riferimenti documentali e normativi” del presente documento), il Fornitore deve consentire la migrazione del servizio verso un altro Fornitore SaaS, con conseguente eliminazione permanente dei propri dati al termine del contratto.
11 Livelli di servizio minimi richiesti e criteri di misura
Per il servizio di manutenzione correttiva ed assistenza sono di seguito identificati gli SLA minimi.
Ogni SLA è identificato da una o più misure. Per “ore/giorni” s'intende “ore/giorni lavorativi”.
Per "tempo di presa in carico" si intende il tempo intercorrente dal momento di emissione della richiesta al momento della comunicazione di avvenuta apertura di un ticket.
Per "tempo di risoluzione" si intende il tempo intercorrente dal momento di apertura di un ticket al momento di soluzione della richiesta con esito positivo e conseguente chiusura del ticket.
Servizio manutenzione correttiva e assistenza:
• Malfunzionamento bloccante:
Tempo massimo di presa in carico in: 1 ora
Tempo massimo di risoluzione: 7 ore
• Malfunzionamento non bloccante: Tempo massimo di presa in carico: 8 ore Tempo massimo di risoluzione: 60 ore
In mancanza di un'indicazione sulla priorità, le richieste saranno trattate come aventi priorità non bloccante.
Il Fornitore dovrà garantire il servizio di manutenzione ed assistenza 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 guasto;
• verifica dell’esecuzione dell’intervento riparatore e registrazione della conclusione.
12 Riferimenti documentali e normativi
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. Circolare AgID n. 2 del 9 aprile 2018, “Criteri per la qualificazione dei Cloud Service Provider per la PA”. Circolare AgID n. 3 del 9 aprile 2018, “Criteri per la qualificazione di servizi SaaS per il Cloud della PA”. |
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) 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 |
Normative edilizie | Circolare n.16063 del 09/07/2010 “Valorizzazione immobili pubblici. Linee guida generali per la costituzione di un fascicolo immobiliare”. Regolamento edilizio vigente del Comune di Milano. |
Proprietà intellettuale | L. 633/41 (“Protezione del diritto d'autore e di altri diritti connessi al suo esercizio”) |
AgID | Linee Guida su acquisizione e riuso di software per le Pubbliche Amministrazioni. Release Finale, 15 maggio 2019, e s.m.i. Allegato A delle suddette linee guida: Guida alla pubblicazione di software come open source. |