Durchgängige Modellierung Der Schlüssel zu erfolgreichen Software-Entwicklungsprojekten

Autor / Redakteur: Marcus Groß / Gerald Viola

Mit dem Aktionsplan Deutschland-Online der Bundesregierung fiel in Zusammenarbeit mit den Ländern vor drei Jahren der Startschuss für verwaltungsebenenübergreifende eGovernment-Projekte. Die Implementierung einfacher Standard-Software tritt dabei immer mehr in den Hintergrund. Zunehmend gilt es, spezifische Fachverfahren und komplexe Lösungen zur Verwaltungsmodernisierung neu zu entwickeln und nach Wegen zu suchen, den gestiegenen Anforderungen an die Erstellung, Weiterentwicklung und langfristige Pflege dieser anspruchsvollen Software-Lösungen gerecht zu werden.

Firmen zum Thema

Quelle: Fotolia, Sebastian Kaulitzki
Quelle: Fotolia, Sebastian Kaulitzki
( Archiv: Vogel Business Media )

Eine bewährte und erfolgreiche Methode ist in diesem Zusammenhang die „durchgängige modellbasierende Softwareentwicklung“, oft auch als MDA (Model Driven Architecture) bezeichnet.

Diese Vorgehensweise sieht vor, durch eine systematische Beschreibung von Modellen auf unterschiedlichen Abstraktionsniveaus und durch halbautomatische Modelltransformationen die Anforderungskomplexität zu strukturieren und einzugrenzen. Ziel ist es, möglichst viele Artefakte eines Softwaresystems generisch aus formalen Modellen abzuleiten.

Die entscheidende Grundlage für die Generierung der Artefakte des Softwaresystems sind dabei hinreichend formale und zugleich abstrakte Modelle, in denen die Architektur oder Funktionalität adäquat beschrieben wird. Die fachlichen und technischen Modelle nehmen somit eine zentrale Stellung im Software-Entwicklungsprozess ein, weil sie eben nicht nur für die Beschreibung oder Dokumentation des Softwaresystems aus den Anforderungen heraus verwendet werden, sondern eine ausführbare Anwendung direkt aus den Modellen heraus konstruktiv erzeugt werden kann.

Problemstellung

Es gibt eine Anzahl von Phasen, die für jede klassische Softwareentwicklung gleich sind und die sequentiell ablaufen – unabhängig vom eingesetzten Vorgehensmodell oder den verwendeten Methoden. Typischerweise wird dieser sequentielle Prozess durch Rücksprünge aufgeweicht und nicht nur einmalig, sondern in mehreren Iterationen durchlaufen. Entscheidend hierbei ist, dass die Rücksprünge zu der jeweils richtigen Phase erfolgen. Das bedeutet beispielsweise, dass bei geänderten Anforderungen ein Rücksprung in die Anforderungs- oder Analysephase erfolgen sollte, während ein Implementierungsfehler zu einem Rücksprung in die Realisierungsphase führen müsste.

Die Praxis zeigt jedoch allzu oft, dass genau diese Empfehlungen nicht eingehalten werden. Mit Beginn der Realisierungsphase werden fast alle Änderungen nur noch auf Quelltextebene geplant und umgesetzt. Eine solche Vorgehensweise erkennt man meist daran, dass es zwar Analyse- und Design-Modelle gibt, diese aber nur einen historischen Stand repräsentieren, der meist auch dem Startzeitpunkt der Realisierung entspricht.

Die einfache Begründung für diese Fehlerquelle im Entwicklungsprozess ist, dass jede Änderung sowohl im Design-Modell als auch im Quelltext manuell eingepflegt werden müsste. Somit ist jede Anpassung des Design-Modells aus Entwicklersicht ein Zusatzaufwand, der eingespart werden kann. Ein Phänomen, das als „programmer‘s shortcut“ bezeichnet wird.

Die Probleme, die daraus für die Öffentliche Hand resultieren, liegen auf der Hand: So steckt das eigentliche Wissen über die Anwendung zunehmend in den Köpfen erfahrener Entwickler, was zu hohem Aufwand führt, wenn sich die Teamzusammensetzung ändert und neue Team-Mitglieder sich in Tausende Zeilen Quelltext einarbeiten müssen. Pflegt man die Quelltextanpassungen aber erst später im Design-Modell, sind Inkonsistenzen vorprogrammiert. Dadurch steigt das Risiko, hochkomplexe Entwicklungsprojekte im vorgegebenen Zeitrahmen nicht erfolgreich zu beenden sowie vorgegebene Budgetrestriktionen nicht einzuhalten.

Nächste Seite: Der modellgetriebene Entwicklungsansatz sorgt für die richtige Reihenfolge

Vorgehensmodell

Auch bei der modellgetriebenen Softwareentwicklung hält man an der klassischen Phasenfolge fest. Eine durchgängige, modellgetriebene Softwareentwicklung automatisiert jedoch einen Teil dieser Phasenfolge, nämlich den Schritt vom Design zur Realisierung. Dabei wird durch Transformationen aus dem Design-Modell ein wesentlicher Teil der Realisierungsergebnisse generiert. Der modellgetriebene Entwicklungsansatz sorgt damit automatisch dafür, dass die richtige Reihenfolge (Analyse ->Design -> Implementierung) eingehalten wird. Denn die Modelle werden als essenzielles Zwischenprodukt der Entwicklung verwendet und nicht nur zur Dokumentation.

Der Ansatz der IBM

Die IBM hat gemeinsam mit ihrem Geschäftspartner, dem Nürnberger Softwarehaus MID, einen Ansatz zur systematischen und durchgängigen Modellierung komplexer Software-Lösungen entwickelt. Er hat sich bereits mehrfach bei softwareintensiven Projekten zur Verwaltungsmodernisierung bewährt. Die darin praktizierte Vorgehensweise unterstützt die methodische Kompetenz aufseiten der Projektpartner der Öffentlichen Verwaltung und führt zu einer deutlichen Verbesserung der Produktivität sowie zu einer Reduzierung der langfristigen Kosten für Software-Entwicklung und -Pflege.

Dies wird auch durch Jürgen Schwarz, IBM Practice Leader DMS Public Sector, bestätigt: „Vielfältige Projekterfahrungen bei Öffentlichen Auftraggebern zeigen – insbesondere bei größeren Entwicklungsprojekten – dass die durchgehende modellgetriebene Entwicklung eindeutig dazu beiträgt, den Brückenschlag von den Anforderungen bis zur fertigen Lösung zu verbessern und damit die Chance auf den Projekterfolg zu erhöhen. Die methodisch erzwungene Disziplin im Vorgehen birgt Vorteile, aber auch Anforderungen sowohl an die Kompetenzen auf Seite des Auftraggebers als auch auf Seiten des Auftragnehmers.“

Grundlage für eine solche durchgängige Modellierung ist die Modellierungsmethodik M3 der MID. Sie liefert eine Antwort auf den stetig wachsenden Zeit- und Erfolgsdruck bei der Realisierung komplexer Projekte. Ziel ist es, dem Öffentlichen Dienst eine klare Anleitung für die Gestaltung und Dokumentation von Projekten an die Hand zu geben. M3 beschreibt systematisch die einzelnen Prozessschritte, Modellierungsebenen und Rollen von der Projektidee bis zum Code und verbessert durch ihren umfassenden, konzeptionellen Ansatz gleichzeitig die Qualität der entstehenden Software.

Im Unterschied zu anderen Methoden setzt M3 bereits vor der eigentlichen Entwicklungsarbeit an, um so von Beginn an ein möglichst vollständiges Gesamtbild über alle beteiligten Abteilungen und Verwaltungsprozesse zu gewinnen und alle Anforderungen in das Projekt einzubeziehen. Die Modellierungsmethodik erlaubt es, die gleichen Zusammenhänge mit mehreren Modellen unterschiedlicher Abstraktionsniveaus zu beschreiben. Auf der obersten Abstraktionsebene wird das System aus rein fachlicher Sicht und unabhängig von der Realisierungsplattform dargestellt. Auf den darunter folgenden Stufen bewegt man sich in Richtung der technischen Realisierung.

Die fachlich orientierten Modelle auf den höheren Abstraktionsstufen erlauben es außerdem, Interessengruppen ohne IT-spezifisches Fachwissen am Entwicklungsprozess zu beteiligen. Dadurch wird unter anderem die Wiederverwendbarkeit und Langlebigkeit der Modelle gesichert, da erfahrungsgemäß die fachlichen Aspekte eines Systems dauerhafter sind als deren technische Umsetzung.

„In unserer MID ModellierungsMethodik steckt das Wissen aus einer Vielzahl von modellgetriebenen Ansätzen der Industrie und den Behörden, gepaart mit der Erfahrung der Berater, die diese Ansätze mit der Modellierungsumgebung Innovator in der Praxis eingesetzt haben. M3 gibt Projektbeteiligten einen Leitfaden an die Hand, ein Projekt schneller und zielgerichteter aufzusetzen und von der Erfahrung anderer Projekte zu profitieren“, fasst Jochen Seemann, Geschäftsführer der MID, zusammen.

Nächste Seite: Höhere Produktivität in späten Projektphasen und während der Wartung

Vorteile

Schließlich wird durch ein durchgängiges modellgetriebenes Vorgehen insbesondere in späten Projektphasen und während der Wartung eine deutlich höhere Produktivität erzielt. Die von den Entwicklern ungeliebte Aufgabe der Dokumentationserstellung kann durch diesen Ansatz ebenfalls erleichtert werden, indem man auch hier generativ vorgeht, das heißt, Dokumentationen automatisiert erzeugt. Neben Quelltext und Dokumentation lassen sich auch weitere Artefakte wie Konfigurationsdateien und Testfälle generieren.

Für die Bereiche Anforderungs- und Projektmanagement ergeben sich aus dem modellbasierenden Ansatz ebenfalls Vorteile. So lassen sich für modellierte Artefakte Status und Fertigstellungsgrad festhalten, die automatisch ausgewertet werden können. Die Anbindung an ein Ticketing-System erlaubt außerdem die Rückverfolgung der Fertigstellungsgrade der Anforderungen bis ins Modell. Deren Auswertungen bilden wiederum die Grundlage für Projektstatusdokumente.

Die generischen Anforderungsdokumente, Grundlage für eine fachliche Modellierungsebene, können mit den erstellten Modelldiagrammen verknüpft werden. Somit wird eine leichte Verfolgbarkeit von Anforderungen zu Design und Code und zurück möglich.

Damit lässt sich in der durchgängigen Produktionskette der modellgetriebenen Softwareentwicklung feststellen, welche Auswirkungen Änderungen von Anforderungen auf das bereits modellierte und implementierte System haben. Eine sowohl qualitative als auch quantitative Bewertung ist in diesem Stadium unerlässlich, jedoch ohne ein entsprechendes Modellierungs-Tool fast unmöglich oder im besten Falle höchst ungenau.

Fazit

Durch eine enge Verzahnung von modellbasierendem Anforderungsmanagement und modellgetriebener Code-Erstellung sowie dessen Dokumentation wird sichergestellt, dass die Bestandteile im Einklang gehalten werden, Inkonsistenzen vermieden und eine langfristige Pflegbarkeit auch komplexer Software-Lösungen gewährleistet wird. Der beschriebene Ansatz erleichtert damit nicht zuletzt die Frage nach der Führungsrolle im Entwicklungsteam oder die oft schwierige adäquate Besetzung dieser Position.

(ID:2020823)