Die Migration einer Software auf eine neue Plattform steht an, und die Machbarkeit soll getestet werden, außerdem sollen die größten technischen Herausforderungen identifiziert werden. Die Entwicklung eines Prototypen ist dafür die beste Methode. Was sollte dazu gehören?

Der Prototyp sollte einen Durchstich durch alle Schichten der Anwendung realisieren, somit etwa das Lesen und Schreiben von Daten, die Businesslogik und die Oberfläche umfassen. Allerdings muss hier genauer hingesehen werden. Wenn z.B. die GUI verschiedene Typen von Funktionen umfasst, sollte jeder Typ im Prototypen repräsentiert sein, Masken ebenso wie die Programmsteuerung und Reports. Das Gleiche gilt für die anderen Schichten der Anwendung.

Der Prototyp soll zeigen, wie die Migration erfolgen kann, und das betrifft zweierlei:

1. Wie wird aus den Architekturzusammenhängen der Altanwendung die Architektur der zukünftigen Anwendung? Wenn die Altanwendung z.B. eine Client-Server-Anwendung ist, die in eine Webumgebung migriert werden soll, dann ist damit zumeist auch eine neue Anwendungsarchitektur verbunden. Ein Prototyp ist also immer auch Architekturprototyp.
2. Wie kann der Code der Altanwendung möglichst systematisch (automatisch oder nach engen Programmierrichtlinien) in die neue Architektur übertragen werden? In der Regel ist das mit einem Refactoring der Businesslogik verbunden. Der Prototy sollte es erlauben, strikte Anweisungen für die “Umarbeitung” einer Anwendungsfunktion auf die neue Plattform zu definieren, oder sogar Codegeneratoren zu konzipieren, die aus dem alten Code den neuen erzeugen – wenigstens zum großen Teil.

Schließlich sollte ein Migrationsprototyp möglichst auch ein Oberflächenprototyp sein. An der Oberfläche muss eine Applikationsmigration immer den größten Spagat vollbringen: Einerseits soll der Anwender die vertrauten Funktionen ohne weiteres intuitiv wiederfinden, andererseits hat er zumeinst auch eine Erwartung, wie eine Anwendung in der neuen Umgebung auszusehen hat. Eine PC-Anwendung hat bestimmte typische Oberflächenelemente, die eine Web-Applikation nicht oder anders implementiert – und umgekehrt. Ein Oberflächenprototyp kann zeigen, wie die vertrauten Elemente sich plausibel in der neuen Umgebung wiederfindenlassen – Migration von Anwendungen ist immer ein bisschen so wie behutsame Fassadensanierung, man möchte modernisieren, aber den vertrauten Charme auch bewahren.

Welchen Aufwand hat man, wenn man eine Software, etwa eine Client-Server-Lösung, auf eine neue Plattform migrieren muss? Die Antwort auf diese Frage hängt von vielen Parametern ab, aber wie kommt man auf eine plausible erste Schätzung? Hier ein paar Hinweise.

Gut ist, wenn die Entwicklungsaufwände, welche in die Software seit ihres Bestehens geflossen sind, bekannt sind, etwa durch die Stundenerfassung in der Softwareentwicklung. Von der Entwicklung der ersten Version sollte der Aufwand für die Anforderungsanalyse separiert werden. Sodann werden die einzelnen Releases sowie die Wartungsaufwände daraufhin bewertet, zu welchem Anteil sie Neuentwicklung von Funktionalität waren und welcher Anteil Änderungen der bestehenden Software waren. So erhält man eine erste Vorstellung davon, was eine Neuentwicklung der gleichen Anforderungen kosten würde.

Dieser Gesamtaufwand ist in Entwicklungsaufwand und Testaufwand zu separieren. Während der Entwicklungsaufwand im Migrationsprojekt durch Wiederverwendung zum Teil erheblich reduziert werden kann, ist der Testaufwand kaum zu reduzieren. Allenfalls bei der Erstellung von Testfällen kann Aufwand gespart werden, wenn auf bestehende Dokumente zurückgegriffen werden kann.

Im nächsten Schritt widmet man sich dem Thema Wiederverwendbarkeit. Wenn die verwendeten Entwicklungswerkzeuge auf der Zielplattform ebenfalls verwendet werden können, kann man beurteilen, ob Teile des Codes (eventuell nach einem Refactoring) wiederverwendet werden können, das gilt nicht nur für Programmiersprachen, sondern auch für Frameworks, Reportingtools u.a.

Im Allgemeinen ist allerdings das Migrationsprojekt mit einem Versionswechsel bei den Werkzeugen verbunden. Wenn man zu dem Ergebnis kommt, dass z.B. 70% des Codes wiederverwendet werden kann, beträgt die tatsächliche Einsparung in der Entwicklung wahrscheinlich weniger als 50%, abhängig von der Weite des Versionssprungs, der Sauberkeit der Architektur und der Codequalität.

Die ursprünglichen Aufwände der Anforderungsanalyse können nicht vollständig abgezogen werden, da während der verschiedenen Releases oft die Anforderungen nur unvollständig dokumentiert und aktualisiert worden sind. Ein intensiver Review ist geboten, und das Motto “Der Code ist die Dokumentation” führt oft zu lückenhafter oder falscher Umsetzung in der neuen Software.

Alles in allem sind die Aufwände für eine Migration oft höher als erwartet. Es ist gut, eine Top-Down-Schätzung, wie hier kurz skizziert, an den Anfang zu stellen, und gegen eine Bottom-Up-Schätzung, die auf einer Stückliste (Object Points, Function Points o.ä.) basiert, zu verproben. Das zeigt frühzeitig nicht nur, welches Budget, sondern auch, welcher Zeitrahmen für die Migration einzuplanen ist.

Am Anfang jedes Softwareprojekts steht ein Anforderungsdokument, in dem der Kunde beschreibt, welche Anforderungen er an die neue Software hat. Dafür gibt es bekanntlich verschiedene Möglichkeiten und Detaillierungsgrade, es kann sich um allgemeine Festlegungen zu den Geschäftszielen handeln, die mit der Software erreicht werden sollen, aber auch um genaue Beschreibungen, welche Funktionen die Software haben soll und wie diese aussehen und sich verhalten sollen.

In jedem Fall stellt sich die Frage, wie weit der Anbieter in die fachlichen Details und Geschäftsprozesse des Kunden eindringen sollte. Häufig sagt man, dass es gut und sogar notwendig ist, dass der Softwaredesigner, vielleicht sogar der Entwickler, die betroffenen Vorgänge beim Kunden versteht und seine Ziele, die letztlich die Erfolgskriterien des Projekte sind, nachvollziehen kann. Aber ist das wirklich immer nötig? Und anders herum: reicht das immer aus?

Versteht der Entwickler viel von den Verfahren und Prozessen des Kunden, hat er etwa Branchen-Know-How, dann birgt das durchaus auch Gefahren. Häufig vermutet der Kunde, dass er Details nicht mehr erklären muss, und auch der Entwickler glaubt nach wenigen Hinweisen schon, dass “alles klar” ist. Auf dieses Weise kann es in Details zu Flüchtigkeitsfehlern kommen, die erst im produktiven Betrieb bemerkt werden.

Eine klare Aufgabentrennung, in der der Kunde ein Anforderungsdokument zu erstellen hat, das es nicht erfordert, dass der Entwickler sich überhaupt mit der Fachlichkeit beschäftigt, scheint dann die Lösung zu sein. Allerdings entstehen auf diese Weise selten optimale Lösungen. Die Vorstellungen, die sich der Kunde von der Software macht, sind manches Mal nur mit viel Aufwand umsetzbar, auf der anderen Seite kann der Entwickler aus anderen Projekterfahrungen heraus Lösungen anregen, auf die der Kunde gar nicht kommt. In so einem Moment wird der Entwicklungspartner zum Berater.

Damit eine solche Partnerschaft gelingt, muss sie allerdings richtig strukturiert werden, und auch die Entscheidungs- Verantwortung muss klar definiert sein. Insbesondere muss vertraglich klar geregelt sein, wie sich die Ergebnisse der Beratung auf die Definition der Erfolgskriterien und auf das Projektbudget auswirken, sonst sagen die Projektbeteiligten am Ende: “Die Zusammenarbeit war sehr schön, und wir haben uns gut verstanden – leider ist das Projekt nicht zu einem erfolgreichen Ende gekommen…”

Vor einigen Wochen ging es in diesem Blog schon einmal um das Thema, wie gesetzliche Reglungen in Software-Lösungen berücksichtigt werden sollen. Dabei ist ein Aspekt noch nicht zur Sprache gekommen: soll die Software den Anwender dazu zwingen, gesetzliche Reglungen einzuhalten, oder ist er selbst dafür verantwortlich?

Ein Beispiel: In unserer Software SceddyPro werden natürlich auch die Regelungen des Arbeitszeitgesetzes berücksichtigt, und zwar schon in dem Moment, in dem der Benutzer die bevorzugten Schichtmuster vorgibt. Soll die Software nun verbieten, dass Muster definiert werden, in denen die Zeit zwischen zwei Schichten kürzer ist, als nach dem Gesetz erlaubt, oder soll nur eine Warnung angezeigt werden?

Wir haben uns dafür entschieden, dem Benutzer einen Hinweis zu geben, wenn er die gesetzlichen Vorgaben verletzt, ihm jedoch die Entscheidung zu überlassen, ob er streng nach dem Gesetz plant oder nicht.

Die Situation ist mit der eines Autofahrers vergleichbar, dem das Navigationssystem anzeigt, welche maximale Geschwindigkeit zulässig ist. Theoretisch wäre es denkbar, dass das System unmittelbar dafür sorgt, dass diese Vorschrift auch eingehalten wird. Auch wenn eine solche technische Lösung von manchem gewünscht wird, lehnen die meisten Fahrer sie ab. Einerseits trauen wir der Technik nicht zu, für jede Veränderung der konkreten lokalen Verkehrsvorschriften immer die aktuellen Daten ins Auto übertragen zu können, ganz davon abgesehen, dass das Navigationsystem auch Fehler machen kann. Andererseits kann es Ausnahmesituationen geben, in denen wir selbst entscheiden müssen, welche Geschwindigkeit wir fahren müssen.

So ist es auch im Fall einer Personaleinsatzplanungslösung wie SceddyPro. Einerseits ist trotz Softwarewartung und Aktualisierungsservice nicht sicher, ob die Software jeden Fall und jede Veränderung der Regelungen sofort enthalten kann. Andererseits, und das ist noch wichtiger, muss der Planer selbst in jedem Moment entscheiden können, wie er das Personal plant. Für die Einhaltung der Vorschriften ist er verantwortlich, und wie er dieser Verantwortung gerecht wird, muss er auch selbst entscheiden.

Zurück zu obigem Beispiel: ein Mitarbeiter wird für die Spätschicht und die Frühschicht am Tag darauf eingeplant. Die Ruhezeit dazwischen entspricht nicht den Vorschriften.  Der Planer vereinbart mit dem Mitarbeiter deshalb, dass er die Spätschicht etwas früher verlässt und etwas später zur Frühschicht kommt und dann entsprechend länger bleibt. Damit wird die Regelung eingehalten, das aber bei der Planung im System schon zu berücksichtigen, würde einen großen Aufwand bedeuten.

Zumeist ist, so zeigt sich an diesem Bispiel, eine Softwarelösung dann der praktischen Situation am besten angemessen, wenn sie dem Benutzer die Entscheidung über die konkrete Regeleinhaltung überlässt. Denn gearbeitet wird nicht in der Software, sondern am tatsächlichen Arbeitsplatz, und da passiert manches, was sich unsere Softwareweisheit kaum träumen lässt.

Immer häufiger hört man in den Service-Centern von Unternehmen, dass irgend etwas nicht ginge, weil die Software es nicht zulässt. Der Kunde hat einen Wunsch, aber die Software verbietet, dass er erfüllt wird. Er hat noch nicht alle Daten für den Auftrag zusammen. Er will eine spezielle Auskunft haben. Er bittet, eine zusätzliche Telefonnummer zu notieren, die bei der Lieferung gewählt werden soll.

In der Anforderungsanalyse werden die Geschäftsprozesse oft aus Idealsituationen heraus beschrieben, genauer gesagt, es werden die Notwendigkeiten beschrieben, die, wie wir glauben, in der Sache selbst liegen, die Sachzwänge. Um einen Auftrag abarbeiten zu können, benötigt man bestimmte Kundendaten, diese Daten sind in der Datenbank Pflichtfelder. Werden sie nicht gefüllt, dann kann der Auftrag nicht angelegt werden.

Hat also der Kunde eine Detailinformation nicht zur Hand, dann wird die ganze Bestellung nicht ausgelöst. Software macht, wenn sie so programmiert ist, das Leben nicht einfacher, sondern bürokratischer. Online-Portale erscheinen heute oft auf den ersten Blick kundenfreundlich, aber unter der Oberfläche lauert in der Software kein Freund und Helfer, sondern ein Bürokrat.

Softwareentwickler schaffen formale Lösungen für Probleme, die oft formal nicht beschreibbar sind. Nur der Idealfall passt zur Software. Aber damit fordert die Technik, dass die Wirklichkeit sich ihren Idealprozessen anzupassen habe – und eigentlich war es doch umgekehrt gedacht, eigentlich wollten wir Softwarehersteller das Leben doch vereinfachen, statt es durch starre Vorgaben und Zwänge  an die Leine zu nehmen.

Die Alternative besteht nicht einfach in einem schlichten “Weniger Muss – mehr Kann!”. Wir müssen in die Konzeption unserer Lösungen schon ein wenig mehr Nachsichtigkeit mit Anwendern und Betroffenen stecken. Statt simpler Muss-Felder eher Sicherheitshinweise, dass bestimmte Informationen noch gebraucht werden. Genau überlegen, welche Daten zwingend benötigt werden, welche anderen Informationen hingegen nachgeliefert werden können. Größere Notizfelder, die auf Aufträgen und Lieferscheinen auch zu sehen sind. Am Ende haben doch immer lebendige Menschen mit dem Geschäftsprozess zu tun, die können denken und lesen, auf deren Klugheit können wir vertrauen.

Wird die Software auf diese Weise teurer? Das ist nicht so einfach zu beantworten. Eine Standarddatenbankprüfung eines Muss-Feldes mit einer nichts-sagenden Fehlermeldung ist natürlich schnell programmiert, die kann sogar schon im Framework eingebaut sein. Legt man auf mehr Benutzerfreundlichkeit wert, so muss man jeden Fall ohnehin einzeln bedenken, spezifizieren und implementieren. Beachtet man zudem, dass Benutzerzufriedenheit ein wesentliches Qualitätsmerkmal ist, dann ist es in jedem Fall ökonomisch, diese Zufriedenheit und die der anderen Betroffenen im Blick zu behalten. Der höhere Aufwand bei der Anforderungsanalyse zahlt sich am Ende aus.

Es ist jedoch vor allem eine Frage der Sichtweise, die alle Entwicklungsbeteiligten einnehmen: Betrachten wir einen Idealzustand, oder wollen wir die reale Welt der Softwarebenutzer besser gestalten? Wenn man sich bei Designentscheidungen diese Frage immer wieder stellt, dann wird man auch Lösungen finden, welche die Benutzer in realen Situationen nicht beschränken, sondern unterstützen.