Lieferung 4.3 Entwicklungsprozess für mobile Anwendungen

Transkript

1 Lieferung 4.3 Entwicklungsprozess für mobile Anwendungen für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket Arbeitspaketleitung Förderkennzeichen Projektleitung Partner Autoren Lieferdatum AP 4 Agile Entwicklungsumgebung andrena objects 01IS11012A andrena objects ag Jochen Winzen andrena objects ag arconsis IT-Solutions GmbH FZI Forschungszentrum Informatik Jochen Winzen M24 Letztes Änderungsdatum Version 1.0 ModAgile Mobile L4.3 Entwicklungsprozess für mobile Anwendungen 1

2 1 Einleitung In diesem Dokument wird der Entwicklungsprozess von ModAgile Mobile beschrieben. Insbesondere geht es um die zentrale Frage: Was ändert sich bei der App Entwicklung mit ModAgile Mobile? Im folgenden Kapitel wird zunächst eine kurze Übersicht gegeben, welche Eigenschaften gängige Entwicklungsprozesse gemeinsam haben und was speziell agile Entwicklung ausmacht. Als nächstes wird darauf eingegangen, wie sich das ModAgile Mobile Framework in einen agilen Entwicklungsprozess einbinden lässt und welche Herausforderungen dabei für das Team entstehen. 2 Entwicklungsprozess für mobile Anwendungen Auch wenn die Entwicklung mobiler Anwendungen eine ganz andere Dynamik aufweist, als die klassische Entwicklung von Geschäftsanwendungen, gibt es bereits eine Vielzahl von Entwicklungsprozessen, die mehr oder weniger lange am Markt etabliert sind. Aus diesem Grund wurde für das Projekt ModAgile Mobile grundsätzlich kein neuer Entwicklungsprozess erdacht, sondern darauf geachtet, dass die einzelnen Prozessschritte kompatibel mit einer Vielzahl vorhandener Prozesse gestaltet sind. Insbesondere ist es den Projektbeteiligten ein Anliegen, die schnellen Entwicklungszyklen aus der agilen Entwicklung mit den modellgetriebenen Ansätzen zu kombinieren oder sogar auf diese anzuwenden. Dies ist aus unserer Sicht auch gelungen und wird im Folgenden genauer erläutert. 2.1 Eigenschaften gängiger Entwicklungsprozesse Es gibt bestimmte Phasen / Prozessschritte bei der Softwareentwicklung, die grundsätzlich invariant zu dem gewählten Entwicklungsprozess sind. In der Praxis unterscheidet sich deren Anwendung häufig darin, ob die jeweilige Phase komplett abschlossen wird oder bis zum Projektende inkrementell mehrmals durchlaufen wird. Hier folgt eine kurze Auflistung der Prozessschritte, die auch für die Entwicklung mit dem ModAgile Mobile Framework relevant sind: Anforderungsanalyse / Spezifikation Design Implementierung Testen Qualitätssicherung Dokumentation ModAgile Mobile L4.3 Entwicklungsprozess für mobile Anwendungen 2

3 2.2 Spezifika agiler Entwicklungsprozesse Was genau macht einen agilen Entwicklungsprozess aus? In aller Regel wird hier auf das Manifest der agilen Entwicklung [1] verwiesen, das insbesondere die Grundprinzipien der agilen Entwicklung pragmatisch zusammenfasst. Im Rahmen von ModAgile Mobile wurde SCRUM [2] als Grundlage für einen agilen Entwicklungsprozess gewählt und auch schon in Lieferung 5.3 Integrierter agiler Prozess zur modellgetriebenen Software-Entwicklung mit Werkzeugunterstützung umfassend dokumentiert. Daher werden hier bestimmte Fakten nur kurz dargestellt und für eine detaillierte Erklärung auf die entsprechenden Referenzen verwiesen. 2.3 Entwicklungsprozess eines einzelnen Sprints Abbildung 1 Klassischer SCRUM-Prozess Der klassische SCRUM-Prozesse (siehe Abbildung 1) adressiert vor allem die Entwicklung von Code-Artefakten wie Quellcode, Test und Dokumentation. In modellgetriebenen Software- Entwicklungsprojekten sind für diesen Prozess Erweiterungen vorzunehmen. Dabei wird der grundsätzliche SCRUM-Prozess bewusst nicht umgebaut, um Schulungsaufwände zu minimieren, da bereits viele Entwickler mit agiler Entwicklung vertraut sind und um die positiven Erfahrungen mit SCRUM übertragbar zu halten. Wichtig ist hier noch einmal hervorzuheben, dass bereits nach einem Sprint (von 2 bis 4 Wochen Dauer) eine lauffähige Anwendung vorliegen soll (potentially shippable product increment), die der Kunde ausführen kann. ModAgile Mobile L4.3 Entwicklungsprozess für mobile Anwendungen 3

4 2.4 Einbettung der Modagile-Werkzeuge Prozessintegration Abbildung 2 Erweiterter SCRUM-Prozess mit Artefakten modellgetriebener Entwicklung In Abbildung 2 sind die gegenüber Abbildung 1 erweiterten Elemente mit blauen Pfeilen (unterer Bereich der Abbildung) dargestellt. Zur Erweiterung werden die Artefakte, die für die modellgetriebene Entwicklung notwendig sind, in die bestehenden Sprints von SCRUM fest integriert. Dies bedeutet, dass beispielsweise Modelle und Templates in jeder Iteration vollständig mit gepflegt werden müssen. Jeder Sprint umfasst dabei die komplette Umsetzung mindestens eines modellgetriebenen Entwicklungszyklus, bestehend aus (optional) Meta-Modell-Anpassung (optional) Migration bestehender Modell-Instanzen entsprechend der Meta-Modell- Änderungen Modell-Änderungen (optional) Template-Anpassungen Generatorlauf zur Code-Erzeugung Testausführung für modellbasierte Tests und Integrationstests ModAgile Mobile L4.3 Entwicklungsprozess für mobile Anwendungen 4

5 Bei Spezialfällen von Iterationen, die reine Code-Artefakte betreffen, die nicht aus der modellgetriebenen Entwicklung stammen, ist für genau diese Iteration keines der zuvor genannten Artefakte anzupassen. Die Erweiterung des SCRUM-Prozesses um die Artefakte der modellgetriebenen Entwicklung (Element mit blauen Pfeilen in Abbildung 2) ist leicht zu illustrieren, aber schwer umzusetzen. Hier hat das Projekt ModAgile Mobile eines der Grundprobleme adressiert, das bisher in der Kombination von agilen und modellgetriebenen Ansätzen auftritt (oder diese Kombination verhindert). Die klassischen modellgetriebene Ansätze sind nicht darauf ausgelegt, dass das System bereits mit manuellem Code ergänzt wird, während noch Änderungen am (Meta-)Modell vorgenommen werden. So ist es zwar grundsätzlich möglich, auch das Modell inkrementell zu erweitern, dies jedoch in einem Sprint mit Code-Änderungen zusammenzuführen ist und bleibt die eigentliche Herausforderung Artefakte Um eine gleichmäßige Entwicklung aller Artefakte in einem agilen modellgetriebenen Prozess sicherzustellen, müssen neben den konventionellen Artefakten wie Code auch die spezifisch modellgetriebenen Artefakte kontinuierlich mitentwickelt werden. In jeden Sprint müssen also die folgenden Artefakte eingebunden werden: Templates Modelle Meta-Modelle Generat (Code, Tests, Generierte Dokumentation) Integration Um Konsistenz zwischen Generat und Modellen sicherzustellen, muss ein jeder Sprint in sich abgeschlossen sein. Jede Meta-Modell-Änderung muss von allen Modellen reflektiert werden und jede Modelländerung muss vom Generat (Code, Test, ggf. Dokumentation) widergespiegelt werden. Analog zu der Abgeschlossenheit von SCRUM Sprints werden die Konsistenzbedingungen auf die modellgetriebene Entwicklung übertragen. Dies ermöglicht kompakte kleinteilige Änderungen, stets lauffähige und potentiell lieferbare Produkte und abgeschlossene Qualitätssicherung am Ende eines jeden Sprints Prozessschritte Welche Änderungen ergeben sich nun bei der App Entwicklung mit ModAgile Mobile im jeweiligen Prozessschritt? Anforderungsanalyse / Spezifikation Diese Phase ist zwar grundsätzlich technologieunabhängig. In agilen Prozessen werden die Anforderungen fortlaufend verfeinert und bilden pro Sprint (Sprint Backlog in Form von User Stories) die Basis der Implementierungsarbeiten durch das Entwicklerteam. Auf dieser Ebene sind dann doch technologische Rahmenbedingungen zu beachten, insbesondere muss das Team vor / in der Sprint Planung präzisieren, an welchen Artefakten Anpassungen vorzunehmen sind. Dies hat maßgeblich Einfluss auf den ModAgile Mobile L4.3 Entwicklungsprozess für mobile Anwendungen 5

6 Umsetzungsaufwand; je mehr Artefakte angepasst werden müssen, umso teurer ist die Entwicklung. Das ModAgile Mobile Framework gibt schon eine Grundmenge an Funktionalität vor, z.b. einfache UI-Elemente mit automatisch generierter Datenbindung an das Domänenmodell. Eine Erweiterung der Anwendung um die im Framework unterstützten Features ist daher günstig umzusetzen. Damit ein Team die Features kennt, sollte es sich vorab die Validierungsmodelle des Frameworks anschauen (siehe Lieferung 2.2 Validierung der Anforderungen). Design Auch in der Software Design Phase gilt es die Vorgaben des ModAgile Mobile Frameworks zu kennen und zu beachten. Es wird eine gewisse Referenzarchitektur des Gesamtsystems vorgegeben / generiert, an die sich die Entwickler halten müssen. Diese wurde in Lieferung 3.1 Beschreibung der Referenzarchitektur ff. dokumentiert. Der Vorteil der Referenzarchitektur ist, dass ein Entwickler im Fall eines Framework- Features nur 1-2 Methoden manuell implementieren muss, der Rest wird für alle unterstützten Plattformen automatisch generiert. Implementierung Auch diese Phase der Entwicklung verändert sich im Zusammenspiel mit den modellgetriebenen Technologien. Es ist nicht nur Code zu schreiben, sondern unter Umständen auch Artefakte wie Meta-Modelle oder Generator-Templates anzupassen. Das Ziel unseres Frameworks ist hier, dass der Entwickler so wenig wie möglich modellieren und implementieren muss, sondern einfache Feature-Bausteine zur Anwendungsentwicklung bereitstehen. Im Rahmen des Projektes konnte nur eine Teilmenge aller möglichen Features abgebildet werden. Daher fallen für die Entwicklung realer Apps definitiv noch Aufwände für Erweiterungen auf der Modellebene an. Testen Auch die Artefakte für das plattformunabhängige Testen der generierten Anwendungen wurden bei ModAgile Mobile geschaffen (UI-Test-DSL in Lieferung 8.1 DSL und Generator für automatisierte Unit- und Akzeptanz-Tests). Dieses Feature konnte noch nicht unter realen Projektbedingungen erprobt werden. Insbesondere fehlt ein Vergleich zur manuellen Testfallerstellung auf mehreren Plattformen. Der Vorteil wird generell in der Plattformunabhängigkeit der Tests auf Modellebene gesehen. Der Nachteil dabei ist ganz klar die höhere Komplexität für Tester, die in der Regel keine Erfahrung mit modellgetriebenen Ansätzen haben. Qualitätssicherung Zur Qualitätssicherung stehen neben den Tests Werkzeuge zur Metrikerfassung auf Modellebene bereit. In einem agilen Projekt sollte dies in den automatisierten Build- Prozess eingebunden werden und verursacht damit nur initial Aufwand im Team. Dokumentation Auf diesem Prozessschritt lag keine besondere Priorität. D.h. es ist mit dem Framework möglich, auch Dokumentation (partiell) zu generieren. Es wurde jedoch noch kein Feature hierfür gebaut. Somit bleibt die Dokumentation (noch) ein manueller Schritt. ModAgile Mobile L4.3 Entwicklungsprozess für mobile Anwendungen 6

7 2.4.4 Organisatorische Integration Beim Einsatz des ModAgile Mobile Frameworks zur App Entwicklung gibt es auch auf organisatorischer Ebene ein paar Randbedingungen zu beachten / erfüllen. Der Einfachheit halber wird im Folgenden ein bereits bestehendes agiles Team zur App Entwicklung angenommen. In einem SCRUM-Prozess gibt es nur sehr wenige Rollen: Product Owner Scrum Master Team Im einem klassischen SCRUM-Projekt wird davon ausgegangen, dass das Team alle Fähigkeiten und Fertigkeiten vorweist (oder erlernt), um die Anwendung erfolgreich umzusetzen. Dafür hat sich der Begriff eines cross-functional Teams etabliert. Dies ist mitunter eine der größten Herausforderungen, wenn in einer Organisation agile Entwicklungsmethoden eingeführt werden. Es sollen nun Teams gebildet werden mit Personen, die vorher auf verschiedene Abteilungen verteilt waren. Bei der App Entwicklung für eine mobile Plattform (z.b. Android) umfasst das SCRUM-Team u.a. Software-Entwickler, UI-Designer, QA/Tester. Bei ModAgile Mobile wird diese Messlatte noch ein Stück höher gelegt, indem die Software- Entwickler auch fundierte Kenntnisse in der modellgetriebenen Technik brauchen als auch die Technologie-Stacks mehrerer Plattformen in einem Team vereint werden. Diese Konstellation gibt auch einen Hinweis darauf, dass es kontraproduktiv wäre, ein so gestaltetes Team nur für ein einziges Projekt / eine Anwendung zusammenzustellen. Der nötige Know-How-Aufbau im Team wäre hier kaum zu amortisieren. Große Vorteile verspricht es allerdings, ein solches Team mehrere Anwendungen für viele Plattformen erstellen zu lassen. Dann profitiert das Team von der Wiederverwendbarkeit von Wissen über Projekte hinweg. Diese Lernkurve konnten wir auch im Projekt ModAgile Mobile selbst erleben, war doch die Erstellung der Plattform-Unterstützung für Windows Phone signifikant einfacher / schneller als die der zuerst gewählten Technologie-Stacks. Es konnte bereits auf vorhandenes Wissen und Werkzeuge des Frameworks zurückgegriffen werden. 3 Fazit und Ausblick Für die Implementierung von Referenzbeispielen und Werkzeugen im Projekt ModAgile Mobile wurde der agile Entwicklungsprozess SCRUM gewählt. Der Einsatz modellgetriebener Techniken in einem agilen Kontext bringt besondere Herausforderungen mit sich, wie in den vorherigen Kapiteln dargestellt wurde. Trotzdem ist der gewählte Ansatz unserer Meinung nach kompatibel mit einer großen Bandbreite an (agilen) Entwicklungsprozessen. Die spezifischen Anpassungen beim Einsatz des ModAgile Mobile Framework sind nun in weiteren Anwendungsprojekten zu optimieren. ModAgile Mobile L4.3 Entwicklungsprozess für mobile Anwendungen 7

8 4 Literaturverzeichnis [1] Beck et al., Manifesto for Agile Software Development, [Online]. Available: [2] J. Sutherland und K. Schwaber, The Scrum Guide, July [Online]. Available: ModAgile Mobile L4.3 Entwicklungsprozess für mobile Anwendungen 8