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.

La prossima apocalisse software

La prossima apocalisse software, The Coming Software Apocalipse, avverrà perché stiamo realizzando sistemi che vanno oltre la nostra capacità intellettiva.

The Coming Software Apocalipse, un articolo di James Somers su The Atlantic, descrive come la troppa enfasi sul codice, e la poca attenzione ai requisiti e al ragionare per modelli, crea rischi insostenibili in un mondo sempre più regolato dal software.

Software aziendale fuori dal settore IT

La quantità di software che le aree aziendali acquisiscono al di fuori dal controllo del settore IT continua a crescere, e rende sempre più critica la gestione del parco applicativo aziendale.

In “Bottom-Up Enterprise Information Systems: Rethinking the Roles of Central IT Departments“, gli autori

Modern technology (such as open source software, outsourcing, and cloud computing) enable users to bypass central IT to procure or configure their own enterprise information systems.

Coupled with inherent organizational limitations, the result is bottom-up enterprise information systems becoming a new reality in many organizations. Managing such systems requires central IT to be a collaborative partner that guides functional areas toward effective IT practices. Central IT’s operational role may diminish as the functional areas assume increased duties.

However, when IT roles are distributed across the organization, additional coordination is required by central IT, functional areas, and vendors alike.

Imparare a imparare

Ci sono blocchi mentali da rimuovere, per poter imparare cose nuove.  Apatia, arroganza, noia, confusione, scetticismo. Poi soprattutto paura di non farcela, ansia, frustrazione, impazienza, insicurezza, rassegnazione.

Per imparare a imparare è necessario riconoscere questi “modi” negativi e non permettere che ostacolino l’apprendimento.

Learning to Learn“, di Peter Denning e Gloria Flores in Communications of the ACM, December 2016, esplora i modi negativi, spiega che ruolo giocano nel bloccarci e come superarli.

Perché superarli si può, innanzitutto con la consapevolezza che, in ogni nuova competenza da acquisire, siamo tutti principianti.