Waterfall Pitfall #1

4 June, 2007 (22:56) | agile, extreme, programming, xp

Nel corso degli ultimi anni sono state spese molte parole nel tentativo di spiegare il perchè del fallimento dell’ingegneria del software, talmente tante da rendere difficile il tentativo di riassumerle. Come consulente e “evangelist” delle metodologie Agili, mi sono trovato più di una volta nella condizione di rispondere a domande del tipo: “Perchè le metodologie tradizionali non funzionano?”. L’obiettivo è quello di rispondere nel modo più breve e convincente possibile, il pericolo, è quello di perdersi e non essere sufficientemente incisivi, sopratutto affrontando il discorso con passione e con molte argomentazioni in testa, per questo nel corso degli anni ho sintetizzato la mia risposta “standard” e l’ho suddivisa in tre punti che affronterò in tre post distinti. Questo è il primo


waterfall
La strategia di base è quella di accompagnare il proprio interlocutore in una sequenza di implicazioni logiche che ci porteranno a demolire tutte le assunzioni che stanno alla base delle metodologie ingegneristiche, una delle quali (se non la principale) è l’analogia fra l’attività di produzione del software e le fasi di realizzazione di un artefatto di produzione ingegneristica/manifatturiera

Lo scopo iniziale era quello di “ereditare” dalle scienze ingegneristiche quella formalità che avrebbe potuto salvare la produzione del software, devo ammettere che all’epoca questo tentativo aveva un suo perchè, quello che non ammetto è che nei 30 anni seguenti nessuno l’abbia più messo in discussione

Lo mettiamo in discussione noi adesso utilizzando l’onnipresente metafora della costruzione del ponte. Prendiamo ad esempio la fase di Progettazione, a questa fase viene dato molto peso e rigore in quanto un errore causerebbe un danno economico rilevante nella fase successiva di Costruzione, ovvero la fase più lunga e onerosa. Parrebbe logico fare lo stesso discorso anche per quanto riguarda il software, si sa che un errore di Design fatto all’inizio del progetto può causare in seguito dei seri problemi, ma…


ponte
Analizziamo meglio la fase di Progettazione, abbiamo detto che è una fase molto rigorosa, talmente rigorosa da produrre un modello che rappresenta in maniera corretta e completa ciò che si andrà a costruire. Nel mondo dell’edilizia tale modello è indispensabile, in quanto la fase di Costruzione è una semplice traduzione del modello nell’artefatto che esso rappresenta, senza aggiunta ne perdita di informazioni

Succede la stessa cosa anche nel software? Se la fase di Progettazione di un ponte si conclude con la realizzazione di un modello matematico/fisico dello stesso, cosa viene realizzato alla fine della fase di Design? Una serie di diagrammi UML? Riuscite a pensare ad un modello del software che abbia le stesse caratteristiche di quello del ponte? Esiste un modo per rappresentarlo in maniera corretta e completa? Un modello da poter tradurre senza perdita o aggiunta di informazioni?


code
La risposta è di una semplicità imbarazzante, il codice sorgente. Proseguiamo con il ragionamento, se il modello del nostro prodotto è il suo codice sorgente, qual’è la fase successiva? Abbiamo detto che la Costruzione è la traduzione del modello nell’artefatto, quindi la risposta è altrettanto semplice, la compilazione. Da qui viene la frase che dico sempre: “la manodopera non esiste nel mondo dell’informatica, gli unici operai in questo settore sono i computer”

Notate come la fase più dispendiosa da un lato (Costruzione) venga messa in relazione con la fase meno costosa dall’altro (Compilazione), questo ci porta alla prima conclusione: le metodologie ingegneristiche utilizzano un processo che è stato pensato per gestire delle limitazioni fisiche (la costruzione costosa e irreversibile dell’artefatto) che il codice non ha! Questo per esempio ci consente di adottare delle strategie iterative/incrementali che sarebbero impossibili in ambito ingegneristico

Se non vi ho convinto, non preoccupatevi, questo è solo il riscaldamento, non perdetervi il resto :-)

P.S. Se qualcuno sta pensando al fatto che esistono modelli alternativi di rappresentazione del software, preciso subito che il discorso non cambia di una virgola: se il modello è semanticamente ben specificato è possibile scrivere un compilatore per esso, altrimenti, se il modello è ambiguo, per definizione non è corretto e completo (cvd)

Comments

Pingback from All software works ok | Open eyes Working brain
Date: March 31, 2010, 10:59 pm

[...] by Ryan Brush’s “Code is Design” in 97 Things Every Programmer Should Know and by Gabriele’s “Waterfall Pitfall #1″ (italian), software construction is understood in terms of the better known building construction. And since [...]

Write a comment