Nel capitolo precedente sono state identificate le fasi che percorre un programma durante la propria vita: analisi del problema, stesura del progetto, realizzazione del codice, test, consegna del programma e manutenzione. Il modo con cui queste fasi vengono combinate dà origine ad un particolare "ciclo di vita".

L’oggetto di tutte queste fasi, dello studio e della realizzazione è sempre lo stesso: la soluzione informatica ad un problema dell’utente, ma assume via via vari aspetti con il procedere del lavoro.

Per l’utente il problema è definito in modo semplice, non tecnico, legato al settore in cui opera. Tutto il sistema è visto in modo particolarmente astratto, con specifici metodi elaborati nel tempo per dare significato ad ogni parte dell’insieme.

Questa visione è poi la base dei test di accettazione, nel senso che anche se non è completamente formalizzata, è il metro di giudizio che verrà impiegato per considerare terminato e accettabile l’intero progetto.

L’analista trasforma le indicazioni dell’utente in una rappresentazione formalizzata del problema, seguendo particolari metodologie.

Questa rappresentazione è generalmente più complessa rispetto alla visione del cliente, perchè inizia a tener conto dei problemi informatici anche se in modo completamente indipendente dalla soluzione che poi verrà adottata.

Il programmatore recepisce il risultato dell’analisi, ed arriva alla realizzazione della soluzione. Per fare questo ingigantisce il problema, perchè deve tener conto di tutte le "necessità" del computer.

A questo punto la soluzione è diventata molto grossa, dipende dal linguaggio e dal sistema prescelto, ed è molto difficile da modificare.

Ad ogni fase l’oggetto trattato quindi cambia aspetto, assume nuove forme che pur rispettando sempre quanto precedentemente stabilito, tendono al risultato finale: un programma che risolve il problema del cliente.

Ma quand’è che viene verificato il risultato di ogni fase? Che vuol dire anche: quando si riesce a sapere se il lavoro è stato svolto correttamente ed è di buona qualità?

La risposta a queste domande è abbastanza semplice: le sei fasi in cui abbiamo diviso la vita di un programma si presentano divise in tre realizzative e tre di verifica del lavoro svolto.

Se le fasi realizzative si susseguono con una certa logica, il processo di verifica si estende in ogni caso e per ogni prodotto in ognuna delle altre tre.

La bontà di una analisi viene verificata nella fasi di progetto, alla consegna ed in fase di manutenzione; un buon progetto viene apprezzato da chi realizza il codice, ma mostra le proprie qualità soprattutto in manutenzione; una buona codifica porta a test ridotti e programmi mantenibili ed estendibili.

Da queste considerazioni viene evidenziato un problema: non sempre lavoro e verifica avvengono in momenti vicini nel tempo! E più lontani sono il processo di creazione con quello di verifica, più costoso sarà riparare agli errori che verranno riscontrati.

Stabilire un ciclo di vita è dunque stabilire delle caratteristiche e delle previsioni su come sarà svolto il lavoro, scegliere un determinato modello di sviluppo influenzerà le attività da svolgere in ogni fase.

Un ciclo in cascata ci obbliga a fare delle analisi estremamente accurate, mentre se adottiamo il ciclo a prototipo rapido dovremo prevedere dei sistemi di codifica veloci ed economici.

Non sempre è possibile scegliere il ciclo di vita, perchè è il tipo di applicazione o di cliente che ci obbliga a seguirne uno, in ogni caso è importante conoscere a priori le risorse necessarie e i problemi a cui andremo incontro, in modo da dotarci degli strumenti adeguati.