Il approccio incrementale utilizza un numero stabilito di passaggi e lo sviluppo va dall'inizio alla fine in un percorso lineare di progressione.
Lo sviluppo incrementale viene effettuato in fasi dalla progettazione, implementazione, test / verifica, manutenzione. Questi possono essere suddivisi ulteriormente in sottomasi ma i modelli più incrementali seguono lo stesso schema. Il Waterfall Model è un approccio di sviluppo incrementale tradizionale.
L'approccio iterativo non ha un numero prestabilito di passaggi, ma lo sviluppo è fatto in cicli.
Lo sviluppo iterativo è meno interessato al monitoraggio del progresso delle singole funzionalità. Invece, l'attenzione è posta sulla creazione di un prototipo funzionante prima e sull'aggiunta di funzionalità nei cicli di sviluppo in cui i passaggi di Increment Development vengono eseguiti per ogni ciclo. La modellazione agile è un tipico approccio iterativo.
Il modello incrementale è stato originariamente sviluppato per seguire il tradizionale modello di catena di montaggio utilizzato nelle fabbriche. Sfortunatamente, la progettazione e lo sviluppo del software ha poco in comune con la produzione di beni fisici. Il codice è il progetto, non il prodotto finito dello sviluppo. Le buone scelte di progettazione sono spesso "scoperte" durante il processo di sviluppo. Bloccare gli sviluppatori in un insieme di ipotesi senza il contesto appropriato può portare a progetti scadenti nel migliore dei casi oa un deragliamento completo dello sviluppo nel peggiore dei casi.
L'approccio iterativo sta diventando una pratica comune perché si adatta meglio al percorso naturale di progressione nello sviluppo del software. Invece di investire molto tempo / sforzi nella ricerca del "design perfetto" basato su ipotesi, l'approccio iterativo consiste nel creare qualcosa che sia "abbastanza buono" da avviare e evolvere per soddisfare le esigenze dell'utente.
tl; dr - Se stavi scrivendo un saggio sotto il modello incrementale, proverai a scriverlo perfettamente dall'inizio alla fine di una frase alla volta. Se lo hai scritto sotto il modello iterativo, sbattere una bozza veloce e lavorare per migliorarlo attraverso una serie di fasi di revisione.
Aggiornamento:
Ho modificato la mia definizione di "Incremental Approach" per adattarla a un esempio più pratico.
Se hai mai avuto a che fare con il contratto, l'Incremental Approach è il modo in cui viene eseguita la maggior parte dei contratti (specialmente per i militari). Nonostante le molte sottili variazioni del tipico "Waterfall Model", la maggior parte / tutte sono applicate allo stesso modo nella pratica.
I passaggi vanno come segue:
- Contratto di aggiudicazione
- Revisione preliminare del progetto
- Revisione critica del design
- Congelamento delle specifiche
- sviluppo
- Fielding / Integrazione
- Verifica
- Test di affidabilità
Il PDR e il CDR sono i luoghi in cui le specifiche vengono create e riviste. Una volta che la specifica è completa, dovrebbe essere congelato per impedire il creep dell'oscilloscopio. L'integrazione si verifica se il software viene utilizzato per estendere un sistema preesistente. La verifica serve a verificare che l'applicazione corrisponda alle specifiche. L'affidabilità è un test per dimostrare che l'applicazione sarà affidabile a lungo termine, questo può essere specificato come un SLA (Service Level Agreement) in cui il sistema è necessario per sostenere una certa percentuale di tempo di attività (ex 99% di operatività per 3 mesi ).
Questo modello funziona alla grande per i sistemi che sono semplici da specificare su carta ma difficili da produrre. Il software è molto difficile da specificare su carta con qualsiasi grado di dettaglio apprezzabile (ex UML). La maggior parte dei "tipi di business" responsabili della gestione / contrattazione non si rendono conto che, quando si tratta dello sviluppo del software, il codice stesso è la specifica. Le specifiche cartacee spesso impiegano più o meno tempo / sforzo per scrivere come il codice stesso e in pratica si rivelano incompleti / inferiori nella pratica.
Gli approcci incrementali tentano di sprecare tempo / risorse trattando il codice stesso come specifica. Invece di eseguire le specifiche della carta attraverso più passaggi di revisione, il codice stesso passa attraverso più cicli di revisione.