Viele individuelle Softwarelösungen in Unternehmen und Verwaltungen werden jahrzehntelang genutzt. Sie erfüllen ihren Zweck, die Nutzer sind mit ihnen vertraut, sie passen optimal zu den Geschäftsprozessen. Auch wenn sie nach einigen Jahren altmodisch wirken und die Benutzerführung sowie das Design nicht mehr den Ansprüchen an moderne Systeme genügen, gibt es für viele Jahre keinen Grund, sie aufwändig durch eine neue Lösung zu ersetzen.
Umso älter die Software wird, desto schwieriger wird es, die Lösung in eine neue Welt zu bringen. Eine Windows-Anwendung etwa, die direkt auf eine Datenbank zugreift, kann nicht einfach zu einer modernen Web-Applikation umgebaut werden. Aber selbst, wenn die Softwarearchitektur nicht grundsätzlich verändert werden soll, selbst wenn die Plattform und die Umgebungen, in denen das System entstanden ist, sich in den vergangenen Jahren nur evolutionär weiter entwickelt haben, wird eine Aktualisierung immer schwieriger, je mehr Versionsnummern zwischen der Zeit der Entstehung und der Gegenwart liegen.
Notwendige Neuprogrammierung
So stellt sich irgendwann die Frage der Neuprogrammierung der Software. Zur mangelnden Ergonomie der Benutzeroberfläche kommt, dass immer mehr Module und Schnittstellen in aktuellen Umgebungen schlicht nicht mehr funktionieren. Das Problem ist dann oft, dass der Aufwand, der in so ein Projekt gesteckt werden muss, dem Nutzen nicht zu entsprechen scheint: mit hohen Kosten und einem kaum abzuschätzenden Zeitbudget auf der Seite der Betroffenen wird eine neue Lösung bereitgestellt, die am Ende kaum mehr kann als das vertraute System und an die man sich zudem erst einmal gewöhnen muss.
Was ist zu tun? Am Anfang steht eine schonungslose Bestandsaufnahme dessen, was da ist. Alte Individualsoftware, die über Jahrzehnte im Einsatz ist, wird oft etwas euphemistisch als ein „gewachsenes System“ bezeichnet. Was bedeutet das wirklich? Über viele Jahre wurde die Lösung oft an vielen Stellen weiterentwickelt, an neue Prozesse und Anforderungen angepasst und erweitert. Dies geschah oft ohne ausführliche Spezifikation und Dokumentation im Dialog zwischen Entwicklern und Anwendern. Die Folge eines solchen Vorgehens über Jahre ist, auch wenn es fast unvermeidbar ist, dass die Lösung im Innern immer unübersichtlicher wird, und dass niemand mehr genau weiß, was die Funktionen im Detail wirklich im Einzelfall tun – man weiß nur, dass es irgendwie das Richtige ist.
Auf der anderen Seite gibt es Teile der Software, die von niemandem mehr genutzt werden, von denen man oft irgendwann nicht mehr weiß, ob sie noch gebraucht werden, ob irgendein Nutzer noch damit arbeitet. Das ist bei Funktionen an der Oberfläche noch relativ unproblematisch, weil man wenigstens im Prinzip ermitteln kann, welche Menüpunkte und Schaltflächen noch verwendet, welche Berichte und Auswertungen noch genutzt werden. Wenn es aber „unter die Motorhaube“ geht, wenn Spezialfälle in einem Algorithmus oder in einer Auswertung besonders behandelt werden, dann ist es problematisch, wenn das Wissen darüber nur „im Code“ steckt – und noch problematischer ist es, wenn niemand mehr weiß, ob der Spezialfall überhaupt noch eine Rolle spielt. „Wachstum“ von Software heißt über Jahre leider oft, dass ein undurchsichtiges Gestrüpp entsteht, bei dem niemand mehr weiß, ob ein Ast längst tot ist oder ob er die Hälfte des Gewächses mit Nahrung versorgt.
Schrittweises Vorgehen ist notwendig
Wenn man als Softwareentwickler vor die Aufgabe gestellt wird, den Aufwand für das Neuerstellen einer solchen Software zu schätzen, bleibt einem gar nichts anderes übrig, als nach einer ausführlichen Analyse des bestehenden Systems an vielen Stellen Aufschläge für Überraschungen vorzusehen. Das Ergebnis sind oft Schätzungen, die weit jenseits der Erwartungen des Auftraggebers liegen, die aber dennoch realistisch sind. Im Ergebnis wird das Projekt der Neuprogrammierung noch weiter hinausgezögert, was aber nur den Effekt hat, dass es am Ende noch teurer wird.
Die Alternative besteht darin, ein schrittweises Wachstum der neuen Lösung zu konzipieren.
Die Analyse-Phase
Dazu ist zuerst die Frage zu beantworten: Was sind die zentralen Aufgaben, die mit der Software unterstützt werden sollen? Andres gesagt: Welche Geschäftsprozesse stehen im Fokus der Software? Wer sind die Benutzer, was genau machen sie mit der Software?
Detaillierter ist zu klären:
- Welche Funktionen werden tagtäglich im Alltag benötigt?
- Welche Funktionen werden regelmäßig, aber seltener (monatlich, jährlich) gebraucht?
- Welche Funktionen sind nicht zwingend notwendig, auch wenn sie geschätzt werden und hin und wieder hilfreiche Unterstützung im Alltag bieten?
- Welche Funktionen sind veraltet, auch wenn sie nützlich wären, entsprechen aber nicht mehr den Anforderungen?
- Welche Funktionen werden gar nicht mehr genutzt?
Am Ende dieses Analyse-Prozesses kann durch eine systematische Betrachtung aller sichtbaren Funktionen ermittelt werden, ob es Funktionen in der Software gibt, die sogar ganz in Vergessenheit geraten sind oder unbekannt sind.
Ein solcher Analyse-Prozess wird immer lückenhaft bleiben müssen, da oft versteckte Funktionen existieren, die in Vergessenheit geraten sind, die aber dennoch in bestimmten Spezialfällen gebraucht werden. Dabei kann es sich sowohl um Benutzer-Interaktionen handeln, an die sich die Nutzer erst wieder erinnern, wenn sie sie brauchen, oder auch um Spezialfälle in Berechnungen, Algorithmen und Berichten, die im Hintergrund notwendig sind, deren Existenz aber in Vergessenheit geraten ist.
Ziel des Analyse-Prozesses ist es immer, einen Fahrplan zur Umsetzung der Neuprogrammierung zu entwerfen, der den Aufwand auf das Minimum reduziert und der sicherstellt, dass nach und nach die notwendigen Funktionen bereitgestellt werden.
Implementierung eines Basis-Moduls
Von dieser Analyse ausgehend kann ein Basis-Modul für eine Neuentwicklung konzipiert und als Prototyp entwickelt werden. Dieses sollte die Funktionen enthalten, die täglich benötigt werden. Für die Inbetriebnahme des Basis-Moduls – zunächst im Parallelbetrieb zur Alt-Anwendung – wird ein Termin festgelegt. Von diesem Termin ausgehend wird festgelegt, zu welchen Terminen weitere Funktionen (die seltener, aber zu bestimmten Zeiten, etwa zum nächsten Quartals- oder Jahresende, gebraucht werden) implementiert werden müssen.
Bei der Entwicklung des Prototyps und des Basismoduls werden die wichtigsten Benutzer eng einbezogen. Das hat zwei Effekte:
- Während des gemeinsamen Tests fallen den Benutzern oft Besonderheiten auf, die während der Analyse vergessen wurden, oder es wird festgestellt, dass Funktionen doch anders benötigt werden, als es vor Jahren, als die alte Software entstand, der Fall gewesen ist.
- Die Benutzer lernen bereits die neue Oberfläche und Nutzerführung kennen. Das erleichtert den schnellen Einstieg und die Akzeptanz der neuen Lösung.
Die Inbetriebnahme und Testphase werden intensiv von den Entwicklern begleitet, denn in dieser Zeit fallen die vergessenen Funktionen auf, die in besonderen Fällen benötigt werden. Hier muss agil und zügig reagiert werden, es ist wichtig, dass Auftraggeber und Entwicklungsfirma dafür von Anfang an Zeit und Budget vereinbaren.
Time Boxing
Parallel zur Inbetriebnahme des Basismoduls werden die Prioritäten zu den weiteren Schritten konkretisiert, überarbeitet und ergänzt – die Implementierung weiterer regelmäßig benötigter Funktionen wird entsprechend des Zeitplans umgesetzt.
Schon bei der Implementierung des Basis-Moduls, vor allem aber bei der Umsetzung der weiteren Schritte, kommt der Einhaltung der Termine größte Bedeutung zu, da eine effektive Nutzung der neuen Lösung nur möglich ist, wenn nach der ersten Inbetriebnahme die Teilfunktionen bedarfsgerecht bereitgestellt werden. Deshalb muss, vor allem, wenn sich bei Tests und Besprechungen zeigt, dass bestimmte Details noch nicht berücksichtigt waren, immer wieder Termintreue gegen die Priorisierung der Umsetzung abgewogen werden.
Ergebnis
Im Ergebnis der dargestellten Vorgehensweise wird folgendes sichergestellt:
- Termingerecht wird eine neue Lösung erstellt, die bei allen Benutzern auf Akzeptanz stößt.
- Kosten für die Spezifikation und die Umsetzung werden minimiert, da nur das spezifiziert und implementiert wird, was wirklich gebraucht wird, alter Ballast wird abgeworfen.
- Es entsteht eine Lösung, die an zukünftige Anforderungen kostengünstig und schnell angepasst werden kann.