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.

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.

All diese Aspekte können dafür sprechen, auch über Jahre gewachsene Client-Server-Anwendungen in eine Web-Architektur zu überführen. Dazu sind allerdings eine Reihe von Vorüberlegungen nötig. Von einer kompletten Neuprogrammierung ist, auch wenn Ausgangs- und Ziel-Technologien weit auseinander liegen, zumeist abzuraten. Neue Anforderung und neue Technologien  in einem Projekt zu vereinen vergrößert die Gefahr, dass das Projekt zu einem Millionengrab wird und nie zu einem erfolgreichen Ende gebracht wird.

Welcher Ansatz der richtige ist, hängt oft nicht primär von der Technologie der bisherigen Anwendung ab. Ob sie in Visual Basic oder C/C++ oder in Java geschrieben ist, oder ob es sich gar um eine Großrechner-Anwendung handelt, ist zumeist nicht so wichtig wie die Frage, ob die Anwendung eine klare Schichten-und Modul-Architektur hat und ob Entwicklungsstandards während der gesamten Lebenszeit der Anwendung weitgehend eingehalten wurden.

Eine einfache Checkliste kann zu einer ersten Beurteilung eines Software-Migrationsprojekts hilfreich sein. Auf ihrer Basis ist eine Analyse möglich die zeigt, welche Bestandteile ein Durchstich-Prototyp haben sollte, mit dessen Hilfe eine seriöse Kosten- und Zeitschätzung für eine erfolgreiche Migration möglich ist.

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…”

Aber damit sind die Möglichkeiten von Planungssoftware längst nicht ausgeschöpft. Mit den meisten Lösungen lassen sich nämlich auch Plan-Spiele durchführen, lässt sich ein Projekt oder ein Planungszeitraum auch simulieren, lassen sich Tests durchführen, wie ein Vorhaben unter Idealbedingungen abaufen wird und was passiert, wenn unvorhergesehene Zwischenfälle wie Krankheit und ähnliches auftreten.

So lassen sich mit einer Projektmanagementsoftware auch verschiedene Szenarien eines Projektablaufplans durchspielen und die Robustheit des Projekts gegen Störungen und Ausfälle lässt sich für verschiedene Varianten testen.

Ein Personaleinsatzplanungs-Werkzeug wie SceddyPro, das auf der Anwendung von Dienstrahmen für unterschiedliche Arbeitszeitmodelle beruht, kann z.B. auch für Simulationsläufe verwendet werden, die zeigen, wie viel Personal bei der Anwendung bestimmter Arbeitszeitmodelle wirklich notwendig ist, und wie etwa in Zeiten der Personalknappheit durch Variation der Dienstrahmen eine verlässliche Anpassung der Planung möglich ist.

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.