Modellgetriebene Entwicklung — Irrungen und Wirrungen

Es gibt einen richtig tollen Artikel (Blog) über modell-getriebene Entwicklung in der Software-Entwicklung, der durch ein, zwei Absätze Absatz meines Buches (Scrum-Produkte zuverlässig und schnell entwickeln) motiviert worden ist. Die Autorin zeigt, dass ich ihrer Meinung nach “Äpfel mit Birnen verwechsel.”

Ich finde den Artikel gut, weil die Autorin deutlich macht, wie modell-getriebene Entwicklung zu verstehen ist. Diesen Absatz finde ich besonders gut:

Eine Bemerkung noch zum Wissensmanagement: Bei modellgetriebener Entwicklung ist das Fachwissen – ein äußerst wertvolles Gut einer Organisation – nicht gut durchmischt mit Technologie-Know-how im Code zu finden. Es ist auch nicht nur in den Köpfen von Mitarbeitern vorhanden. Sondern es exisitert in Form fachlicher Modelle, auf denen bei Weiterentwicklung und Wartung immer wieder aufgesetzt werden kann, weil sie per Roundtrip und Reverse-Transformation konsistent zu technischen Modellen und Code gehalten werden. Das heißt, modellgetriebene Entwicklung, wie wir sie verstehen, bietet hohen Investitionsschutz für das Fachwissen einer Organisation.

Ich zweifel das gar nicht an — das ist sicher so. Mein Frage ist ein wenig anders motiviert. Die Frage ist — kann man Fachwissen in Form von Modellen beschreiben? Nonaka und Takeushi sehen das in Ihren Arbeiten zum Wissensmanagement ähnlich, wie die Autorin. Wenn das Umfeld tatsächlich bekannt ist, dann kann man es codifizieren–also Modelle entwickeln.

Ich wundere mich nur! Gibt es in unserer schnelllebigen Zeit, tatsächlich die Chance, Fachwissen erst in Form von Modellen aufzuschreiben? Wissenschaftler brauchen Jahre, um Modelle zu entwickeln.

Andererseits–Ohne diese Modelle gibt es nach Thomas Kuhn (Die Struktur wissenschaftlicher Revolutionen) gar keine Erkenntnis, denn sie sind die Grundbedingungen, dass sich geordnet Wissen “bilden” kann. Dann kommt es zum Paradigmenbruch, das Modell bricht–neue Wege werden gegangen.

Agile Software Entwicklung und modell-getriebene Entwicklung sind kein Widerspruch, sie können sich sinnvoll ergänzen, das haben wir vor Jahren bei ComBOTS gesehen. Es kommt aber auf das Umfeld an, in dem es eingesetzt wird. Scrum ist ein kreativer wissensbasierter und wissenschafts-naher Ansatz zum Führen von Teams und Organisationen beim Entwickeln von Produkten (t.B. Software). Modell-getriebene Software Entwicklung ist eine Variante, wie man Software entwickelt.

Übrigens –Der sehr lesenswerte Artikel zeigt, dass ein Prinzip beim Schreibens immer funktioniert: Ärger ist ein toller Motivator🙂 Freut mich sehr, dass meine Provokationen diese Reaktionen auslösen. Lasst uns diskutieren.

One response to “Modellgetriebene Entwicklung — Irrungen und Wirrungen

  1. Danke für die Stellungnahme zu meinem Artikel. Inhaltlich sind wir also gar nicht soweit auseinander.

    Zur Frage, ob man Fachwissen mit Modellen beschreiben kann: Für die Modellierung von fachlichen Aufgaben, Abläufen und Strukturen steht heute ein breites Spektrum an Notationen und Kalkülen zur Verfügung. Eine interessante Übersicht geben z.B. Uwe Kastens und Hans Kleine Büning in ihrem Buch „Modellierung“. Ich will mich hier aber nicht auf die Theorie beziehen, sondern drei „Erfolgsmodelle“ aus der Welt unserer Kunden nennen.

    Beispiel 1 – Modellieren von Strukturen
    Ein großer Finanzdienstleister verwaltet seit Jahren sein Wissen über Kunden, Produkte und Märkte in einem Data-Warehouse. Zur fachlichen Strukturierung der Geschäftsdaten setzt er das klassische Entity-Relationship-Modell ein, erweitert um Data-Warehouse-typische Elemente zur multidimensionalen Datenmodellierung. Diese Modelle werden maschinell in tabellenorientierte Relationenmodelle und technische Datendefinition umgesetzt.

    Beispiel 2 – Modellieren von Abläufen
    Am Anfang der Entwicklung von Systemen, die das Autofahren angenehmer und sicherer machen sollen, steht eine fachliche Aufgabe: Es ist das beobachtbare Verhalten zu beschreiben, mit dem die Systeme auf externe Ereignisse reagieren sollen. Kunden von uns setzen hier erfolgreich auf Statecharts als Notation für endliche Automaten (keine Erfindung der UML, sondern von David Harel, 1984) und generieren daraus Code für unterschiedliche Hardware und Betriebssysteme.

    Letztes Beispiel – Noch einmal Modellieren von Abläufen
    Diesmal im Business-Bereich. Hier gibt es mit der Business Process Modeling Notation (BPMN), die seit 2006 OMG-Standard ist, eine neue Darstellungsform, um den Ablauf von Geschäftsprozessen festzuhalten – einschließlich der Kommunikation mit externen Partnern in einer serviceorientierten Welt. BPMN-Diagramme sind Flowcharts, die auf Petri-Netzen basieren. Sie sind für die direkte Abbildung auf Code zum Beispiel in der Business Process Execution Language (BPEL) konzipiert.

    Sie fragen, wie stabil ist Fachwissen? Also wie lange halten diese Modelle? Die Beispiele haben eines gemeinsam: Das Wissen, das hier modelliert ist, ändert sich nicht in kurzer Zeit radikal. Es ändert sich evolutionär. Am langlebigsten ist das Wissen über Strukturen.

    Wie geht man mit Änderungen bei modellgetriebener Entwicklung um? Am besten so, denke ich🙂

    – Die Änderungsanforderung kommt ins Backlog und wird priorisiert.

    – Im Sprint Planning 1 wird anhand der vorhandenen fachlichen Modelle der Änderungsbedarf konkretisiert (über Modelle lässt sich gut reden!).

    – Im Sprint Planning 2 definiert das Team Aufgaben zur Änderung der fachlichen Modelle für den Business-Analytiker oder Fachinformatiker. Zum Glück ist das Team ja interdisziplinär besetzt. (Später im Sprint läuft die Transformation der geänderten fachlichen Modelle in technische Modelle und Code maschinell ab und dauert höchstens ein paar Minuten. Die Modelltransformationen müssen allerdings iterativ konzipiert sein, sich also immer wieder anwenden lassen, sonst funktioniert’s nicht.) Die Detaillierung der maschinell erzeugten technischen Modelle und die Implementierung von Einzelheiten der Anwendungslogik müssen als Aufgaben für die Entwickler geplant werden. Wie natürlich auch die Entwicklung von Testfällen, Test etc.

    – Und dann kann der Sprint starten …

    Sorry, mein Kommentar ist etwas lang geraten. Zum Abschluss trotzdem noch das: Sie haben recht – Ärger ist ein Motivator. Aber Sie merken, der Ärger ist schnell verflogen.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s