MDSD Herausforderung: Organisation und Einführung

723 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie, Business
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
723
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
13
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

MDSD Herausforderung: Organisation und Einführung

  1. 1. Model Driven Software Development Herausforderung: Organisation und Einführung Referent: Carsten SchädelSeite 2 / 30
  2. 2. MDSD – RahmenbedingungenSeite 3 / 30
  3. 3. Rahmenbedingungen von MDSD … ist ein Paradigmenwechsel … ist nicht für jedes Problem einsetzbar … schafft neue anspruchsvolle Rollen im Entwicklungsprozess … bedarf VorleistungenSeite 4 / 30
  4. 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 ProjektesSeite 5 / 30
  5. 5. Vorgehensweise (Abhängig vom aktuellen Wissensstand – nicht zwingend chronologisch)Seite 6 / 30
  6. 6. Vorgehensweise Voraussetzungen – MDSDSeite 7 / 30
  7. 7. Voraussetzungen - MDSD MDSD-tauglicher Problemraum? Zeit? Budget? Rückendeckung Management? Wissensstand der Projektteams?Seite 8 / 30
  8. 8. Vorgehensweise Voraussetzungen – MDSD Gegensätze meisternSeite 9 / 30
  9. 9. Gegensätze Infrastruktur- Anwendungs- entwicklung entwicklunggute, wiederverwendbare Komponenten möglichst schnell, gute Produkte Seite 10 / 30
  10. 10. Gegensätze Mögliche Lösung: agiler Entwicklungsprozess kurze Iterationsstufen Infrastruktur- Anwendungs- entwicklung entwicklung gemeinsame Anforderungsanalyse kurze Iterationsstufen gemeinsame Anforderungsanalyse KundeSeite 11 / 30
  11. 11. Gegensätze wenn ungelöst, kann drohen: – fehlende Akzeptanz bei Entwicklern und Kunden – fehlende Akzeptanz beim Management – scheitern des ProjektesSeite 12 / 30
  12. 12. Vorgehensweise Voraussetzungen – MDSD Gegensätze meistern Voraussetzungen – ParadigmenwechselSeite 13 / 30
  13. 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 erkennenSeite 14 / 30
  14. 14. Voraussetzungen - Paradigmenwechsel längere Entwicklungszeiten akzeptabel? positiv mit Zweifeln umgehen – MDSD verargumentieren können – Zweifeln im Projektteam/ Entwicklern/ Umgebung entgegenwirkenSeite 15 / 30
  15. 15. Vorgehensweise Voraussetzungen – MDSD Gegensätze meistern Voraussetzungen – Paradigmenwechsel neue, bzw. veränderte Rollen besetzenSeite 16 / 30
  16. 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 ToolsSeite 17 / 30
  17. 17. Neue oder veränderte Rollen Anwendungsentwickler – Verwendung der DSL und Modelle – Verwendung der Infrastruktur Coach – Coaching für Mitarbeiter und Fachabteilungen TesterSeite 18 / 30
  18. 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 SpezialisierungSeite 19 / 30
  19. 19. Nicht alle Rollen besetzbar? Coaching externe Unterstützung mit architektur-zentrierter MDSD startenSeite 20 / 30
  20. 20. Vorgehensweise Voraussetzungen – MDSD Gegensätze meistern Voraussetzungen – Paradigmenwechsel neue, bzw. veränderte Rollen besetzen ‚starke‘ technische ProjektleitungSeite 21 / 30
  21. 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‘ erkennenSeite 22 / 30
  22. 22. Vorgehensweise Voraussetzungen – MDSD Gegensätze meistern Voraussetzungen – Paradigmenwechsel neue, bzw. veränderte Rollen besetzen ‚starke‘ technische Projektleitung mit ‚proof of concept‘ startenSeite 23 / 30
  23. 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 abSeite 24 / 30
  24. 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 HerausforderungSeite 25 / 30
  25. 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. 26. Analyse ‚proof of concept‘ Zeit, Budget? Akzeptanz bei Projektteams und Fachabteilungen? – Fachabteilungen bei fachlicher MDSD Unterstützung notwendig?Seite 27 / 30
  27. 27. ZusammenfassungSeite 28 / 30
  28. 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 vorbereitenSeite 29 / 30
  29. 29. Fragen ?Seite 30 / 30

×