Dal punto di vista più generico possibile, qualunque tipo di programma, di gestione archivi, di sistema, real-time, di controllo vive tre momenti fondamentali: definizione, sviluppo, manutenzione.

Queste tre fasi si ritrovano sempre, indipendentemente dal problema preso in esame, dal paradigma di sviluppo scelto, dal ciclo di vita impostato.

Nella prima fase si definisce cosa (what) verrà creato: lo sviluppatore identifica i dati da trattare e le funzioni caratteristiche del sistema, costruisce un modello dell’attività da eseguire, stabilisce i vincoli e le prestazioni richieste.

Il risultato di questa fase sono le specifiche ed i criteri di validazione dell’intero progetto, cioè deve essere prodotto un documento che servirà a verificare se il progetto è stato completato con successo.

In effetti il software, rispetto agli oggetti materiali, è molto più elusivo, difficile da "vedere" e controllare; per una casa è semplice verificare se è finita: deve avere il tetto, le pareti, le porte e le finestre. Chiunque ha dei metri di giudizio per comprendere se una casa è terminata o ancora in lavorazione. Un programma invece si ‘nasconde’ all’interno del computer, l’unica parte visibile è l’interfaccia utente, che però potrebbe anche essere solo una bella facciata senza alcuna colonna di sostegno. Non c’è altro modo per comprendere quando un prodotto può considerarsi completo se non confrontare l’oggetto sviluppato con le linee guida e i test di validazione decisi in questa fase.

La seconda fase è quella del come (how): tutte le specifiche, risultato del passo precedente, devono essere tradotte in un programma comprensibile al calcolatore.

Per raggiungere questo obiettivo ci sono tre sottoattività: impostare l’architettura dell’intero progetto software dividendo le funzioni in moduli e definendo i tracciati record, scrivere le righe di codice che realizzano ogni singolo modulo, testare il risultato.

Al termine di questa fase ci ritroviamo con un programma completo, pronto per essere "posto in opera".

Dopo un periodo di prima verifica, di addestramento del personale, di assestamento del prodotto, il sistema entra lentamente a regime.

Si passa così all’ultima fase, quella di gestione della crescita del prodotto (change).

Questa attività di manutenzione può a sua volta essere divisa in due aspetti: uno di correzione e l’altro di crescita.

Nessun prodotto esce dalle "linee di programmazione" completamente privo di errori, e man mano che l’uso rivela delle imperfezioni, queste vengono corrette ed eliminate. Più esaustivi saranno stati i test "in house" da parte dello sviluppatore, meno critica sarà questa attività; anche se è sicuramente vero che le condizioni di test in laboratorio, con archivi caricati di dati fittizi, non riescono mai a garantire una sicurezza totale del prodotto.

Il secondo aspetto della manutenzione è la crescita del prodotto.

Un sistema informativo, una procedura, un piccolo programma, una volta posti in opera, rivelano nuovi aspetti che prima non potevano essere presi in considerazione, come nuove gestioni dei dati prodotti, estensioni a settori prima non considerati, o addirittura fanno nascere nuove attività perchè le persone prima impegnate a elaborare i dati ora dispongono di tempo libero.

In un certo senso, ogni soluzione informatica modifica l’ambiente che l’ha generata, quindi chi utilizza un programma non è più chi lo ha richiesto, ma un nuovo soggetto con nuove richieste e nuove necessità.