venerdì 24 marzo 2017

Specifiche (cioè il contrario di "vedémo, mettémo, levàmo, checcevò?")

Mini serverino casalingo Intel NUC (in basso)
con scheda grafica esterna (in alto)
inclusa nel suo specifico case esterno con ventole
e collegata al serverino su porta Thunderbolt 3.
Non c'entra niente con l'articolo ma mi piace.
Per scrivere un software servono le specifiche, cioè la descrizione completa, precisa, senza ambiguità, coerente, verificabile, sia per il contenuto che per l'autorità ("chi" può aggiornare "cosa"), tracciabilità ("chi" ha stabilito "cosa"), priorità ("questo" è più importante di "quello"). In breve: le specifiche servono a togliere dubbi passati, presenti e futuri.

Più è delicato il software e più le specifiche devono rispettare quelle caratteristiche. Ogni ambiguità o mancanza, infatti, sostituisce l'ingegnerizzazione con la fantasia e le incertezze (e dunque la fretta e la confusione) di chi dovrà scriverlo, collaudarlo e documentarlo. Le specifiche non devono dire quanto tempo e quante risorse servono: questi sono infatti aspetti commerciali, non tecnici, e vanno concordati in altra sede.

Quando alla committenza viene dimostrato che le specifiche fanno veramente cagare, immediatamente cambia idea (il che significa che lo sapevano già e che nel frattempo hanno tentato di prenderti per il sedere). Per questo è indispensabile continuamente dichiarare a prescindere che le specifiche fanno cagare: in tal modo la committenza sfoltirà da sola, a poco a poco, gli svarioni più madornali, oppure rifilerà il pastrocchio a qualcuno più ingenuo di te.

Vediamo qui sotto alcuni esempi in cui bisogna prendere a calci nel sedere chi ti consegna specifiche non proprio perfette.


Esempio 1: specifica incompleta o addirittura inesistente.

"Ma come? ti ho scritto una mail di due pagine per spiegarti come devi realizzare una via di mezzo tra Facebook e Twitter orientata alla vendita di cibo per cani, e ti lamenti pure?" ... "Ma come? ti ho detto in ogni dettaglio come devi realizzare un clone del prodotto Sbirgnaus del nostro concorrente e aggiungere l'indicizzazione, e ti lamenti pure?" ... "Ma come? ti ho girato i risultati di ricerca Google su come si implementa il protocollo, e ti lamenti pure?"

No comment.


Esempio 2: specifica imprecisa o troppo generica.

"Ma come? ti ho detto che per sicurezza gli accessi devono essere protetti da password, e ti lamenti pure?"

Spiegazione (molto breve) di "protetti da password": database utenze con replicazione, validazione e scadenze password, canale criptografato e workaround conseguenti, separazione privilegi dentro e fuori, livelli di clearance per la manutenzione, aggiornamenti di sicurezza continui con relativi restart, nuove limitazioni alle vecchie e nuove procedure, misure anti-hacking e relativo collaudo, simulazione di intrusione e relativa mitigazione, compliance con le best practices, possibile riscrittura from scratch di procedure basate su librerie obsolete, poco manutenute, o di dubbia fama... (poi i mega-manager si chiedono come mai ragazzini craccano siti web e programmi)

In altre parole: la specifica doveva spiegare cosa si intendeva per "sicurezza" e quali passi occorrono per ottenerla. Non è che uno dice "password" e magicamente le minacce che verranno inventate in futuro vengono già sconfitte.


Esempio 3: specifica ambigua, tipicamente da parte di chi non sa esattamente cosa vuole.

"Ma come? nella specifica c'è scritto chiaramente che l'User Id è incrementato automaticamente e che non devono esistere due utenti con lo stesso account, cos'è che non si capisce?"

Ambiguità: non si capisce se lo User Id è unico, e non si capisce nemmeno se Utente e Account esprimono lo stesso concetto. Per esempio sarebbe stato molto più chiaro così: "l'Account utente è univocamente identificato da un User Id, unsigned 32 bit che cresce monotonicamente".

"Ma come? nella specifica c'è scritto chiaramente che le API supporteranno JSON e XML. Di che ti lamenti?".

Ambiguità: supporteranno adesso oppure in futuro? Le specifiche devono parlare come se il software che descrivono esiste già. Le specifiche non sono letteratura, non servono a far bella figura, ma a farsi capire da chi deve lavorarci su. Devono dare risposte, non domande. Devono fugare dubbi, non crearne.


Esempio 4: specifica non autoritativa, cioè l'estensore non sa fare il suo mestiere.

"Ma come? nella specifica c'è scritto chiaramente che crediamo che siano da supportare più interfacce e che siete invitati ad aggiungere quelle che vi sembrano convincenti, e indicarle qui sotto..."

Questa non è una specifica ma solo l'opinione di uno che ha le idee poco chiare, e che invece di spiegare cosa va fatto e come va fatto chiede opinioni e iniziativa. In realtà andava scritta così: "sono da supportare solo le interfacce Sbrauz 1.x e Sbarabambagnaus, più la Sbrauz 2.0 in sola lettura per i flussi singoli".

Se si prevedono aggiornamenti, possono provenire solo dalla stessa autorità che l'ha scritta e sempre rispettando le sue caratteristiche: "aggiornamento (GD, 47/2017): il supporto della Sbrauz 2.0 deve prevedere anche la lettura di flussi multipli, come documentato negli allegati tecnici 131-GD-2017 e 133-GD-2017".


Esempio 5: specifiche non verificabili, cioè confusionarie.

"Ma come? non è chiaro? l'utente deve poter scorrere la lista immagini dei prodotti in modo veloce e fluido".

Il requisito funzionale ("scorrere immagini") viene vincolato a uno non funzionale, addirittura un concetto ambiguo ("scorrere veloce e fluido"). La parte funzionale è verificabile (si può facilmente stabilire se il software permette di scorrere la lista immagini o no), la seconda parte non è verificabile ("quanto" deve essere veloce? come si misura la fluidità? in quali ambienti deve risultare veloce e fluido?), e addirittura non si capisce se sia più importante la lista o la velocità. Certo che se metto una sola immagine sarà tutto veloce e fluido, no?

Magari poi ti arriva un nuovo requisito funzionale: "scorrere anche le sotto-liste di prodotti". La fluidità si deve applicare anche a queste? Quanto veloce deve essere? Ok, "entro 500 millisecondi": ma su quale piattaforma hardware? con quante immagini e di che dimensioni? Da quale momento deve cominciare il conteggio dei 500: dall'inizio del caricamento della pagina, o dal suo completamento?...

"Ma di che ti lamenti? i report vengono generati in PDF quando richiesto, e devono essere scaricati o inviati via e-mail. Più chiaro di così?"

Confusionario. I report di "cosa" e generati da "chi"? Dell'utente o del manutentore? In quali circostanze possono essere "generati" e in quali no? La confusione è dovuta all'esprimersi con verbi impersonali e senza far capire chiaramente "chi" fa "cosa".


Esempio 6: micromanagement, cioè specifiche che scendono troppo nei dettagli.

"Ma di che ti lamenti? l'utente deve autenticarsi attraverso Facebook cliccando sul tasto di login, e il suo username, avatar ed email andranno inseriti in database".

Le specifiche devono essere complete ma questo non significa spiegare i minimi dettagli. Non si capisce se il dire "inserire in database" implichi come requisito l'avere un database in più, oppure è solo un suggerimento di usare qualcosa di concettualmente simile ad un database. E non si capisce se l'inserimento riguarda solo quei quattro campi oppure se riguarda almeno quei quattro campi.


Esempio 7: specifiche incoerenti.

"Ma di che ti lamenti? il nostro obiettivo deve essere un'interfaccia user friendly ottimizzata per le prestazioni; la parte client va scritta in Java perché così sarà più veloce".

E quando la parte user friendly impedisce di ottimizzare meglio le prestazioni, quale dei due concetti va considerato? E come si fa a verificare quale dei due obiettivi (o entrambi) è stato raggiunto? E cosa garantisce che il solo "scrivere in Java", in quel preciso contesto, migliora la velocità percepita dall'utente finale?


Esempio 8: specifiche senza glossario, le capisce solo chi le ha scritte.

"Ma di che ti lamenti? il TDR delle richieste va in TO a 3000, più chiaro di così!"

Solo che non c'era un glossario che ti dice "TDR = tempo di risposta espresso in millisecondi" e "TO = timeout". Il primo caso è un concetto noto ma espresso con una sigla gergale (e non necessaria), interna a certi settori dell'azienda, il secondo caso è un concetto noto ma espresso con una sigla inutile (nessuno abbrevia "timeout", tanto meno con "TO"). Le sigle come TCP/IP, FIFO, ecc., rintracciabili su wikipedia vanno bene; ma le sigle sconosciute all'esterno dell'azienda vanno spiegate tutte.

Nessun commento:

Posta un commento