Fachbereich Elektrotechnik und Informationstechnik. Bachelorarbeit. zur Erlangung des akademischen Grades. Bachelor of Engineering (B.Eng.

Transkript

1 Fachbereich Elektrotechnik und Informationstechnik Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Engineering (B.Eng.): Analyse und Optimierung eines Softwareentwicklungsprozesses bezüglich der Abwärtskompatibilität am Beispiel des Produktes SCOOBOX Eingereicht von: Geboren am: Holger Klaus in Jena Matrikel-Nummer Hochschulbetreuer: Betrieblicher Betreuer (dotsource GmbH): Prof. Dr.-Ing. Oliver Jack Dipl.-Inf. Sven Petzold Datum der Themenausgabe : Datum der Abgabe:

2 Sperrvermerk Die vorliegende Arbeit beinhaltet interne und vertrauliche Informationen der Firma dotsource GmbH. Die Weitergabe des Inhaltes der Arbeit und eventuell beiliegender Zeichnungen und Daten im Gesamten oder in Teilen ist grundsätzlich untersagt. Es dürfen keinerlei Kopien oder Abschriften - auch in digitaler Form - gefertigt werden. Ausnahmen bedürfen der schriftlichen Genehmigung der Firma dotsource GmbH. 2

3 Inhalt I. Abbildungsverzeichnis... 5 II. Quellcodeverzeichnis... 6 III. Abkürzungsverzeichnis... 7 IV. Abstract Einleitung Die dotsource GmbH Die SCOOBOX Zielsetzung Vorgehen Analyse der Problemstellung Entwicklungsmodell Prozesse Architektur Stand der Forschung und Technik Entwicklungsmodelle Iteratives Modell Agile Softwareentwicklung Continuous Delivery Prozesse Versionierung und Release Management Regelmäßige Integration Build-Prozess Automatische Tests Statische Code Analyse Infrastruktur Automatisierung Architektur Komponenten und Abhängigkeiten Agile Datenbankentwicklung Konzept und methodisches Vorgehen Entwicklungsmodelle Prozesse Versionierung und Release Verwaltung Build-Prozess

4 Automatische Tests Statische Code Analyse Infrastruktur Automatisierung Architektur Komponenten und Abhängigkeiten Agile Datenbankentwicklung Umsetzung Statische Codeanalyse Violation s Multilingual Prüfung Build-Prozess Einsatz einer Ram Disk Einsatz alternativer Task Aufrufe Parallelisierung des Build-Prozesses Datenbankmigration Automatische Tests Bewertung Realisierungen Sonar Build-Prozess Datenbankmigration Automatische Tests Zusammenfassung Fazit und Ausblick V. Glossar VI. Anhang VII. Literaturverzeichnis VIII. Thesen IX. Selbstständigkeitserklärung

5 I. Abbildungsverzeichnis Abbildung 1: Einteilung der Softwaretechnik[5]...11 Abbildung 2: Anteile bei der Softwareentwicklung...12 Abbildung 3: SCOOBOX Architektur (Ausschnitt)...14 Abbildung 4 Scrum Zusammenfassung [14]...18 Abbildung 5: Beispielhafter Aufbau eines Kanban Boards...20 Abbildung 6 Beispiel einer Deployment Pipeline [20] (S. 4)...21 Abbildung 7: Gegenüberstellung von DB-Init und DB-Migrate...34 Abbildung 8: Schematische Darstellung der Abhängigkeiten in der build.xml (erstellt mit yworks Ant Explorer)...39 Abbildung 9: Abhängigkeiten SCOOBOX Cartridges, schematisch dargestellt, Stand Abbildung 10: Ablauf des erstellten Migrate Skripts

6 II. Quellcodeverzeichnis Listing 1: Anpassung XSL Datei für gezielten Versand...36 Listing 2: Ausschnitt(vereinfacht) Clean.xml parallelisiert...39 Listing 3: Ausschnitt(vereinfacht) Build_all.xml parallelisiert...40 Listing 4: Ausschnitt (vereinfacht) Build_all.xml setparallelbuildproperties...41 Listing 5: Ausschnitt(vereinfacht) Build_all.xml build_all_fast

7 III. Abkürzungsverzeichnis Abkürzung CD CI CMS CVS DCVS ISML MMF QA ORM SVN TDD VM XP XLT XSLT Bedeutung Continuous Delivery Continuous Integration Configuration Management System Concurrent Versions System Distributed Concurrent Versions System Intershop Markup Language Minimal Marketable Feature Quality Assessment Object Relational Mapping Subversion Test Driven Development Virtuelle Maschine Extreme Programming Xceptance Load Test Extensible Stylesheet Language Transformation 7

8 IV. Abstract Software wird nach einem Release oft umfänglich weiterentwickelt und unterliegt zahlreichen Releases. Insbesondere agile Vorgehensmodelle fördern dieses Vorgehen. In vielen Entwicklungsprojekten ist es eine wichtige Anforderung, trotz dieser laufenden Fortentwicklung eine Abwärtskompatibilität zu bestimmten Systemen bereitzustellen. Genau diese Umstände treffen auf das Produkt SCOOBOX des Unternehmens dotsource GmbH zu, bei der diese Arbeit entstand. Die SCOOBOX ist eine Sammlung von Softwaremodulen, mit denen Online Shops, auf Intershop Basis, um Social Commerce Inhalte erweitert werden können. Sie wird kontinuierlich weiterentwickelt und in Kundenprojekten der dotsource GmbH eingesetzt. Vor der Erstellung dieser Arbeit war eine Aktualisierung der SCOOBOX innerhalb eines Kundensystems nur mit sehr hohem Aufwand möglich. Ziel dieser Arbeit ist es deshalb diesen Aufwand zu verringern. Auf Basis von aktuellen Recherchen wird in dieser Arbeit der aktuelle Stand der Technik zu dieser Thematik beschrieben. Für Einzelne, Methoden wird die praktische Umsetzung betrachtet. Insbesondere wurden Verbesserungen in den Bereichen der statischen Codeanalyse, der automatischen Tests und der agilen Datenbankentwicklungsprozesse umgesetzt. Für eine verbesserte Codeanalyse und die Einführung von automatische Tests wurde der Build Prozess so optimiert, dass er weniger Zeit (etwa 2 min statt 7 min) in Anspruch nimmt Neue Code Analyse Regeln wurden für Intershop Pipelines und ISML Dateien erstellt. Die Prüfung von JavaScript Dateien und die Ausführung automatischer Oberflächen- und Unit-Tests wurden vorbereitet. 8

9 1. Einleitung Die Entwicklung von Software ist zunehmend dadurch gekennzeichnet, dass die Produkte komplexer werden, während sich die zur Verfügung stehende Zeit gleichzeitig verkürzt. Auch Anforderungen können sich im Prozess der Entwicklung verändern. Daraus folgt eine kontinuierliche Fort- und Weiterentwicklung der Software, die jedoch die Gefahr birgt, dass durch Veränderungen die Kompatibilität mit bestehenden Produktivsystemen eingeschränkt wird. Nach einer Untersuchung aus dem Jahr 2011 gibt es bei mehr als einem Drittel der Projekte so schwerwiegende Probleme, dass ihr Abschluss bedroht ist. [1] Die immer breiter werdenden Anwendungsmöglichkeiten für moderne Software sind die Basis für einträgliche Gewinnmargen in der IT-Branche. Allerdings ist zu berücksichtigen, dass der Entwicklungsprozess in der Regel hoher Anfangsinvestitionen bedarf. Umso bedeutender ist es, Methoden zu entwickeln und einzusetzen, die den Entwicklungsprozess sicher gestalten und im Ergebnis hochqualitative Produkte generieren. Für die Unternehmen ist es ein bedeutender und sich dauerhaft wiederholender Prozess, die effektivsten Methoden und Technologien zu erproben und anzuwenden. Dadurch können Wettbewerbsvorteile erzielt und die Termintreue gegenüber Kunden verbessert werden. Die vorliegende Arbeit beschäftigt sich mit der Analyse und Optimierung eines Softwareentwicklungsprozesses am Beispiel der SCOOBOX, welche ein Produkt der dotsource GmbH ist. Die dotsource GmbH und die SCOOBOX werden in den folgenden Abschnitten vorgestellt Die dotsource GmbH Die dotsource GmbH wurde im Jahr 2006 in Jena gegründet. Heute beschäftigt das Unternehmen rund 90 Mitarbeiter. Im Jahr 2012 wurde ein Umsatz von 4,3 Millionen Euro realisiert. Mit diesen Ergebnissen ist dotsource eine der wachstumsstärksten E-Commerce Agenturen Deutschlands. Im Internetagentur-Ranking2013 [2] wurde sie auf dem 56. Platz notiert. Die dotsource GmbH ist professioneller Anbieter von E-Commerce Produkten. Der größte Geschäftsanteil wird durch die Umsetzung von Großprojekten für Onlineversandhäuser realisiert. Als Basis werden Softwareprodukte von Intershop und Magento eingesetzt. Aktuell wird das Portfolio mit weiteren Partnern, wie z.b. Eggheads oder Hybris erweitert. Ein zusätzlicher Geschäftsbereich ist das Angebot von Beratungs- und Unterstützungsdienstleistungen. [3] 9

10 Um den langfristigen Erfolg zu sichern, werden im Unternehmen nach und nach neue Konzepte des E-Commerce getestet, verbessert und umgesetzt. Dafür hat die SCOOBOX, welche im nächsten Abschnitt vorgestellt wird, eine besondere Bedeutung. Eine langfristige Vision ist "E-Commerce ab der ersten Idee", welche das Ziel beschreibt, E-Commerce Plattformen zu erstellen, bei deren Konzeption, Entwicklung und Realisierung der Kunde durchgehend beraten wird. [4] 1.2. Die SCOOBOX Die SCOOBOX (Social Commerce Out Of the BOX) ist eine Erweiterung der Standard Intershop Software. In der Vergangenheit wurde sie ausschließlich für die Umsetzung von Kundenprojekten verwendet. Die SCOOBOX stellt Funktionen bereit, wie es sie in den sozialen Netzwerken gibt, wie etwa eine Pinnwand oder eine Nachrichtenfunktion. Weitere Features sind zum Beispiel Blog, Forum, Mobile Shopping und Co-Shopping. Zusätzlich gibt es die Möglichkeit, die Nutzerprofile mit sozialen Netzwerken, wie Facebook oder Google+ zu verknüpfen. Am Beispiel der SCOOBOX soll in dieser Arbeit aufgezeigt werden, welche Optimierungen, technischer Art, den Bestand eines Softwareentwicklungsprojektes für die nächsten Jahre sichern können Zielsetzung Das Ziel dieser Arbeit ist es, Technologien, Prozesse und Tools zu finden, mit denen Softwareentwicklungsprozesse optimiert werden können. Der Schwerpunkt ist die Verbesserung der Abwärtskompatibilität. Die SCOOBOX wurde in der Vergangenheit projektorientiert und mit den in der Agentur etablierten Prozessen entwickelt. Es sollen praktische Lösungen zur Verbesserung erarbeitet werden. Nach folgenden Kriterien soll beurteilt werden, welche Maßnahmen ergriffen werden sollen: Nutzen Initialaufwand laufende Aufwände Einsetzbarkeit in anderen Teams Anschließend sind die Lösungen in kurzfristige und langfristige Ziele einzuteilen, von denen ausgewählte Maßnahmen umgesetzt werden. Aufgrund der zeitlichen Begrenzung 10

11 bei der Erstellung dieser Arbeit ist es nicht möglich, die Auswirkungen der praktischen Umsetzungen auf die Abwärtskompatibilität zu betrachten. Nach dem Guide to the Software Engineering Body of Knowledge wird die Softwaretechnik in Teilbereiche untergliedert (siehe Abbildung 1). Software Requirements (Anforderungsanalyse) Software Design (Softwareentwurf) Software Construction (Programmierung) Software Testing (Softwaretests) Softwaretechnik Software Maintenance (Softwarewartung und -evolution) Software Configuration Management (Konfigurationsmanagement) Software Engineering Management (Projektmanagement) Software Engineering Process (Vorgehensmodelle) Software Quality (Software Qualität) Abbildung 1: Einteilung der Softwaretechnik [5] In der Arbeit werden alle diese Bereiche, mit Ausnahme der Software Requirements untersucht Vorgehen Zunächst muss analysiert werden, welche Probleme bei einer Systemaktualisierung der SCOOBOX berücksichtigt werden müssen. Dabei kann auf Erfahrungen von Mitarbeitern aus Projekten und eigene Recherchen zurückgegriffen werden. Es ist eine Literaturrecherche zum Thema Softwaretechnik mit dem Fokus agile Softwareentwicklung und Kompatibilität notwendig. Vor diesem Hintergrund soll eine umfassende Übersicht über aktuelle Technologien bezüglich des Themas erstellt werden. 11

12 Entsprechend der Zielsetzung der Arbeit sind Lösungen zu erarbeiten. Kurzfristig umsetzbare Konzepte sollen in der laufenden Entwicklung angewendet werden. Nicht automatisierbare Prozesse werden im Team etabliert, während automatisierbare Prozesse installiert und eingerichtet werden. Abschließend sind die Resultate bezüglich ihres Aufwandes und Potenziales zu bewerten Analyse der Problemstellung Wie in Gesprächen mit Mitarbeitern festgestellt wurde, gibt es beim Entwicklungsprozess der SCOOBOX vielschichtige Ansätze zur Verbesserung der Abwärtskompatibilität. In den folgenden Abschnitten werden diese beschrieben Entwicklungsmodell Im SCOOBOX Entwicklungsprozess werden einige Elemente der agilen Entwicklung angewendet, welche vorwiegend durch das Scrum Modell beschrieben werden. Dieses Modell wird im Abschnitt näher beschrieben. Die Kundenprojekt-orientierten Teams im Unternehmen wenden das iterative Modell an, das im Abschnitt beschrieben wird. Abbildung 2: Anteile bei der Softwareentwicklung 12

13 Nach einer Umfrage von 2012 (siehe Abbildung 2) des Unternehmens SoftServer werden genau diese zwei Methoden überwiegend eingesetzt. Gegebenenfalls sind andere Vorgehensmodelle für die Anforderungen bei dotsource effektiver oder es ist sinnvoll einzelne Methoden (best practices) zu übernehmen oder zu kombinieren Prozesse In Gesprächen mit Mitarbeitern wurde festgestellt, dass es im Entwicklungsprozess der SCOOBOX zu wenig Minor Releases gibt. Das führt dazu, dass Kundenprojekte in der Regel nicht auf einer definierten Version SCOOBOX basieren. Bei Start eines Kundenprojektes wird die jeweils aktuelle Revision des Software Repositories verwendet. Das erschwert die Aktualisierung, weil keine standardisierten, wiederholbaren Prozesse etabliert werden können. Ein Ziel ist es deshalb, Prozesse zu etablieren, die häufigere Releases ermöglichen. Ein weiterer Komplex, der in dieser Arbeit betrachtet wird, ist Continuous Integration (CI) Bei dotsource gibt es bereits etablierte CI Prozesse, die mit dem Werkzeug Jenkins realisiert sind. Jenkins führt die Integration automatisch einmal täglich (Nightly Build) durch. Es wäre wünschenswert, die Integration häufiger durchzuführen, um den Entwicklern ein schnelleres Feedback zu liefern. Dafür ist es notwendig, einen möglichst schnellen Build-Prozess zu realisieren. Bislang wird ein modifiziertes Intershop Build-Skript verwendet, für das es kleinere Abwandlungen zwischen den Java-Teams gibt. Die Softwarequalität kann mit automatischen Tests und statischer Code Analyse optimiert werden. Gegenwärtig gibt es keine automatischen Tests im SCOOBOX Projekt. Die statische Codeanalyse wird durch das Werkzeug Sonar durchgeführt, welches durch das Jenkins System gestartet wird. Sonar prüft Java Dateien mit den Plug-ins Findbugs und PMD. Die statische Codeanalyse wird bei der SCOOBOX Entwicklung bislang ausschließlich auf Java Dateien angewendet. Bei einer SCOOBOX Aktualisierung treten Probleme erfahrungsgemäß aber insbesondere bei den Dateien auf, die nicht durch Sonar analysiert werden. Das sind vorwiegend ISML- und XML-Dateien. Beispielsweise sind einige ISML-Dateien sehr groß, was dazu führt, dass bei einer Aktualisierung sehr viel Code auf Änderungen untersucht werden muss. Das trifft insbesondere dann zu, wenn in einem Kundenprojekt die SCOOBOX Funktionen stark modifiziert wurden. Ein weiteres Problem ist, dass die Verletzungen der Sonar Regeln nur in der Weboberfläche und in der Entwicklungsumgebung angezeigt werden. So müssen Entwickler häufig darauf hingewiesen werden, dass sie ihre Sonar Verletzungen berichtigen sollen. Die Einführung eines verbesserten Feedback-Prozesses ist deshalb 13

14 erforderlich. Zusätzlich erschweren unterschiedliche Regelsets zwischen den Teams ein einheitliches Verständnis. Es kommt in der laufenden Entwicklung immer wieder vor, dass sich Schnittstellen ändern. Veraltete Schnittstellen sollten beibehalten werden und als deprecated gekennzeichnet werden, um eine Abwärtskompatibilität der Standardsoftware zu gewährleisten. Es wäre positiv, wenn die Entwickler automatisch auf solche Fehler aufmerksam gemacht werden Architektur Die SCOOBOX ist auf Basis ihrer Features in Module eingeteilt (z.b. Messages). Ein Modul ist wiederum in mehrere Untermodule, sogenannte Cartridges zerlegt (siehe Abbildung 3). SCOOBOX Messages Album Core Storefront Backoffice Core Storefront Backoffice Abbildung 3: SCOOBOX Architektur (Ausschnitt) Für Demonstrationszwecke wurde der SCOOBOX Demoshop Outbacker erstellt. Dieser verursacht erfahrungsgemäß Probleme bei der Aktualisierung der SCOOBOX. Die Ursache ist die unzureichende Abgrenzung von Outbacker Komponenten zur SCOOBOX Basisfunktionalität. Der Outbacker Demoshop enthält zwar ebenfalls eigene Cartridges, doch hat es sich so entwickelt, dass Outbacker Inhalte in anderen Cartridges vorhanden sind. Ein weiteres Architekturproblem ist die Datenbankentwicklung im SCOOBOX Projekt. Während der Entwicklung der SCOOBOX werden regelmäßig Änderungen an den Tabellen der Oracle-Datenbank vorgenommen. Bei einer Aktualisierung der SCOOBOX Applikation entstehen Inkompatibilitäten mit der Datenbank. Aufgrund des Wertes der Bestandsdaten ist eine Neuinitialisierung der Datenbank nicht möglich. Stattdessen müssen die Daten in das neue System überführt werden. Es dürfen dabei keine Daten verloren gehen oder beschädigt werden und der Online-Shop muss anschließend 14

15 ordnungsgemäß ausgeführt werden. Das ist aktuell nur mit hohem manuellem Aufwand möglich. 15

16 2. Stand der Forschung und Technik In diesem Kapitel wird der Stand der Forschung und Technik in Bezug zur Zielstellung dieser Arbeit dargestellt. Im ersten Teil werden Entwicklungsmodelle, im zweiten Teil Prozesse und im dritten Teil auf die Architektur bezogene Maßnahmen beschrieben Entwicklungsmodelle Die klassischen Entwicklungsmodelle werden in der reinen Softwareentwicklung allgemein immer weniger angewendet (siehe Abbildung 2). Im Bereich des E-Commerce ist es besonders wichtig, auf veränderte Anforderungen, schnell reagieren zu können. Aufgrund dieser Besonderheit werden in diesem Abschnitt überwiegend agile Methoden und Modelle beschrieben Iteratives Modell Das iterative Vorgehensmodell wird oft als Zwischenstadium beim Übergang zu einem agilen Vorgehensmodell benutzt. Oft wird es als Miniwasserfall bezeichnet. [6] Es beinhaltet die gleichen Phasen wie das klassische Wasserfallmodell: [7] (S.23) Anforderungsanalyse Systemdesign Programmierung/Modultest Integration/Systemtest Auslieferung Im Gegensatz zum Wasserfallmodel wiederholen sich die Phasen in relativ kurzen Zeitabständen. Dadurch verringern sich ökonomische Risiken, ohne dass eine große Umstellung notwendig ist. Durch die häufige Wiederholung werden Probleme schneller sichtbar und Anforderung und Planung können schneller angepasst werden Agile Softwareentwicklung Die agilen Softwareentwicklungsmodelle und Prinzipien entstanden etwa um das Jahr 2000 und werden heute zunehmend eingesetzt. Im Jahr 2001 wurden Werte und Prinzipien der agilen Entwicklung im sogenannten Agilen Manifest festgeschrieben: [7] (S23, 24) Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Software mehr als umfassende Dokumentation 16

17 Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung Reagieren auf Veränderung mehr als das Befolgen eines Plans. [8] Basierend auf diesen Werten wurden folgende Prinzipien festgelegt (Auszug): [9] Zufriedenstellen der Kunden durch schnelles Ausliefern funktionierende Software möglichst häufig ausliefern Änderungen an den Anforderungen immer begrüßen zukunftsgerichtete Entwicklung, konstantes Entwicklungstempo tägliche Kommunikation der Programmierer mit den fachlichen Experten wichtigstes Fortschrittsmaß ist funktionierende Software persönliche Kommunikation ist zu bevorzugen Motivation der Projektbeteiligten anhaltende Aufmerksamkeit für technische Erstklassigkeit und gutes Design selbst organisierende Teams Der agile Ansatz ermöglicht es Entwicklerteams, schneller auf veränderte Anforderungen zu reagieren und verringert die Risiken. Die Qualität des Software-Designs und die Kommunikation im Team werden verbessert. Der Kunde bekommt genau das Produkt, welches ihm in seinem Geschäftsumfeld den größten Nutzen bringt. Die Anwendung der agilen Prinzipien wirkt sich aber auch positiv auf die Entwicklungsgeschwindigkeit und Softwarequalität aus. [10] (S.13) Es gibt aber auch Kritiker des agilen Vorgehens. Einer davon ist Mike Gualtieri. Er vertritt die These, dass es falsch ist, die Funktion der Software als primäres Fortschrittsmaß festzulegen. Er behauptet, dass es schlecht ist, wenn Programmierer von ihrer eigentlichen Aufgabe, dem Programmieren zu sehr abgelenkt werden: Software developers want to be measured on what they know code instead of what they don t know: the domain, business requirements, and the user. Zu dem agilen Prinzip, der engen Kommunikation zwischen Entwickler und Kunden schreibt er: Developers would much rather stick with what they know The absurd Agile solution to getting the requirements right is to meet with the business every day. [11] Basierend auf den Werten und Prinzipien entstanden zahlreiche Vorgehensmodelle, die vor allem Praktiken der Programmierung und das Projekt Management betreffen (best practices). Die drei typischen agilen Vorgehensmodelle Scrum, Extreme Programming und Kanban werden in den folgenden Abschnitten vorgestellt. 17

18 Scrum Scrum ist ein Modell, welches ausschließlich den Projektablauf beschreibt. Scrum gibt keinerlei Richtlinien zur konkreten Softwareentwicklung vor. [12] Scrum definiert drei Rollen, den Product Owner, den ScrumMaster und das Team (siehe Abbildung 4). Der Product Owner vertritt den Kunden. Er formuliert Anforderungen und priorisiert sie. Der Scrum Master ist für den reibungslosen Ablauf des Projektes verantwortlich, ist selbst aber kein Mitglied des Teams. [13] (S.18) Abbildung 4 Scrum Zusammenfassung [14] Die Anforderungen für das Produkt werden im Product-Backlog festgehalten. Für feststehende Zeiträume, sogenannte Sprints, wird gemeinsam eine Planung durchgeführt. Das heißt, es werden Elemente des Product-Backlog in das Sprint-Backlog übertragen. Am Ende eines Sprints werden die Ergebnisse dem Product Owner vorgestellt. Innerhalb eines laufenden Sprints hat dieser keinen Einfluss auf die Entwicklung. [13] (S. 93) Ein wichtiges Hilfsmittel, mit dem die Kommunikation im Team verbessert werden soll, sind kurze tägliche Treffen, welche als Daily Scrum bezeichnet werden. Zusätzlich werden einmal pro Sprint so genannte Retrospectives im Entwicklerkreis durchgeführt. Sie werden genutzt, um den Entwicklungsprozess kontinuierlich zu analysieren und zu verbessern. [15] 18

19 Scrum allein gestellt ist kein agiler Entwicklungsprozess. Die Agilität wird erst erreicht, wenn zusätzlich die Prinzipien des Agilen Manifests berücksichtigt werden. [16] Extreme Programming Xtreme Programming (XP) ist eine Sammlung von Methoden, die darauf ausgerichtet sind, Aufwände und Risiken gut einschätzen zu können. Im Gegensatz zu Scrum werden neben der Planung zusätzlich Prozesse vorgegeben, die die Entwicklung betreffen. Die markanteste Eigenschaft von XP ist eine stark eingeschränkte Anfangsplanung, die agile Vorgehensweisen dadurch unterstützt, dass mit relativ geringem Aufwand Änderungen durchgeführt werden können. Das gibt Entwicklern und Kunden die Möglichkeit, während der Entwicklung dazugewonnene Erkenntnisse in das Projekt einzubeziehen. Ein weiterer Effekt ist, dass früh erkannt werden kann, wenn die Umsetzung bestimmter Ziele zu aufwändig oder nicht durchführbar sind. [17] Das Team ist komplett selbstorganisiert. Es erstellt Aufwandsschätzungen und plant die Iterationen selbst. Die User Storys für das Endprodukt und die Liefertermine werden aber durch den Kunden bestimmt. [10] (S. 16) Eine Methode des XP ist die Paarprogrammierung. Sie verteilt das Wissen innerhalb des Teams. So wird die Codequalität verbessert, was die Aufwände für Wartung und Weiterentwicklung senkt. Das kann sich langfristig positiv auf die Gesamtkosten auswirken. [18] Auch Code Reviews und Refactorings sollten regelmäßig durchgeführt werden. [17] Um die Geschwindigkeit der Entwicklung konstant hoch zu halten, sollte immer ein möglichst einfaches Design (Continuous/Evolutionary Design) gewählt werden, mit dem die aktuelle Aufgabe gerade so erfüllt wird. Es sollten keine Annahmen über zukünftige Anforderungen gemacht werden, weil diese sich laufend ändern können. Dieses Vorgehen steht in direktem Zusammenhang mit der kurzfristigen Planung. Die Software sollte so oft wie möglich ausgeliefert werden (Small Releases). Das gibt dem Kunden die Möglichkeit, regelmäßig Produktentwicklung zu überprüfen und gegebenenfalls Änderungswünsche einzubringen. Test Driven Development (TDD) und Continuous Integration sind weitere Methoden von XP, mit denen die Qualität sichergestellt werden soll. TDD bedeutet, dass die Entwickler parallel zur Entwicklung selbst Unit und Akzeptanz Tests schreiben. Akzeptanz Tests überprüfen die User Storys und Unit Tests überprüfen die Java Ebene (Klassen). Die Tests werden automatisch, vor dem Check-in von Programmcode, durchgeführt. [17] Continuous Integration wird im Absatz beschrieben. 19

20 Kanban Das Kanban Vorgehensmodell entstand auf Basis des gleichnamigen Prozesses des Unternehmens Toyota Motor Corporation. Das Ziel von Kanban ist es, die Zeit, für die Entwicklung eines einzelnen Features zu verringern. Es gibt keine festgelegten Entwicklungsphasen oder Zeiten. Die Features der Software werden in MMF (Minimum Marketable Features) eingeteilt. Jedes MMF enthält eine Reihe von Aufgaben (Tasks). Es wird gleichzeitig immer nur an einem MMF gearbeitet. Die restlichen MMFs sind in einer Warteschlange und dürfen erst begonnen werden, wenn das Aktuelle abgeschlossen ist. Nur in Ausnahmefällen kann auch kurzzeitig an einem anderen MMF gearbeitet werden (Urgent Slot). Die Reihenfolge in dieser Warteschlange kann jederzeit durch das Projektmanagement verändert werden. Die Visualisierung erfolgt auf dem sogenannten Kanban Board. Das Board kann als Entwicklungswerkzeug oder auch als Tafel realisiert werden (siehe Abbildung 5). Bei Anwendung von Kanban entsteht ein fließender Entwicklungsprozess bei minimaler Ablenkung von außen. [19] Abbildung 5: Beispielhafter Aufbau eines Kanban Boards Continuous Delivery Eine der neueren Softwareentwicklungsmethoden ist Continuous Delivery (CD). Die Ursache für ihre Entwicklung ist der Wunsch, regelmäßig und in kurzen Abständen Releases erstellen zu können. Das hat vor allem wirtschaftliche Vorteile. Man kann nach und nach einzelne Features verkaufen. Dadurch lassen sich Projekte leichter finanzieren. 20

21 Die Release Zyklen können mit Hilfe von CD auf wenige Wochen oder sogar Tage verkürzt werden. Um das zu ermöglichen, wird der gesamte Entwicklungsprozess stark automatisiert und einige neue Methoden eingeführt. Abbildung 6 Beispiel einer Deployment Pipeline [20] (S. 4) Der Kern von CD ist die sogenannte Deployment Pipeline. Diese kann bei jedem Projekt etwas anders gestaltet werden. Der allgemeine Aufbau ist in Abbildung 6 dargestellt. Die Prozesse sind chronologisch vom Commit bis zum Release angeordnet. Die Pipeline läuft soweit wie möglich automatisch ab. Im CD-Modell sind vor allem die folgenden Maßnahmen und Prozesse wichtig: [21] Verstecken von unfertigen Features (Feature Toggles) Continuous Integration Automatisierte Tests Automatisiertes Deployment schnelles Feedback und Einbeziehung aller in der Firma beteiligten Personen in den Feedback-Prozess Es gibt eine Vielzahl an Umsetzungsvarianten von CD, was auf die unterschiedlichen Anforderungen der Unternehmen zurückzuführen ist. Ein Beispiel ist das Open Source Projekt: OpenDelivery. Dort werden ausschließlich Open Source Tools genutzt. Für eine bessere Skalierbarkeit laufen alle automatischen Prozesse innerhalb einer Cloud Infrastruktur ab. [22] 2.2. Prozesse Es gibt bei der Softwareentwicklung vielschichtige Prozesse mit Potenzial für Verbesserung. In diesem Abschnitt wird eine Übersicht über diese angegeben Versionierung und Release Management Alle Dateien, die für die Ausführung und das Testen der Anwendung notwendig sind, sollten in einem Versionskontroll-System erfasst werden. Dazu gehören zum Beispiel. Build-Skripte sowie Bibliotheksdateien. Es ist darüber hinaus empfehlenswert, alle anderen, das Projekt betreffenden Dateien wie Dokumentation in das Versionsverwaltungssystem aufzunehmen. [20] (S. 33) 21

22 In dem folgenden Abschnitt werden die drei am häufigsten verwendeten Typen der Versionsverwaltungssysteme vorgestellt Zentrale Versionsverwaltung Die zentrale Versionsverwaltung wurde mit CVS bereits Anfang der 90er Jahre eingeführt. CVS wurde ab dem Jahr 2000 weitestgehend durch Subversion (SVN) abgelöst, das bis heute eine sehr große Verbreitung aufweist. [23] (S.20,21) Die Daten und ihre Geschichte werden auf einem einzelnen Server in einem sogenannten Repository gespeichert. Jedem Entwickler ist es möglich mit einem Client System auf die Dienste des SVN Servers zuzugreifen. Ein zentrales Konzept in Versionsverwaltungssystemen ist das sogenannte Branching. Ein Branch ist ein eigener Entwicklungszweig, der von anderen Programmierern nicht beeinflusst werden kann. Wenn der Inhalt eines Branches wieder dem Hauptentwicklungszweig zugeführt werden soll, ist es notwendig die einzelnen Dateien zusammenzuführen (Merging). Das kann problematisch sein, wenn der Umfang der Änderungen groß ist und keine Automatik durch die Entwicklungsumgebung zur Verfügung steht. Es haben sich mehrere Strategien für die Erstellung von Branches entwickelt: [20] (S ) Develop on Mainline Branching und merging o Branch for Release o Branch by Feature o Branch by Team Develop on Mainline bedeutet, dass alle Entwickler auf der gleichen Codebasis arbeiten. Es werden keine Branches erstellt. Das begünstigt den Continuous Integration Prozess, weil nur ein Entwicklungszweig getestet werden muss. Die Problematik von Branching und Merging kann durch die Stream Basierte- und die verteilte Versionsverwaltung verringert werden. Diese Systeme werden in den nächsten Abschnitten beschrieben Stream basierte Versionsverwaltung Die Stream basierten Versionsverwaltungssysteme besitzen ebenfalls eine zentrale Architektur. Für Branches wird der Begriff des Streams eingeführt. Im Gegensatz zu Branches werden Streams nicht wieder zusammengeführt (kein Merging). Stattdessen können die Änderungen eines Streams für andere Streams vorgeschlagen werden. Für jeden Stream gibt es einen verantwortlichen Entwickler, der über Kompetenz im 22