Tutti se la prendono con il modello di sviluppo software a cascata.

Da un certo punto di vista fanno bene perché è una soluzione che ha diversi difetti, come ad esempio il fatto che non consente di utilizzare la esperienza e la conoscenze acquisite nel corso del progetto.

Però, nonostante questo,  ci sono dei pregi che gli vanno riconosciuti. Non tanto perché lui si offenda (è un modello non può offendersi!) ma il rischio è sempre quello di gettare via il bambino con l'acqua sporca.

Sono stato quindi contento di leggere questo post dove Peter Stevens ne sottolinea i principi (cito letteralmente):

Waterfall says:
1. Figure out the business requirements first
2. Don't change your requirements while you are implementing
3. Test your code to ensure that it works