Software Usabile e Solido

Cos’è?

Secondo la definizione dell’ISO, l’usabilità è la misura in cui un prodotto può essere usato da utenti specifici per ottenere obiettivi specifici con efficacia, efficienza e soddisfazione in contesti d’uso specifici.

Sebbene datata come definizione (1998) è ancora molto utile perché lega l’usabilità, una proprietà difficile da materializzare, a indicatori di performance degli utenti che invece possono essere misurati o stimati in maniera abbastanza buona; ad esempio svolgendo un test con utenti.
L’efficacia fa riferimento all’insieme degli obiettivi che si dovrebbero poter raggiungere, e gli errori nei risultati e nel percorso.
L’efficienza è legata allo sforzo, al tempo, alla lunghezza del processo necessario per raggiungere quegli obiettivi con un certo livello di efficacia.
La soddisfazione, rilevata mediante questionari (ad esempio il SUS; vedi anche la pagina di Perlman sui questionari per l’usabilità, oppure il Net Promoter Score), ha a che fare con una gamma di aspetti molto ampia, dalla gratificazione dai risultati ottenuti al piacere e coinvolgimento relativo al prIocesso necessario per ottenerli.
Nota che l’usabilità dev’essere contestualizzata: invece di dire “questo prodotto è usabile”, occorre dire “questo prodotto è usabile in questo contesto d’uso per costoro e per fare queste cose”, dove il contesto incorpora vari aspetti quali la postura, l’ambiente fisico, quello sociale, i dispositivi di interazione, lo stato mentale.

D’altro canto, software solido è software che manifesta delle proprietà architetturali quali manutenibilità, adattabilità, estendibilità, riusabilità. Sono tutte proprietà importanti perché aumentano la velocità di sviluppo, riducendo sia il time-to-market che il costo. Più nello specifico, nel contesto del progetto orientato agli oggetti, SOLID è un acronimo attribuito a Michael Feathers che richiama i seguenti principi: Single responsibility, Open-closed, Liskov substitution, Interface segregation, and Dependency inversion. Questi principi rappresentano il nocciolo di ogni progetto orientato agli oggetti e sono i tool concreti mediante i quali si possono ottenere le proprietà menzionate sopra.

È importante sviluppare software che sia solido e usabile?

Siccome è difficile vedere quando un’interfaccia utente è usabile, rovesciamo la domanda. Cosa succede quando un’interfaccia utente è poco usabile?

Succede che la base della User Experience (UX) manca: l’interfaccia sarà bella, attraente, il sistema sarà facile da vendere, ma gli utenti tenderanno a smettere di usarlo per via di frustrazioni, difficoltà nel ricordare come usarlo, errori che si commettono, tempo e fatica impiegati nel capire come aggirare gli ostacoli.
Il Servizio Clienti continuerà a ricevere reclami da utenti insoddisfatti, che non porranno più alcuna fiducia sul sistema, e ne parleranno male, evitando ove possibile di usarlo.
Il team di sviluppo faticherà a rattoppare l’interfaccia nella speranza di migliorarla.

Un’architettura software solida e usabile conduce a un sistema stabile nel tempo:

L’interfaccia utente sarà debolmente accoppiata al resto del sistema. Quindi sue modifiche avranno un impatto minimo sul resto del sistema, che non le vincolerà.
Un’interfaccia utente usabile sarà meno soggetta a modifiche, perché già adeguata e tarata alle esigenze degli utenti.
Il modello concettuale dell’interfaccia, che è la base dell’interfaccia, è stabile perché si appoggia su un modello di dominio che è stato ben progettato, e quindi che riflette proprietà dello spazio del problema (stabili) piuttosto che proprietà dello spazio della soluzione, come ad esempio tecnologie e dettagli implementativi (più instabili).
Il sistema supporta modifiche senza che si incappi in effetti domino o in rischi inaspettati, dato che l’architettura è modulare e stratificata.

Perché entrambi, solido e usabile?

Un’interfaccia utente usabile va bene, ma essa manifesta solo proprietà esterne di qualità. Che ne è di proprietà interne? Ad esempio, è importante che il sistema sia resiliente al cambiamento dato che le modifiche avverranno di continuo: perché alcuni requisiti mancano, alcuni sono errati, un nuovo segmento di mercato si è aperto, nuove feature, nuovi task, nuove tecnologie sono apparsi, il sistema deve poter interoperare con altri nuovi sistemi, etc. A meno che l’architettura non sia solida queste modifiche saranno costose e rischiose da implementare. D’altro canto, un sistema solido privo di un’interfaccia utente usabile verrà sempre meno usato.

In conclusione, l’ottenimento di un sistema solido e usabile rappresenta un buon bilanciamento di caratteristiche di qualità interna ed esterna. La qualità esterna fa riferimento a ciò che può essere percepito da utenti durante l’uso del sistema e che influenza la UX, mentre la qualità interna riguarda ciò che viene misurato dal team di sviluppo durante lo sviluppo e la manutenzione, e influenza il costo di produzione e il tempo di rilascio. Un’attività sostenibile di sviluppo del software richiede che l’organizzazione raggiunga determinati livelli di qualità interna; nello stesso modo, il successo del prodotto nel mercato richiede qualità esterna.

Come si fa a produrre un sistema solido e usabile?

La nostra esperienza ci suggerisce che un approccio iterativo di gestione agile di un progetto che combini le seguenti attività risulta efficace.

Ingegneria dei requisiti, nella quale, tra l’altro, si indentificano soggetti interessati, loro esigenze e preferenze, dove le user story vengono fatte emergere, dove personaggi e scenari d’uso vengono definiti, dove diagrammi di affinità che rappresentano come i task possono essere svolti vengono creati.
User-centered development, dove le caratteristiche ed esigenze degli utenti vengono comprese durante tutto lo svolgimento del progetto, dove prototipi dell’interfaccia vengono costruiti in modo da ridurre l’incertezza, dove valutazioni di usabilità vengono svolte ripetutamente al fine di validare scelte progettuali.
Lean UX, approccio moderno alla definizione in corsa di un prodotto (product discovery) che vede nelle osservazioni derivanti dal sistema in esercizio lo spunto principale per un continuo miglioramento del prodotto.

Una gestione agile del progetto può essere combinata con pratiche rigorose di ingegneria del software quali:

Domain Driven Design, dove un modello del dominio viene sviluppato come nocciolo dell’architettura, che riflette il dominio del problema e riduce la distanza tra analisi e design.
Design for Testability, dove varie tecniche (asserzioni, design by contract, built-in self test, principi di design, fault-injection) vengono utilizzate in modo da valutare correttezza e affidabilità.
Continuous Integration, dove gli sviluppatori usano un sistema di gestione delle versioni con cui fare il commit in una repository, e non appena una modifica alla repository viene individuata, una procedura automatica si incarica di generare una nuova versione eseguibile del sistema, che viene subito testata automaticamente, così da fornire agli sviluppatori un feedback quasi immediato.

Aspetti in comune e differenze

Cos’hanno in comune usabilità e solidità?

Il modello concettuale dell’interfaccia utente (ovvero, modello dei dati e delle operazioni che l’utente può manipolare) è la base per avviare un processo di Domain Driven Design, che conduce a un modello più sofisticato del dominio, che al termine funge da base su cui radicare il modello concettuale.
Lo sviluppo è iterativo in entrambi i casi: nel primo caso serve per ridurre l’incertezza relativa al sistema da costruire, mentre nel secondo serve per rendere il processo di sviluppo più trasparente.

E le differenze?

Il modello concettuale non è la stessa cosa del modello di dominio, dato che il primo deve essere adatto agli utenti (che potranno essere esperti, ma forse anche principianti assoluti nel dominio). Il modello del dominio invece, costituisce le fondamenta del sistema, e quindi deve coprire tutte le possibili viste che ci potrebbero essere sul dominio, da parte di tutti i possibili soggetti interessati, inclusi anche altri sistemi con cui occorrerà interoperare.
Ovviamente cambia l’ambito: interfaccia utente per l’usabilità, e archittettura per la solidità.

SOFTWARE USABILE E SOLIDO

Software Usabile e Solido

Cos’è?

È importante sviluppare software che sia solido e usabile?

Come si fa a produrre un sistema solido e usabile?

Aspetti in comune e differenze