"Datenmodellierung ohne Medienbruch" war in der CW 37/01 ein Bericht übertitelt, in dem die Autoren beschreiben, mit welch dürftigen Mitteln in der Anwendungsentwicklung oft gearbeitet wird. Das Hauptziel von Datenmodellen sollte es sein, eine stabile Basis für die Konzeption von Anwendungen zu bilden. Die in dem Artikel vorgeschlagene Lösung, fachliche Definitionen über Excel zu erfassen, anschließend in Access zu importieren und die grafische Darstellung im Case-Tool Erwin vorzunehmen, kann vielleicht als pragmatisch, nicht jedoch als integriert bezeichnet werden. Derartige Konstrukte zur Selbsthilfe zeigen das Dilemma, in dem Anwendungsentwickler nach wie vor stecken: mit unzureichenden, wenig integrierten Mitteln hochkomplexe Programme effizient entwickeln zu müssen.
Die Diskrepanz zwischen Entwicklerpraxis und dem professionellen beziehungsweise technologischem Image der IT-Branche lässt sich an Beispielen belegen:
-Auf ein Datenmodell wird im fachlichen Entwurf verzichtet - das ist zu technisch.
-Systeme und ihre Funktionen werden als Word-Dokumente beschrieben, ihre Bestandteile und ihr Zusammenwirken sind darin aber schwer erkennbar, Referenzbegriffe nur selten einheitlich und eindeutig benannt.
-Für Funktions- und Maskenabläufe werden, wenn überhaupt vorhanden, bunte Folien etwa über Powerpoint erstellt.
-Die zum System gehörenden Teile werden erst in der technischen Umsetzung eindeutig beschrieben und vielleicht bei Projektende nachdokumentiert.
-Dokumente werden in uneinheitlichen Formaten, Ablagemedien und -strukturen verwaltet, die nur der Verfasser kennt. Außenstehende finden Informationen über die Anwendungen und aus den Projekten nur mit hohem Einarbeitungsaufwand.
-Es gibt kaum qualitätssichernde Prüfungen - so würde zum Beispiel die Angabe "Preis = PLZ * Name/Geburtsdatum" in einer Funktionsbeschreibung nicht als Fehler moniert werden.
Bei solchen Problemen bleiben Effizienz und Qualität auf der Strecke. Verloren geht die Eindeutigkeit der benutzten Begriffe, die Einheitlichkeit der erstellten Dokumente, die Konsistenz und Transparenz - und das alles, weil es sich letztlich nur um einfachen Text handelt, der die Strukturen der Systeme nicht klar darstellt. Hohe Kosten spätestens in der Wartung sind die Folge.
Ein geregelter ProzessDabei sind die Abläufe immer gleich: Anforderungen werden in Projekten zu Systemen umgesetzt, die Prozesse unterstützen, die wiederum Informationen benötigen oder liefern. Das System besteht aus Funktionen, die Daten lesen und schreiben, zueinander in Beziehung stehen und aus Datenelementen bestehen. Ihr Zusammenwirken sollte deshalb mit geeigneten Systemhilfsmitteln unterstützbar sein. Stattdessen wird in den Unternehmen in vielen tausend Projekten mit ungeeigneten Mitteln gearbeitet oder das Rad neu erfunden.
Gründe für diesen IT-Alltag gibt es genug. Ein wesentlicher Aspekt besteht darin, dass das Marketing für IT-Technologien bestimmte Themen aus dem Blickfeld rückt. So dominieren zurzeit Techniken rund um das "E" die Szene. Ob Java, XML oder EAI, mit dem methodischen Konzipieren von Anwendungen haben diese Techniken kaum etwas zu tun - sie blenden die konzeptionellen Projektphasen einfach aus. Case ist jedenfalls als Thema nicht mehr "in". Dabei gilt die Erkenntnis, dass ein Fehler umso mehr Aufwand zur Behebung erfordert, je früher er gemacht wurde, nach wie vor. Hinzu kommt, dass die verfügbaren Werkzeuge oft nicht in die vorhandene Entwicklungsorganisation passen. Mit dem Einsatz von Office-Produkten verzichtet man auf wesentliche aufgabenspezifische Funktionalität, kann dafür aber schöne Dokumente vorweisen.
Ein weiterer Grund liegt darin, dass die ohnehin geringe Nachfrage nach Produkten, verteilt auf viele Hersteller, keine leistungsfähigen Lösungen entstehen lässt. Seit sich die IBM von der Idee des AD/Cycle und ihrem Repository Manager verabschiedet hat, existiert keine Instanz mehr, die einheitliche Methoden und Strukturen in der Systementwicklung wirklich zu ihrem Anliegen macht. Mehr noch: Methodik wird als Störfaktor empfunden.
Wie es sein sollteSo bleibt das folgende Szenario in vielen Entwicklungsabteilungen weitgehend Vision:
-Alle Elemente eines Systementwurfs sind in einem Repository erfasst und damit quantitativ definiert. Sie bilden die Grundlage für die Aufwandskalkulation, stehen über festgelegte Strukturen in Beziehung zueinander und können in mehreren Projekten verwendet werden.
-Alle Systementwürfe und -dokumente beziehen sich begrifflich auf diese Elemente mit einheitlichen Schreibweisen und konsistenten Begriffen - inklusive der an der Benutzeroberfläche (Masken, Listen, Belege) verwendeten Bezeichnungen.
-Es besteht jederzeit Transparenz darüber, wo welche Elemente auftreten beziehungsweise benutzt werden. Die Beschreibung referenzierter Objekte ist direkt abrufbar.
-Die Entwürfe werden automatisch formalen Plausibilitätsregeln unterworfen.
-Die Definitionen sind eins zu eins die Basis für Texte in Benutzerdokumenten und Online-Help-Systemen.
Fazit: Der Trend zu Standardprodukten verlagert die Softwareentwicklung nach außen. Die Hersteller setzen dabei mächtige und integrierte Werkzeuge ein, die auch von Anwendern genutzt werden können. Wo man jedoch Anwendungen selbst entwickeln will, muss zur höheren Wiederverwendbarkeit und Wartungsfreundlichkeit in die Entwicklungsinfrastruktur investiert werden. Im Bereich der Objektorientierung sind mit UML Standards auf dem Weg, auch wenn dieser noch steinig ist. Letztlich geht es darum, den von der Entwicklungsabteilung benötigten Techniken eine höhere Piorität einzuräumen.(ue)
*Reinhold Völker ist Management-Berater bei CSC Ploenzke, Kiedrich.