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.

Es gibt viele Gründe, gewachsene Unternehmensanwendungen ins Web zu bringen. Nicht nur die Verfügbarkeit der Anwendungsfunktionen außerhalb des lokalen Netzes spricht dafür. Deployment-Kosten für neue Versionen sinken, Patches und Change Requests können einfacher verteilt werden. Außerdem entsprechen Web-Anwendungen immer mehr den Look&Feel-Erwartungen der Anwender. Schließlich kann durch eine Web-Anwendung die Verfügbarkeit der Funktionalität auf verschiedenen Plattformen bis hin zu mobilen Geräten wie Smartphones und Tablets sicher gestellt werden.

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.

“Wir brauchen einen neuen Shop” sagt der Auftraggeber, ein mittelständischer Logistikanbieter, der so genannte C-Artikel für Großunternehmen bereithält. Vor vielen Jahren war eine einfache Web-Lösung erstellt worden, ein Portal, in dem die Kunden sich anmelden konnten und die Artikel, die sie immer wieder brauchten, suchen und bestellen konnten.

Im Laufe der Jahre war ein ausgeklügeltes Preisberechnungsverfahren, dass die speziellen Konditionen jedes Kunden berücksichtigte, hinzugekommen, ebenso spezielle Einschränkungen, die es einzelnen Mitarbeitern nur gestatteten, bestimmte Artikel in genau definiertem Umfang zu bestellen.

So steckte viel Kernkompetenz des Logistikers in der Lösung, aber die Oberfläche war längst nicht mehr “State of the Art”. Die Kunden waren inzwischen durch die Möglichkeiten großer Publikums-Shops verwöhnt, komfortable Suchmöglichkeiten, eine moderne Oberfläche und intuitive Bestellabwicklung mussten her.

Kein “Schnick-Schnack”

Es wäre ganz falsch, solche Wünsche beiseite zu wischen und zu argumentieren, das System biete doch so viele Funktionen, die kein bekannter Shop hat oder benötigt, das würde die unmoderne Benutzeroberfläche aufwiegen. Dass der Benutzer mit dem System wirklich effektiv arbeiten kann, hängt ganz stark davon ab, dass er intuitiv damit zurecht kommt – und diese Intuition bekommt der Benutzer, wenn er Bücher, Tickets und Fahrkarten in den einschlägigen Shopsystemen des Internet bestellt.

Nun gibt es eine Reihe von Werkzeugen, die die erwartete Shop-Funktionalität mehr oder weniger gut bereitstellen, einige davon sind sogar frei verfügbar. Es stellt sich also die Frage, ob ein solches Werkzeug verwendet und angepasst werden sollte, sodass die Funktionen des alten Bestellsystems, möglicherweise verbessert, wieder bereitstehen, oder ob auf der Basis des alten Systems ein Modernisierungsprojekt gestartet wird.

Welche Entscheidung die richtige ist, hängt natürlich von den Details des Einzelfalls ab. Verwendet man eine Standard-Lösung, besteht immer die Gefahr, dass man sich von den vielen Features blenden lässt und den Aufwand unterschätzt, die vielen individuellen Regeln, die das Tagesgeschäft braucht, in das System zu integrieren. Oft wird das eine oder andere vergessen – und der Verlust wird erst schmerzlich bemerkt, wenn das neue System in Betrieb genommen wird.

Die Verwendung eines Standard-Systems hingegen hat den Vorteil, dass erprobte und vertraute Verfahren für Standard-Abläufe zum Einsatz kommen. Häufig stellt sich allerdings während des Projekts heraus, dass die Abläufe im eigenen Geschäftsprozess dann hier und da doch nicht so standardisiert sind – und auch nicht sein sollen.

Letztlich kommt es immer drauf an, ob das System die Kernkompetenzen des Unternehmens unterstützen soll oder eher ein notwendiges Beiwerk betrifft. Ist letzteres der Fall, dann genügt eine Standard-Lösung. Gilt es aber, das Kerngeschäft abzubilden, dann macht Individualität stark, denn die unterscheidet uns vom Wettbewerb.

Für die Bewältigung komplexer Probleme, kann man auch ausgefallene Methoden anwenden, dieses möchte ich hier an der Brainwriting-Technik Collective-Notebook Method zeigen.

Da diese Methode recht zeitaufwendig ist, ist sie auch zur Findung schnellere Lösungen nicht geeignet und sollte dann ggf. zum Einsatz kommen, wenn das Problem groß und/oder komplex genug ist.

Kernidee ist das jeder Teilnehmer ein Notizbuch mit sich führt und das über Wochen und rund um die Uhr.

Zu Anfang wird das Problem konkret definiert und es wird festgelegt, wer zur möglichen Lösung beitragen soll. Nun bekommt jeder Teilnehmer ein Notizbuch, an dessen Anfang das Problem niedergeschrieben ist.

Dieses Notizbuch soll den Teilnehmern in der Findungsphase quasi durchgehend zugänglich sein und ihnen die Möglichkeit bieten, im Fall einer guten Idee, diese sofort im Buch festzuhalten. Aber nicht nur Geistesblitze sind dort niederzulegen, sondern auch z.B. ein mal am Tag sollte grundlegend ein Eintrag erfolgen.

Nach den (wenigstens) 2 Wochen fassen alle Teilnehmer ihre eignen Ergebnisse zusammen und in einer gemeinsamen Sitzung werden dann die Ergebnisse ausdiskutiert und im Idealfall zu einer Gesamtlösung ausgearbeitet.

In diesem Artikel möchte ich darauf eingehen warum Softwaretests genügend beachtet werden sollten.

Das Testen eines Softwareproduktes wird gerne bei der Planung von Zeiten innerhalb des Projektmanagements vernachlässigt.
Nach Faustformel des iSTQB® sind um die 50% des Gesamtbudgets für Tests einzuplanen.

Man muss immer bedenken, dass der Aufwand für Tests ggf. weit niedriger ist, als die Folgekosten durch nicht aufgedeckte Fehlerzustände.

(z.B. Fehler in Steuerungsanlage s.u.)

Quelle: http://commons.wikimedia.org/wiki/File:Studenka_train_accident_3.jpg

Um einzugrenzen, wie hoch das Risko ist und in Folge der Testaufwand sein sollte, kann man nach folgender Formel gehen:

Wahrscheinlich des Schadenseintritts mal die Schadenshöhe

Das Testen fängt im Idealfall schon bei der Anforderungserhebung an, wenn es um die Qualitäts der erstellten Dokumente geht.