README

Il calendario degli eventi partecipato dai cittadini

OpenAgenda facilita la collaborazione tra i soggetti che animano la vita culturale di una comunità locale; associazioni, biblioteche e musei raccolgono i propri eventi in un unico calendario che ne facilita la diffusione multicanale, in coordinamento con l'ente locale. In questo modo, la P.A. propone un significativo cambio di paradigma rispetto al passato: rende autonomi e responsabilizza i cittadini nella gestione degli eventi pubblici, mantenendo un ruolo di coordinamento e di validazione dell’intero processo, a garanzia del suo corretto funzionamento. Un modo per rafforzare le relazioni tra amministrazione e territorio, secondo il paradigma dell'OpenGovernment.

Per maggiori informazioni, vedi: https://www.opencontent.it/Per-la-PA/OpenAgenda

Documentazione

La documentazione di OpenAgenda è stata realizzata con Readthedocs ed è disponibile in questi formati:

Manuale d'uso per gli operatori della PA: http://manuale-openagenda.readthedocs.io/it/latest/manuale_amministratori.html
Manuale d'uso per le Associazioni: http://manuale-openagenda.readthedocs.io/it/latest/manuale_associazioni.html

Sei un programmatore ed hai bisogno di aiuto?

Per segnalare malfunzionamenti utilizzare la funzionalità GitHub Issues di questo repository
Per richiedere l'assistenza di uno sviluppatore scrivere a info@opencontent.it

Titolare della licenza

Opencontent SCARL Via Galilei Galilei 24 - Trento (Italy) Codice fiscale e P.IVA: 02190640223 https://www.opencontent.it/

Responsabile tecnico

Opencontent SCARL https://www.opencontent.it/ Opencontent si è occupato della progettazione, realizzazione e manutenzione tecnica di OpenAgenda

Licenza e modalità d'uso

OpenAgenda è rilasciato con licenza aperta, GNU General Public License v2.0, che puoi leggere integralmente qui: http://www.gnu.org/licenses/gpl-2.0.txt

Grazie a questa licenza, qualsiasi utente di OpenAgenda gode delle quattro libertà fondamentali:

Libertà di eseguire il programma come si desidera, per qualsiasi scopo (libertà 0).
Libertà di studiare come funziona il programma e di modificarlo in modo da adattarlo alle proprie necessità (libertà 1). L'accesso al codice sorgente ne è un prerequisito.
Libertà di ridistribuire copie in modo da aiutare gli altri (libertà 2).
Libertà di migliorare il programma e distribuirne pubblicamente i miglioramenti da voi apportati (e le vostre versioni modificate in genere), in modo tale che tutta la comunità ne tragga beneficio (libertà 3). L'accesso al codice sorgente ne è un prerequisito.

Codice etico

OpenAgenda è un'applicazione Open Source. Il codice sorgente viene rilasciato con licenza GNU General Public License v2.0 per due ragioni:

il modello di business di Opencontent ed il suo codice etico aziendale, che identifica nella condivisione del sapere un fattore determinante per migliorare costantemente la qualità e la competitività aziendale
la tutela degli utenti ed in particolare degli enti pubblici, che possono più facilmente rispettare quanto previsto dall'Art. 68 (sotto riportato) e dal Piano Triennale per l'informatica nella Pubblica Amministrazione (in particolare, capitoli 4, 7 e 13 sotto riportati).

PRINCIPALE NORMATIVA DI RIFERIMENTO

Codice dell'Amministrazione Digitale - Art. 68. Analisi comparativa delle soluzioni

In vigore

Le pubbliche amministrazioni acquisiscono programmi informatici o parti di essi nel rispetto dei principi di economicità e di efficienza, tutela degli investimenti, riuso e neutralità tecnologica, a seguito di una valutazione comparativa di tipo tecnico ed economico tra le seguenti soluzioni disponibili sul mercato: a) software sviluppato per conto della pubblica amministrazione; b) riutilizzo di software o parti di esso sviluppati per conto della pubblica amministrazione; c) software libero o a codice sorgente aperto; d) software fruibile in modalità cloud computing; e) software di tipo proprietario mediante ricorso a licenza d’uso; f) software combinazione delle precedenti soluzioni.

1-bis) A tal fine, le pubbliche amministrazioni prima di procedere all’acquisto, secondo le procedure di cui al codice di cui al decreto legislativo n. 50 del 2016, effettuano una valutazione comparativa delle diverse soluzioni disponibili sulla base dei seguenti criteri: a) costo complessivo del programma o soluzione quale costo di acquisto, di implementazione, di mantenimento e supporto; b) livello di utilizzo di formati di dati e di interfacce di tipo aperto nonché di standard in grado di assicurare l’interoperabilità e la cooperazione applicativ a tra i diversi sistemi informatici della pubblica amministrazione; c) garanzie del fornitore in materia di livelli di sicurezza, conformità alla normativa in materia di protezione dei dati personali, livelli di servizio tenuto conto della tipologia di software acquisito.

1-ter) Ove dalla valutazione comparativa di tipo tecnico ed economico, secondo i criteri di cui al comma 1-bis, risulti motivatamente l’impossibilità di accedere a soluzioni già disponibili all’interno della pubblica amministrazione, o a software liberi o a codici sorgente aperto, adeguati alle esigenze da soddisfare, è consentita l’acquisizione di programmi informatici di tipo proprietario mediante ricorso a licenza d’uso. La valutazione di cui al presente comma è effettuata secondo le modalità e i criteri definiti dall’AgID.

Piano Triennale: 4. Infrastrutture immateriali

4.1. Dati della Pubblica amministrazione

La valorizzazione del patrimonio informativo pubblico è un obiettivo strategico per la Pubblica amministrazione. Per sfruttare le potenzialità dell’immenso patrimonio dei dati raccolti e gestiti dalle PA è necessario attuare un cambio di paradigma nella loro gestione che consenta di superare la “logica a silos” in favore di una visione sistemica. Il dato deve essere inteso come bene comune, condiviso gratuitamente tra Pubbliche amministrazioni per scopi istituzionali e, salvo casi documentati e propriamente motivati, utilizzabile dalla società civile.

Per implementare tale paradigma, il Piano individua tre aree:

basi di dati di interesse nazionale, ovvero basi di dati affidabili, omogenee per tipologia e contenuto, rilevanti per lo svolgimento delle funzioni istituzionali delle Pubbliche amministrazioni e per fini di analisi. Esse costituiscono l’ossatura del patrimonio informativo pubblico, da rendere disponibile a tutte le PA, facilitando lo scambio di dati ed evitando di chiedere più volte la stessa informazione al cittadino o all’impresa (principio once only);
open data, ovvero “dati di tipo aperto”. Essi comportano un processo finalizzato a rendere i dati della Pubblica amministrazione liberamente usabili, riutilizzabili e ridistribuibili, da parte di chiunque e per qualunque scopo, anche commerciale, purché non siano soggetti a particolari restrizioni (ad es.: segreto di stato, segreto statistico, vincoli di protezione dei dati personali definite dal Garante della privacy);
vocabolari controllati e modelli dei dati, che costituiscono un modo comune e condiviso per organizzare codici e nomenclature ricorrenti in maniera standardizzata e normalizzata (vocabolari controllati) e una concettualizzazione esaustiva e rigorosa nell’ambito di un dato dominio (ontologia o modello dei dati condiviso).

La valorizzazione del patrimonio pubblico richiede un’attenta regia che disegni i processi di standardizzazione, generazione, conservazione e riuso dei dati. Questo potenziamento porterà benefici in termini di maggiore efficienza amministrativa, riuso dei dati a vantaggio del cittadino (che così evita di fornire nuovamente dati già in possesso della Pubblica amministrazione) e ampliamento delle possibilità di analisi, ivi incluse la comprensione e la predizione di fenomeni sociali a supporto del processo di policy making e dello sviluppo di servizi al cittadino.

Piano Triennale: 7. Strumenti per la generazione e la diffusione di servizi digitali

7.2. Obiettivi strategici

Favorire la diffusione del paradigma open source, agevolando la costituzione di una community di sviluppatori di applicazioni e componenti software di utilità per la PA.
Incentivare l’adozione delle Piattaforme abilitanti (ad es. SPID, PagoPA, ANPR) tramite la realizzazione e diffusione di kit di sviluppo, ambienti di validazione e verifica, la comunicazione trasparente sullo stato di avanzamento di ciascun progetto e la segnalazione e discussione di anomalie.
Fornire linee guida da seguire e toolkit utili allo sviluppo di applicazioni e servizi con adeguati livelli di design, user experience, sicurezza e usabilità.
Favorire lo sviluppo di prodotti e servizi digitali basati sull’utilizzo di basi di dati, API e informazioni rese disponibili dalle Pubbliche amministrazioni (ad es. applicazioni per l’interrogazione di basi di dati pubbliche).
Condividere indicazioni e componenti software che permettano di ridurre i costi di implementazione di nuovi prodotti digitali, favorendo il riuso e l’interoperabilità .
Supportare le amministrazioni nella diffusione e nella divulgazione dei servizi e degli strumenti necessari alla comunicazione del percorso di attuazione del Piano triennale.

Piano Triennale: 13. Principi per lo sviluppo di progetti digitali

Questo capitolo contiene principi che vengono qui ricordati e raccomandati perché ritenuti fondamentali per la realizzazione dei progetti contenuti nel Piano. Gli accorgimenti sono sia di natura pratica - per la gestione del progetto - sia di natura contrattuale e amministrativa per la stesura del contratto, la definizione degli obiettivi, e l’approvvigionamento delle risorse.

Infine, la predisposizione di un progetto digitale per la realizzazione di un nuovo sistema o per l’evoluzione di un sistema esistente, richiede:

un chiaro disegno di cosa si vuole ottenere (design);
un piano di come costruirlo (realizzazione);
una strategia per portarlo all’adozione degli utenti finali (lancio);
un piano per mantenere il sistema aggiornato, sicuro, e utile nel tempo, oltre che per assicurarne il continuo funzionamento anche in caso di malfunzionamenti o disastri (evoluzione e manutenzione).

Nei paragrafi seguenti si descrivono questi punti in maggior dettaglio.

13.1. Design del progetto

La fase di design è essenziale per la buona riuscita del progetto. A tale proposito, si rinvia al capitolo Service design delle Linee guida di design per i servizi web della PA. In particolare, in fase di progettazione dei servizi si raccomanda di:

Coinvolgere sempre i cittadini, a partire dalla comprensione dei loro bisogni (Strategia n°1 delle Linee guida). Questo vuol dire immaginare come il cittadino (o l’utente finale) andrà a utilizzare il sistema e fare in modo che tutte le funzionalità siano disegnate intorno alle sue esigenze, consentendogli di ottenere facilmente e rapidamente ciò di cui ha bisogno - senza inutili passaggi, e con istruzioni comprensibili a chiunque.
Studiare per capire, documentare per non ripetere (Strategia n°3 delle Linee guida). È necessario conoscere il contesto nel quale opererà un progetto, definirne gli obiettivi, attenersi agli standard e fare ricerche su eventuali alternative valide a livello nazionale e internazionale, oltre che sulla disponibilità di strumenti e processi già sperimentati con successo che possono essere riutilizzati. Ogni fase di sviluppo del progetto deve essere documentata e resa disponibile in maniera aperta, da una parte per garantirne l’integrità e la sostenibilità futura, dall’altra per consentire possibili collaborazioni che potrebbero di aggiungervi nuovo valore.
Applicare il principio once only (Strategia n°6 delle Linee guida). Evitare che i cittadini debbano fornire le stesse informazioni più di una volta. Ogni processo deve essere pensato per essere quanto più semplice e usabile possibile, sostituendo le vecchie procedure quando necessario.
Individuare obiettivi e metriche. È necessario quindi individuare gli obiettivi da raggiungere, in termini di funzionalità e processi, insieme alle metriche in grado di valutare il successo e il gradimento del progetto. Ad esempio, in un sistema di fatturazione elettronica, un obiettivo potrebbe essere quello di “avere un processo per cui non è mai necessario stampare fatture”. Quando possibile, si raccomanda di usare metriche oggettive piuttosto che dati ricavati da questionari o rilevazioni. Ad esempio, considerando il “numero di fatture stampate tradizionalmente” come un indicatore di inadeguatezza del sistema o il “numero di fatture inviate elettronicamente” come fattore di successo.
Partire dai dati (Strategia n°4 delle Linee Guida). Per prendere decisioni basate su comportamenti e dati reali è necessario realizzare servizi e processi interamente digitali, non limitandosi alla semplice trasposizione on line di un processo erogato in modalità tradizionale.
Nominare un product owner, ovvero una persona che - preferibilmente all’interno della PA e comunque non legata al soggetto che realizzerà il prodotto - sappia rappresentare le aspettative e i bisogni degli utenti finali del servizio progettato e che abbia una chiara competenza sui processi che si vuole digitalizzare e del risultato che si vuole ottenere. Ad esempio, in un progetto di fatturazione elettronica, il product owner sarà una persona che conosce bene i processi di fatturazione e sarà in grado di guidare gli esecutori del progetto fornendo consigli e indicazioni su come inviare e processare tali fatture, i dati che queste devono contenere, ecc.

13.2. Realizzazione del progetto

[...]

Da un punto di vista tecnico inoltre occorre:

Rendere i dati aperti, condividere processi e strumenti (Strategia n°8 delle Linee Guida). Condividere ogni dato, ogni processo, ogni codice, ogni idea, ogni fallimento, ogni informazione è necessario e vitale per tutti i servizi, per favorire la trasparenza e la qualità nello sviluppo. Il codice e la documentazione di ogni servizio realizzato dalla Pubblica amministrazione dovrebbero essere rilasciati in formato aperto con una licenza adeguata per consentire un risparmio di costi e di tempo; laddove non fosse possibile, l’impedimento andrà adeguatamente motivato.
Preferire componenti liberi o open source, ovvero componenti software i cui codici sorgente siano disponibili e, se possibile, liberamente modificabili e adattabili alle esigenze della PA, come specificato all’articolo 68 del CAD. L’utilizzo di prodotti commerciali o i cui sorgenti sono chiusi dovrà essere puntualmente giustificato ed è consentito solo nel caso in cui il rapporto costo e funzionalità necessarie per il progetto sia più conveniente rispetto alle alternative open source.
Scegliere soluzioni hardware in base a valutazioni di economicità ed efficienza, in particolare valutando il costo di migrazione a soluzioni alternative (uscita dal lock-in) e garantendo la neutralità tecnologica.
Avvalersi del cloud della PA. Salvo comprovate ragioni tecniche, il software ed il progetto devono essere disegnati per essere utilizzati sul cloud della PA, come definito nel paragrafo 3.1 “Data center e cloud”.

Infine, il software realizzato deve:

Essere strutturato in microservizi, ovvero in componenti che svolgono poche funzionalità ben definite (ad es. verifica codice fiscale, esistenza dell’utente nella base di dati), controllate tramite API e facilmente riutilizzabili, in modo da poter essere messe a disposizione di altre PA tramite la developer community (cfr. capitolo 7 “Strumenti per la generazione e la diffusione di servizi digitali”).
Esporre le API, ovvero realizzare interfacce che consentano ai sistemi di comunicare e interagire tra di loro facilmente e in maniera automatica. L’interfaccia esposta all’utente e tutte le funzionalità del prodotto devono essere costruite attraverso l’uso di tali API (cfr. capitolo 5 “Modello di interoperabilità”).
Utilizzare basi di dati progettate secondo le regole esposte nel paragrafo 4.1 “Dati della PA” e, in particolare, inserire nel Data & Analytics Framework (DAF) le informazioni in merito alla natura delle operazioni realizzate e alle loro mutazioni nel tempo.
Mantenere l’interoperabilità di dati, servizi e processi secondo le regole di interoperabilità e cooperazione dettate da AgID, fatti salvi i criteri necessari per garantire la privacy degli utenti. I dati devono essere resi disponibili come open data e devono essere accompagnati da un’esaustiva descrizione dei campi e del loro significato (metadati).
Utilizzare solide strategie di testing e qualificazione, ovvero utilizzare test di unità, test funzionali e fuzz test per verificare il codice ed effettuare stress test per verificare il carico che il prodotto sarà in grado di sostenere. Si consiglia inoltre l’utilizzo di strategie di analisi statica del codice, e l’auditing del risultato per affrontare i problemi relativi alla sicurezza.
Utilizzare best practices di sicurezza come, ad esempio, criptare le password e le comunicazioni via rete.
Includere tutta la documentazione necessaria, ovvero includere documentazione sulla struttura dei dati utilizzati (campi, tabelle, ecc.), sul funzionamento e l’utilizzo del software, nonché documentazione sul funzionamento del prodotto, su come mantenerlo, aggiornarlo e monitorarlo.
Appartenere alla PA, ovvero il contratto deve specificare che tutti i diritti sul prodotto realizzato, dal codice alla documentazione, dai nomi di dominio alle licenze, librerie di terze parti o brevetti registrati sul prodotto appartengono alla PA. In questo modo, la PA potrà continuare l’evoluzione del prodotto, anche avvalendosi di fornitori diversi da quelli che lo hanno sviluppato in origine.
Essere messo a disposizione di altre PA, ovvero registrato nel market place di Consip e, quando possibile, messo a disposizione liberamente completo di sorgenti e documentazione, con licenze aperte che ne consentano l’utilizzo, la modifica o l’evoluzione da parte di terzi.

Quando poi è importante l’integrazione del progetto con software realizzati da terze parti o sistemi preesistenti, si consiglia di:

Mettere a disposizione strumenti e infrastrutture di testing, ovvero mettere a disposizione ambienti dove provare il proprio software, account di prova, o simulatori, utilizzabili liberamente da terze parti per verificare l’integrazione tra componenti.
Utilizzare e documentare processi per coordinare gli aggiornamenti software che prevedano dei meccanismi per annunciare il rilascio imminente di nuove versioni (newsletter, forum, …), il rilascio in ambienti di testing, e solo a seguito di verifica funzionale con gli utenti del sistema e software di terze parti in ambienti di testing, il rilascio in produzione.
Mettere a disposizione librerie e kit di sviluppo, ovvero esempi di codice e componenti software pronti per essere utilizzati da terze parti nei loro prodotti per integrarsi con i vostri sistemi. Questo facilita il riuso, migliora la qualità del codice, diminuisce i costi di manutenzione e aggiornamento, diminuisce significativamente il rischio di incompatibilità ed implementazioni non conformi alle specifiche, e diminuisce i costi di sviluppo per ognuna delle terze parti.

13.3. Lancio del progetto

Nello stabilire un percorso per portare all’adozione del progetto, la PA deve:

Individuare la strategia di adozione di minor resistenza, ovvero trovare il modo più semplice, veloce e con minore impatto perché il prodotto possa iniziare ad essere adottato, anche in forma limitata o incompleta. Anziché introdurre un grande cambiamento in un unico passo, è preferibile avanzare a piccoli passi incrementali - individualmente più semplici e meno rischiosi - verso il raggiungimento dell’obiettivo finale.
Individuare una strategia di utilizzo incrementale, ovvero trovare quei meccanismi che consentano l’adozione del prodotto, prima da parte di un numero ristretto di utenti, poi di un numero più ampio e, infine, da parte di tutti gli utenti. È importante evidenziare come il lancio di un servizio destinato alla totalità degli utenti non determini l’arresto delle attività di sviluppo o il completamento del prodotto. Al contrario, quando possibile, si raccomanda di individuare strategie che consentano di usare il prodotto ancor prima del suo completamento, al fine di individuare problemi, riorganizzare le priorità e iniziare a fornire i benefici derivanti dall’innovazione, seppure con un prodotto parziale.
Individuare un piano per il lancio completo del prodotto, ovvero per dismettere il prodotto precedente. Per progetti di grande dimensione, è importante evidenziare che una strategia di lancio può richiedere non solo la realizzazione del prodotto, ma campagne di promozione con gli utenti, meccanismi di comunicazione (mailing list, twitter, realizzazione di siti vetrina) e tutto ciò che è considerato importante per portare all’adozione del prodotto stesso.
Comunicare efficacemente, spesso, ovunque (Strategia n°5 delle Linee Guida). Le Pubbliche amministrazioni devono comunicare in maniera chiara l’utilità e i prerequisiti del servizio, oltre a tutte le informazioni relative alla protezione dei dati personali, alla tutela della vita privata e alla sicurezza informatica, raggiungendo i cittadini attraverso i canali di comunicazione più usati e diffusi, dando loro la possibilità di accedere ai propri dati, di controllarli e di correggerli, mantenendo un continuo dialogo, anche oltre e dopo il lancio del servizio.

13.4. Evoluzione e manutenzione del progetto

Nel definire le strategie per l’evoluzione e la manutenzione del progetto, si raccomanda alla PA di:

Assicurare la manutenzione e l’aggiornamento periodico di tutti i software e i sistemi al fine di prevenire problematiche di sicurezza, garantire la compatibilità del software con nuove tecnologie e la conformità con l’evoluzione normativa.
Assicurare un piano per la continua evoluzione del prodotto, ovvero stabilire o avere una strategia per migliorare il prodotto dopo il lancio, aggiungere funzionalità, correggere problematiche e, più in generale, consentirne l’aggiornamento.
Assicurare una strategia di disaster recovery e business continuity, ovvero assicurarsi che, in caso di malfunzionamento o disastro, i dati critici non vengano persi e sia possibile continuare nell’erogazione dei servizi, seppur in modalità ridotta.
Assicurare la continua verifica dei parametri di funzionamento, come, ad esempio, il monitoraggio del software (errori, richieste, latenza), audit periodici per garantirne la sicurezza, ecc.
Predisporre tutte le procedure necessarie per evitare il lock-in, mantenendo aperta la possibilità di passare da un fornitore a un altro. L’utilizzo di diversi fornitori per la realizzazione, il mantenimento e il lancio del prodotto garantisce generalmente una migliore capacità di migrazione ad altro fornitore.

opencontent / openpa_agenda-ls

Maintainers

Details