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