Lean ist in

MDSD und die Vermeidung von Abfall

Die wahrscheinlich effektivste Methode, um die Effizienz und Produktivität eines Softwareentwicklungsprozesses zu erhöhen, ist die Vermeidung von Abfall. Modellgetriebene Entwicklung stellt da keine Ausnahme dar, bringt sie doch zusätzliche Artefakte und Aktivitäten mit sich, die sich mit Abfall anfüllen oder selbst als Abfall enden können. Abfall umfasst in diesem Zusammenhang alles, was Aufwand erfordert oder Kosten verursacht, letztendlich aber nichts zur Wertschöpfung des Endprodukts beiträgt. Da das „Sehen von Abfall“ der erste Schritt zu dessen Vermeidung ist, führt Tabelle 1 für MDSD typischen Abfall auf. Er ist den aus der industriellen Produktion bekannten sieben Kategorien von Abfall zugeordnet. Auch sind die unter [3] vorgestellten Entsprechungen in der Softwareentwicklung im Allgemeinen mit aufgeführt. Eine wesentliche Strategie zur Vermeidung von Abfall ist es, immer nur das zu produzieren, was aktuell nachgefragt wird (Pull System: „. deliver what they want, when they want it, in the amount they want it“ [4]).

Industrielle Produktion Software-entwicklung
im Allgemeinen
MDSD im Besonderen
Inventar Nicht vollständig erledigte Arbeit Domänenwissen, das man zwar modellieren kann, aber noch nicht in Transformationen verarbeitet wird

Fehlende Validierung für unterstützte Domänenkonzepte

Transformationen, die noch nicht in den Produktionsprozess integriert sind

Überproduktion Zusätzliche Features Ausdrucksmittel im Metamodell oder in der DSL, die in realen Domänenmodellen nicht verwendet werden

Generierung von Artefakten, die niemand verwendet

Nachbearbeitung Neuerfinden Manuelle Transformationsschritte

Nur teilautomatisierte Transformationen

Vor- oder Nachbearbeitung von Artfakten außerhalb des Produktionsprozesses

Transporte Arbeitsübergaben MSDS-Featureentwicklung in Mikrosilos

Manuelle Übernahme von Transformationsprodukten in einen separaten Produktionsprozess

Bewegung Aufgabenwechsel Ständiger Wechsel zwischen MDSD-Prozessentwicklung und Entwicklung für das Produkt, das MDSD-Artefakte konsumiert
Warten Verzögerungen Anlaufzeit für die Unterstützung eines neuen Domänenkonzepts im MDSD-Prozess

Zeit, die benötigt wird, um weitere Domänenmodelle in den Transformationsprozess einzupflegen

Defekte Defekte Generierung von fehlerhaften Artefakten

Tabelle 1: Vergleich zwischen Produktion, Softwareentwicklung und MDSD

MDSD und schnelle Entwicklung

Mit schneller Entwicklung ist hier nicht hastige Entwicklungstätigkeit gemeint, sondern ein Entwicklungsprozess, der die Zeit zwischen Planung eines Features und dessen Auslieferung möglichst kurz hält. Leider kann man immer wieder beobachten, dass bei der Einführung modellgetriebener Entwicklung eine falsche Strategie gewählt wird. Diese manifestiert sich in einer impliziten Unterscheidung von zwei Phasen:

  1. MDSD-Prozessentwicklung: Die Entwicklung des Metamodells, DSL und Transformationen und die Integration in den übergeordneten Entwicklungsprozess.
  2. MDSD in Produktion: Schnelle und billige Produktion von aus Modellen abgeleiteten Artefakten.

Dieser Ansatz ist fehlgeleitet und sogar gefährlich. Eine Entwicklungsmethode mit dem vagen Versprechen einzuführen, später einmal hoch produktiv zu sein, lässt sie als langsam und unflexibel erscheinen. Das kann zur vorzeitigen Ablehnung oder, wenn die Sponsoren nach initialer Zustimmung die Geduld verlieren, zum plötzlichen Abbruch führen. Stattdessen sollte man Folgendes beherzigen:

  • Schon in den ersten Iterationen sollte ein gewisses Maß an Anwendungsfunktionalität produziert werden
  • Kein „Big Design up-front“, statt dessen die für das aktuell nachgefragte Anwendungsfeature nötigen Erweiterungen an DSL, Transformationen und Workflows inkrementell zum Bestehenden hinzufügen
  • Vermeidung einer langen Warteschlange von durch den MDSD-Prozess zu unterstützenden Features (wird diese in der „first in, first out“-Reihenfolge abgearbeitet, erhöht sich mit zunehmender Länge auch die Zeitspanne zwischen Anforderung und Auslieferung eines Features)
  • Nur im Ausnahmefall einem spät angeforderten Feature Vorrang gewähren (dadurch erhöht sich die Wartezeit der zurückgestellten Features und führt letztlich zu einem Anstieg in der Varianz der Zeit zwischen Anforderung und Auslieferung, was den Produktionsprozess als unberechenbar erscheinen lässt).

Aus Sicht der schlanken Entwicklung empfiehlt es sich, die Anzahl der sich in Entwicklung befindenden Features zu begrenzen, auch bekannt als Work-in-Progress-(WIP-)Limit. Außerdem sollte stets die Balance zwischen den Features zur MDSD-Prozessentwicklung und Anwendungsentwicklung gewahrt werden.

Kommentare

Schreibe einen Kommentar

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