Attualmente sto leggendo alcune pubblicazioni sui modelli di sviluppo del software. Ovunque guardi, leggo solo i problemi con il modello Waterfall e come l'approccio di sviluppo iterativo e incrementale risolva questi problemi. Ma non riesco a trovare alcuna informazione su quando evitare questo approccio.
Quindi, per quale tipo di progetti dovresti evitare uno sviluppo iterativo e incrementale?
La necessità di uno sviluppo iterativo e incrementale sulla maggior parte dei progetti software deriva dal fatto che i requisiti di quei progetti sono in costante cambiamento e il fatto che rapidamente producendo un prototipo per iterarlo sembra produrre risultati migliori rispetto al tentativo di produrre un specifiche complete prima di iniziare lo sviluppo.
L'unica situazione a cui posso pensare dove ciò non si potrebbe applicare è quella in cui è facile implementare il progetto, ma progettarlo è difficile, e una volta progettato non può essere facilmente modificato. Ad esempio, un nuovo linguaggio di programmazione o il software incorporato per alcuni dispositivi fisici o il dispositivo stesso (sebbene non sia più un software). In questi casi, riuscire a farlo correttamente nella prima versione potrebbe essere molto più importante della possibilità di rilasciare in qualsiasi momento o rispondere rapidamente dopo il rilascio.
Naturalmente, non ci sono assoluti. Per andare con il mio esempio di linguaggio di programmazione, Clojure è stato progettato nel corso di due anni e mezzo da un solo ragazzo prima che pubblicasse qualcosa per il pubblico. Il rovescio della medaglia, Rust ha avuto molte versioni alfa che hanno rotto le funzionalità di base prima di stabilirsi su una versione 1.0 stabile. Ho sentito cose positive su entrambe le lingue.
In generale, più è difficile cambiare le cose dopo il rilascio, più si vuole fare affidamento su design e test iniziali piuttosto che su prototipi e iterazioni future. Ma personalmente, non vorrei mai evitare lo sviluppo iterativo; Al massimo accetterei a malincuore la sua impraticabilità.
In alcuni progetti, devi seguire un rigoroso processo di sviluppo, che potrebbe non essere iterativo. Un esempio per questi è nel settore aerospaziale quando devi fornire software con gli standard DO-178B / C e simili.
Per uno, non hai nemmeno una scelta in questi casi. Non potresti svilupparlo in modo iterativo, neanche se lo volessi. Ma ancora più importante, questi progetti non si prestano molto bene allo sviluppo iterativo.
Pensa a scrivere software di controllo che viene sparato nello spazio (letteralmente!). Non c'è più margine di miglioramento una volta che è in volo (è già diverso se la tua cosa inizierebbe a funzionare sulla Luna o sulla ISS, perché le patch software diventano possibili). Inoltre, l'hardware sottoposto a controllo è in genere molto maturo ei requisiti sono stati ben analizzati e raramente soggetti a modifiche.
Casi simili si verificano nel software che deve essere certificato. Mentre è possibile sviluppare quelli iterativamente, c'è un certo punto in cui devi dichiarare il tutto completo per ottenere la certificazione. Dopodiché, non devi più toccare il software o la tua certificazione è nulla. Di nuovo, uno scenario che non favorisce esattamente lo sviluppo iterativo.
Detto questo, noto comunque sempre più progetti software in questi settori che vanno verso sviluppi incrementali (all'interno della cornice immutabile degli standard richiesti). Inoltre, viene prestata molta attenzione a ridurre la quantità di software che non può essere sviluppato in modo iterativo (o richiede solo la certificazione) e separarlo chiaramente dal software rimanente. I vantaggi monetari di questa mossa sono ovvi (almeno a chiunque abbia mai visto il costo del software che controlla un aereo), ma sono anche i vantaggi tipici del libro di testo dello sviluppo incrementale a cui gli sviluppatori del prodotto sono interessati.
Leggi altre domande sui tag development-process development-methodologies waterfall iterative-development