Der einfachste Fall der Wartung ist der Neustart: Strg + Alt + Entf :−)
Befinden sich die Programme in Betrieb, so werden an ihnen oft Veränderungen und Erweiterungen vorgenommen. Mögliche Wartungsarbeiten sind der Austausch von bestimmten Algorithmen durch leistungsfähigere (z. B. schnellere) oder der Einbau zusätzlicher Benutzerfunktionen. In der Regel enthält das Programm noch Fehler, die sich erst im laufenden Betrieb herausstellen und im Rahmen der Wartung korrigiert werden. Viele Programme hängen auch von gesetzlichen Bestimmungen oder Tarifvereinbarungen ab und müssen regelmäßig aktualisiert werden. [INFODUDEN]
Die Wartung kann als Nachbesserung des im Betrieb befindenden Softwareproduktes betrachtet werden. Es ist die (hoffentlich) letzte Phase und bringt selbstverständlich auch ein Dokument, das alle Änderungen protokolliert, hervor.
Die Kosten der Wartung hängen besonders stark von den Vorgängerphasen ab:

• Aus dem Entwurf geht die Hierarchie der Unterprogramme bzw. der Module insbesondere der Laufzeitbibliotheken hervor. Unterprogramme können durch verbesserte Versionen ersetzt werden, ohne dass das System neu installiert werden muss (Update).
• Im Falle einer Reinstallation müssen die bereits vorhandenen Benutzereinstellungen und -projekte respektiert werden. Deshalb sollten komplizierte Sicherungen der Benutzerdaten von Unterprogrammen automatisch und umfassend erledigt werden können. Es sei denn, die Sicherung selbst bedarf einer Verbesserung (ggf. Konvertierungsfunktionen erforderlich).
• Bei der Spezifikation legt man beispielsweise fest, welche Parameter ohne Compilierung einfach nachjustiert werden können. Gegebenenfalls kann der Endbenutzer selbst durch Ändern der Parameterwerte, das Programm an neue Anforderungen anpassen (HotLine−Wartung).
• Bei der Implementation richtet der Programmierer meist einen alternativen DebugModus ein (Logging), welcher bei Bedarf aktiviert werden kann. Anhand von sogenannten Log−Files kann viel nachvollzogen, insbesondere Fehler aufgespürt werden.
• Automatisch verifizierbare Systeme können jeder Zeit neu getestet werden (SystemSelbstCheck).

Besonders im laufenden Betrieb der Software ist es wichtig, dass die gesamte Entwicklungsdokumentation zur Software einheitlich und aktuell {Was, wenn die Software nicht das macht, was jedoch laut Dokumentation sein sollte?} ist.
Wenn nun neue Anforderungen oder Änderungen fällig werden, muss der Entwickler bzw. der Wartende sich schnell in der Dokumentation zurechtfinden, um dann entscheiden zu können, an welcher Stelle die Software erweitert bzw. geändert werden muss.
Der Softwareproduzent würde nämlich mit vielen Problemen zu kämpfen haben, wenn die Dokumentation nicht mit der Software übereinstimmen sollte:

• Längere Nachentwicklungszeiten z. B. wegen Suche an falscher Stelle im Code,
• Entstehung von unverträglichen Konzepten z. B. Bruch von Konventionen,
• Redundater Code z. B. Neuentwicklung von bereits realisierten Komponenten
• sowie Inkonsistenz im Allgemeinen, die Software kann nicht mehr richtig wachsen.

Bei Inkonsistenzen in der Dokumentation wird der Entwickler früher oder später gezwungen sein, die Dokumentation an die bereits realisierte Software anzupassen. Die Alternative dazu ist nämlich erschreckend, die Software stagniert — keine weiteren Änderungen aus Entwicklerseite erwünscht — sonst kann das fehlerfreie Verhalten der Software nicht mehr garantiert werden.