L'idea di "manutenzione del software" deriva dal pensare che il software possa essere gestito nello stesso modo di qualsiasi progetto di ingegneria. Ogni progetto ha un ciclo di vita:
- Analisi dei requisiti
- Progettazione / Pianificazione
- Costruzione / Implementazione
- Uso / Manutenzione
Questo significa che, una volta completato il progetto, sono necessari alcuni sforzi e risorse per mantenerlo in condizioni di lavoro complete. Ma in tutti i casi, la quantità di risorse necessarie per la manutenzione è ridotta rispetto all'attuazione effettiva. Immagina un grande edificio o una macchina complessa. Sì, potresti volerlo ridipingere o sostituire alcune parti, ma in generale rimarrà lo stesso per tutta la sua vita operativa.
Quindi, se si assume che anche il software sia un prodotto di ingegneria, ha anche una fase di manutenzione. Il problema è che l'ipotesi che il software sia lo stesso di qualsiasi progetto di ingegneria è già stato affrontato molte volte. Uno dei problemi legati alla "manutenzione" è che il software è così "soft" da poter cambiare drasticamente anche dopo che la fase di implementazione è ufficialmente terminata. Questo è il motivo per cui alcune persone considerano la "manutenzione" come la maggior parte degli sforzi. Perché anche se sulla carta il software è "finito" è così facile cambiarlo che verrà modificato.
Questo è il motivo per cui la maggior parte delle moderne metodologie di sviluppo del software non hanno realmente una tale struttura ingegneristica e presuppongono che il software non sarà mai "finito" e che può cambiare drasticamente in qualsiasi momento della sua vita. Anche dopo molti anni di produzione.