Modelli iterativi
Osservando il modello a cascata e le sue varianti ci si è ben presto resi conto che la stringente sequenzialità delle fasi costituiva un grosso limite non conciliabile con la flessibilità richiesta dallo sviluppo software e con la naturale mutevolezza dei requisiti imposti dal cliente. Si inizia dunque a pensare di permettere agli sviluppatori di ripetere alcune fasi più di una volta, ciclando su di esse fino a ottenere un prodotto soddisfacente, nascono così i primi modelli interativi.
Modello a cascata con singola retroazione
Uno dei primi modelli iterativi è in realtà una variante del modello a cascata, in cui si permette di fare un’unico salto indietro, quindi a parire da una fase si può ritornare alla fase precedente (ad esempio si può iterare tra Codifica e Testing fino a consegnare il prodotto). In realtà sfruttando questa nuova introduzione è facile notare che è possibile eseguire delle iterazioni complete che vanno dalla fase dei requisiti fino alla fase di testing.
Anche in questo modello non si può però tornare indietro dalla consegna per eseguire attività di manutenzione; inoltre, l’introduzione di un’iterazione rende molto più difficile pianificare il lavoro e monitorarne l’avanzamento: si tratta di una caratteristica condivisa da molti modelli iterativi.
Modello prototipale
Un particolare modello incrementale è quello protitipale, in questo modello viene introdotto il concetto di protitipi usa e getta (throw away), interi programmi che vengono costruiti e poi vengono buttati via.
Lo scopo del prototipo non è consegnare un prodotto finito, ma ricevere feedback dal cliente per essere sicuri di aver compreso a pieno i suoi requisiti, oppure testare internamente un’idea o uno strumento. Per questo motivo tali prototipi vengono costruiti fregandosene di correttezza, pulizia del codice e leggibilità. I protitipi possono dunque essere:
- pubblici: per capire meglio i requisiti del cliente (vd. L3);
- privati: nel mondo agile sono chiamati spike, e servono a esplorare nuovi strumenti, linguaggi e scelte per problemi difficili; inoltre, molto spesso succede che una volta programmata una soluzione, il problema viene compreso meglio (“do it twice”).
I prototipi pubblici possono generare la tentazione di consegnarli come prodotto finito, ma c’è l’enorme rischio di dover gestire in futuro un software non mantenibile, con codice illeggibile e con un altissimo debito tecnico.
La propotipizzazione riduce significativamente gli errori di analisi dei requisiti e di design, specialmente per le interfacce utente.
Il modello prototipale è iterativo perchè ogni volta viene buttato il lavoro fatto e rieseguito da capo, questo fino ad avere una versione definitiva senza le problematiche incontrate che hanno causato l’eliminazione dei lavori precedenti.