MDSD spezifisches Projektmanagement. Thomas Stahl b+m Informatik AG

Transkript

1 MDSD spezifisches Projektmanagement Thomas Stahl b+m Informatik AG

2 Firmenprofil b+m Informatik AG b+m / isn Gesamtanbieter für IT-Dienstleistungen mit Branchen- und Prozesskompetenz in den Bereichen Finanzwirtschaft, Handel & Logistik, Gebäude- & Wohnungswirtschaft, Öffentliche Verwaltung, Gesundheit & Sport Branchenunabhängige Kompetenz in den Bereichen Software-Architektur und Software-Engineering 205 Mitarbeiter Sitz in Melsdorf, Kiel, Hamburg, Hannover, Berlin, Cottbus Eines der führenden Norddeutschen Unternehmen in der IT-Branche isn Kiel / Hamburg: jüngste Tochtergesellschaft seit September 2005 Stetiges und stabiles Wachstum

3 b+m Seit über 10 Jahren praktische Projekt-Erfahrung mit MDSD Techniken, Engineering / Methodik, Management openarchitectureware MDSD-Tool-Suite Ursprünglich entwickelt bei b+m OpenSource Projekt seit 09/2003 Referenzen (nur MDSD ) Gothaer / IDG, VW, Audi, ivv, FinanzIT, Großbanken b+m Finance-Produkte

4 MDSD spezifisches Projektmanagement Motivation Warum MDSD-Tailoring für das Projektmanagement? Methode / Paradigma kann unter der Haube nicht das volle Potenzial ausspielen Know-how nicht beliebig verfügbar => Skalierungsprobleme möglich Traditionelle Schätzverfahren passen u. U. nicht (Architektur erhält z. B. ein anderes relatives Gewicht) Spezifische Artefakte müssen Eingang in das Releasemanagement und das Testing führen Spezifische Risiken verlangen spezifisches Risikomanagement

5 Grundlagen Denkmodell, Begriffe Application-Code Applikations- Applikations- Application- Modell Modell DSL DSL (e. g. Profile) Transfor-- Transformationen mations Domain Architecture analyse Individual Code Repetitive Code Generic Code separate Repetitive Code Handcrafted Handcrafted Individual Code Code Code Platform Plattform model driven generative domain specific re-usable implements a family of software uses creates

6 Trennung von Produkt- und Produktionsstraße Parallele Entwicklung von Anwendung und Domänenarchitektur Unmittelbares Feedback zwischen den Strängen Beide Stränge iterativ/inkrementell mit Timeboxing Die DA-Entwicklung ist der AW-Entwicklung eine Iteration voraus Stabile DA-Releases während einer Iteration Application Development (n) feedback Integration and Feedback Infrastructure Development (n+1)

7 Domänenarchitektur/ Bootstrapping Domäne Transformationen Plattform Domänenanalyse/ Design Prototyping Platffrom Plattform (initial) DSL/ Metamodell Referenzimplementierung erstellen DSL-Editor erstellen Referenzmodell erstellen Referenzimplementierung Referenzmodell Transformationen ableiten Programmiermodell dokumentieren Plattformentwicklung MDSD- Plattform Transformationen Programmier- Modell

8 Rollen Mögliches MDSD-Rollenmodell Application Engineering Domain Engineering Kunde Anwendungsentwickler Projektmanager Produktmanager Domänenanalytiker Domänen- Experte Domänenarchitekt Anwendungsarchitekt Kunde Domänenanalytiker Test - Ingenieur prachdesigner Referenzimplementierer Prototypentwickler Plattformentwickler Transformationsentwickler Anforderungsanalytiker Tester Domänenarchitekt Domänenexperte

9 Rollenbezogene Planung Personaleinsatz Anwendungsentwickler Domänenarchitekt und -analytiker Bootstrapping Stabilisierung und Rollout der Domänenarchitektur Routine Zeit

10 Test Test von Domänenarchitekturen (Produktionsstraße) Implizite Tests auf der konkreten Ebene, statt explizite Tests auf der Meta-Ebene (Problem: Überspezifikation) Aufbau von Unit-Tests / Test-Suiten an Konstrukten / Partitionen der DSL orientieren MDSD-Unterstützung für Testengineering Hier: Software-Test als MDSD-Domäne => DSL (Test-Partition), Generierung etc. Kaskadiertes MDSD ggf. sinnvoll, um Technologiebindungen zu isolieren

11 Versionierung Trennung von Produkt und Produktionsstraße Framework-Metapher Integration von generiertem und nicht-generiertem Code Integrationspattern für Code vs. Protected-Regions / Areas Versionierung von Teilmodellen Partitionierung von DSL und Metamodell (vertikal, horizontal) Verteilte Modellierung und Evolution: Unterschiedliche Versionen einer DA(-Partition) einsetzbar Integrationspattern für Partitionen (auf Modell-Ebene oder via Transformation / Generator)

12 Aktives Risikomanagement Einige typische Risiken bei MDSD-Projekten Toolzentriertheit Gesetzte, aber kontraproduktive Toolkette oder Vorgehen Überlastetes DA-Entwicklungs-Team Elfenbeinturm Keine Trennung zwischen Produkt und Produktionsstraße Fehlendes (Release-)Management bei manuellen Eingriffen in das Generat MDSD-unerfahrene Teams oder Projektmanager ohne Coach Unkontrolliertes Off-/Near-shoring

13 Adaptionsstrategien Projekt Legacy Unternehmen Evolution Auswahl eines Pilotprojektes Nutzen vs. Kosten + Risiken (Keimzelle, Automationspotenzial, Start small, Akzeptanz auf Entwicklerseite, Coaching, nicht-kontraproduktive Infrastruktur) Start mit architekturzentrierter MDSD Explizite Projektinitialisierung (Grundlagen, Rollendefinition, Planung) Modellierung / Generierung von Adapter-Infrastruktur (SOA/BPM) Modernisierung (Refactoring, DA-Bootstrapping, Nachmodellierung) Klassifikation des Software-Inventars (Strategisch (Wettbewerbsvorteil), Nichtstrategisch (Infrastruktur), Legacy) Definition von Zulieferketten (Supply Chains): Make, Buy, OpenSource MDSD als Integrationswerkzeug Make strategischer Assets: PLE+MDSD MDSD und/vs. Offshoring? Wartung/Evolution von Domänenarchitekturen (Assets) Kaskadierung von DA, Productline-Engineering

14 Kurze Werbung ;-); MDSD-Buch (deutsch) Stahl, Völter et al, dpunkt 2005 Techniken, Engineering, Management Zweite, aktualisierte Auflage in Arbeit MDSD-Buch (englisch) Stahl, Völter et al, Wiley 2006 Aktualisierter Inhalt gegenüber der 1. deutschen Auflage