Lean ist in

MDSD und das Optimieren des Ganzen

Unter [3] befindet sich die Feststellung: „Brillante Produkte entstehen aus einer Kombination von günstiger Gelegenheit und Technik“. Das gilt auch für den Einsatz modellgetriebener Entwicklung. Zwar ist die Technik ein wichtiger Aspekt bei jedem Einsatz von MDSD. Oftmals führt jedoch die Fehleinschätzung von potenziellen Anwendungsfeldern dazu, dass MDSD nur unzureichend zur Optimierung des Ganzen beiträgt. Aber was zeichnet eine günstige Gelegenheit für MDSD aus?

Inhärente Komplexität: Eine Tätigkeit leistet in der Regel genau dann einen wesentlichen Beitrag zur Erschaffung eines nützlichen Endprodukts, wenn sie nicht trivial ist, sie also ein erhebliches Maß an mentaler Anstrengung erfordert. In diesem Sinn sollte sich auch MDSD der essenziellen Problemstellungen annehmen. Das vermeintliche Musterbeispiel für MDSD, das Generieren großer Mengen von Boilerplate-Code, adressiert eher unbeabsichtigte Komplexität und trägt daher auch nur bedingt zur Wertschöpfung bei.

Relevanz: Wenn man das, was von einem MDSD-Prozess produziert wird, auch weglassen könnte, läuft man Gefahr, ein Muster ohne Wert abzuliefern. So kann es passieren, dass man MDSD, gemessen an den Ergebnissen, für zu kompliziert, zu umständlich oder per se für zu teuer hält.

Häufigkeit: Hält man es für ausreichend, während der Entwicklung eines Produktreleases nur einige wenige Male Artefakte aus Modellen abzuleiten, sollte man den Einsatz von MDSD an sich hinterfragen. Modellgetrieben bedeutet schließlich, dass häufige Änderungen an Modellen zu einem Motor der Entwicklung werden.

Ausmaß: Oftmals ist es die schiere Menge an zu verarbeitenden Informationen oder die große Zahl der zu generierenden Artefakte, die die Investitionen in einen MDSD-Prozess rechtfertigen. Bis zu einem gewissen Grad kann das Ausmaß einer Aufgabe mangelnde inhärente Komplexität kompensieren. Das gilt jedoch nicht für mangelnde Relevanz oder Häufigkeit.

Da heutzutage die Bewertung von Softwareproduktionsprozessen unter dem ökonomischen Blickwinkel oft unerbittlich ist, sollte man jede sich bietende Gelegenheit nutzen, das Optimierungspotenzial von MDSD auszuschöpfen:

  • MDSD sollte den Bedarf an expliziter Koordination verringern. Gerade MDSD kann das durch systemübergreifendes Bereitstellen von kompatiblen Artefakten unterstützen. Modellgetrieben entwickelte Insellösungen sind nicht zuletzt deshalb von eher zweifelhaftem Wert.
  • MDSD sollte mithelfen, das Endprodukt breit und flexibel einsetzbar zu machen. Das gelingt jedoch nur, wenn die Belange der Anwendungsfunktionen und der technischen Infrastruktur auch in den Bausteinen der MDSD-Lösung möglichst stark voneinander entkoppelt sind.
  • Nicht zuletzt sollte MDSD auch immer so umgesetzt werden, dass alle Teilbereiche des Entwicklungsprozesses davon profitieren (also inklusive Testen, Installation etc.). Denn kaum etwas wäre der Optimierung des Ganzen so abträglich wie ein MDSD-Prozess, der neben vielen Artefakten auch viel manuell zu erledigende Arbeit generiert.
Zusammenfassung

Modellgetriebe Entwicklung kann nicht nur in einer agilen und schlanken Art und Weise betrieben werden, sie sollte sogar in dieser Weise umgesetzt werden, um ihr volles Potenzial auszunutzen. Die hier vorgestellten Prinzipien der schlanken Entwicklung lassen sich mit jedem agilen Vorgehen umsetzten. Sowohl Scrum als auch XP bieten genau wie Kanban einen angemessenen Rahmen. Nur tun sollte man es. Die Zeit von MDSD als dem IT-Äquivalent träger Massenproduktion ist vorüber.

Bernd Linowski (bernd.linowski[at]tcs.com) ist Diplominformatiker und ist als Softwarearchitekt bei Tata Consultancy Services (TCS) in Düsseldorf tätig. Seine Schwerpunkte sind modellgetriebene Softwareentwicklung, domänenspezifische Sprachen und die Architektur von verteilten Systemen. Er ist ein Freund von schlanken und agilen Entwicklungsprozessen.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.