Post
 |
| 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. |
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