AGILE MODELLBASIERTESOFTWAREENTWICKLUNGIN DER PRAXIS

agilen Vorgehensweisen bekannt waren:Dies sind beispielsweise die iterativ-inkre-mentelle Entwicklung, Timeboxing, diePriorisierung von Anforderungen und dieintensive sowie frühe Einbindung desKunden bzw. der Endanwender. AusPlatzgründen können hier nur einige wenigeTechniken Erwähnung finden, die für dasProjektmanagement von Bedeutung sind.

Agiles Projektmanagement betrachtetnicht nur Prozesse, sondern auch Produkte,die wir in Anlehnung an den RationalUnified Process (RUP) Artefakte nennen.Die Basis sind Vorlagen, die für das gesamte

Wenn die Entwicklungsprozesse bereits nach MDA/MDD-Ansatz (Model DrivenArchitecture bzw. Development) ausgerichtet sind und eine entsprechende MDA-Tool-Kette existiert, dann ist agiles Projektmanagement (APM) für die modellbasierteSoftwareentwicklung ein weiterer folgerichtiger Schritt in Richtung „professionelleMDA-Projekte”. In diesem Rahmen sind das Projektmanagement und das Zusamm-enspiel mit der Softwareentwicklung zu optimieren. Der Artikel zeigt einen praxisna-hen Ansatz, um auf der Basis des „Eclipse Process Framework” einen MDA-Entwicklungsprozess für das Projektmanagement bereitzustellen und dabeikonsequent agil und damit flexibel zu bleiben. Wir nennen diesen Ansatz APM4MDA.

m e h r z u m t h e m a :www.qme-Software.dewww.apm4mda.org

36 37

Prof. Dr. Roland Petrasch

(E-Mail: petrasch@tfh-berlin,de)

lehrt und forscht an der TFH Berlin im

Bereich modellbasierte Softwareent-

wicklung sowie Projekt- und

Qualitätsmanagement.

Florian Fieber

(E-Mail: florian.fieber@qme-software.de)

ist Berater bei der qme Software in Berlin

und beschäftigt sich mit Qualitätsmanage-

ment im Rahmen von MDA-Projekten.

Maciej A. Bednarz

(E-Mail: mab@hacon.de)

ist Softwareentwickler bei der HaCon

Ingenieuresellschaft mbH in Hannover

und beschäftigt sich mit den Themen

JEE/ SOA-Architekturen, Softwaretest und

angewandte MDA.

■ Kombiniertes Vorgehen: Traditionelle(schwergewichtige) Vorgehensmodelle,z. B. das V-Modell XT (vgl. [VMXT]),und agile (leichtgewichtige) Vorgehens-weisen sind kein Widerspruch und las-sen sich durchaus kombinieren.

■ Regelwerk: Auch die agilen Vor-gehensweisen kommen mit klarenVorgaben daher (vgl. [Oes08]) und soll-ten nicht in einer Beliebigkeit oderAnarchie enden, wo jeder alles darf.

■ Externe und interne Sicht: Teams mitagilen Vorgehensweisen sind internbasisdemokratischer und selbst organi-sierter als bei traditionellen Ansätzen.Nach außen muss dies jedoch nichtzwingend „sichtbar” sein.

■ Werte im Vordergrund: Agile Ansätzebetonen den Menschen und die Werte,nach denen gehandelt wird, und unter-breiten durchaus auch konkrete Vor-schläge zum Vorgehen, liefern jedochkein umfassendes Wertesystem im Sinneeiner Leitkultur.

Besonders die zuweilen heraufbeschworenePolarisierung, die die traditionellen Vor-gehensmodelle (Stichwort „Wasserfall”)von den agilen Verfahren trennt, führt zuGlaubenskriegen und ist wenig zielführend,denn es bestehen viele Gemeinsamkeitenund sie lassen sich in Einklang bringen. Sobietet das V-Modell XT beispielsweise eineProjektdurchführungsstrategie für die agileSystementwicklung an, wobei es vor einerBewertung allerdings weiterer praktischerErfahrungen bedarf.

Agiles ProjektmanagementIm Folgenden wollen wir uns weniger mitden Werten der Agilität befassen als mit denhandfesten Praktiken, die sich aufPrinzipien stützen, die schon lange vor den

Agilität – was wardas doch gleich?Agile Ansätze existieren mittlerweile insehr unterschiedlicher theoretischer undpraktischer Ausprägung: Da werden einige„gute alte” XP-Techniken (eXtremeProgramming) in Verbindung mit anderen,eher schwergewichtigen Vorgehensmo-dellen verwendet oder es gibt Scrum-Projekte, die der reinen Lehre folgen. Beider Vielfalt der Verfahren und Variantenfällt es schwer, die agilen Gemeinsamkeitenund Best Practices zu erkennen und einoptimales Vorgehen zu finden. Denn wederdas blinde Mitlaufen und kritikloseAkzeptieren der Agilität, noch eine unre-flektierte Abwehrhaltung sind hilfreich.Das Fehlen substanzieller sozialer, organi-satorischer und methodischer Bausteine imSoftwareentwicklungsprozess macht jedenAnsatz – ob agil oder nicht agil – unglaub-würdig und führt letztlich nur zur„Wurschtelei”. Das gilt sowohl für denEngineering-Prozess als auch für Quer-schnittsaufgaben, wie das Projekt- undQualitätsmanagement.

Was steckt nun eigentlich hinter demBegriff „Agilität” und wie grenzt diesersich von den traditionellen Ansätzen ab?Keine Sorge: An dieser Stelle wollen wirnicht die altbekannten Prinzipien desAgilen Manifestes ausbreiten, z. B. „Busi-ness people and developers must worktogether daily throughout the project” (vgl.[Bec01]), sondern eher einige kurze An-merkungen machen, die für das Verstehenvon APM4MDA hilfreich sind:

■ Kein agiler Standard: Bei den agilenAnsätzen gibt es kein offizielles Standard-verfahren, sehr wohl aber Standardi-sierungsbemühungen, z.B. mit den „ScrumAlliance Certifications” (vgl. [Scr]).

d ie au torenschwerpunk t

3 / 2 0 0 8

Projekt gelten. Papier wird dabei kaum nochproduziert – Artefakte sind bei modellgetrie-benen Projekten eigentlich „nur noch”abstrakte Sichten auf ein zentrales Modell-Repository. In konkreter Ausprägung kön-nen sich diese in Dokumenten wiederfinden,jedoch sind auch andere Formen, wie Build-Ergebnisse oder z. B. auch elektronischeProtokolle, möglich.

Kommen wir zu den Phasen, die ein agi-les Projekt durchlaufen sollte. Neben denPhasen sind auch einige Artefakte genannt:

■ Vorbereitungsphase: Feature-Katalog,Domänenmodelle, Projektplan

■ Startphase: detaillierte Features, Proto-typ, Softwarearchitektur

■ Hauptphase mit der iterativ-inkremen-tellen Entwicklung: Integrations-Builds, Releases

■ Abschlussphase: Abnahmetestprotokoll

Entscheidende Artefakte zu Beginn einesProjekts sind unter anderem die Use-Casesund die Feature-Liste, auf deren Basis dieAufwandsschätzung (Widget- oder Use-Case-Point-Technik) möglich ist. Häufigzum Einsatz kommende Methoden, die vonhistorischen Daten ausgehen (z. B. die Ana-logiemethode), sind bei den ersten MDA-Projekten kaum verwendbar.

Wir haben die Erfahrung gemacht, dassMDA-Projekte ohne die Aufwände für dieMDA-Infrastruktur, mindestens 20 bis 30 %weniger Kosten verursachen als ähnlicheProjekte ohne MDA-Ansatz. Dies deckt sichauch mit anderen Erfahrungen (vgl. z. B.[Fri06]). Insofern kann durchaus zunächst„klassisch” geschätzt werden, wobei aller-dings das MDA-Infrastrukturprojekt zubeachten ist, das eine separate Investitiondarstellt – dazu aber später mehr.

Wichtig für die erste Projektplanung sinddie Produkt-Features, die in Release-Fea-tures unterteilt werden. Ausgehend von derRelease-Planung lassen sich dann Itera-tionen mit Iterations-Features planen. DieIterationen (mit einer Dauer von ca. einemMonat) planen die Teams eigenständig,wobei sich hier das Timeboxing-Verfahrenbewährt hat: Die Iteration wird dabei zeit-licher „Fixstern”, d. h. als nicht veränder-bares Zeitfenster definiert (siehe Abb. 1).Bei der Iterationsplanung werden bestimm-te Ergebnisse (in der Regel Artefakte) vor-gesehen. Stimmen dann die tatsächlicherstellten Artefakte nicht mit den geplantenüberein, so erfolgt eine Übertragung in dienächste Iteration (aber keine zeitliche

Verschiebung der Iteration selbst). DieDiskrepanzen ermöglichen Rückschlüssefür die nächste Planung im Sinne einerProzessverbesserung.

Meilensteine kennzeichnen einen irrever-siblen Status eines Projekts, d. h. einbestimmter Stand – beispielsweise eineMenge an umgesetzten Release-Features –ist vorhanden. Meilensteine sind also nichtzwingend zeitlich fixiert, wobei es natürlichdas Ziel sein muss, die Meilenstein-Terminezu halten. Sie werden unter anderem je-weils am Ende eines Releases geplant.

Eine hohe Prozessqualität ist dannerreicht, wenn innerhalb aller Timeboxendie jeweiligen Iterations-Features umgesetztsind und am Ende alle Release-Featurespünktlich vorliegen, sodass sich der geplan-te Meilenstein nicht verschiebt.

Grenzen der AgilitätDies alles darf aber nicht über eines hinwegtäuschen: Zuweilen gibt es handfeste Ver-klemmungen zwischen Prozess- undVorgehensmodellen einerseits und den agilenAnsätzen andererseits. Das drückt sich inkaum vereinbaren Prozessen, Rollen oderArtefakten aus. Im Folgenden wird ein sol-cher Konflikt am Beispiel des Prozess-referenzmodells Automotive SPICE undSCRUM (vgl. [SPI05] und [Pic08]) gezeigt.

In der Literatur und auch in realenScrum-Projekten ist das Team für den

Aufgabenbereich Qualitätsmanagementzuständig (vgl. [Pic08], S. 24, 122). Dieslässt sich jedoch nur schwer mit der An-forderung des Prozessmodells AutomotiveSPICE vereinbaren: Hier wird eineTrennung beim Supporting Process SUP.1(Qualitätssicherung) explizit gefordert:„Quality assurance team members are notdirectly responsible to the project organi-sation – they work independently from it”(vgl. [SPI05], S. 53).

Ein weiterer Punkt ist die Terminologie:XP beispielsweise lässt sich zwar theoretischauf MDA abbilden, aber die Code-Zentrierung ist dem XP „auf die Stirn”geschrieben – eine extreme Modellierung willdaraus einfach nicht werden, zumal essen-zielle Bestandteile der MDA fehlen, z.B.DSL-Entwicklung, Metamodellierung oderReferenzimplementierung. Weder bei denPrimär- noch bei den Folgetechniken des XPfindet sich so etwas (vgl. [Bec04]).

Weiterhin müssen die agilen Technikenauch im Team vermittelt werden, da sonstUnverständnis entstehen kann: Die zeitlichfixierte Iteration scheint zu dem agilenWert „Responding to change over follo-wing a plan” (vgl. [Bec01]) im Widerspruchzu stehen, was jedoch nicht stimmt, dennwichtig sind die Iterationsergebnisse, diesehr wohl flexibel vom Plan abweichenkönnen, wenn es beispielsweise Änderun-gen bei den Anforderungen gab. Das

schwerpunk tschwerpunk t

Abb. 1: Produkt-, Release- und Iterations-Features.

(EPF) dargestellt (siehe Abb. 3): Dabei gehtes um die Referenzimplementierung, d. h.die manuelle Entwicklung eines kleinenBeispielprojekts, um die Zielarchitekturgenau kennenlernen zu können. ImRahmen dieser Aktivität sind unter ande-rem die Zielarchitektur zu definieren, diezu verwendenden Frameworks zu evaluie-ren und die Anwendung manuell zu imple-mentieren. Anschließend kann auf dieserBasis der Generator entwickelt werden, derin Zukunft eine manuelle Implementierungweitestgehend unnötig macht. Nicht aufge-führt ist bei diesem vereinfachten Ablaufbeispielsweise das Testen, aber es wurdedeutlich, wie eine Iteration definiert ist. Siewird als Timebox geplant. Es ist durchausmöglich, die Referenzimplementierung inmehreren Iterationen zu erstellen. Am Endesteht ein Meilenstein, der die Fertigstellungder Implementierung symbolisiert.

MDA: parallele EntwicklungAber nun zurück zum „großen Ganzen”:Das reine Y-Modell ist – so wie dasWasserfallmodell auch – wenig praxisnah,da es weder die iterativ-inkrementelle Ent-wicklung darstellt, noch den beidenTeilprojekten die notwendige Autonomiegibt: Der Aufbau und die Weiterent-wicklung einer MDA-Werkzeugkette undeiner passenden Infrastruktur verläuft zwarkoordiniert, aber asynchron zu Kunden-projekten bzw. der Produktentwicklung.Letzteres ist ja in der Regel das Ziel einerindustriellen Softwarefertigung auf derBasis von modellbasierten Verfahren. Ab-bildung 4 zeigt die nebenläufige Weiter-entwicklung der MDA-Infrastruktur, so-dass bei der Release-Planung der paralleldazu verlaufenden Kundenprojekte flexibelentschieden werden kann, in welcherAusbaustufe die MDA-Tools zum Einsatzkommen – so werden MDA-Projekte agil.

Diese Stufen der MDA-Infrastruktur las-sen sich je nach Domäne, Technologie undindividuellen Anforderungen gestalten. Sokönnen sie zum Beispiel einen zunehmendhöheren Codegenerierungsanteil bedeuten:

■ Erste MDA-Gehversuche (Stufe 1)bestehen in der Regel darin, nur dieDomänenklassengerüste und die Persis-tenzschicht automatisiert aus den Mo-dellen (PIM) zu erzeugen.

■ Die Weiterentwicklung (Stufe 2) um-fasst dann Teile der Geschäftslogik-schicht (z. B. Zugriffsfassaden) und

38 39

Modellen, so bietet sich zunächst alsVeranschaulichung das Y-Modell an (sieheAbb. 2). Dabei ist zwischen zwei grundle-genden Projekten zu unterschieden:

■ dem Kundenprojekt und■ dem MDA-Infrastrukturprojekt (auch

Generatorprojekt genannt).

Das Kundenprojekt umfasst die typischenMDA-Aktivitäten: die plattformunabhängigeModellierung der fachlichen Welt derAnwender (CIM, PIM), die Transformationzum plattformabhängigen Zielarchitektur-modell (PSM) und schließlich die Code-generierung (PSI). Das MDA-Infrastruktur-projekt besteht aus der Entwicklung vondomänenspezifischen Sprachen (DSLs), UML-Metamodellderivaten oder UML-Profilensowie der Transformationsspezifikation und -implementierung, sodass dann alles schön„verpackt” als Generator zur Verfügung steht.

MDA-AktivitätsbeispielUm eine Iteration im Kontext des Y-Mo-dells näher zu erläutern, sei ein typisches(aber stark vereinfachtes) Vorgehen beiMDA-Projekten als Aktivitätsdiagrammmit Hilfe des Eclipse Process Frameworks

Kommunizieren und Verstehen solcherMechanismen ist essenziell, kommt abereben nicht von selbst bzw. „über Nacht”.

ModellbasierteSoftwareentwicklungDie grundlegenden Ideen der modellgetrie-benen Entwicklung sind im MDA-Guideder Object Management Grouip (vgl.[OMG03]) einführend erklärt, aber ein ein-heitliches MDA/MDD-Vorgehensmodell,bei dem in standardisierter Form Strategienund Prozesse festgelegt sind, sucht man zurZeit noch vergeblich. Die Anwendungs-möglichkeiten sind derart breit (z. B.„Model-to-Model”, „Model Merging”,„MDA Reverse Engineering”), dass derar-tiges wohl auch erst in den nächsten Jahrensukzessive entstehen wird. Ansätze mitähnlichem Namen, z. B. Model DrivenSoftware Development (MDSD), stellenletztlich nur Spezialfälle der MDA dar.

Es gibt allerdings einige sich mehr oderweniger zwingend ergebende Aktivitäten,Artefakte und Rollen, etwa Softwarearchi-tekt oder (Meta-)Modellierer. Unterstelltman einem Prozess ein konsequentesForward-Engineering mit dem Ziel derSoftwaregenerierung auf der Basis von

schwerpunk t

Abb. 2: Y-Modell für MDA-Projekte mit Kunden- und MDA-Infrastrukturprojekt (inAnlehnung an [Pet06]).

3 / 2 0 0 8

einige Aspekte der Benutzungsober-fläche, z. B. den Web-Flow.

■ Stufe 3 könnte dann auch die komplet-ten Geschäftsregeln, Algorithmen unddie Benutzungsoberfläche umfassen,beispielsweise in Form von HCI-

Patterns (Human Computer Inter-action, vgl. [Pet07]).

Eine Stufe ist aus Sicht des Projekt-managements dabei zunächst nichts ande-res als ein Release. Komplexer wird es

schwerpunk t

Abb. 3: MDA-Aktivität Referenzimplementierung als Iteration.

Abb. 4: Parallelentwicklung von Kundenprojekten und MDA-Infrastruktur.

dann, wenn es unterschiedliche Ziel-architekturen und umfangreiche Projektebzw. Poduktlinien gibt, was natürlich dannauch Auswirkungen auf die MDA-Infrastruktur hat. Wir wollen uns imFolgenden aber auf kleinere (weniger als 8Mitarbeiter) bis mittlere Projekte (8 bis 20Mitarbeiter) beschränken. Folgende Teamsund Rollen sind dabei vorhanden:

■ Entwicklungsteam für das Kunden-projekt: Hier sind Rollen wie System-analytiker, Softwareentwickler undTester vorhanden. Die Gewichtung derbeteiligten Rollen und die Ausprägungder Aktivitäten des Entwicklerteamsverändern sich über den Zyklus einesMDA-Projekts. Während der initialenPhase kann die Erstellung eines Proofof Concepts im Vordergrund stehen.Diese mündet bei ausreichender Ab-deckung der initialen Anforderungen inder Ableitung entsprechender wiederverwendbarer Softwareartefakte, dieauf einer höheren Ebene als derKodierung logisch in Modellen darge-stellt werden.

■ Technikteam für die MDA-Infra-struktur: Zu diesem Team gehörenSoftwarearchitekten, (Meta-)Model-lierer und (MDA-)Tool-Experten. DasModellierungsteam übernimmt dietechnischen Artefakte der initialenKodierungsebene und definiert darausein logisches Modell, das als Steuerungfür den parallel zu erstellendenGenerator dient. Die Aktivitäten desMDA-Teams sind sinnvollerweise pha-senverschoben zu den Aktivitäten desEntwicklungsteams, jedoch aufgrundder inkrementellen Vorgehensweisenicht von diesen entkoppelt.

■ Projektleitung: Dies kann zwar imEinzelfall eine einzelne Person (Projekt-leiter) sein, sollte bei MDA-Projektenallerdings noch die Kundenprojekt-und technische Team-Leitung mit ein-schließen.

Nach der Betrachtung einiger MDA-Pro-zesse und -Rollen kehren wir zunächstnoch einmal kurz zum Konzept derVorgehensmodelle zurück.

UMA und SPEMEin Vorgehensmodell definiert Methodender Softwareentwicklung, d. h. Beziehun-gen zwischen den Elementen „Rolle”,

Aufgabenbeschreibungen, Rollendefini-tionen und Dokumentvorlagen sind somitan zentraler Stelle für jeden zugänglich; dasWerkzeug wird dadurch zu einer wichtigenGrundlage eines effektiven Software-Quali-tätsmanagements.

Übergang zumProjektmanagementMDA erfordert aus unserer Sicht ein agilesProjektmanagement. Die Entwicklung vonGeneratoren geht mit fortlaufenden Testsund notwendigen Anpassungen am Meta-modell bzw. den Transformationen einherund wird von zahlreichen Rückkopplungender Iterationen untereinander begleitet. Aufder Basis des mit dem EPF-Composer defi-nierten APM4MDA-Vorgehens sind fürkonkrete Projekte nun quasi Prozess-modellinstanzen zu bilden, mit denen ineinem Projektmanagement-System weiter-gearbeitet werden kann, wobei sicherzu-stellen ist, dass die Agilität erhalten bleibt.Wir verwenden hierfür die Software„Projektron BCS” (vgl. [Pro]): Nach demImport des EPF-basierten MDA-Vorgehens-modells können die notwendigen Planungs-aktivitäten erfolgen, z. B. Meilenstein-,Release- und Iterationsplanung. Wichtig istdabei ein fein-granulares Rechtesystem, dasden Teams ein selbst organisiertes lokalesProjektmanagement ermöglicht. JedemTeammitglied ist damit die notwendigebasisdemokratische Freiheit überlassen,wobei die Projektleitung einen Überblicküber alle Teams hat und somit dieAuskunftsfähigkeit und Steuerbarkeitsichergestellt sind – gerade bei großen IT-Projekten, bei denen APM zum Einsatz

42 43

Anwendung in Prozessen zum anderen. DieMethoden werden im Method Content ver-waltet, in Processes lassen sich unterschied-liche Lebenszyklen definieren. Abbildung 5zeigt das MDA-Vorgehen für Kunden-projekte: Die Iterationen finden innerhalbder schon erwähnten Phasen des APMstatt: Vorbereitungs-, Start-, Haupt- undAbschlussphase. Der Methodenteil, dersich in den Disziplinen (Disciplines)wiederfindet, ist überwiegend ausAbbildung 2 bekannt.

Eine Methode im Method Content stellteine Anleitung für einen bestimmten Be-reich oder eine bestimmte Disziplin derSoftwareentwicklung dar, z. B. dieErstellung des plattformunabhängigen Mo-dells (PIM). Sie wird durch die Elemente„Rolle” (z. B. Domain Analyst, Modeler),„Aufgabe” (z. B. Define Product Features,Model Use Cases) und „Arbeitsergebnis”(z. B. Feature-Liste, Use-Cases) sowie derenBeziehungen untereinander beschriebenund lässt sich durch zusätzliche Dokumen-tation (z. B. Richtlinien, Checklisten)ergänzen. Die Aktivitäten der Prozessdi-mension sind in einem hierarchischen Pro-jektstrukturplan (Work BreakdownStructure) abgebildet. Sie enthalten Re-ferenzen auf die Methodeninhalte.

Das EPF bietet somit als generischesFramework zur Erstellung von Prozessender Software- bzw. Systementwicklung einegute Grundlage für die Definition vonAPM4MDA. Die Inhalte und Prozesse las-sen sich in Form eines web-basiertenHandbuches exportieren, das beispiels-weise im Intranet jedem Prozess- undProjektbeteiligten zur Verfügung steht.

„Aufgabe” und „Produkte” (Projektarte-fakte). Durch die logische und zeitlicheAnordnung der Methoden entsteht einLebenszyklus. Ein Vorgehensmodell be-steht somit zum einen aus statischen, vomLebenszyklus unabhängigen Inhalten (Me-thoden) und zum anderen aus deren kon-kreter, dynamischer Anwendung in Pro-zessen (Lebenszyklus). Diesem Paradigmafolgen die bekannten Vorgehensmodelleder Softwareentwicklung, z. B. das V-Modell XT, der RUP, aber auch agileAnsätze, wie XP. Obwohl die genanntenVorgehensmodelle auf diesem Prinzipbasieren, sind sie nicht kompatibel zuei-nander, d. h. sie verwenden unterschiedli-che Metamodelle. Zwar lassen sich dieElemente und Konzepte oft aufeinanderabbilden, dies hat jedoch auch seineGrenzen, unter anderem bei der Kombi-nation oder Integration der Inhalte.

Die Unified Method Architecture (UMA)(vgl. [Shu07]) versucht sich an einerLösung dieses Problems: Ein Metamodellzur Spezifikation von Methoden und Pro-zessen ermöglicht die Definition verschie-dener Vorgehensmodelle bzw. deren In-halte. Auch eine Integrationunterschiedlicher Ansätze ist denkbar. DieUMA ist eine Weiterentwicklung derVersion 1.1 des Software ProcessEngineering Metamodel (SPEM) derOMG. Große Teile der UMA sind ihrerseitsin die Version 2.0 der SPEM eingeflossen(vgl. [OMG07]).

EPF: Basis für APM4MDADas Eclipse Process Framework (EPF) derEclipse Foundation basiert auf der UMA(und zukünftig auf SPEM 2.0) zur De-finition von Methoden und bietet somit eingenerisches Prozessmanagementwerkzeugzur Definition beliebiger Vorgehens-modelle. EPF ist eine freie Version des kom-merziellen Werkzeugs „Rational MethodComposer” von IBM. Das aktuelle Releasedes EPF enthält den „EPF Composer” und„OpenUP” (Open Unified Process, vgl.[Ecl-a] und [Ecl-b]). Während der EPFComposer ein Prozessdefinitionswerkzeugdarstellt, handelt es sich beim OpenUP umeinen minimalen, ausgeprägten und er-weiterbaren iterativen Softwareentwick-lungsprozess im Sinne eines Vorgehens-modells, der die Basis für eigeneErweiterungen und Anpassungen darstellt.

Das Grundprinzip des EPF ist die Tren-nung von wieder verwendbarem Inhalt inForm von Methoden zum einen und deren

schwerpunk t

Abb. 5: Methoden und Lebenszyklus von APM4MDA.

3 / 2 0 0 8

kommt, ist dies eine essenziell wichtigeFunktionalität.

Abschließend sei noch darauf hingewie-sen, dass es auch oder gerade bei agilenProjekten wichtig ist, jederzeit zu wissen,wo das Projekt steht: Wöchentliches Mi-kro-Controlling ermöglicht den Entwick-lern eine Rückmeldung, unter anderem inForm von Restaufwandsschätzungen. DerAmpelstatus signalisiert dann in sehranschaulicher Form, ob und wo dieProjektleitung eingreifen muss, damit alleswieder im „grünen Bereich” ist. Abbildung6 zeigt den Ampelstatus anhand einigerAufgaben.

FazitModellbasierte Softwareentwicklung kann(oder besser: muss) durch agiles Projekt-management professionalisiert und auchfür größere Projekte erschlossen werden,wenn ein MDA-spezifisches Vorgehen und

geeignetes – d. h. erfahrendes – Personal zurVerfügung stehen. Zwar sind Werkzeugenicht alles, aber auch bei MDA-Projektengilt: Ohne Tools ist alles nichts. DieVerbindung zwischen EPF-basierter Pro-zessdefinition und umfassendem Projekt-management mit Projektron BCS hat sichals praktikabel erwiesen – die Prozesse las-sen sich flexibel erstellen und im Projektleben. Wie so oft ist es nicht mit einem ein-zelnen Werkzeug getan, sodass es auf diepassende Kombination und die nahtloseIntegration ankommt.

Den APM4MDA-Ansatz konnten wirhier zwar nur oberflächlich skizzieren undeinige wichtige Aspekte – etwa die ThemenAufwandsschätzung, Release-, Iterations-und Meilensteinplanung, Aufgabe undRetrospektive sowie Abnahmen – konntengar nicht behandelt werden, aber ein ersterhilfreicher Eindruck konnte sicherlich ver-mittelt werden. ■

schwerpunk t

Abb. 6: Mikro-Controlling mit Hilfe des Ampelstatus in Projektron BCS.

Literatur & Links[Bec01] K. Beck et al., Manifesto for Agile

Software Development, 2001, siehe:

www.agilemanifesto.org

[Bec04] K. Beck, Cynthia Andres: Extreme

Programming Explained. Embrace Change

(2. Aufl.), Addison-Wesley 2004

[Ecl-a] The Eclipse Foundation, Eclipse Process

Framework Project, siehe: www.eclipse.org/epf

[Ecl-b] The Eclipse Foundation, Open Unified

Process, siehe: epf.eclipse.org/wikis/openup/

[Fri06] P. Friese, Erfahrungsbericht: Einsatz

des Open Source MDA Generators Andro

MDA im Projekt Kombiverkehr KMS bei

Lufthansa Systems, in: F. Fieber, R. Petrasch,

W. Neuhaus, Tagung der SIG MDSE, Logos

Verlag 2006

[Oes08] B. Oestereich, C. Weiss, APM –

Agiles Projektmanagement – Erfolgreiches

Timeboxing für IT-Projekte, dpunkt.verlag,

2008

[OMG03] Object Management Group

(OMG), MDA Guide, Version 1.0.1, 2003,

siehe: www.omg.org/mda

[OMG07] Object Management Group

(OMG), Software & Systems Process

Engineering Metamodel Specification, v2.0

(Beta 2), ptc/2007-08-07, 2007, siehe:

www.omg.org/docs/ptc/07-08-07.pdf

[Pet06] R. Petrasch, O. Meimberg, Model

Driven Architecture, dpunkt.verlag, 2006

[Pet07] R. Petrasch, Model Based User

Interface Design: Model Driven Architecture

und HCI Patterns, in: GI Softwaretechnik-

Trends, Mitteilungen der Gesellschaft für

Informatik, Band 27, Heft 3, 9/07

[Pic08] R. Pichler, Scrum – Agiles Projekt-

management erfolgreich einsetzen, dpunkt.

verlag, 2008

[Pro] Projektron BCS, siehe: www.projektron. de

[Scr] Scrum Alliance, Inc., www.scrumalliance.

org

[SPI05] SPICE User Group, The

Procurement Forum: Automotive SPICE.

Process Reference Model, Process Assess-

ment Model, 2005

[Shu07] A. K. Shuja, J. Krebs: IBM Rational

Unified Process – Reference and Certification

Guide: Solution Designer, IBM PressPub,

2007

[VMXT] Bundesministerium des Inneren

(BMI), V-Modell XT, siehe: www.v-modell-xt.de