Questa fase è sempre sottovalutata: si allocano poche risorse, non si stimano i tempi corretti di manutenzione, si ha sempre l’idea che questo lavoro sia marginale rispetto ai nuovi sviluppi.

Quello che è peggio è che anche in presenza di grossi sforzi manutentivi, questi non vengono riconosciuti, continuando a privilegiare la costruzione di nuovi programmi.

Probabilmente i fattori che spingono a questo atteggiamento sono sia psicologici che economici: creare un nuovo prodotto è molto più affascinante che non correggere e migliorare uno vecchio, ed è molto più facile convincere il cliente a pagare un programma mai visto che un canone di assistenza periodico

La manutenzione si divide in diversi tipi: adattiva, migliorativa e correttiva.

Gli aspetti adattivi tendono a far migrare il software dall’ambiente in cui è stato usato verso nuove realtà operative. Questo può avvenire sia per esigenze pre-stazionali che per una naturale evoluzione dell’hardware.

Proprio nell’introduzione di questo libro abbiamo notato come lo sviluppo dell’hardware corra in modo impressionante rispetto ad ogni altra attività umana. La via migliore per preservare gli investimenti software è far migrare da un computer all’altro i pacchetti che già si usano.

Nel capitolo relativo ai test abbiamo visto come sia praticamente impossibile creare un programma privo di errori. Ogni pacchetto viene rilasciato con un inevitabile bagaglio di errori al suo interno.

Nell’uso verranno via via rilevati, soprattutto in occasione di quegli usi diversi dalla routine come possono essere le chiusure annuali o una nuova installazione.

La manutenzione correttiva interviene a rimuovere questi errori, che normalmente si rivelano più delle sviste che delle gravi lacune di programmazione o algoritmiche.

Il terzo aspetto della manutenzione è il migliorare un prodotto: i programmi invecchiano, diventando pian piano obsoleti. Se non si implementano con continuità nuove prestazioni, dopo un pò di tempo, perdono la loro utilità originale perchè superati dalle sopravvenute esigenze.

Questo fa capire come la manutenzione non sia l’ultima fase di un pacchetto destinato ad essere abbandonato, ma semplicemente un momento tra il termine di un ciclo di sviluppo ed un altro.