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 ?