EthicSoft Informatica Analizzare O Riallineare
Licenza:
I contenuti di questo articolo sono proprietà intellettuale dei relativi autori e protetti ai sensi dell'art. 1 della legge italiana sul diritto d'autore n. 633 del 22 aprile 1941.
La copia, parziale o integrale, è illegale escluso il caso di citazioni di lunghezza massima di un singolo paragrafo e il cui testo sia completamente incluso in un link a questa pagina.

Analisi progettoIl valore dell’analisi nella programmazione

Perché “perdere” tempo per fare analisi in informatica in realtà è guadagnare tempo?

Mi è capitato di riflettere una settimana su un problema, parlare con le persone interessate, e quindi scrivere codice per un giorno ottenendo risultati efficienti ed efficaci.
Mi è anche capitato di dover partire in quarta con specifiche approssimative e incrementali, da riallineare periodicamente. In questo caso il risultato è stato che in diverse settimane si è ottenuto un lavoro di qualità mediocre, ovvero ho dovuto fare un lavoro inefficiente ed inefficace.

Perché 2 ore di lavoro di analisi mancata diventano 20 ore di modifiche in corso d’opera?

Perché relativamente poche modifiche in corso d’opera possono duplicare tempi e costi di un progetto?
La conseguenza dei una analisi carente, quando non sia il fallimento completo del progetto, è il riallineamento in corso d’opera per inserire valore aggiunto che si poteva ottenere subito e a basso costo.
Possiamo sintetizzare i motivi nel degrado strutturale, nel mantenimento del progetto e nel fattore umano.

I riallineamenti portano degrado strutturale

Una analisi debole produce basse performance nella realizzazione del software.
Essendo l’efficienza della realizzazione legata ai costi, e l’efficacia del software legata al valore realizzato, una analisi insufficiente porta ad un innalzamento dei costi produttivi e ad un abbassamento del valore prodotto.

Inefficienza

Il lavoro non integrato nel progetto iniziale tipicamente comporta o buttare via il lavoro precedente e doverlo rifare, dimezzando l’efficienza delle ore di lavoro rispetto ai risultati.

Inefficacia

Poi per definizione, quando una funzionalità non era stata pensata in fase di analisi, dover fare una modifica, incastrando qualcosa in qualcos’altro che non era pensato per supportarla, porta ad una situazione in cui il supporto funzionale necessario ad una buona riuscita dell’operazione è scarso.
Il risultato abbassa l’efficacia del software, perché a quel punto, per motivi di budget e tempo, si abbassa ulteriormente l’efficienza ri-progettando a livello strutturale oppure “si fa quel che si può“.

Esempio

Prendiamo ad esempio la generazione di un testo dinamico preso da database in una pagina web già stata progettata e scritta una volta: Qui il lavoro in parte andrà rifatto, inoltre a priori non è detto che quella pagina includa tutte le funzionalità e librerie necessarie, quindi potrebbe essere necessario fare una modifica più ampia oppure introdurre un “tapullo” appesantendo la pagina e rendendola meno mantenibile.
Riuscendo a prevedere la modifica in fase di analisi si poteva valutare, progettare, fare e ottenere immediatamente questa funzionalità con un costo di almeno 1/3 di costo in termini di tempi, lavori e impatto sulla qualità.

L’analisi riduce il costo del processo realizzativo

Questo tipo di inefficienze si accumulano per via dello scorrere del tempo e del fatto che il progetto non vive in un contesto isolato, con risorse dedicate full time 24/7 ed in quantità costante, ma si affianca ad altre attività le quali hanno le loro priorità e risorse.

La priorità scende o diventa incostante

Avendo preventivato X giornate, includendo sia attività che imprevisti, e potuto riempire il resto del tempo con altre attività, se si aggiunge troppo lavoro non pianificato o si lavora in modo troppo inefficiente, il lavoro non preventivato finisce per debordare nei tempi morti, rallentare per dover essere ri-pianificato, o quando sia quello a maggior priorità danneggia altre attività portando costi indiretti al sistema produttivo.

Allungare i tempi di rilascio ha un costo intrinseco

Allungare il progetto ha un costo intrinseco, che apparirebbe anche se non si facesse alcun intervento nel periodo in più.
Questo perché esistono dei costi di mantenimento giornalieri per praticamente ogni progetto, quali operatività del server, stipendio di eventuali persone dedicate, costi legali, ecc.. Inoltre se il progetto attende di essere rilasciato si aggiungono i mancati guadagni del periodo posticipato del rilascio, e se il prodotto è particolarmente innovativo in questo periodo si perde valore innovativo.

Il fattore umano amplifica i costi di riallineamento

Fattore fondamentale: I progetti sono in mano ad esseri umani.

Fattore “focalizzazione”

La discontinuità causata sia dal tempo tra le specifiche che dalle conseguenti ri-pianificazioni e allungamenti di tempi, aggiunge un fattore “defocalizzazione” ovvero tra un intervento e l’altro il personale si dimentica il dettaglio delle scelte tecniche fatte (parliamo di codici in centinaia o migliaia di punti di intervento, non si possono tenere a memoria, vanno ristudiati ogni volta), quindi chi lavora al progetto deve ristudiarsi il pezzo su cui intervenire, tempo che tipicamente supera quello dell’intervento (pensiamo a quanto tempo serve per prendere la mira e a quanto per sparare), il fattore umano quindi amplifica l’inefficienza e l’inefficacia strutturale e logistica.

Manutenibilità

Un software che esce da una buona analisi sarà sicuramente più pulito, con giri meno contorti e più lineari, con concetti incapsulati meglio, più modulare, più estensibile e con meno ridondanze inutili.

Tutti questi fattori portano ad un innalzamento della manutenibilità ed estensibilità.

Anticipando il maggior numero possibile di funzionalità note alla fase di analisi, quando anche si dovessero fare modifiche in corso d’opera queste saranno fatte in un ambiente più pulito e amichevole, ottenendo risultati più efficienti ed efficaci.

Seguimi
Seguimi

Latest posts by Luca Colombi (see all)

Licenza:
I contenuti di questo articolo sono proprietà intellettuale dei relativi autori e protetti ai sensi dell'art. 1 della legge italiana sul diritto d'autore n. 633 del 22 aprile 1941.
La copia, parziale o integrale, è illegale escluso il caso di citazioni di lunghezza massima di un singolo paragrafo e il cui testo sia completamente incluso in un link a questa pagina.