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

1. Case Story :
Modellgetriebene Softwareentwicklung
bei der Rentenzahlung
Referenten:
Holger Benz (Deutsche Post AG, NL Renten Service)
Christoph Schmidt-Casdorff (iks GmbH)
Seite 2 / 32

2. Einführung
Erfahrungsbericht über den Einsatz von MDSD
– MDSD - Modellgetriebene Softwareentwicklung im Projekt
AMIS der NL Renten Service der Deutschen Post AG
– konkrete Erfahrungen aus einzelnen ausgewählten Bereichen
der MDSD
Folien mit projektbezogenen Aussagen tragen ‘AMIS‘ im Titel
Keine Einführung in MDSD / MDA
Seite 3 / 32

3. NL Renten Service
NL Renten Service der Deutschen Post AG
Zahlung der gesetzlichen deutschen Altersrente
– gemäß den gesetzlichen Bestimmungen
– im Auftrag der Träger der Rentenversicherung
Seite 4 / 32

4. NL Renten Service
26 Millionen Konten von ca. 18 Millionen Rentnern
305 Millionen Rentenzahlungen pro Jahr
24 Millionen Rentenberechnungen pro Jahr
17 Millionen Rentenzahlungen ins Ausland pro Jahr
Auszahlung von 195 Milliarden € pro Jahr
Seite 5 / 32

5. Projektbeschreibung AMIS
Änderungsmanagement und Informationsaustausch
mit Leistungsträgern (DRV/Bund et al.)
– großteils dateibasierte Satzverarbeitung
– Größenordnung pro Monat:
• Auflieferung von ca. 0,5 – 1 Mio. Datensätze
• Versand von bis zu mehreren Mio. Datensätzen an die Leistungsträger
Seite 6 / 32

6. Seite 7 / 32
AM Batch
AM Dialog
AM Pensionen Weltweit
AM Abgleichsersuchen
ZM Entgelte & Auslagen
Projektbeschreibung AMIS
ZM Zahlungsausführung
ZM Pensionen Weltweit
Phasen in AMIS
LM Rückfluss-
/Rückforderung
LM Postvorschuss
LM Pensionen Weltweit
LM Kontoauszug / Abgleich

7. Projektbeschreibung AMIS
Phase 1 : AMIS – Veränderungsdienst abgeschlossen
und im Wirkbetrieb
Mehrjähriger Zeithorizont des Gesamtprojektes
Seite 8 / 32

8. Problembeschreibung AMIS
Zentrales Businessmodell, welches
– durch 3 Datei-/ Datensatzformate gespeist wird
– in mehr als 15 Datensatzformate transformiert wird
– in Web-GUIs dargestellt wird
– in mehr als 10 Kundenanschreiben transformiert wird
>30 Formate beziehen sich auf das Businessmodell
– je Format mehr als 1000 Einzelinformationen
Seite 9 / 32

9. Problembeschreibung AMIS
Name Vorname Titel
GUI
Byte-Position
. . . .
Datensatz
Datensatz
-format Datensatz
Datensatz
-format Zentrales Datensatz
-format
business model Datensatz
-format
-format
-format
Datensatz
-format
business logic
Anschreiben
Anschreiben
Anschreiben
Seite 10 / 32

10. Motivation für MDSD in AMIS
Familie von Softwaresystem mit struktureller Gemeinsamkeit
– Gemeinsamkeit ist modellierbar
– Gemeinsamkeiten sind in jeder Phase (von AMIS) zu finden
Zentrales Management der Detailinformationen
– Dokumentation und Management von Abhängigkeiten
– Detailinformationen nicht doppelt in Analyse und Implementierung
Große Anforderung an Qualität
– Qualitätssicherung durch Generierungsansatz
Seite 11 / 32

11. DSL in AMIS
Seite 12 / 32

12. DSL in AMIS
Seite 13 / 32

13. DSL in AMIS
• DSL – Metamodell mittels UML
• Unsere DSL unterstützt programmierbare Erweiterungen
des Modells
Seite 14 / 32

14. DSL in AMIS
+ Ermittlung der DSL durch Referenzmodell
• Ermittlung des Metamodells (und der DSL) anhand
einer Referenzmodellierung
• damit waren ca. 80% der DSL erfasst
• die restlichen 20% ergaben sich innerhalb eines Jahres
durch neue Anforderungen seitens der Modellierung
• seitdem ist DSL stabil
Prozess zur Ermittlung der DSL war nicht vorgegeben
― schlecht planbar
Seite 15 / 32

15. Generatoren in AMIS
- Generatoren auf nicht ausgereifter DSL aufgesetzt
- Generatoren und Framework wurden zu früh parallel zum
Referenzmodell umgesetzt
 führte zu unnötigem Refactoring
• Geduld mitbringen, bis DSL/Metamodell eine zufriedenstellende
Reife erreicht hat
Seite 16 / 32

16. Softwarearchitektur in AMIS
Ermittlung, Validierung und Wartung der Zielplattform
+ Prototyp für Generatoren und Framework
+ Implementierung einer Referenzarchitektur
+ Validierungen von DSL-Erweiterungen
+ Referenzarchitektur wird gepflegt
Seite 17 / 32

17. Testverfahren in AMIS
Modell
– Modellvalidierung (syntaktische Qualitätssicherung)
- derzeit mit eigen-implementierter Validierung
Generatoren / Framework
– Validierung der DSL/Generatoren durch Referenzmodell
und zugehörige Unit-Tests
Seite 18 / 32

18. Testverfahren in AMIS
Programmierte Modellerweiterungen
– Entwicklung einer Simulationssoftware für aus-/ eingehende
Datenformate
Generate
– Integrations- und Akzeptanztests auf großer Datenmenge
Modell
– Inhaltliche Qualitätssicherung auf Modellebene
Seite 19 / 32

19. Rollen und deren Anforderungen
Rollen für
Domäne / Modellierung
– DSL-Analyse
– Modellierung
– Architektur
Generatoren / Transformationen
– Architektur, Generatorenentwicklung, Frameworkentwicklung
– Generierung
Seite 20 / 32

20. Rollen in AMIS
Es wurden Rollen in Personalunion besetzt
– Architektur, Generatorenentwicklung
– DSL-Analyse, Modellierung
– Generierung besetzen spezielle EntwicklerInnen
Sehr erfahrene Köpfe für DSL-Analyse, Generatoren-
und Frameworkentwicklung
− Gefahr von ,Kopfmonopolen’ in kleinen Teams
+ Große Flexibilität gerade in ‘Aufbruchsphase‘
Seite 21 / 32

21. Modellierung in AMIS
Modellierung mündet unmittelbar in Software:
+ Verlangt große Exaktheit der Analyse
− Laufzeitaspekte fließen in Modellierung ein
Pair-Modelling (Modellierung + Entwicklung)
Betreuung der DSL durch Architektur und DSL-Analyse
+ Erweiterungen der DSL werden erkannt
+ Ausdehnung der Software-Systemfamilie
Seite 22 / 32

22. Generierung in AMIS
− Modell beeinflusst mehrere Teilprojekte daher
explizite Generierung:
– Generierung obliegt der Entwicklung
– Generierung ist nicht Bestandteil des Build-Prozesses
– Versionierung der Generate pro Teilprojekt
– auf separatem Rechner inkl. lokaler Modultests
– explizite Freigabe von Versionen der Generate
Seite 23 / 32

23. Einsatz von MDSD in AMIS
Einsatz von MDSD > 40% (bezogen auf Modelle)
Mengengerüste
– derzeit ca. 100.000 Modellelemente, davon < 2% (ca. 1.900)
programmatisch ergänzt
Kleines Entwicklungs- und Modellierungsteam
(< 10 Personen)
– davon 3 externe Kräfte
Seite 24 / 32

24. Ablösung der
Aufwände bzgl. MDSD proprietären
Generatorumgebung
PT aggregiert
Insgesamt 4 Releases
1000
Aufwand verringert
sich deutlich
800
600
Stabilisierung
der Infrastruktur
400
Aufsetzen und Pflege der MDSD-
Infrastruktur
200
0
2003 2004 2005 2006 2007 2008 Jahr
Projektbeginn Wirkbetriebseinführung Phase 1
Seite 25 / 32

25. Aufwände bzgl. MDSD
PT aggregiert Wiederverwendung von
Pflege der MDSD
Infrastruktur Modellen und Entwicklung
1000
Modellierungsaufwand erreicht
800
den für MDSD-Infrastruktur
600
Vorlauf zur Erzeugung
der Infrastruktur
400
200 Modellierung
0
2003 2004 2005 2006 2007 2008 Jahr
Projektbeginn Wirkbetriebseinführung Phase 1
Seite 26 / 32

26. Aktueller Stand in AMIS
Stabilität / Verlässlichkeit
– DSL ist seit über einem Jahr stabil
– Generatoren sind stabil und zuverlässig
– Framework ist bis auf kleinere Änderungen stabil
– Entwicklungsprozess hat sich stabilisiert und bewährt
Seite 27 / 32

27. Risiken in AMIS
Methodik ist pflegeintensiv
– muß konsequent gelebt werden
– neigt zu Erosion
– erfordert Verständnis der Beteiligten am Prozess
– Weg zurück ist schwer
domänen-zentrierte MDSD greift früh im Entwicklungsprozess
– systematische Fehler haben gravierende Auswirkungen
Bindung der Generatoren an proprietäres Tool
Komplexität der DSL muss begrenzt bleiben
– Gefahr unklarer Modellierungsregeln
– Gefahr impliziter Abhängigkeiten zwischen Modellierungselementen
Seite 28 / 32

28. Sicht des Projektmanagements
Integration von Modellierung und Implementierung
– erschwert Zuordnung der Verantwortlichkeiten für einzelne
Arbeitsergebnisse
• Termin- und Aufwandskontrolle wird schwieriger
– klassische Wasserfallmethode ist fast unmöglich
• Iterationen zwischen Modellierung und Entwicklung
Seite 29 / 32

29. Bewertung von MDSD nach 5 Jahren
Erfolgreiches Management der Mengen an Detailinformationen
Robuste Software durch Framework-Einsatz
Wartungsaufwand reduziert sich um mehr als 50 %
(konservativ geschätzt)
– Vergleich der Aufwände bereits abgelöster Anwendung zu
nicht abgelösten Anwendungen
Seite 30 / 32

30. Resümee
In unserem Fall und bei unserer Ausgangssituation hat sich der
Einsatz von Modellgetriebener Softwareentwicklung gelohnt.
Seite 31 / 32

31. www.iks-gmbh.com
www.deutschepost.de/rentenservice
Seite 32 / 32