Feature-based Programming

6 Feature-based Programming in a Nutshell (S. 53-54)

6.1 Ausgangslage: Agilität versus Bürokratie

Agile Methodologien1 gehen davon aus, dass Software-Projekte imWesentlichen situativ gesteuert werden müssen und daher – so die Theorie – jedes Projekt einen individuellen Prozess benötigt. In diesem Sinne kann man solche Methodologien als Baukästen (oder auch so genannte Blueprints) betrachten, aus denen man sich die einzelnen passenden Bausteine heraussuchen und für sich selbst zusammensetzen kann. Agile Methodologien werden auch leichtgewichtig genannt, da sie angeblich mit einem Minimum an Bürokratie und formalen Regeln auskommen.

Im Gegensatz dazu gibt es die schwergewichtigen Methodologien, von denen heute der bekannteste Vertreter der Rational Uni.ed Process (RUP) ist. Schwergewichtig bedeutet hier ein Mehr an bürokratischen Elementen und formalen De.nitionen, die die Flexibilität und Agilität verringern. RUP kann ebenfalls nach einem Baukastenprinzip an die eigenen Bedürfnisse angepasst werden.

Beide Ansätze bergen ein Problempotential: Ein Minimum an Bürokratie und Formalisierung bedeutet auf der einen Seite nicht automatisch, dass eine höhere Flexibilität vorliegt. Es kann auch einfach bedeuten, dass für viele Fragen und Probleme in der Entwicklung einfach keine gemeinsamenVorgehensweisen abgestimmt sind.Wenn dann ein Ereignis während der Entwicklung auftritt, das systematisch und wiederholbar behandelt werden muss, dann wird in einem agilen Projekt ad hoc entschieden, was zu tun ist. Das Team kann dann oft nur reagieren, anstatt zu agieren. Bei der Einführung eines agilen Prozesses in einem Unternehmen müssen daher oft weitere bürokratische Elemente hinzugefügt werden, die im Blueprint des jeweiligen Prozesses nicht adressiert werden. Welche Elemente erforderlich sind, muss dann jeder für sich selbst heraus.nden. Da im Blueprint weniger formale Elemente de.niert sind, wirken agile Prozesse oft einfacher, transparenter und übersichtlicher. Das sind sie natürlich auch, aber: Zur Vervollständigung ist noch eine eigene, zusätzliche Denkleistung, viel Erfahrung und Organisationstalent erforderlich. Der Projektleiter wird so auch gleichzeitig zum Prozess-Architekten, der durch Trial-and-Error das Verfahren für sich selbst anpassen muss.

Auf der anderen Seite bedeutet möglichst viel Bürokratie und Formalisierung auch nicht automatisch, dass man wirklich alles unter Kontrolle hat. Was auf dem Papier steht, muss nicht zwingend mit derWirklichkeit (dem Programmcode) des Projektes übereinstimmen. Dokumentation undWirklichkeit müssen ständig miteinander synchronisiert werden. Diese Synchronisation muss bidirektional sein: Während der Entwicklung ergeben sich Änderungen an der Spezi.kation und der Modellierung, die sich in Programmänderungen niederschlagen müssen. Und egal wie gut und sorgfältig das Team das zu entwickelnde System im Vorfeld modelliert hat, es werden bei der Programmierung immer Erfahrungen gemacht, die die Anpassung und Veränderung der vorher erstellten Modelle erfordern. Meine Erfahrung ist: Es ist bisher nicht möglich, ein Modell einer Software im Vorfeld so zu entwickeln, dass daraus komplexe Programme generiert werden können oder dass einfach 1:1 herunterprogrammiert werden kann. Und nach meiner Ansicht wird es das auch nie geben.

Die Idee der schwergewichtigen Methodologien ist m. E. eng verknüpft mit der Annahme, dass man aus formalen Modellen (wie z.B.UML) Software generieren kann, denn nur durch eine Werkzeugunterstützung und generative Techniken lassen sich umfangreiche bürokratische Software-Prozesse überhaupt realisieren. Code-Generierung auf Basis formaler Modelle ist zwar für kleine Teilaspekte (wie z.B. sehr einfache Persistenz- Layer) prinzipiell möglich. Aber bis heute gibt es weder eine vollständige gra.sche Notation noch eine dazugehörige vollständige Semantik, mit der alle Aspekte einer Software rein durch Bilder beschrieben werden können. Und wenn es diese Bildersprache irgendwann gibt, dann bin ich mir nicht ganz sicher, ob die Menschen die verschiedenen zweidimensionalen Diagramme in einem größeren Software-Projekt noch wirklich alle zueinander in Perspektive setzen werden können. Es ist die Suche nach einer neuen Programmiersprache, einer Sprache, die auf Bildern basiert, anstatt auf englischsprachigen Texten. Der Gedanke ist: Wenn wir Software aus der Spezi.kation generieren können, dann brauchen wir nur noch zu spezi.zieren und wir brauchen nicht mehr zu programmieren. Damit entfällt auch das Problem der Synchronisation zwischen Programmcode (Wirklichkeit) und den Modellen (Scheinwirklichkeit).