Software per comuni ed enti pubblici: prima si guarda che cosa esiste già
Il Codice dell’amministrazione digitale vi chiede di confrontare le strade prima di far scrivere un software nuovo, e di restare titolari di quello sviluppato apposta per voi. Il codice che scriviamo su misura per un ente è dell’ente.
Che cosa deve sapere un comune o un ente pubblico prima di far sviluppare un software?
Prima si confrontano le strade, come chiede l’articolo 68 del Codice dell’amministrazione digitale: riuso, software libero, cloud, licenze, sviluppo nuovo. Se si sviluppa, le specifiche di progetto devono dare all’ente la titolarità dei diritti, salvo oneri eccessivi comprovati, e di regola il codice va reso disponibile con licenza aperta. Poi, secondo la classe ACN dei dati, si sceglie dove installarlo.
Prima di far scrivere un software nuovo: la valutazione comparativa
Per acquisire un programma, l’articolo 68 del Codice dell’amministrazione digitale (decreto legislativo 82/2005) chiede al vostro ente una valutazione comparativa, tecnica ed economica, fra sei strade: un software sviluppato per conto dell’amministrazione, il riuso di uno già sviluppato per un’altra, il software libero o a codice aperto (open source), un servizio in cloud, un prodotto con licenza d’uso, o una combinazione di queste.
I criteri stanno nella stessa norma. Si guarda il costo complessivo, cioè acquisto, messa in opera, manutenzione e supporto. Si guarda quanto il software usa formati e interfacce aperti, e se coopera con gli altri sistemi della pubblica amministrazione. E si guardano le garanzie del fornitore su sicurezza, protezione dei dati personali e livelli di servizio.
La norma mette anche un limite. Un prodotto proprietario con licenza d’uso si può acquistare solo se dalla valutazione risulta, con una motivazione, che mancano soluzioni già disponibili nella pubblica amministrazione, o a codice aperto, adatte a quello che vi serve.
Le Linee guida dell’AgID su acquisizione e riuso del software suggeriscono di cominciare da un documento descrittivo delle esigenze, con i bisogni e i vincoli del vostro ente. Poi dicono dove cercare: prima nel catalogo di Developers Italia, dove le amministrazioni pubblicano il software che altre possono riusare, poi nel software a codice aperto di terzi. Le licenze e lo sviluppo nuovo si guardano dopo, se lì manca una soluzione adatta.
L’articolo 69: di chi è il codice, e dove si pubblica
L’articolo 69 del Codice chiede di scrivere nelle specifiche di progetto che l’amministrazione è titolare di tutti i diritti sul software sviluppato apposta per lei, salvo che risulti eccessivamente oneroso per ragioni tecniche ed economiche comprovate. Da noi il codice di un software scritto su misura per il vostro ente è del vostro ente: è di chi ha pagato il lavoro, con la documentazione e gli ambienti.
Il comma 1 aggiunge un obbligo per l’amministrazione titolare: rendere disponibile il codice sorgente, completo della documentazione, in un repertorio pubblico e con una licenza aperta, in uso gratuito ad altre pubbliche amministrazioni o ai soggetti giuridici che vogliano adattarlo. Fanno eccezione solo motivate ragioni di ordine e sicurezza pubblica, difesa nazionale e consultazioni elettorali.
Le Linee guida AgID consigliano di sviluppare direttamente sulla piattaforma dove pubblicherete il codice, dall’inizio della progettazione. Il file publiccode.yml descrive il software, e da lì Developers Italia ricava la sua scheda nel catalogo.
Dove si scrive il codice, sulla vostra piattaforma dal primo giorno o con un rilascio al termine del lavoro, lo concordiamo prima di cominciare.
Un software nostro già in uso in un ente pubblico
Trascrive le riunioni dal vivo e in differita, distingue chi parla e manda il testo ai partecipanti. Gira sull’infrastruttura dell’ente, riconoscimento vocale compreso, e fra la registrazione e il testo non passa nessun servizio di terzi.
L’abbiamo scritto in due mesi, con tre persone. Lo possono avere anche altri enti, nella forma adatta a ciascuno.
Se prendete un software a riuso
Se nel catalogo di Developers Italia c’è un software che fa quasi tutto quello che vi serve, il vostro ente lo può prendere a riuso e farlo adattare, senza chiedere un’autorizzazione a chi ne è titolare. L’allegato D delle Linee guida AgID dice chi può fare il lavoro per conto dell’ente: le sue persone, una sua società in-house o un fornitore che l’ente sceglie.
Le modifiche ricadono nell’articolo 69, come il software sviluppato apposta: l’ente acquisisce la titolarità di quello che fa aggiungere, e lo rilascia con licenza aperta. Prima di sviluppare funzioni nuove si prende contatto con chi mantiene il software, dai canali pubblici del suo repository, e alla fine gli si propongono correzioni e funzioni nuove.
Dove stanno i dati, e dove gira il software
Dove può girare il software dipende dalla classe dei dati: ordinari, critici o strategici, secondo il Regolamento dell’Agenzia per la cybersicurezza nazionale sulle infrastrutture digitali e i servizi cloud per la pubblica amministrazione, che si applica dal 1° agosto 2024.
Il Regolamento chiede a ogni amministrazione l’elenco dei propri dati e servizi digitali, ognuno con la sua classe, e un servizio non ancora classificato non si può mettere a disposizione degli utenti. I livelli minimi salgono con la classe, per i centri di elaborazione dati dell’ente come per i servizi cloud; quali servizi cloud sono qualificati, e a che livello, lo dice il catalogo pubblicato da ACN.
Quello che scriviamo si installa dove decidete voi, sui server del vostro ente o in cloud, e in tutti e due i casi l’infrastruttura deve avere i livelli che il Regolamento chiede per quella classe.
I sistemi che il vostro ente usa già
Un software nuovo per un comune legge o scrive in quello che c’è già: il protocollo informatico, la contabilità, i gestionali dei singoli servizi. È la parte che porta via più tempo, e il modo lo decide quello che quei sistemi permettono: file di scambio, accesso al database, un middleware, o API scritte da noi dove mancano.
Se i dati stanno in un’altra amministrazione, c’è la Piattaforma Digitale Nazionale Dati dell’articolo 50-ter del Codice. Le amministrazioni sono tenute ad accreditarsi, a sviluppare le proprie interfacce e a rendere disponibili le proprie basi dati, e le interfacce, scritte secondo le Linee guida AgID sull’interoperabilità, stanno in un catalogo API.
Per un software in licenza, le Linee guida su acquisizione e riuso chiedono anche di poter esportare gratis, in ogni momento, l’intera base di dati in un formato standard, aperto e documentato. È una domanda da fare a chiunque vi proponga un software.
Servizi per i cittadini: SPID, pagoPA, app IO e accessibilità
Se il servizio chiede di identificare chi entra, l’articolo 64 del Codice vuole SPID o la carta d’identità elettronica, e ammette anche la carta nazionale dei servizi. I pagamenti elettronici che l’ente riceve passano da pagoPA, a cui le amministrazioni sono tenute ad aderire per l’articolo 5, e l’articolo 64-bis chiede di rendere i servizi in rete raggiungibili dall’app IO.
Per l’accessibilità, le Linee guida AgID che attuano la Legge 4/2004 rimandano alla norma europea EN 301 549, cioè al livello AA delle WCAG 2.1 per il web. Ogni sito e ogni app dell’ente ha la sua dichiarazione di accessibilità, compilata sulla piattaforma dell’AgID e da riesaminare entro il 23 settembre di ogni anno.
Sicurezza, e le garanzie da chiedere al fornitore
Fra i criteri della valutazione comparativa ci sono le garanzie del fornitore su sicurezza, dati personali e livelli di servizio. Sono le prime cose da chiedere per iscritto.
dotenv è certificata UNI CEI EN ISO/IEC 27001:2024, la norma sulla gestione della sicurezza delle informazioni: certificato IIS-1225-06, rilasciato da Dasa-Räegister, ente accreditato ACCREDIA, valido fino al 15 dicembre 2028. Il PDF del certificato si scarica dalla pagina delle certificazioni.
Le regole di sicurezza del vostro ente, se vanno oltre la norma, entrano nel contratto e nel progetto.
Dopo il rilascio
Anche le modifiche fatte in manutenzione ricadono nell’articolo 69, e per le Linee guida AgID si fanno nel repertorio dove il codice è già pubblicato, senza aprirne un altro.
I difetti del software consegnato li correggiamo a nostro carico, nella garanzia di legge. La manutenzione continuativa è un accordo a parte, a pagamento, e lì mettiamo per iscritto i tempi di risposta che vi servono. Il codice resta vostro anche se un giorno la manutenzione la affidate a un altro fornitore.
Chi serve dal vostro ente, e chi c’è da dotenv
Dal vostro ente serve una persona che possa decidere, e che ci sia quando si guarda il software che gira. Serve chi segue i sistemi informativi, perché dove stanno i dati e con che cosa parla il software si decide insieme. Va coinvolto presto anche l’ufficio per la transizione al digitale, o il suo responsabile, che per l’articolo 17 del Codice coordina lo sviluppo dei sistemi informativi. E servono le persone che useranno il software ogni giorno, che provano il prototipo per prime, e chi lo seguirà dopo il rilascio.
Da parte nostra, su ogni progetto lavorano almeno due persone e c’è documentazione scritta: se una manca, il lavoro va avanti. Si procede a fasi, e alla fine di ognuna decidete voi se proseguire.
Cosa preparare per la prima chiamata
Si comincia con una chiamata, gratuita, anche in videochiamata. Poi una visita in sede, per vedere come lavorate oggi nel servizio da cui parte il bisogno. Per la chiamata vi chiediamo, se li avete:
- Il servizio da cui parte il bisogno, e chi ne risponde.
- Il documento delle esigenze e la valutazione delle alternative, se ci sono già.
- La classe dei dati che il software tratterà, se è già decisa, e le regole di sicurezza del vostro ente.
- I sistemi con cui il software dovrà parlare.
- Se il software apre un servizio ai cittadini, o incassa pagamenti.
Come lavoriamo anche: Per le startup · Per le PMI · Per le grandi aziende
Domande frequenti
- Che cosa vuol dire prendere un software a riuso?
- Vuol dire usare un software che un’altra amministrazione ha pubblicato con licenza aperta nel catalogo di Developers Italia, adattandolo se serve. Le modifiche le può fare il personale dell’ente, una società in-house o un fornitore scelto dall’ente, e vanno proposte a chi mantiene il software originale.
- Un comune può comprare un software in licenza?
- Sì, se la valutazione comparativa lo giustifica. L’articolo 68 del Codice la consente solo quando risulta, motivandolo, che per quello che serve all’ente non c’è una soluzione adatta fra quelle già disponibili nella pubblica amministrazione e fra il software open source.
- Siete certificati ISO 27001?
- Sì, con il certificato IIS-1225-06 rilasciato da Dasa-Räegister, accreditato ACCREDIA, valido fino al 15 dicembre 2028. La norma riguarda la gestione della sicurezza delle informazioni; le regole dell’ente che vanno oltre la norma entrano nel contratto.
- Serve un documento con le esigenze prima di contattarvi?
- Basta sapere che cosa deve fare il software e quali dati tocca. Se un documento c’è lo leggiamo, e il perimetro lo scriviamo insieme.
- Come si affida il lavoro a dotenv?
- La procedura d’acquisto si definisce con l’ente, caso per caso. dotenv è presente sul MEPA.
- Se ci fermiamo dopo il prototipo, che cosa resta all’ente?
- Le schermate e la progettazione, che restano vostre anche se non andate avanti.
- Possiamo fermarci a metà lavoro?
- Sì, alla fine di una fase: si lavora a fasi, ed è lì che decidete se proseguire. Quello che è stato fatto fino a quel punto resta all’ente.
- Usate l’intelligenza artificiale?
- Sì, come supporto, su tutti i progetti. Le scelte le fanno le persone, e di quello che rilasciamo risponde dotenv. I dati dell’ente passano solo da servizi di AI privati nostri, mai da servizi esterni. Sull’AI ci portano competenza anche le persone di Neurally, l’azienda che abbiamo fondato.
Raccontateci che cosa deve fare il software, e dove devono stare i dati.