Mittelständische Firmen denken immer häufiger darüber nach, ihren Bedarf an individueller Software über preiswerte Entwicklung in Billiglohnländern wie Indien zu decken. Oft wird hiervon allerdings abgesehen, weil man einen viel zu großen Aufwand bei der Beschreibung der Anforderungen – und dies dann auch noch in englischer Sprache – befürchtet. Neuartige Methoden wie IOD – Iterative Offshore Development – reduzieren diesen Aufwand erheblich. Die Befürchtung bei der Offshore Software-Entwicklung ist, zumal dann, wenn dies auch noch zum Festpreis erfolgen soll, dass im Vorfeld jede Anforderung bis ins kleinste Detail beschrieben werden muss, um am Ende auch das zu erhalten, was man von der Investition erwartet. Dieses Verfahren ist extrem aufwändig und zudem oft überhaupt nicht durchführbar, weil sich die Anforderungen bei einer Entwicklungsdauer von mehr als 6 Monaten in der Regel auch verändern. Diese Veränderungen dann in sämtlichen betroffenen Einzelfunktionen nachzudokumentieren (unter Beachtung aller Querverweise und Auswirkungen auf andere Prozesse), ist nahezu unmöglich, wenn die Software-Entwicklung völlig getrennt ist von den künftigen Anwendern.

Simulation des Entwicklungsprozesses im Zeitraffer

Bei konsequenter Anwendung des IOD sind diese Befürchtungen jedoch unbegründet. Kurz gesagt: IOD simuliert den Entwicklungsprozess, den eine Software in einem Software-Haus im Laufe von vielleicht zehn Jahren durchläuft, im Zeitraffer und komprimiert diese Entwicklung je nach Projektgröße auf einen Zeitraum von ein bis zwei Jahren.

Wird eine Software-Idee erstmals umgesetzt, so konzentriert man sich zunächst auf die allerwichtigsten Funktionen, um möglichst schnell einen Nutzen aus der neuen Idee ziehen zu können und um zu testen, ob die Idee den erwarteten Effekt in der Praxis auch tatsächlich bewirkt. Allerdings muss beim Design der Architektur der Lösung (Datenbankstruktur, Datenerfassung und Auswertung, Freiheiten der Benutzer bei der Oberflächengestaltung, Rechtevergabe usw.) bereits die Lösung in einer Form angedacht sein, die zum jetzigen Zeitpunkt als die künftig längerfristig nutzbare Version angesehen wird.

Von der Funktionsliste zur fertigen Software

Es wird folglich zunächst eine möglichst vollständige Funktionsliste der künftigen Anwendung erstellt, ohne diese Funktionen jedoch im Detail zu spezifizieren. Danach werden die einzelnen Funktionen (oder Teilfunktionen) in X-Prioritäten zerlegt. Dabei bedeutet Priorität Eins, dass die Anwendung ohne diese Funktion nicht ausführbar ist. X-Funktionen sind Merkmale der Anwendung, die lediglich noch dem Komfort dienen. Die Anzahl der Iterationen hängt dabei von der Komplexität der Gesamtanwendung ab.

Jeder Prioritätsstufe („Iteration“) durchläuft nun sämtliche Phasen der Software-Entwicklung: Definition (Pflichtenheft-Erstellung), Design, Programmierung, Test und Abnahme. Konkret bedeutet dies: Zunächst wird ein Pflichtenheft erstellt, das die technische Umgebung definiert. Außerdem werden hier bereits Schnittstellen zu anderen Anwendungen skizziert.

Dann wird das Management-Summary für die Gesamtanwendung erstellt. Dies ist eine verbale Beschreibung der künftigen Software, in der alle Zielsetzungen, die für die Investitionsentscheidung relevant sind, festgehalten werden. Dazu zählen insbesondere die erwarteten Verbesserungen der Geschäftsprozesse, Entscheidungshintergründe bei Freigabe der Investition usw. Dieses Management-Summary sollte sämtlichen Projektbeteiligten bekannt sein. Es stellt den roten Faden für die Gesamtentwicklung dar – an den dort definierten Zielsetzungen hat sich jede Funktion der künftigen Software zu messen.

Als Nächstes wird die Funktionsliste erstellt und mit den Prioritäten versehen. Diese Dokumente sind ausreichend, um eine konkrete Budget-Aussage treffen zu können. Aufgrund dieser ersten Schätzung, die bereits eine Genauigkeit von plus/minus 20 Prozent haben sollte, wird das Investitions-Budget für die Software-Entwicklung festgelegt. Die Hauptunsicherheit hierbei ist der Aufwand, der bei der detaillierten Definition der weiteren Funktionalitäten entsteht, da dieser in sehr wesentlichem Umfang vom kundeneigenen Projektmanagement, Entscheidungskompetenzen der beteiligten Projektmitarbeiter und der Steuerung des Gesamtprojektes abhängt. Insofern ist der Vorort-Aufwand in der Gesamtschätzung zu diesem Zeitpunkt und damit in dem oben erwähnten Budget nicht enthalten.

Nunmehr wird das Detail-Pflichtenheft für alle Funktionen der Priorität Eins erstellt. Dabei sollen bereits in Priorität Eins alle Teilmodule des Gesamtprojektes berücksichtigt sein, um frühzeitig eventuelle Designfehler zu erkennen, die ansonsten eventuell erst bei einem Integrationstest zutage treten und das Basisdesign in Frage stellen könnten. Ist das Prio-1-Pflichtenheft freigegeben (und eingefroren), wird die Software zum Festpreis mit festen Terminen Offshore entwickelt. Während der Entwicklungszeit kann sich das Kundenteam auf die Erstellung des Pflichtenheftes für die Prio-2-Funktionen konzentrieren.

Wenn das Release 1 fertig gestellt ist, erfolgt die Installation und Abnahme beim Kunden. Dieser hat nun eine vollständige, lauffähige Version der Gesamt-Software zur Verfügung, wenn auch mit minimaler Funktionalität. Gleichzeitig geht das Release 2 in die Programmierung zum Offshore-Serviceanbieter. Der Kunde kann jetzt mit Release 1 bereits arbeiten oder zumindest „spielen“ und ein Gefühl für die Anwendung entwickeln. Dabei stellt sich oft schon heraus, dass Funktion 1 in der „Primitivversion“ eigentlich ausreichend ist und nicht weiter verbessert bzw. erweitert werden muss. Andererseits wird damit realisiert, ob eventuell eine andere Funktion, die bisher nicht auf dem Plan stand, offenbar vergessen worden ist und noch ergänzt werden muss.

Psychologischer Vorteil

Aufgrund der iterativen Vorgehensweise werden mit jedem Release Funktionen ergänzt und Erweiterungen vorgenommen, ohne dass diese von Anfang an bis ins Detail bekannt oder definiert sein müssen. Die Anwendung wächst quasi mit der Erfahrung, die der Benutzer damit macht – ganz wie im richtigen Leben, bei der eine Software über Jahre hinweg immer weiter entwickelt wird. Nur dass mit diesem Verfahren etwa alle ein bis drei Monate ein Release erstellt wird und damit der Prozess quasi im Zeitraffer simuliert wird. Ein weiterer Nebeneffekt: Die Anwender können bereits während der Entwicklungszeit geschult werden und Verbesserungsvorschläge aus der Praxis fortlaufend problemlos noch mit einbringen – ein psychologischer Effekt, der nicht unterschätzt werden sollte.

Günter Wiskot, Geschäftsführer

BLAFOC Black Forest Consulting GmbH

D-76307 Karlsbad

Telefon: (+49) 07202/409 99-0

www.blafoc.com