Ogni errore ha un costo, perchè costringe a rivedere il lavoro svolto per correggerlo. Gli errori con il costo più elevato sono quelli che vengono rilevati dopo molto tempo, o molte fasi.

Un errore di codifica, se viene rilevato nella fase di test, ha un costo bassissimo, in quanto lavoro di routine per il programmatore; un errore o una incomprensione tra l’analista e il cliente, che viene rilevata solo alla consegna del prodotto, obbliga a rivedere l’analisi, la progettazione, riprogrammare il codice, rieseguire i test, rielaborare la manualistica e effettuare un nuovo addestramento del personale che userà la procedura.

Da queste considerazioni nasce il ciclo di vita a prototipo rapido.

In questo ciclo di vita, dopo una prima analisi sommaria, viene prodotto un prototipo dell’applicazione. L’utente vede così il risultato di ogni sua richiesta e può verificare se l’analista ha colto tutti gli aspetti del problema o se ci sono ancora delle incomprensioni di fondo.

La serie delle verifiche prosegue attraverso vari prototipi, finchè, raggiunta una situazione stabile e completa, si procede alla costruzione vera e propria del programma secondo il ciclo tradizionale. Questo ciclo cerca di ridurre al minimo i "salti lunghi", cioè gli errori costosi avvicinando il momento dell’accettazione del progetto da parte del cliente alla fase di analisi.

Cos’è un prototipo? un prototipo deve essere un programma che presenta la stessa operatività del programma finale, pur richiedendo pochissimo tempo per essere sviluppato.

Entrambi questi aspetti sono estremamente logici: se il prototipo non rispetta quello che sarà il risultato finale, il cliente non è in grado di verificare se la strada intrapresa è quella giusta; se il prototipo non viene sviluppato in tempi rapidissimi (e con costi contenuti) , ritorniamo ai problemi del ciclo di vita in cascata.

Ma queste due considerazioni sono antitetiche: come è possibile costruire in tempi rapidissimi un prototipo funzionante dell’intera applicazione? Si possono sfruttare fondamentalmente due appigli: efficenza ed estetica.

Il prototipo sarà usato solo per verifica, non per ottenere risultati reali; quindi non è richiesta una grossa efficienza, e neppure la capacità di trattare grossi volumi di dati. Anche l’aspetto estetico in questa fase non è fondamentale: l’utente può caricare i dati anche con maschere parziali o non curate, magari in bianco e nero e non a finestre.

Queste considerazioni ci portano a indicare gli strumenti necessari per implementare questo ciclo di vita: 4GL e generatori di applicazioni.

I 4GL sono dei linguaggi specializzati, ad altissimo livello, che permettono di ottenere un programma completo scrivendo pochissime righe di codice. I generatori di applicazioni invece sono programmi che partendo da alcune definizioni, creano in modo automatico il codice completo per l’intera procedura.

In entrambe i casi lo scotto che si paga è un programma a volte poco efficiente (se si deve ottenere una funzionalità non prevista), o addirittura l’impossibilità di costruire parti di programma che escono dalla casistica trattata dal linguaggio o dal generatore.

Entrambi gli strumenti hanno però le caratteristiche necessarie per coprire la fase di costruzione del prototipo, con un leggero vantaggio da parte dei generatori che alla fine della fase prototipale hanno già prodotto un codice nel linguaggio di terza generazione che verrà usato per lo sviluppo effettivo del programma.