"Don't rub the lamp if you don't want the genie to come out."
(dt.: "Reibe nicht an der Lampe, wenn du nicht möchtest, dass der Geist heraus kommt.")
(Unbekannt)

Änderungen

Mit jeder Änderungsanforderung geht natürlich ein Stück des Projekts wieder von vorne los, mitsamt Erstellen der Anforderungen, Analyse, Designänderungen, Implementierung, Test, Übergang zum Kunden, Anpassung der Dokumentation und auch Fehlerbehebung und Wartung. Hier wird also oft mit einem leichtsinnig geäußerten Wunsch eine ganze Lawine (bzw. Iteration) losgetreten (s. Spruch oben auf dieser Seite). Man sollte sich immer vor Augen halten, dass "Änderungen" im Gegensatz zu "Fehlern" etwas geplantes sind, d.h. man muss auch wieder gemäß der ursprünglich vereinbarten Planungsmethode vorgehen.

Spätestens mit Beginn der Wartungsphase gibt es ein etabliertes Echtsystem! Dies wirkt sich natürlich auf den Entwicklungsprozess aus, denn man muss nun Rücksicht auf die bereits erfassten Daten nehmen und alle Änderungen vor dem Übergang erst auf dem Testsystem mit den Echtdaten vom Kunden testen lassen. Es müssen also auch für Datenbanken Änderungsskripte verfasst werden. Insbesondere müssen Wege gefunden werden, die den Einbau neuer Funktionalitäten in eine bereits arbeitende Software ermöglichen. Die Anwender sind ja bereits geschult, die Handbücher verteilt und die Arbeitsschritte ggf. bereits gefestigt. Ganz wichtig ist es, zu verhindern, dass vorher stabile Funktionalitäten durch Änderungen oder vermeintliche Verbesserungen instabil, also "verschlimmbessert" werden. Im Zweifelsfalle kann dies nur über sehr intensive und ggf. gar vollständige Tests sichergestellt werden. Oft wird erst zu diesem Zeitpunkt festgestellt, wie sensibel Software gegen Änderungen sein kann, was auch zu dem Spruch "Never touch a running system!" (dt.: "Fasse niemals ein laufendes System an!") geführt hat.

Doch Software altert! Und sei es auch nur, weil die Hardware sich schnell erneuert oder das Betriebssystem unten drunter rasante Fortschritte macht. Wenn Sie heute ein Microsoft Word 5.5 für MS-DOS ans laufen bringen müssen, dann verstehen Sie, was ich meine. Finden Sie mal ein MS-DOS und dazu die passenden Treiber für Ihre Hardware - das wird spaßig. Wenn Sie eine maßgeschneiderte Software ablösen sollen, die 1974 auf einer VAX programmiert wurde, fängt der Spaß schon beim Bandformat und der Dateicodierung an (schließlich müssen Sie ja die Altdaten übernehmen). Ich bekam Ende 2003 eine Diskette zugesandt, die Dateien von 1979 enthielt - da zeigt der Explorer von Microsoft Windows nichtmals mehr das Dateidatum an! Ich wunderte mich überhaupt, dass ich von der Diskette noch was einlesen konnte, denn stellenweise war sie so stark abgenutzt, dass man schon hindurchsehen konnte! Ich denke, diese kleine Auswahl reicht schon, um zu beweisen, dass Software wirklich altert - und zwar schneller, als man gemeinhin denkt. Wer sich mit dem Aufbewahren und der Lesbarkeit von Informationen über einen langen Zeitraum beschäftigen muss, sollte einen Blick in das Buch [B3] werfen.

Es gibt auch Fälle, wo die Software nach dem Projektende nur noch geringfügig geändert wird. Ich habe mal mit einem Kollegen in Assembler ein Betriebssystem für eine Speicherschreibmaschine entwickelt (die erste mit LCD und aufrüstbarem Speicher); nach dem Projektende wurde tatsächlich kein neuer Programmstand mehr in PROMs gegossen. Heute wäre das sicherlich anders: bei Digitalkameras kann beispielsweise oft per USB-Kabel eine neue Softwareversion in die Flash-Speicher der Kamera geladen werden, aber große Änderungen sind das auch nicht. Wenn Sie in ein paar Jahren beim Betanken Ihres Autos gleichzeitig ein Software-Update erhalten, sind die Änderungen hoffentlich auch nur Verbesserungen. Wenn es sich nicht gerade um Gerätesoftware handelt, werden in aller Regel in gewissen Abständen größere Updates fällig, die ein gut geplantes Versionsmanagement erfordern. Manchmal dienen auch hier die Updates nur dazu, mit Betriebssystem und Hardware Schritt zu halten oder Fehler auszumerzen, aber manchmal wird Software auch erst nach einigen Updates richtig erwachsen; dies hat zu der Weisheit geführt: "Kaufe niemals eine Version 1.00".

Bei kundenspezifischer Software (also Individualsoftware) werden Folgeversionen häufig über Nachträge zum Hauptvertrag, Wartungsverträge mit festen Intervalls oder Dauerbestellungen mit abrufbarem Stundenkontingent abgewickelt. Diese Verträge gestalten sich oft schwierig, weil beispielsweise der Kunde in aller Regel nur schwer nachweisen kann, dass ein Fehler wirklich mit dem Update reingekommen ist und nicht vorher schon drin war. Wenn die Gewährleistungsfrist abgelaufen ist, geht das Gerangel schon direkt wieder los. Oft wird die Wartung aus bestimmten Gründen auch nicht von dem Unternehmen durchgeführt, dass die Software ursprünglich entwickelt hat. Dann lehnt der neue Partner natürlich die Verantwortung für den alten Code ab - was nicht immer einfach auseinander zu halten ist.

Change Management
Change Control Boards
Bei großen Projekten bereits mit Kick-Off-Meeting direkt unter dem Projektlenkungskreis etablieren.