Post on 26-Jun-2015
description
transcript
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 ?