Upload
iks-gesellschaft-fuer-informations-und-kommunikationssysteme-mbh
View
575
Download
2
Embed Size (px)
DESCRIPTION
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
Citation preview
Seite 2 / 30
Herausforderung:
Organisation und Einführung
Referent:
Carsten Schädel
Model Driven Software Development
Seite 3 / 30
MDSD – Rahmenbedingungen
Seite 4 / 30
Rahmenbedingungen von MDSD
… ist ein Paradigmenwechsel
… ist nicht für jedes Problem einsetzbar
… schafft neue anspruchsvolle Rollen im Entwicklungsprozess
… bedarf Vorleistungen
Seite 5 / 30
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 6 / 30
Vorgehensweise(Abhängig vom aktuellen Wissensstand –
nicht zwingend chronologisch)
Seite 7 / 30
Vorgehensweise
Voraussetzungen – MDSD
Seite 8 / 30
Voraussetzungen - MDSD
MDSD-tauglicher Problemraum?
Zeit?
Budget?
Rückendeckung Management?
Wissensstand der Projektteams?
Seite 9 / 30
Vorgehensweise
Voraussetzungen – MDSD
Gegensätze meistern
Seite 10 / 30
Gegensätze
Infrastruktur-
entwicklung
Anwendungs-
entwicklung
gute, wiederverwendbare Komponenten möglichst schnell, gute Produkte
Seite 11 / 30
Gegensätze
Infrastruktur-
entwicklung
Anwendungs-
entwicklung
Mögliche Lösung: agiler Entwicklungsprozess
Kunde
kurze Iterationsstufen
gemeinsame
Anforderungsanalysekurze Iterationsstufen
gemeinsame
Anforderungsanalyse
Seite 12 / 30
Gegensätze
wenn ungelöst, kann drohen:
– fehlende Akzeptanz bei Entwicklern und Kunden
– fehlende Akzeptanz beim Management
– scheitern des Projektes
Seite 13 / 30
Vorgehensweise
Voraussetzungen – MDSD
Gegensätze meistern
Voraussetzungen – Paradigmenwechsel
Seite 14 / 30
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 15 / 30
Voraussetzungen - Paradigmenwechsel
längere Entwicklungszeiten akzeptabel?
positiv mit Zweifeln umgehen
– MDSD verargumentieren können
– Zweifeln im Projektteam/ Entwicklern/ Umgebung entgegenwirken
Seite 16 / 30
Vorgehensweise
Voraussetzungen – MDSD
Gegensätze meistern
Voraussetzungen – Paradigmenwechsel
neue, bzw. veränderte Rollen besetzen
Seite 17 / 30
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 18 / 30
Neue oder veränderte Rollen
Anwendungsentwickler
– Verwendung der DSL und Modelle
– Verwendung der Infrastruktur
Coach
– Coaching für Mitarbeiter und Fachabteilungen
Tester
Seite 19 / 30
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 20 / 30
Nicht alle Rollen besetzbar?
Coaching
externe Unterstützung
mit architektur-zentrierter MDSD starten
Seite 21 / 30
Vorgehensweise
Voraussetzungen – MDSD
Gegensätze meistern
Voraussetzungen – Paradigmenwechsel
neue, bzw. veränderte Rollen besetzen
‚starke‘ technische Projektleitung
Seite 22 / 30
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 23 / 30
Vorgehensweise
Voraussetzungen – MDSD
Gegensätze meistern
Voraussetzungen – Paradigmenwechsel
neue, bzw. veränderte Rollen besetzen
‚starke‘ technische Projektleitung
mit ‚proof of concept‘ starten
Seite 24 / 30
‚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 25 / 30
‚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 26 / 30
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 27 / 30
Analyse ‚proof of concept‘
Zeit, Budget?
Akzeptanz bei Projektteams und Fachabteilungen?
– Fachabteilungen bei fachlicher MDSD
Unterstützung notwendig?
Seite 28 / 30
Zusammenfassung
Seite 29 / 30
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 30 / 30
Fragen ?