Quale metodo per l’Internet of Things?

Quale metodo per l’Internet of Things (IoT)? Come condurre i progetti?

In un articolo in Communications of the ACM, novembre 2017,
Is There a Single Method for the Internet of Things? , Ivar Jacobson e colleghi si pongono la domanda e individuano due metodi: Ignite e IoT Methodology.

Ma servono davvero metodi nuovi? Secondo gli autori, anche i metodi per lo sviluppo di soluzioni IoT devono integrarsi nel framework Essence da loro definito (l’evoluzione di Semat, fatta propria dall’Object Management Group).

In questo modo lo sviluppo di soluzioni IoT può essere confrontato con quello di altre tipologie di sistemi e sfruttare le pratiche che si sono dimostrate utili in altri settori, evitando di ripartire da zero (e dover reinventare la ruota).

Lo scopo di Essence-Semat, come affermano gli autori, è infatti quello di definire un terreno comune con cui poter mettere a confronto metodi diversi, per enuclearne le pratiche  che possono adattarsi nel modo migliore alle esigenze di ogni specifico ambito.

Il design è un’attività continua, non solo una fase

Nell’approccio a cascata, il design è una fase (periodo di lavoro) distinta, con un inizio e una fine definiti e criteri di ingresso e uscita specificati.

Il design visto come fase (cioè periodo delimitato nel tempo) era adeguato alla produzione industriale tradizionale, e ad altri settori come l’edilizia. Ora è meno adeguato, in quanto gli utenti (consumatori, clienti) stanno diventando sempre più esigenti e impongono ai propri fornitori un miglioramento continuo.

The world that digital technology creates is highly complex and ever-changing. There is rarely now a simple and clear-cut design phase, followed by an installation or rollout phase. The system being designed has become fluid. It needs to be constantly optimized and refined. The interface must be constantly evolving based on customer feedback. In this sort of world, design becomes a constant process and a way of thinking.

Come scrive Gerry McGovern in Design has become a continuous activity, le organizzazioni sono costrette ad adeguarsi alla crescente maturità dei propri clienti, ad ascoltarli e a migliorare continuamente il design del proprio prodotto o servizio.

Il vero rischio dell’intelligenza artificiale

Molti, sempre più spesso, mettono in guardia sui rischi dell’intelligenza artificiale.

David Lorge Parnas, uno dei grandi saggi dell’ICT, dall’alto dei suoi 60 anni di esperienza ne mette in questione la stessa esistenza: forse, più che di intelligenza artificiale, bisognerebbe parlare di “stupidità naturale”.

Il vero rischio, secondo Parnas, sta nel fidarsi dei procedimenti euristici (probabilistici) come se fossero algoritmi verificabili:

Instead of asking “Can a computer win Turing’s imitation game?” we should be studying more specific questions such as “Can a computer system safely control the speed of a car when following another car?” There are many interesting, useful, and scientific questions about computer capabilities. “Can machines think?” and “Is this program intelligent?” are not among them. Verifiable algorithms are preferable to heuristics. Devices that use heuristics to create the illusion of intelligence present a risk we should not accept.

The Real Risks of Artificial Intelligence, di David Lorge Parnas, in Communications of the ACM, October 2017

Organizzazione settore IT per prodotti o per progetti

L’organizzazione del settore IT all’interno delle aziende può essere basata su approcci diversi.

In “Products Over Projects”, Sriram Narayan illustra le differenze tra l’approccio organizzativo basato su progetti (orientato tipicamente al solo sviluppo, con risorse allocate in modo temporaneo e tratte da reparti corganizzati per tipo di competenza) e quello basato su prodotti, più stabile e multifunzionale.

https://martinfowler.com/articles/products-over-projects.html

Casi d’uso e scenari alternativi

Lo scenario base di un caso d’uso (descrizione funzionale) può avere numerose varianti. Alcune tra queste sono semplici, altre complesse, e possono a loro volta dare origine ad ulteriori varianti.

Come gestire le varianti di varianti? Me lo ha chiesto una studentessa di informatica, proponendo un esempio interessante, che riporto qui. Nel seguito la mia risposta, con uso degli scenari alternativi.

Buongiorno Dott. Comai,

mi chiamo xxx, studentessa di informatica.

In questi giorni sto tentando di documentare alcuni semplici casi d’uso, utilizzando il suo template:

(http://adcorsi.com/analisidisegnowp/wpcontent/uploads/2013/08/templatecasiuso.odt)

Nel descrivere i casi d’uso mi è sorto, però, un dubbio:

E’ possibile che una variante dello scenario base abbia a sua volta varianti? C’è qualche regola che lo vieta?

Ad esempio, per il caso d’uso PrelievoSoldi (molto semplice) ho il seguente scenario base:

  1. Il cliente inserisce la tessera e inserisce il pin
  2. Il sistema valida il pin
  3. Il cliente indica l’importo da prelevare
  4. Il sistema autorizza il prelievo e restituisce la tessera
  5. Il cliente ritira la tessera, il denaro e la ricevuta.

Vorrei descrivere la situazione particolare in cui il sistema non riconosce il pin (passo 2). In tal caso l’utente può effettuare altri due tentativi, se sbaglia anche l’ultimo tentativo il sistema restituisce la tessera ed il caso d’uso termina con errore.

Non so se la descrizione dell’anomalia sia meglio esprimerla in una sola variante oppure descrivere ogni tentativo come variante di variante. Di seguito le riporto le mie due soluzioni:

Soluzione con unica variante dello scenario base:

2a.Se il sistema non riconosce il cliente, il cliente deve reinserire il proprio pin. Se il sistema riconosce il pin, il cliente torna al passo 3 dello scenario base. Altrimenti, lo reinserisce ancora e se il sistema non lo riconosce nuovamente restituisce la tessera al cliente.

Soluzione con variante per ogni tentativo:

Variante 1:

2a. Il pin non è valido

      1. Il cliente inserisce di nuovo il proprio pin.

        2. Il sistema valida il pin, si ritorna al passo 3 dello scenario

            base

Variante 2: variante della variante 1

2a.2a. Il pin non è valido

        1. Il cliente inserisce di nuovo il proprio pin

         2. Il sistema valida il pin, e ritorna al passo 3 dello scenario 

             base

Variante 3: variante della variante 2

2a.2a.2aIl pin non è valido

              1. Il sistema restituisce la tessera e termina il caso d’uso con errore.

                2. Il cliente ritira la tessera

Spero possa aiutarmi

Grazie

La soluzione è l’uso degli scenari alternativi, cioè di descrizioni di scenario ulteriori rispetto allo scenario base, anche se ad esso riconducibili. In pratica:

Prendere la variante che può avere varianti, e “promuoverla” a scenario alternativo.

Lo scenario alternativo:
1 – è una variante a cui viene attribuito un titolo (es. “Pin non valido”) e che può essere a sua volta articolata in una serie di passi
2 – referenzia il passo dello scenario base da cui parte, come una variante, quindi parte con un “se…”
3 – indica come si conclude il caso d’uso (tornando a un passo dello scenario base, o con un esito diverso)
4 – può avere proprie varianti

Plain Language

Scrivere in modo semplice (Plain Language) per farsi capire meglio da chi ci leggerà.

E’ importante sempre, e lo è in particolare per le specifiche dei requisiti e di analisi dei sistemi informatici, condivise e lette da persone con ruoli diversi:

  • committenti, utenti e altre parti interessate (stakeholder)
  • progettisti e sviluppatori software
  • tester (verificatori del corretto funzionamento del sistema)
  • redattori di manuali operativi

In questa pagina ho riportato una serie di indicazioni e riferimenti: Scrivere in modo semplice.

Un articolo recente del Nielsen Norman Group sottolinea l’importanza del Plain Language anche quando si scrive per un pubblico di esperti: Plain Language Is for Everyone, Even Experts.