Uno sguardo di sistema sulla “Contact Tracing App”

Versione 1.5 – Originale pubblicato qui.

Premessa

Un argomento caldo in questo periodo sui cui si sono visti molti scontri, non solo tra le persone della strada ma anche tra esperti è la famosa (o famigerata) App di Contact Tracing.

In seguito ai lavori di una commissione di esperti (task force dati) il commissario straordinario Arcuri ha annunciato la scelta di una app, tra quelle proposte in riposta ad una bando congiunto di tre ministeri ( Telemedicina e data analysis ).

La app verrà sviluppata dalla società Bending Spoons e il codice sorgente del sistema di contact tracing sarà rilasciato con licenza Open Source MPL 2.0.

Uno sguardo di sistema

Sebbene buona parte delle osservazioni si siano concentrate su aspetti tecnologici e di impatto sulla privacy, il tema può essere analizzato sotto diverse prospettive.

Si tratta di un sistema complesso e come tale comporta articolati bilanciamenti di vantaggi e svantaggi su molte dimensioni.

Provo ad elencare alcune delle dimensioni che dalla mia personale esperienza, da un punto di vista di Sistemi Informativi e Ingegneria del Software, mi paiono degne di nota:

  • modelli epidemiologici
  • tecnologia
  • qualità dei dati
  • sviluppo software
  • adozione ed efficacia
  • processi e logistica di supporto
  • impatto sociale e giuridico

Queste dimensioni e la loro discussione che segue non vogliono rappresentare una critica ma bensì degli spunti per una riflessione più ampia all’interno della società civile.

L’obiettivo finale è quello di far prendere coscienza della complessità del problema, del fatto che non esiste una soluzione perfetta, sebbene alcune soluzioni siano meno imperfette di altre.

Si tratta di inquadrare il problema in un contesto articolato, dove la risposta alle domande su un sistema complesso deve essere quella del buon ingegnere: “dipende!”. Dipende dal punto di vista e da quale compromesso tra tali punti di vista si voglia scegliere.

Modelli epidemiologici

Ci sono diversi modelli che descrivono le dinamiche del contagio. Quello base è il modello SIR (Susceptible, Infected, Recovered), in cui il parametro R0 indica l’evoluzione del contagio (quanti individui vengono contagiati da ciascun individuo infetto).

Recenti studi hanno stimato l’effetto di un contact tracing digitale. In estrema sintesi, ipotizzando un auto-isolamento immediato, sarebbe sufficiente un livello di adozione della App pari al 60% per garantire un regresso dell’epidemia (in termini SIR, R0 viene abbassato sotto la soglia critica pari a 1).

L’articolo citato considera diversi livelli di efficacia nel contenimento delle persone infette, ma non approfondisce ulteriormente.

Resta il fatto che sui modelli epidemiologici restano grossi punti interrogativi derivanti dal fatto che si conosce ancora poco questo virus. Ad esempio il numero di asintomatici che potrebbe ammontare al 50% (con punte anche molto più elevate). Un altro punto chiave è se i guariti sviluppino immunità e per quanto duri.

Quindi si tratta di stime con un basso livello di confidenze e a cui occorre aggiungere ulteriore incertezza dovuta al fatto che il sistema non sia ideale sotto gli altri aspetti.

Tecnologia

Sono state sviluppate diverse tecnologie per il “contact tracing” digitale ed a livello internazionale sono disponibili alcuni standard (quello più rilevante è probabilmente DP-3T ) di cui la App dovrà tenere conto. Inoltre è stato annunciato lo sviluppo di nuove funzionalità inserite direttamente nei sistemi operativi di Apple e Google.

Questi approcci si basano sullo scambio di piccoli messaggi anonimi tramite BTLE (Bluetooth Low Energy) in modo da poter risalire a chi è stato in contatto con soggetti che si rivelano infetti.

L’uso di altre tecnologie di geolocalizzazione, come GPS o le celle telefoniche, oltre a essere difficilmente conciliabili con la privacy per come è concepita all’interno dell’UE, sono poco precisi, particolarmente al chiuso.

Qualità dei dati

Buona parte dei ragionamenti fatti assume che i dati raccolti tramite le app e poi sfruttati per identificare potenziali contagi siano perfetti. Nella pratica, e lo sa bene chi lavora quotidianamente con grandi moli di dati, la qualità dei dati rappresenta un limite critico.

Usando lo standard ISO/IEC 25012:2008 e, a titolo esemplificativo, escludendo le caratteristiche di qualità che dipendono dai sistemi che le elaborano, considerando solo le caratteristiche intrinseche dei dati:

  • incompletezza (mancano dati su alcuni contatti o in alcuni periodi)
  • incoerenza (dati diversi suggeriscono contatti diversi)
  • mancato aggiornamento (tra app e tra app e sistemi centrali)
  • accuratezza (dei singoli dati, dei tempi, delle distanze)
  • credibilità (per la presenza di fonti di dati non accreditate)

Senza una valutazione e stima della qualità dei dati è impossibile sapere qual’è il livello di affidabilità dell’applicazione e la sua efficacia nel ridurre l’epidemia.

Sviluppo software

Uno degli aspetti spesso trascurati nello sviluppo del software è rappresentato, al di là delle tecnologie utilizzate, dai processi e dalle metodologie utilizzati.

Quando si sviluppano sistemi “safety critical” (da cui dipende la vita delle persone, come il sw di un aeroplano) le norme internazionali impongono l’adozione di una serie di pratiche di sviluppo. Questo perché il comportamento del sw non è “lineare” (ovvero facilmente estrapolabile da una serie di casi noti) a differenza di buona parte dei prodotti fisici, perciò il collaudo non può essere esaustivo e non può dare alcuna garanzia di correttezza.

Un esempio di pratica, spesso trascurata, ma sicuramente applicabile e fondamentale nel caso della App di tracciamento, è la conduzione di piano di sw testing più esteso possibile e largamente automatizzato. Sappiamo che il test di App mobili è difficile, ma non farlo o farlo in maniera limitata potrebbe avere delle conseguenze estremamente gravi.

Adozione ed efficacia

Una volta che la App sarà pronta, perché sia utile è necessario che sia adottata ampiamente, in modo che i potenziali contagiati siano avvertiti tempestivamente e possano prendere provvedimenti.

Tuttavia, se avviene un contagio tra due persone, affinché l’App possa avvertire la contagiata è necessario che:

  1. entrambi abbiano un telefono
  2. si tratti di modelli recente
  3. sia stato aggiornato il sistema operativo
  4. abbiano installato l’App
  5. avessero il telefono con se al momento del contagio
  6. il telefono fosse carico ed acceso al momento del contagio
  7. avessero l’App attiva quando è avvenuto il contagio
  8. il BTLE abbia funzionato correttamente
  9. che chi ha trasmesso il contagio abbia sviluppato i sintomi o sia stato avvisato dall’app
  10. che abbia preso provvedimenti avvisando il medico o il SSN
  11. che sia stato soggetto ad un “tampone”
  12. che il “tampone” abbia dato esito positivo
  13. che chi è stato contagiato riceva la notifica

Questo elenco non vuole essere esaustivo o sistematico ma solo dare un’idea della quantità e varietà di fattori esterni, al di fuori del controllo di chiunque sviluppi l’App o gestisca il sistema di tracciamento.

È importante avere delle stime sulla probabilità di questi eventi e mettere in campo delle azioni per mitigare i rischi connessi.

App Adoption

 

Processi e logistica di supporto

Una App da sola non è sufficiente a raggiungere un obiettivo ampio quale la riduzione dei contagi. Le App sono inserite nel contesto di un Sistema Informativo, che include altri applicativi (ad es. il registro centralizzato dei contagi) che devono operare sinergicamente.

I sistemi informativi di supporto al momento hanno evidenziato preoccupanti carenze. Sviluppare nuovi sistemi non è facile sia per i tempi ristretti (che porterebbero a non adottare le buone pratiche di ingegneria del software cui si accennava sopra) sia per la necessità di integrarli adeguatamente con quelli esistenti (pena la perdita di informazioni).

Il sistema informativo, a propria volta, è immerso in un contesto complesso: altri sistemi informativi e un’organizzazione. L’organizzazione comprende: procedure, strutture e risorse.

Servono delle procedure, ad esempio l’OMS ha definito le procedure raccomandate per il “contact tracing”, ma per eseguire le procedure servono delle organizzazioni che le mettano in pratica e le organizzazioni hanno bisogno di risorse per poterle attuare. Le risorse sono

  • materiali: laboratori, strumenti di analisi, reagenti e consumabili;
  • umane: deve esserci un numero sufficiente di persone, ma soprattuto, esse devono possedere conoscenze e capacità adeguate ai compiti che dovranno svolgere.

Impatto sociale e giuridico

Per ultimo, ma non ultimo per importanza, è fondamentale valutare l’impatto sociale e giuridico. In primis in termini di privacy ma non solo.

A questo proposito è molto chiara la lettera aperta su tracciamento dei contatti e democrazia promossa dal Centro Nexa su Internet & Società e sottoscritta da un ampio numero di esperti.

È probabilmente da attribuire alla tempestività di tale lettera quello che è stato percepito come un cambiamento di rotta da parte del governo su alcuni punti critici.

Queste genere di considerazioni sono fondamentali nello scegliere quali sono le priorità che devono guidare la scelta di pesi e compromessi tra i diversi punti di vista. Un buon ingegnere del software deve ricordare sempre che “ogni linea di codice rappresenta una scelta morale”.

Conclusioni

Queste sono, senza pretesa di completezza, diverse dimensioni che è importante considerare quando si analizza una App che abbia una portata ampia come quella di “contact tracing”, ma “mutatis mutandis” si applicano a tante altre applicazioni. Si tratta di prospettive dovrebbero essere evidenti per chi ha la sensibilità che deriva dalla cultura di sistema, che dovrebbe essere propria di un buon ingegnere del software.

Si tratta di capire che, citando una bella riflessione di Luca Sofri, quando ci si chiede “Di che colore è il mare?” non sempre la risposta è “Blu.”.


Note:

Versioni dei telefoni e sistemi operativi

I telefoni devono essere modelli recenti per due motivi principali:

  • spesso una App sviluppata per funzionare su versioni recenti di iOS o Android è non compatibile e può essere installata su versioni vecchie (un esempio banale: tante API “vecchie” vengono deprecate e quindi non più usate portando a incompatibilità)
  • se la App utilizzerà le nuove API Apple+Google per forza dovrà essere installata una versione nuova del sistema operativo

Purtroppo se i telefono sono vecchi è probabile che non si riescano ad installare versioni nuove del sistema operativo e quindi la App non funziona.

Osservando il livello di diffusione delle diverse versioni di Android  si può vedere come esista una certa frammentazione.

Update:

Aggiornato il 19/10/2020 in seguito ad una conversazione su twitter in cui sono emersi anche altri fattori:

https://platform.twitter.com/widgets.js 

Considerazioni su Riforma Costituzionale “Renzi-Boschi” – Lo stile

La riforma (oltre alla trascurabile abolizione del CNEL) riguarda due punti fondamentali: la trasformazione del bi-cameralismo perfetto in un quasi mono-cameralismo e la netta divisione delle competenze tra stato ed enti locali.

Diversi sono gli aspetti che mi lasciano perplesso di questa riforma:

  • lo stile di scrittura
  • la circoscrizione dell’autonomia dall’interno

Qui provo a parlare del primo.

Continua a leggere

The Role of SE Conferences

I rencently served as Program Chair (together with Tore Dybå) for the ACM/IEEE Internatonal Symposium on Empirical Software Engineering and Measurement. The conference has been very successfull with a record high number of submissions.

As program chair we deemed the quality of contributions to be our top priority and in addition we considered the constraint posed by a program articulated on one day and half. We ended up accepting 23 full papers (18.7% acceptance rate) which resulted even lower than ICSE 2014 (the top conference in Software Engineering). This fact originated a little bit of discussion both within and outside the steering committee.

Historically CS conferences has been tough venues and the best ones are typically valued (at least within the field) as much as good journals and they typically exhibit quite low acceptance rates. In the initial days of software engineering a few journal existed where papers on that topic could be published. Therefore, forcefully, conferences became where SE research found publication venues. Actually conferences remained a very relevant publication type, at leaset during the 90s.

Though, recently, the hysteria about research evaluation and the fact that in most other fields conferences papers are hardly considered publications led to the praxis of considering journal papers only, when it comes to research evaluation.

So my question is what is the future role of conferences in the software engineering (and more in general computer science)?

Should the conferences become mainly meeting and networking events as it is usual in other fields? If this is the way to go we have to wonder whether we should also radically change the revision process: moving from an in-depth reviews from three or more program committee members on the full version of the paper to an easy evaluation of an extended abstract only. Let’s face it: if only journal publication count, why spending a lot of effort in writing and reviewing papers for a conference? Let’s take it easy.

On the other end, if we believe some (not all) conferences represent significant publication venues, we ought to be selective, look for quality papers that are relevant contributions to the discipline.

I have to admit that I lean mostly towards the latter at least as far as ESEM is concerned.