Am 8. April 2008 fand in den Räumlichkeiten des Kosaido International Golfclubs in Düsseldorf die zweite Veranstaltung zum Thema modellgetriebene Softwareentwicklung (MDSD) statt. Unter dem Titel "MDSD - Chance und Herausforderung für IT-Organisationen" lag der Schwerpunkt der Vorträge dieses Mal auf den Organisatorischen Rahmenbedingungen, in denen MDSD erfolgreich betreiben. Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege

1. Model Driven Software Development
Herausforderung:
Organisation und Einführung
Referent:
Carsten Schädel
Seite 2 / 30

2. MDSD – Rahmenbedingungen
Seite 3 / 30

3. Rahmenbedingungen von MDSD
… ist ein Paradigmenwechsel
… ist nicht für jedes Problem einsetzbar
… schafft neue anspruchsvolle Rollen im Entwicklungsprozess
… bedarf Vorleistungen
Seite 4 / 30

4. Rahmenbedingungen von MDSD
… führt i.d.R. nicht zur vollständigen Generierung des Codes
… ist i.d.R. nicht das alleinige Verfahren innerhalb eines Projektes
Seite 5 / 30

5. Vorgehensweise
(Abhängig vom aktuellen Wissensstand –
nicht zwingend chronologisch)
Seite 6 / 30

6. Vorgehensweise
Voraussetzungen – MDSD
Seite 7 / 30

7. Voraussetzungen - MDSD
MDSD-tauglicher Problemraum?
Zeit?
Budget?
Rückendeckung Management?
Wissensstand der Projektteams?
Seite 8 / 30

8. Vorgehensweise
Voraussetzungen – MDSD
Gegensätze meistern
Seite 9 / 30

9. Gegensätze
Infrastruktur- Anwendungs-
entwicklung entwicklung
gute, wiederverwendbare Komponenten möglichst schnell, gute Produkte
Seite 10 / 30

10. Gegensätze
Mögliche Lösung: agiler Entwicklungsprozess
kurze Iterationsstufen
Infrastruktur- Anwendungs-
entwicklung entwicklung
gemeinsame
Anforderungsanalyse
kurze Iterationsstufen
gemeinsame
Anforderungsanalyse
Kunde
Seite 11 / 30

11. Gegensätze
wenn ungelöst, kann drohen:
– fehlende Akzeptanz bei Entwicklern und Kunden
– fehlende Akzeptanz beim Management
– scheitern des Projektes
Seite 12 / 30

12. Vorgehensweise
Voraussetzungen – MDSD
Gegensätze meistern
Voraussetzungen – Paradigmenwechsel
Seite 13 / 30

13. Voraussetzungen - Paradigmenwechsel
Iterationsstufen definieren
– so gering wie möglich
– keine Anforderungsänderung innerhalb einer Stufe
Projektmeetings definieren
– kurze Statusmeetings z.B. einmal die Woche oder einmal am Tag?
offene Umgebung schaffen
– rechtzeitig Trainings- bzw. Coachingbedarf erkennen
Seite 14 / 30

14. Voraussetzungen - Paradigmenwechsel
längere Entwicklungszeiten akzeptabel?
positiv mit Zweifeln umgehen
– MDSD verargumentieren können
– Zweifeln im Projektteam/ Entwicklern/ Umgebung entgegenwirken
Seite 15 / 30

15. Vorgehensweise
Voraussetzungen – MDSD
Gegensätze meistern
Voraussetzungen – Paradigmenwechsel
neue, bzw. veränderte Rollen besetzen
Seite 16 / 30

16. Neue oder veränderte Rollen
Domänenanalysten
– Analyse der Domäne
– Modellierung
– starke Integration der Fachabteilungen (bei fachlicher MDSD)
Infrastrukturentwickler
– MDSD Infrastruktur
– DSL-Erstellung
– Generator und Transformatoren
– Frameworks und Tools
Seite 17 / 30

17. Neue oder veränderte Rollen
Anwendungsentwickler
– Verwendung der DSL und Modelle
– Verwendung der Infrastruktur
Coach
– Coaching für Mitarbeiter und Fachabteilungen
Tester
Seite 18 / 30

18. Neue oder veränderte Rollen
Rollen können in Personalunion besetzt werden
– MDSD-Projektteams müssen nicht riesig sein 
Benötigte Rollen hängen von Art der MDSD ab
– architektur- oder fachlich- zentriert
Spezialisierung
Seite 19 / 30

19. Nicht alle Rollen besetzbar?
Coaching
externe Unterstützung
mit architektur-zentrierter MDSD starten
Seite 20 / 30

20. Vorgehensweise
Voraussetzungen – MDSD
Gegensätze meistern
Voraussetzungen – Paradigmenwechsel
neue, bzw. veränderte Rollen besetzen
‚starke‘ technische Projektleitung
Seite 21 / 30

21. Technische Projektleitung
hohes Verständnis von MDSD und der Bedeutung der
Generierung und Modelle
– keine unbedachte Änderung der Generatoren und Modelle!
Code-Reviews
– auch als Mittel des Trainings
– eventuell mit ‚externer‘ Unterstützung
sollte technisch mind. auf ‚Augenhöhe‘ mit Entwicklern sein
– ‚Ausreißer‘ erkennen
Seite 22 / 30

22. Vorgehensweise
Voraussetzungen – MDSD
Gegensätze meistern
Voraussetzungen – Paradigmenwechsel
neue, bzw. veränderte Rollen besetzen
‚starke‘ technische Projektleitung
mit ‚proof of concept‘ starten
Seite 23 / 30

23. ‚proof of concept‘
Projekt mit ‚anderen‘ Rahmenbedingungen
– mehr Budget und Zeit
Projekt mit überschaubarem Risiko
– wichtig genug und gleichzeitig unwichtig genug
auch ein großes, wichtiges Projekt kann gestemmt werden
– hängt vom Wissenstand des Projektteams ab
Seite 24 / 30

24. ‚proof of concept‘
architektur-zentrierte MDSD
– IT intern
– besser, wenn noch kein MDSD-Wissen vorhanden ist
fachlich-zentrierte MDSD
– Fachabteilungen müssen mit einbezogen werden
– mit bekannter, überschaubarer Domäne starten
– größtes Potential – größere Herausforderung
Seite 25 / 30

25. Vorgehensweise
Voraussetzungen – MDSD
Gegensätze meistern
Voraussetzungen – Paradigmenwechsel
neue, bzw. veränderte Rollen besetzen
‚starke‘ technische Projektleitung
mit ‚proof of concept‘ starten
Analyse ‚proof of concept‘
Seite 26 / 30

26. Analyse ‚proof of concept‘
Zeit, Budget?
Akzeptanz bei Projektteams und Fachabteilungen?
– Fachabteilungen bei fachlicher MDSD
Unterstützung notwendig?
Seite 27 / 30

27. Zusammenfassung
Seite 28 / 30

28. Zusammenfassung
Wahl der MDSD-Art
– bei geringen/keinen Vorkenntnissen mit architektur-zentrierter
MDSD starten
– größtes Potential (bei größerer Herausforderung) liegt aber
in der fachlich-zentrierten MDSD
mit Key-Playern und ‚proof of concept‘ starten
mit realistischem Zeit- und Budgetrahmen starten
Paradigmenwechsel vorbereiten
Seite 29 / 30

29. Fragen ?
Seite 30 / 30