Zuerst ist es mit Softwareprojekten oft so wie mit dem Hausbau: Es gibt eine Leistungsbeschreibung, auf deren Basis ein oder mehrere Anbieter Festpreisangebote abgeben. An denen merkt der Auftraggeber vor allem, dass die Sache teurer wird, als geplant.

An dieser Stelle fangen die Unterschiede an: Während beim Haus Abstriche an den Anforderungen gemacht werden, auf teure Materialien verzichtet wird, alles etwas kleiner dimensioniert wird oder verzichtbare Teile ganz gestrichen werden, wird beim Softwareprojekt erst einmal verhandelt. Verzichtbar ist nichts, trotzdem muss der Preis runter. Zugegeben, das ist etwas holzschnittartig übertrieben, liegt aber nicht völlig neben den Realitäten.

Ein entscheidender Unterschied zwischen dem Hausbau und dem Softwareprojekt sieht man schon, wenn man die Angebote betrachtet: Während das Angebot des Bauunternehmens den Preis für jede Position einzeln ausweist und viele Alternativpositionen enthält, sodass die Möglichkeit von Verzicht und Einsparungen schnell sichtbar sind, enthalten Angebote für Software-Individual-Projekte selten Einzelpreise, und noch seltener Varianten für verschiedene Umsetzungsalternativen.

Aber es geht auch anders: Tatsächlich kann durch die richtige Anforderungszerlegung und -priorisierung auch im Softwareprojekt Flexibilität für die Anforderungserfüllung geschaffen werden. Manche Anforderungen sind zwingend umzusetzen, andere sind verzichtbar oder können skaliert werden. Fast immer gibt es Umsetzungsalternativen, die unterschiedliche Kosten nach sich ziehen.

So wird ein wirkliches Design-2-Budget möglich, bei denen am Ende beide Seiten zufrieden sind. Wenn Sie Details zu diesem Konzept wissen wollen, nehmen Sie Kontakt mit uns auf.

Falls Sie z.B. in der Anforderungserhebung oder bei sonstigen Ideenfindungen Probleme haben, u.a. vielleicht auch durch zu dominante/schwierige Teilnehmer, gibt es Methoden bzw. Kreativitätstechniken die es dem Einzelnen ermöglichen anonymer Betrag zu leisten, um so zu neuen Ideen zu kommen.

Eine davon ist die Methode 635.

Die Methode 635
Der Name ergibt sich aus:
6 Teilnehmer
3 Ideen
5 mal weitergeben

Man setzt sich mit 6 Personen in eine Runde. Jeder der Teilnehmer notiert, auf einem gleichgroßen Blatt Papier, 3 Ideen in der ersten Zeile einer Tabelle mit 3 Spalten. Jede Spalte hat 6 Zeilen.

Nach einer vordefinierten Zeit wird gleichzeitig das Blatt nach rechts weitergereicht.

Im nächsten Zeitintervall erweitert dann jeder die 3 Ideen, die er auf seinem Blatt hat.

Dieses wird solange wiederholt, bis alle einmal jedes Blatt in der Hand hatten.

Zettel

Danach kann das Ergebnis ausgewertet werden.

Auf diesem Weg kann man bei leichten bis mittleren Problemen ggf. schnell zu neuen Ideen und Lösungen kommen.

Der Business Analyst hat mit den Experten der Fachseite gemeinsam ein Fachkonzept erstellt, die Fachseite hat das Konzept abgenommen. Auf der Basis des Fachkonzeptes wird ein Lieferant beauftragt, zuerst ein DV-Konzept zu erstellen und dann die Anwendung zu entwickeln.

Nach den Vorstellungen des klassischen Wasserfall-Modells müsste der Business Analyst das DV-Konzept abnehmen und die Realisierung müsste auf der Basis dieses abgenommenen DV-Konzeptes erfolgen. Das ist aber nur zum Teil richtig.

Richtig ist, dass der Business Analyst das DV-Konzept eingehend prüfen muss, er soll ermitteln, ob alle Anforderungen der Fachseite im DV-Konzept aufgenommen wurden und ob Richtlinien und Vorgaben berücksichtigt worden sind. Eine Abnahme aber würde bedeuten, dass der Business Analyst die Verantwortung dafür übernimmt, dass das DV-Konzept die Anforderungen der Fachseite erfüllt – und das ist nicht möglich. Dem Lieferanten würde sozusagen eine Zwischen-Entlastung erteilt ohne dass er sicherstellt, dass die Software den Anforderungen der Fachseite wirklich gerecht werden wird. Das aber ist nicht möglich.

Zum einen kann der Business Analyst im Allgemeinen die Spezifikationsdetails des DV-Konzeptes nicht einschätzen, da es sich dabei um Vorgaben an den Entwickler handelt, dessen technische Know How der Business Analyst nicht hat und nicht haben muss. Zum Anderen kann eine Spezifikation nicht getestet werden wie eine Software, und nur wenn das möglich wäre, wenn man durch einen Test, durch Ausprobieren könnte, ob die Spezifikation “funktioniert”, könnte man auf das technische Know How zur Prüfung des DV-Konzeptes verzichten.

Das heißt jedoch nicht, dass das DV-Konzept nicht abgenommen werden sollte. Die Abnahme soll prüfen, ob die Anforderungen berücksichtigt werden, ob nicht-funktionale und funktionale Anforderungen abgestimmt sind, ob Richtlinien eingehalten wurden. Die Abnahme stellt fest, dass keine Mängel gefunden wurden – nicht, dass keine Mängel vorhanden sind.

Werden im Software-Abnahmetest Fehler gefunden und stellt sich heraus, dass diese Fehler bereits im DV-Konzept vorhanden sind, so hat der Auftraggeber ein Nachbesserungsrecht sowohl auf das DV-Konzept als auch auf die Software. Optimal ist allerdings, wenn vereinbart wird, dass dies nur für Fehler gilt, die der Business Analyst bei der Abnahme des DV-Konzeptes nicht finden konnte.

Das klingt kompliziert – und ehrlich gesagt, das ist auch kompliziert. Wie ein solcher Vertrag ausgestaltet werden kann, hängt sehr stark vom konkreten Projekt ab. Letztlich ist natürlich das Vertrauensverhältnis zwischen den Partnern und die Bereitschaft zum pragmatischen Kompromis ausschlaggebend – aber das lässt sich im Vertrag nicht festschreiben.

Das Wort Programm hat seine – kaum zu verheimlichende – Wurzel im griechischen programma, was so viel wie Vor-Schrift bedeutet. Im Wort Vorschrift klingt auch die Doppeldeutigkeit an, die das Wort Programm hat: Eine Vorschrift ist auf der einen Seite eine Anweisung, wie sich der oder das mit dem Programm versehene und damit programmierte zu verhalten hat. Die Anweisung ist zwingend, den Befehlen ist Folge zu leisten. Das Verhalten des Programmierten ist determiniert und voraus-berechenbar.

Auf der anderen Seite ist eine Vor-Schrift vielleicht nicht mehr als eine Absichtserklärung, oder ein Vorhaben sich in der Zukunft auf eine bestimmte Weise zu verhalten, das Dokumentieren eines Zieles. Partei-Programme haben diesen Charakter – sie enthalten „programmatische Ziele“.

Schaut man sich vor diesem Hintergrund die IT-Welt an dann fällt zweierlei auf:

Einerseits gibt es in einem IT-Projekt beide Sorten von Programmen: Der Code der Software ist – jedenfalls auf den ersten Blick – ein Programm im ersten Sinne, eine Folge von Befehlen, die auszuführen sind, eine Vorschrift, die das Verhalten des programmierten Systems berechenbar macht. Anforderungsspezifikationen sind hingegen eher programmatische Dokumente, sie beschreiben Ziele, die erreicht werden sollen. Auch Architektur-Richtlinien haben diesen „programmatischen Charakter“. Nützlich ist, ein solches Programm zu haben, bevor der Programmierer seine Arbeit beginnt. Über den Projekterfolg entscheidet die Klarheit des Programms der Fachseite, nicht das Programm des Software-Entwicklers.

Andererseits ist der Trend zu beobachten, dass der Code, die Folge von Programmier-Befehlen, immer weniger das Verhalten des Systems vorher bestimmt. Umso größer die Durchdringung des Alltags mit Software-Systemen ist, desto mehr ist das Verhalten dieser Systeme durch die Daten, die es verarbeitet, und die Umwelt, mit der es verbunden ist, verbunden. Welche Ergebnisse eine Internet-Suche mir liefert, wird weniger durch den Code der Suchmaschine bestimmt als durch die Struktur der Informationen, die im Internet abgelegt wird. Was Wikipedia, Facebook und Twitter wirklich sind oder sein können, ist nicht durch eine Datenbank-Struktur und ein PHP-Script definiert, sondern durch das, was die Benutzer damit machen.

Das muss auch auf die Programme selbst Auswirkungen haben. Wenn sich das Verhalten eines Systems nicht mehr befehlen lässt, muss die ganze System-Entwicklung programmatischer werden. Architekturen und Design sind nur gut, wenn sie zum Nutzen passen, wenn dieser Nutzen und die Benutzung aber nicht vorhersehbar sind, müssen die Vor-Schriften programmatischer werden.

Jede Individualsoftware benutzt Standard-Software, sei es die Datenbank, das Betriebssystem, Drittsoftware, mit der kommuniziert werden muss oder das Entwicklungssystem, mit dem die Individuallösung erstellt wurde. Standard-Software wird weiterentwickelt und so stellt sich für die Individuallösung irgendwann die Frage der Migration auf eine neue Version der genutzten Plattform.

Oft wartet man mit einer solchen Migration so lange, bis sie unumgänglich ist – außerdem macht das Unternehmen, bei dem die Individuallösung im Einsatz ist, auch nicht jeden Plattformwechsel mit. Deshalb muss bei einem Migrationsprojekt oft ein Sprung über drei oder vier Zwischenversionen geschafft werden – und da kann es schon eine Menge von wesentlichen und überraschenden Unterschieden in den genutzten Schnittstellen geben.

Wie soll man in einer solchen Situation vorgehen, und vor allem, wie viel Zeit und Ressourcen muss man einplanen?

Migrationen sind zunächst ganz normale Softwareprojekte, und wie bei diesen gibt es paradigmatisch auch hier zwei Vorgehensmodellen: Phasenmodelle und agile Vorgehensweisen. In einem phasenorientierten Vorgehensmodell wird man zunächst den Migrationsbedarf als funktionale Anforderungsmenge analysieren und spezifizeren, dann ein Umsetzungskonzept entwickeln und schließlich die Migration als Neuimpementierung von Funktionalität umsetzen.

Gerade bei Migrationen ist allerdings der Anteil der Unbekannten Anforderungen besonders groß. Migrationen sind Entdeckungsreisen in die unbekannte Welt der neuen Plattform – und selbst, wenn man Experten für die neue Welt als Lotsen an Bord hat, weiß man nicht, wie das alte Schiff in den neuen Fahrwassern wirklich reagieren wird, welche Schwachstellen in der “Neuen Welt” erst zum Tragen kommen, die man zuvor gar nicht bemerken konnte.

Deshalb bieten sich gerade bei Migrationen agile Vorgehensmodellen an. Kurz gesagt: Man startet mit einem Experiment und schaut, was passiert. Man wagt die ersten vorsichtigen Schritte und beobachtet, wie System und Kontext reagieren. Man löst die auftretenden Probleme und geht den nächsten Schritt – so lange, bis das System in de Ziel-Umgebung stabil läuft.

Agile Projekte dieser Art haben den Nachteil, dass man zu Beginn nicht weiß, wie lange sie dauern und wie aufwändig sie sind – aber paradoxerweise sind sie preiswerter und effizienter als das phasenorientierte Vorgehen, bei dem man zwar immer eine plausible Aufwands- und Kostenschätzung hat – die aber leider nie stimmt, weil man die Überraschungen, die unweigerlich auftreten, nicht einkalkulieren kann.

Natürlich liegt in der wirklichen Projektwelt – wie immer – die Wahrheit in der Mitte. Eine Analyse der entscheidenden Plattform-Differenzenen mit Relevanz-Betrachtung und Risikobewertung soll und kann immer am Anfang stehen und eine intensive Beschäftigung mit den Möglichkeiten und konzeptionellen Neuigkeiten des Zielsystems ist ebenfalls sinnvoll.

In jedem Fall sollte zu Beginn des Migrations-Projektes die Erstellung eines detaillierten Testkonzeptes stehen. Nirgends ist der Einsatz eines Testfall-getriebenen Entwicklungsansatzes so sinnvoll wie bei Migrationen. Die Testfälle sollten hier als White-Box-Tests geplant werden, da der Code der Individual-Anwendung ja bekannt ist. Die Codeabdeckung der Testfälle sollte Risiko-abhängig vorab festgelegt werden.