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
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.