#BIMpill – Waterfall
Nell’ultima pillola di agosto, concediamoci una digressione e qualche riferimento sulle origini del Waterfall, l’insieme di metodi per la gestione dei progetti considerato più tradizionale e forse il più glorificato in un’industria delle costruzioni che si ritiene spesso troppo seria per metodi agili e gestioni snelle. Abbiamo già visto da una parte come la gestione […]
Nell’ultima pillola di agosto, concediamoci una digressione e qualche riferimento sulle origini del Waterfall, l’insieme di metodi per la gestione dei progetti considerato più tradizionale e forse il più glorificato in un’industria delle costruzioni che si ritiene spesso troppo seria per metodi agili e gestioni snelle.
Abbiamo già visto da una parte come la gestione snella e lo sviluppo incrementale nascano appositamente per gestire problemi complessi in situazioni altamente adattive e sarebbero quindi più adatti per un progetto di edilizia.
Scavando nelle origini del Waterfall, scopriamo dall’altro lato come anche questo abbia origini nello sviluppo del software e nasca dalla committenza militare negli Stati Uniti (come anche lo schema COBie).
In particolare tra le sue prime menzioni troviamo il DOD-STD-2167A, del 29 febbraio 1988, in cui si stabilisce che:
«The contractor shall implement a software development cycle that includes the following six phases: Software Requirement Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing»
Nello schema perfezionato da Winston W. Royce nel suo Managing the Development of Large Software Systems (1970) le fasi sono cinque o sei, a seconda della versione.
Quello che però troppo spesso ci si dimentica è che anche in Waterfall il processo è da intendersi come iterativo: le fasi non si chiudono in modo irreparabile prima dell’inizio della successiva ma, al contrario, lo sviluppo della successiva impone una revisione e una verifica su quella precedente e sulle altre fasi del processo ad essa collegate.