Collaudo del software: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
→Modello di sviluppo: aggiunti cenni su agile e varie precisazioni |
|||
Riga 39:
=== Sviluppo a cascata ===
Il procedimento tradizionale di [[Sviluppo software|sviluppo del software]], detto "[[Modello a cascata|a cascata]]" (in inglese "''waterfall''"), prescrive di iniziare il collaudo appena è completata la prima versione del prodotto. I risultati del collaudo vengono utilizzati per rivedere i requisiti, o il progetto, o il codice, e produrre così la versione successiva.
Questo procedimento è stato sottoposto a una severa critica in quanto ha i seguenti svantaggi:
* Se è giunta la data prevista per il completamento del prodotto, si tende a consegnarlo anche se il collaudo non è stato completato o ha dato esito negativo, il che significa che probabilmente si sta consegnando un prodotto scadente.
* Probabilmente, tra i requisiti non è stata inclusa la "collaudabilità" (in inglese, "''testability''"), cioè il progetto e il codice non contengono accorgimenti che agevolino il collaudo. In tal caso, il collaudo risulterà molto più costoso e meno efficace.
* Più tempo passa tra l'introduzione di un errore in un sistema e la segnalazione di un malfunzionamento dovuto a tale errore, più risulta difficile e costoso rimediarvi.
*Dato che il software in tale modello è previsto che venga sottoposto a test solo dopo aver completato la fase di sviluppo, l'eventuale feedback raccolto in fase di prova non può essere usato per alimentare tempestivamente l'apprendimento del team di sviluppo in modo tale che la qualità del codice possa essere migliorata come nei metodi iterativi ed incrementali (come può avvenire ad es. nei metodi "[[Metodologia agile|agili]]"). Pertanto nel modello di sviluppo in cascata le "lezioni apprese" possono essere utilizzate solo in eventuali successivi progetti di sviluppo, il che spesso ne limita l'effettivo valore aggiunto, in quanto la distanza nel tempo dalla fase di raccolta non agevola la applicazione.
Riga 50:
{{Vedi anche|Test Driven Development}}
Un procedimento più recente, detto "guidato dal collaudo" (in inglese, "[[test driven development|''test driven development'']]"), proposto a partire dall'inizio degli anni 1990, consiste nel considerare il collaudo una parte integrante del prodotto:
* Quando si analizzano i requisiti del software da produrre, si analizzano i requisiti del collaudo.
* Quando si progetta l'architettura del software da produrre, si progetta l'architettura del collaudo.
| |||