Agiles Projektmanagement für die modellbasierte Software-Entwicklung

Transkript

1 Agiles Projektmanagement für die modellbasierte Software-Entwicklung SoftwareKonstruktion / -Produktion , GI FG WI-VM AK OpEx Roland Petrasch agil, modellbasiert, service-orientiert, architektur-zentriert, test- und featuregetrieben darf es etwas mehr sein? Beuth Hochschule für Technik Berlin Fachbereich VI - Informatik & Medien Luxemburger Straße 10 D Berlin 1

2 Agenda Agilität I want to believe MDA-Spezifika Scrum / APM Agiles Projektmanagement Projektmanagement für agile modellgetriebene SW-Entwicklung Diskussion Ziel: Work-in-progress vorstellen und zur Diskussion stellen Kontroversen und ehrlichen Diskurs über Agilität anregen Feedback aus anderen Unternehmen erhalten 2

3 Agilität I want to believe... Agil: Alles und nichts Agiles Manifest (=Vision), aber kein agiler Standard und auch kein komplettes explizites soziales Wertesystem (wohl aber ein implizites) Standardisierungsbemühungen, z.b. mit den Scrum Alliance Certifications [Scrum] Teufelszeug : Kombiniertes Vorgehen: Traditionelle (schwergewichtige) Vorgehensmodelle, z.b. V-Modell XT [VMXT], und agile (leichtgewichtige) Vorgehensweisen sind kein Widerspruch und lassen sich durchaus kombinieren. Regelwerk: Auch die agilen Vorgehensweisen kommen mit klaren Vorgaben daher [Oes08] und sollten nicht in einer Beliebigkeit oder der Anarchie enden, wo jede(r) alles darf. 3

4 Agilität I want to believe... Agil: Ein paar kritische Anmerkungen sind erlaubt? Vorteilhaftigkeit bisher nicht zweifelsfrei nachgewiesen nur durch Glaubensbekenntnisse (auch für schwergew. V-Modelle) Implizites Wertesystem (Regelwerk) übt Druck auf die Mitarbeiter aus: Was passiert mit Abweichlern, Verweigerern oder Unbelehrbaren? Erstarrung durch Vorbeter (Pseudo-Normierung), erste Dogmatisierungserscheinungen sichtbar? Externe Vorgaben nicht immer kompatibel mit Agilität: Missionierung von (klassischen) Auftraggebern möglich? Interpretationsspielraum: Wie praxisnah, konsistent, präzise, prägnant ist die agile Theorie? Wann und wie ist man konform? 4

5 Agilität I want to believe... Agil: Ein paar kritische Anmerkungen sind erlaubt? Beispiel 1: Fluktuation der Erkenntnisse XP (1. Auflage): 40h-Woche, Metaphern alles oder nichts XP (2. Auflage): Techniken fehlen, andere sind dazu gekommen Fazit: Was heute richtig ist, kann morgen schon wieder falsch sein Beispiel 2: Koexistenz als Herausforderung Scrum: Team für Qualitätsmanagement zuständig [Pic05, S. 24, 122] Automotive SPICE (Process SUP.1 Quality assurance): Quality assurance team members are not directly responsible to the project organisation they work independently from it. [SPICE, S. 53] Frage: Vereinbarkeit der Ansätze? 5

6 Agilität I want to believe... Agil: Ein paar kritische Anmerkungen sind erlaubt? Beispiel 3: Anforderungen, Aufwandsschätzung und Festpreise Klassisches RE: Das frühe und detaillierte Erfassen aller Anforderungen führt so zu Fehlleistungen bzw. Verschwendung [Pic05, S. 27] Scrum-Projekte: Anforderungen frühzeitig ermitteln und adäquat beschreiben [Pic05, S. 34] Fazit: Ohne Anforderungen ist Schätzung nach wie vor schwierig Beispiel 4: MDA-Tauglichkeit XP, Scrum etc. nur theoretisch für MDA-Projekte anwendbar, aber nicht praktisch (Terminologie, Code-Zentrierung, Team ) Fazit: Aspekte wie DSL-Entwicklung, Metamodellierung, MDA-Tools sind zu beachten 6

7 MDA-Spezifika Model-Driven Architecture (MDA) der OMG Implementierung: Neueste Technologien auf der Basis der Spec. einsetzbar, integrierbar, generierbar Integration: Lösungen für die Integration lassen sich genauso automatisieren wie die Implementierung selbst. Wartung: ungeliebte (oftmals aufwändigste und längste) Phase wird vereinfacht Test und Simulation: Modelle als Basis für Validierung gegen Requirements, Test gegen diverse Infrastrukturen oder Simulation 7

8 MDA-Spezifika Problem der manuellen Programmierung: Verlagerung der formalen Ebene nach hinten 8

9 MDA-Spezifika Lösung: Verlagerung der formalen Ebene nach vorne und automatisierte Code-Erstellung (Generierung) 9

10 MDA-Spezifika MDA-Modelle Computation Independent Model (CIM): Textuell & wenig formal Platform Independent Model (PIM): Formal, aber z.b. ohne technische Details Platform Specific Model (PSM): Ergebnis einer PIM-Transformation Platform Specific Implementation (PSI): Code 10

11 MDA-Spezifika Generierte und manuelle Anteile 11

12 MDA-Spezifika Generierte und manuelle Anteile 12

13 MDA-Spezifika Von Perspektiven (Viewpoint) zu Sichten (Modelle als Artefakte) 13

14 MDA-Spezifika Transformation: Prinzipielles Pattern <<Quellartefakt>> Plattformunabhängiges Modell (PIM ) <<Quellartefakt>> Plattformmodell (PM) Transformation (Generator) Profile, Metamodelle, Markierungen, Mappingund Transformationsregeln etc. <<Zielartefakt>> Plattformabhängiges Modell (PSM) 14

15 MDA-Spezifika Vorgehensweise muss 2 Projekte berücksichtigen: klassisches Kundenprojekt bzw. Produkt(e) MDA-Infrastruktur-, Architektur- oder Generatorprojekt Schematisches Vorgehen als Y-Modell 15

16 MDA-Spezifika Frühe Formalisierung durch modellbasierte / -getriebene SWE kann nicht alle Probleme lösen, aber Modelle lassen sich besser (und früher) prüfen, als Code Modelle (formalisierte Teile) ermöglichen eine Separation der Aspekte (z.b. Dynamik, Struktur), die im Code nur tw. vorhanden ist Modelle sind (evtl.) semantically rich, Code ist semantically poor Modelle lassen sich eher wiederverwenden als Code Konsequenzen für das Projektmanagement MDA-Methodik steckt im Projektplan, z.b. In Form der 2 Projekte Qualifikationsanforderungen der Mitarbeiter ändern sich Schnittstellen, z.b. Requirements-Management, QM, KM sind anzupassen 16

17 Scrum & APM Agiles Projektmanagement Ähnlichkeiten bei Scrum und APM ist [Oes08] mit typischen agilen Merkmalen, z.b. iterativ-inkrementelle Entwicklung, Iterations-Mikroprozess (Sprint) Meilensteinplan (Ergebnisse), Timeboxing (Zeitrahmen) Features, Verfeinerung und Priorisierung von Anforderungen intensive und frühe Einbindung des Kunden und der Endanwender Unterschiede, z.b. bei den Phasen eines agilen Projektes (APM) Vorbereitung (Feature-Katalog, Domain-Modelle, Projektplan), Startphase (Detaillierte Features, Prototyp, Software-Architektur), Hauptphase mit der iterativ-inkrementellen Entwicklung (Integrationsbuilds, Releases) Abschlussphase (Abnahmetestprotokoll). 17

18 oose. Mikrozyklen innerhalb einer Iteration Innovative Informatik Scrum - Sprint Quelle: Scrum-Library, EPF,

19 Mikrozyklen innerhalb einer Iteration oose. Innovative Informatik APM - Iterations-Mikroprozess Quelle: 19

20 Prinzipieller Aufbau einer Iteration oose. Innovative Informatik Quelle: 20

21 Iterations-Wolken-Metapher oose. Innovative Informatik Quelle: 21

22 Scrum / APM Agiles Projektmanagement Fazit Aglität: klassisches PM mit agilen Verfahren zusammenbringen Es werden Prozesse und Produkte (Artefakte) berücksichtigt Scrum und APM sind aber nicht per se MDA-tauglich Ergo: Anpassung und Erweiterung notwendig, insbesondere an den Dual-Projektmodus 22

23 PM für agile modellgetriebene SW-Entwicklung Entscheidende Artefakte zu Beginn eines Kundenprojektes Use-Cases & Feature-Liste (CIM) Basis für Aufwandsschätzung, z.b. Story- oder Use-Case-Point-Technik oder Analogiemethode (historische Daten): MDA-Projekte ohne MDAInfrastrukturaufwände ca % weniger Kosten [Fri06] klassische Schätzung möglich, aber MDA-Infrastrukturprojekt als separate Investition planen (Produktentwicklung) Hauptaufgaben im Kundenprojekt CIM-Transformation (Verfeinerung, Konkretisierung) zu PIM Weitere Transformationen M2M, M2C Manuelle Programmierung managen Einstellung des Verhältnisses zwischen gen. & man. Code (80:20?) 23

24 PM für agile modellgetriebene SWE Projektplanung (Kundenprojekt): Produkt-Features CIM-Ebene: Releaseplan mit Unterteilung in Release-Features Iterations- Sprintplanung mit Iterations-Features (Sprint-Backlog) planen Iteration/Sprint: Dauer von ca. einem Monat durch Teams geplant Timeboxing: Iteration als zeitlicher Fixstern Diskrepanz: Tatsächlich erstellte Artefakte (PIM, PSM, PSI) und geplante Artefakte Übertragung in die nächste Iteration möglich (Meilenstein verschieben) 24

25 PM für agile modellgetriebene SW-Entwicklung Prozessqualität bei APM: Kundenprojekt Iteration (Sprint) mit Timebox und Meilenstein: Planung M0 Timebox 1 M1 Timebox 2 M2 Max. Prozessqualität: Ergebnisse (Artefakte) liegen pünktlich vor Iteration (Sprint) mit Timebox und Meilenstein: Diskrepanz M0 Timebox 1 Timebox 2 M1 Timebox 3 M2 Prozessqualitätsmangel: Einige Ergebnisse (Artefakte) liegen zu spät vor (fehlende Features werden in die nächste Timebox übernommen) 25

26 PM für agile modellgetriebene SW-Entwicklung Prozessmodell mit auf der Basis des Eclipse Process Framework (EPF) Prozessmanagementwerkzeug zur Definition beliebiger Vorgehensmodelle freie Version des kommerziellen Werkzeugs Rational Method Composer von IBM basiert auf der UMA (Unified Method Architecture) und zukünftig auf SPEM 2.0 (Software Process Engineering Metamodel) der OMG Aktuelles Release 1.5 des EPF enthält EPF Composer (Prozessdefinitionswerkzeug) OpenUP (Open Unified Process) [OpenUP]: minimaler und erweiterbarer iterativer Software-Entwicklungsprozess (Vorgehensmodell), Basis für eigene Erweiterungen & Anpassungen Weitere Libraries verfügbar, z.b. Für Scrum 26

27 PM für agile modellgetriebene SW-Entwicklung Prozessmodell mit auf der Basis des Eclipse Process Framework (EPF) Trennung von wiederverwendbarem Inhalt Methoden (Method Content) mit Rollen, Tasks, Guidances, WP Prozesse für Entwicklungs-/Lebenszyklusmodell Generierung eines web-basierten Handbuches Kein PM-Werkzeug 27

28 PM für agile modellgetriebene SW-Entwicklung Aufteilung in zwei Method-Plugins: MDA-Infrastructure and Generator: Tool chain for Code generation (internen Produkt / Service) Scrum4MDA: Customer projects w/ or w/o MDA (d.h. klassische Scrum-Projekte möglich, ohne MDA Infrastructure) 28

29 APM4MDA agile modellgetriebene SWE EPF-basiertes Prozessmodell MDA-Aktivität Referenzimplementierung als Iteration 29

30 PM für agile modellgetriebene SW-Entwicklung MDA-Infrastruktur-/Architektur-/Generatorprojekt Verschiedene Entwicklungsstufen (Stages), da Automatisierungsgrad zunächst gering und später höher Schrittweise Entwicklung: DSL, Metamodell, UML-Profil, Architektur- und Framework-Analyse, Referenzimplementierung Orientierung an Architektur, z.b. Persistenzschicht, Fassaden, Services, Middleware- / SOA-Komponenten, Configuration, User Interface Ziel: MDA-Infrastruktur als Produkt Entwicklungs- bzw. Ausbaustufen, z.b. 1. Stufe (MDA-Pilot-/Initialphase): Erste Erfahrungen, M2C 2. Stufe (MDA-Produktivphase): Breiterer Einsatz, evtl. M2M 3. Stufe (MDA-Infrastrukturphase): Produktcharakteristik, M2M / M2C 30

31 PM für agile modellgetriebene SW-Entwicklung Architektur-/Generatorprojekt MDA-Infrastruktur: Ausbaustufen mit Releaseplan eines Kundenprojektes planen Defensive Planung: mind. 2-3 Releases mit einer MDA-Infrastruktur Anschließende Retrospektive für MDA-Infrastruktur 31

32 PM für agile modellgetriebene SW-Entwicklung Architektur-/Generatorprojekt: Beispiel MDA-Produktivphase Synchronisierung von Kunden- und Generatorprojekt(en) GP-Meilensteine als Output-Meilensteine Kundenprojekt abonniert GP-MS als Input-Meilensteine MDA-ISProjekt Entity-Gen. Kundenprojekt M0 M1 Persistenz-Gen. IM0 Timebox 1 M2 M1 IM1 Service-Gen Timebox 2 GP-MS sind kritisch, da Abhängigkeiten zu Kundenprojekten MDA-IS-Projekt-Iterationen nicht zu umfangreich gestalten M3 M2 32

33 PM für agile modellgetriebene SW-Entwicklung Übergang zum Projektmanagement, z.b. Projektron BCS 33

36 Referenzen [Agile] Kent Beck et al.: Manifesto for Agile Software Development, [Bec04] Kent Beck, Cynthia Andres: Extreme Programming Explained. Embrace Change. Addison-Wesley Longman, 2. Auflage, 2004 [EPF] The Eclipse Foundation: Eclipse Process Framework Project, [Fri06] Peter Friese: Erfahrungsbericht: Einsatz des Open Source MDA Generators AndroMDA im Projekt Kombiverkehr KMS bei Lufthansa Systems. In: Florian Fieber, Roland Petrasch, Wolfgang Neuhaus: Tagung der SIG MDSE, Hamburg, Logos Verlag, 6. Dez [ISO] ISO/IEC International Organization for Standardization (ISO): Information Technology Process Assessment Part 2: Performing an Assessment, [MDA] Object Management Group (OMG): MDA Guide. Version 1.0.1, omg/ , June 2003 ( [OpenUP] The Eclipse Foundation: Open Unified Process, epf.eclipse.org/wikis/openup/ [Oes08] Bernd Oestereich, Christian Weiss: APM - Agiles Projektmanagement - Erfolgreiches Timeboxing für IT-Projekte. dpunkt Verlag, 2008 [Pet06] Roland Petrasch, Oliver Meimberg: Model Driven Architecture. dpunkt, 2006 [Pet07] Roland Petrasch: Model Based User Interface Design: Model Driven Architecture u nd HCI Patterns. In: GI Softwaretechnik-Trends, Mitteilungen der Gesellschaft für Informatik, Band 27, Heft 3, Sept. 2007, S [Pic05] Roman Pichler: Scrum Agiles Projektmanagement erfolgreich einsetzen. dpunkt Verlag, 2008 [Agil] [Pro] Projektron BCS, [Scrum] Scrum Alliance, Inc., [SPEM] Object Management Group (OMG): Software & Systems Process Engineering Metamodel Specification, v2.0 (Beta 2), ptc/ , 2007 [SPICE] SPICE User Group, The Procurement Forum: Automotive SPICE. Process Reference Model, Process Assessment Model, 2005 [VMXT] Bundesrepublik Deutschland: V-Modell XT, 36

37 Diskussion Scrum / APM für MDA bringt beide Welten zusammen Vorteile von bekannten PM-Techniken mit MDA-Ansatz vereint Tool-Unterstützung zwar noch nicht fertig, aber in Arbeit: EPF, PM-Tool, Anbindung an Eclipse-basierte MDA-Tools Kein Papier : Artefakte bei modellgetriebenen Projekten = abstrakte Sichten auf zentrales Modell-Repository (konkrete Ausprägung: Dokumente, Build-Ergebnisse ) Praktische Erfahrungen: Keep it simple, sukzessives Vorgehen, Weiterbildung wichtig, Vorsicht: Tool-Evaluationsfalle 37

38 Vielen Dank für Ihre Aufmerksamkeit Roland Petrasch Beuth Hochschule für Technik Berlin Fachbereich VI - Informatik & Medien Luxemburger Straße 10 D Berlin prof.beuth-hochschule.de/petrasch 38