Herausforderung: Organisation und Einführung

Größe: px

Ab Seite anzeigen:

Download "Herausforderung: Organisation und Einführung"

Kai Bieber
vor 5 Jahren
Abrufe

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

2 Seite 3 / 30 MDSD Rahmenbedingungen

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 Seite 6 / 30 Vorgehensweise (Abhängig vom aktuellen Wissensstand nicht zwingend chronologisch)

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 gute, wiederverwendbare Komponenten Infrastrukturentwicklung Anwendungsentwicklung möglichst schnell, gute Produkte Seite 10 / 30

10 Gegensätze Mögliche Lösung: agiler Entwicklungsprozess kurze Iterationsstufen gemeinsame Anforderungsanalyse Infrastrukturentwicklung Anwendungsentwicklung 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 Seite 28 / 30 Zusammenfassung

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 Seite 30 / 30 Fragen?

Ähnliche Dokumente

MDSD Einführung und Überblick

Model Driven Software Development MDSD Einführung und Überblick Referent: Carsten Schädel Seite 2 / 33 Ziele Grundgedanke Glossar der wichtigsten Begriffe Seite 3 / 33 Glossar Seite 4 / 33 mögliche Definitionen: