Retten Sie das Anwendungswissen mit MDA! Viele Unternehmen - gerade solche, deren Produkte und Dienstleistungen weitgehend mit digitalisierbaren Ergebnissen zu tun haben - sind in hohem Maße von Software abhängig, die die unternehmensspezifischen Geschäftsprozesse unterstützt. Der Ansatz der Model Driven Architecture (MDA) kann hier entscheidende Vorteile bieten.
Für Versicherungen, Banken, und Telekommunikationsunternehmen, aber auch in anderen Branchen nimmt die Abhängigkeit von Software immer mehr zu. Beispielsweise in der Automobilindustrie, in der ein seit Jahren steigender Anteil von Software am Produkt Automobil dazu geführt hat, dass die Softwareerstellung mittlerweile substanziell zu den Produktionskosten beiträgt. Ähnliches gilt für Versorgungs- und Entsorgungsunternehmen. Hier sind Produkte und Dienstleistungen zwar nicht digitalisierbar, ihre Verwaltung, Tarifierung und der Bereich des Kundenmanagements erfordern aber immer mehr Software. Die Aufwände in all diesen Branchen umfassen zwar durchaus nennenswerte Kosten für Standard-Software (Personalwesen, Rechnungswesen, etc.), sind im Wesentlichen aber immer noch von individueller Softwareentwicklung getrieben. Trotz dieser enormen wirtschaftlichen Bedeutung von Software hat die Softwareentwicklung im Allgemeinen noch kein ingenieurmäßiges, also planbares, zuverlässiges und von definierten Konstruktionsprozessen geprägtes Niveau erreicht. Neue Untersuchungen der Standish Group belegen, dass immer noch ca. 50 % aller Softwareprojekte mit Termin-, Qualitäts-, oder Budgetproblemen zu tun haben und dass ca. 15 % aller Softwareprojekte abgebrochen werden.
Gründe für das Scheitern der Softwareentwicklung
Curtis, Krasner und Iscoe haben schon 1988 untersucht, woran es trotz der enormen wirtschaftlichen Bedeutung von Software und trotz des enormen wirtschaftlichen Verlusts, den verzögerte oder abgebrochene Projekte bedeuten können, immer noch nicht gelungen ist, die Entwicklung von Software so zuverlässig wie andere Produktionsprozesse zu gestalten. Aktuellere Studien, beispielsweise vom Software Engineering Institute in Pittsburg, identifizieren auch heute noch die gleichen Gründe für das Scheitern von Softwareprojekten, nämlich:
- unklare und widersprüchliche Anforderungen an die zu entwickelnde Software, - Zusammenbruch von Koordination und Kommunikation zwischen den Projektbeteiligten, - fehlendes Wissen über die Anwendungsdomäne.
Zu dem Phänomen der unklaren und widersprüchlichen Anforderungen tragen unterschiedliche Umstände bei. Zu aller erst ist zu nennen, dass die Entwicklung von Software häufig unter hohem zeitlichen Druck stattfindet. Ob dieser hohe Termindruck dabei selbst gemacht oder sachlich nachvollziehbar ist, spielt keine Rolle. Das Ergebnis ist dasselbe: in kaum einem Projekt findet eine ordentliche Anforderungsanalyse statt, die alle Betroffenen einbezieht, von vornherein klar macht, dass zusätzliche Anforderungen zusätzliches Geld kosten und dass es Widersprüche zwischen Anforderungen unterschiedlicher Beteiligter geben kann, die ausgeräumt werden müssen. Neben dem reinen Termindruck spielt an der ein oder anderen Stelle sicherlich auch die Bequemlichkeit eine Rolle. Bequemlichkeit, die dazu führt, dass Anforderungskonflikte nicht explizit gemacht und nicht gelöst werden. Stattdessen werden die Konflikte verschoben. Und zwar auf das Projektende. Dann werden die Konflikte offensichtlich, lassen sich aber auch nicht mehr so einfach klären wie zu Projektbeginn, denn es gibt ja schon Software, die die eine Anforderung erfüllt und die andere nicht. Jetzt ist Konfliktlösung mit Kosten verbunden, kollidiert mit nahen Terminen. Ein weiterer Beitrag zu unklaren Anforderungen sind die unspezifischen Verweise auf existierende Systeme. Das neue System soll mindestens das Gleiche können wie das Alte, nur in anderer Technologie, es soll mobile und verteilte Geschäftsprozesse unterstützen und dies und das anders machen. So richtig klar ist das eben nicht.
Der Gefahr der unklaren Anforderungen kann mit klar definierten Prozessen aus dem Bereich des Anforderungs-Management, mit horizontalen Oberflächen-Prototypen oder mit so genannten Struktur-Prototypen, die das Zusammenspiel aller zu realisierenden Oberflächen illustrieren, entgegnet werden. Eine weitere Chance besteht darin, dass Modelle, die die Fachlichkeit zum Ausdruck bringen und noch frei von technischen Betrachtungen und Entwurfsentscheidungen sind, während der gesamten Entwicklung verwendet werden und jederzeit einen Überblick über die angestrebte Funktionalität des zu realisierenden Systems geben.
Das Phänomen des Zusammenbruchs von Koordination und Kommunikation findet sich immer seltener, höchstens noch bei sehr hierarchischen Projekten, in denen das Management Entscheidungen trifft, die nicht in den Sachzusammenhängen des Projektes gegründet sind oder in Projekten, in denen das Zusammenwirken von Technik und Fachbereich nicht gefördert wird.
Mit anderen Worten: das erste Phänomen (unklare Anforderungen) tritt noch auf, kann aber immer besser risiko-gemanaged werden. Das zweite (Zusammenbruch der Kommunikation) nimmt an Bedeutung ab, klassische Muster des Projektmanagements reichen, um ihm wirksam zu entgegnen. Dem dritten Phänomen (knappes Anwendungswissen) widmen wir uns im nächsten Abschnitt.
Teil 1 Auf dem Weg in neue technologische Welten 
