mdsd projektbericht modellgetriebene softwareentwicklung bei der rentenzahlung

Post on 29-Nov-2014

1.099 Views

Category:

Technology

2 Downloads

Preview:

Click to see full reader

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

TRANSCRIPT

Seite 2 / 32

Case Story :

Modellgetriebene Softwareentwicklung

bei der Rentenzahlung

Referenten:

Holger Benz (Deutsche Post AG, NL Renten Service)

Christoph Schmidt-Casdorff (iks GmbH)

Seite 3 / 32

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 4 / 32

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 5 / 32

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 6 / 32

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 7 / 32

AM

Abgle

ichsers

uchen

AM

Dia

log

AM Pensionen Weltweit

Phasen in AMIS

ZM

Entg

elte &

Ausla

gen

ZM

Zahlu

ngsausfü

hru

ng

ZM Pensionen WeltweitLM

Rückfluss-

/Rückfo

rderu

ng

LM

Postv

ors

chuss

LM

Konto

auszug /

Abgle

ich

LM Pensionen Weltweit

Projektbeschreibung AMISA

M B

atc

h

Seite 8 / 32

Projektbeschreibung AMIS

Phase 1 : AMIS – Veränderungsdienst abgeschlossen

und im Wirkbetrieb

Mehrjähriger Zeithorizont des Gesamtprojektes

Seite 9 / 32

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 10 / 32

Byte-Position . . . .

Name Vorname Titel

Datensatz-format

Anschreiben

Datensatz-format Datensatz-format Datensatz-format

GUI

Zentrales business model

business logic

Anschreiben

Datensatz-format Datensatz-format Datensatz

-format

Anschreiben

Problembeschreibung AMIS

Seite 11 / 32

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 12 / 32

DSL in AMIS

Seite 13 / 32

DSL in AMIS

Seite 14 / 32

DSL in AMIS

• DSL – Metamodell mittels UML

• Unsere DSL unterstützt programmierbare Erweiterungen

des Modells

Seite 15 / 32

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 16 / 32

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 17 / 32

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 18 / 32

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 19 / 32

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 20 / 32

Rollen und deren Anforderungen

Rollen für

Domäne / Modellierung

– DSL-Analyse

– Modellierung

– Architektur

Generatoren / Transformationen

– Architektur, Generatorenentwicklung, Frameworkentwicklung

– Generierung

Seite 21 / 32

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 22 / 32

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 23 / 32

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 24 / 32

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 25 / 32

PT aggregiert

200

400

600

800

1000

2003 2004 2005 2006 2007 2008 Jahr

Wirkbetriebseinführung Phase 1Projektbeginn

0

Aufsetzen und Pflege der MDSD-

Infrastruktur

Insgesamt 4 Releases

Aufwände bzgl. MDSDAblösung der

proprietären

Generatorumgebung

Stabilisierung

der Infrastruktur

Aufwand verringert

sich deutlich

Seite 26 / 32

PT aggregiert

200

400

600

800

1000

Modellierung

2003 2004 2005 2006 2007 2008 Jahr

Wirkbetriebseinführung Phase 1 Projektbeginn

0

Aufwände bzgl. MDSD

Vorlauf zur Erzeugung

der Infrastruktur

Wiederverwendung von

Modellen und Entwicklung

Modellierungsaufwand erreicht

den für MDSD-Infrastruktur

Pflege der MDSD

Infrastruktur

Seite 27 / 32

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 28 / 32

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 29 / 32

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 30 / 32

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 31 / 32

Resümee

In unserem Fall und bei unserer Ausgangssituation hat sich der

Einsatz von Modellgetriebener Softwareentwicklung gelohnt.

Seite 32 / 32

www.iks-gmbh.com

www.deutschepost.de/rentenservice

top related