Nel mio metodo per l’analisi del software, vi ho parlato del lato più romantico dell’analisi: non mancano però i lati pratici e tecnici che renderanno la vostra analisi precisa, fino a consentire una progettazione pragmatica del software e a portare chiarezza in ogni fase analitica e progettuale.

La pratica dell’analisi è mutata parecchio con gli anni, dal metodo a cascata fino all’agile development.

Premessa personale

Io sono contrario alla navigazione a vista e preferisco che l’analisi sia un testo sempre presente in tutto il ciclo di sviluppo del software, un documento compiuto ma allo stesso tempo non dogmatico che consenta di tenere il timone dritto fino alla consegna di ogni fase.

Prima di affrontare la scrittura di questo testo mi son messo a ripassare (non fa mai male) le varie fasi canoniche della stesura di un’analisi del software: Una noia mortale, mi è venuto da chiedere agli Dei del coding:

Ma il mio lavoro è davvero così noioso? Eppure mi appassiona. Cosa c’è in questa fredda tecnica che posso dire al riguardo? Cosa posso dire per far capire che è un lavoro speciale e pieno di risvolti positivi?

E per l’appunto ho iniziato a scrivere tutto ciò.

Iniziamo!

Enumeriamo le fasi di un’analisi, in una versione che ho asciugato personalmente di passaggi troppo tecnici e noiosi, magari cercando di vederle nell’ottica giusta:

• I goal: quello che si vuole realizzare e a cui non si vuole rinunciare: enumerate gli obbiettivi che il software si propone, scriveteli ognuno su un documento come fossero capitoli del vostro romanzo, dategli un titolo chiaro che ricorderete; scriveteci sotto una breve descrizione.
• Stabilire i processi necessari: ogni parte del software avrà necessità a volte comuni, a volte differenti. Commentate il vostro “romanzo” con un secondo paragrafo: qui ci vorrebbe questo software o questa api di supporto, questo server web, questa libreria etc.
• Definire le architetture (ormai una sola è rara) che formeranno il software: Andate in coda al vostro romanzo e scrivete come titolo: Requisiti del sistema: Ora riempite il capitolo con la lista di una possibile configurazione del sistema che farà girare il vostro software: Esempio: Linux + nginx + nodeJS & Express + MongoDB
• Elencare i requisiti funzionali: Ogni capitolo del vostro romanzo necessita di nuovi paragrafi; quali sono le funzioni necessarie a realizzare l’obbiettivo a titolo di ogni paragrafo? Enumeratele e descrivetele sommariamente.
• Enumerare i requisiti complementari: fate una lista di tutte le cose necessarie ma non facenti parte del Goal del titolo, cose tipo “questa parte è soggetta alla GDPR mettiamola nel documento relativo, serve che l’utente finale accetti le condizioni generali etc.”
• Evitare ambiguità e generalizzazioni nei requisiti: “Dobbiamo disegnare un coniglio, bianco che sorride” è un requisito; “Qui mettiamo un animale simpatico” No. Se avete scritto qualcosa di generico nelle fasi precedenti rendetela compiuta.
• Definire l’hardware e il software necessario per server e client: andiamo nel nostro capitolo finale e aggiungiamo sotto alle architetture software delle specifiche per il “ferro” necessario, possibilmente simulate in varie scale di utenza. Scriviamo inoltre i requisiti Hardware e Software necessari per gli utenti. (Es. Browser Chrome ver. 49 o successiva, scheda grafica openGL ES etc.) 
• Creare un modello del software: Qui se siete ingegneri risponderete da soli UML: Io personalmente tendo ad utilizzare grafici più rozzi che facciano da trait d’union tra professionisti e cliente.
• Definire gli attori (team, marketers, tester, users etc.): Fate un elenco in ogni capitolo di chi ritenete debba prendere parte alla realizzazione del Goal. Poi a fine romanzo fate un indice con tutti assieme. 
• Stabilire i confini (regolamenti di legge, aziendali etc.) Annotate in ogni goal le difficoltà burocratiche o di legge che devono essere risolte: Esempio: contattare un legale per la GDPR, nominare il DPO, questa parte andrebbe brevettata etc.
• L’orologio: il piano di lavorazione; se avete esploso bene il modello del software non dovrete far altro che “pesare” le attività richieste per ogni blocco funzionale e assegnargli un tempo “virtuale” che poi servirà moltiplicare o dividere a seconda di come le attività verranno disposte sul GANTT 
• Grafici e presentazioni per gli azionisti: Una volta che avete pronta tutta l’analisi, riassumetela in una breve presentazione dotata di grafici per il Cliente e i suoi azionisti. Sarà apprezzata.