einführung eines continuous integration systems in einer ... · continuous integration (ci) wird...

Einführung eines Continuous Integration Systems in einer Bank – Ein Fachkonzept

Diplom-Hausarbeit

an der

Verwaltungs- und Wirtschafts-Akademie in Leer e.V.

von

Niklas Schröder

Hoymer Straße 12

26209 Hatten

Betreuung:

Prof. Dr. Ing. Thorsten Spitta

2016

VWA Leer e.V. I Verzeichnisse

Stand: 18.10.16 Niklas Schröder

Inhaltsverzeichnis 1 Einleitung .......................................................................................................................................... 1 2 Projektumfeld .................................................................................................................................... 2

2.1 Vorstellung der OLB AG .......................................................................................................... 2 2.2 Vorstellung der IT-Abteilung .................................................................................................... 2 2.3 Entwicklungsumfeld .................................................................................................................. 3

3 Continuous Integration (CI) .............................................................................................................. 3 3.1 Begriffsbestimmung und Ablauf ............................................................................................... 4 3.2 Versionskontrollsystem ............................................................................................................. 5 3.3 Build-Prozess ............................................................................................................................. 5 3.4 Selbsttestender Build ................................................................................................................. 8

3.4.1 Compiler ............................................................................................................................ 9 3.4.2 Unit-Tests ........................................................................................................................... 9 3.4.3 Systemtest ........................................................................................................................ 10

3.5 Build-Intervall ......................................................................................................................... 11 3.6 Zugriff auf Build-Ergebnisse ................................................................................................... 12

4 Ist-Zustand ....................................................................................................................................... 13 4.1 Softwareentwicklungsprozess ................................................................................................. 13 4.2 Softwareentwicklungssystem .................................................................................................. 15 4.3 Systeme im Softwareentwicklungsprozess .............................................................................. 19 4.4 Verbesserungsbedarf ............................................................................................................... 20

4.4.1 Technischer Verbesserungsbedarf ................................................................................... 21 4.4.2 Organisatorischer Verbesserungsbedarf .......................................................................... 21

5 Integration in den Softwareentwicklungsprozess ............................................................................ 22 5.1 Agiles Vorgehen ...................................................................................................................... 22 5.2 Systemübersicht ....................................................................................................................... 23 5.3 Softwareentwicklungsprozess ................................................................................................. 29 5.4 Build-Prozess ........................................................................................................................... 31 5.5 Verbesserungen ....................................................................................................................... 33

5.5.1 Technische Verbesserungen ............................................................................................ 33 5.5.2 Organisatorische Verbesserungen .................................................................................... 33

6 Fazit ................................................................................................................................................. 34 Literaturverzeichnis ............................................................................................................................ 35 Erklärung ............................................................................................................................................ 36

VWA Leer e.V. II Verzeichnisse


Abkürzungsverzeichnis AG Aktiengesellschaft CI Continuous Integration ID Identifikator MaRisk Mindestanforderungen an das Risikomanagement OLB Oldenburgische Landesbank AG PL/SQL Procedural Language/Structured Query Language SVN Subversion

VWA Leer e.V. 1 Einleitung


1 Einleitung Ein Continuous Integration System verbindet die fachlichen Anforderungen an Software mit ihrer Implementierung sowie der fachlichen Freigabe und unterstützt ihren Produktionseinsatz. Continuous Integration (CI) wird eingesetzt, um Risiken in der Softwareentwicklung zu verringern und die Qualität der Software zu erhöhen [Wies11, S.23]. Beim Einsatz dieser Methode ergeben sich weitere Vorteile, die in dieser Arbeit erläutert werden.

Da das Bauen von Softwarekomponenten zu ablauffähigen Programmen und das Verteilen auf die entsprechenden Ausführungssysteme in einer Bank komplex sind, ist es sinnvoll, diese Tätigkeiten durch den Einsatz eines Continuous Integration Systems zu dokumentieren und zu automatisieren. Die Komplexität ergibt sich durch mehrere Programmiersprachen, Datenbankmanagementsysteme unterschiedlicher Hersteller und verschiedener Ablaufbetriebssysteme. Dies gilt insbesondere für eine Bank, die als Universalbank tätig ist, da für alle Sparten die entsprechenden Anwendungen bereitgestellt werden müssen. Eine Universalbank ist ein Institut, das alle oder fast alle typischen Bankgeschäfte betreibt [Buba16].

Dieses Fachkonzept beschreibt die Integration von CI in den Softwareentwicklungsprozess mit der Programmiersprache Java, dem Datenbankmanagementsystem Oracle und dem Ablaufbetriebssystem Unix. Bei der Entwicklung mit anderen Werkzeugen können die beschriebenen Techniken, geringfügig modifiziert, ebenfalls angewandt werden.

Da die Integration von CI in den Softwareentwicklungsprozess im Vordergrund dieses Fachkonzeptes steht, richtet sich diese Arbeit besonders an Personen, die daran interessiert sind, CI in einem Unternehmen einzuführen. Es soll den Interessierten ermöglicht werden, das Gelesene in die Praxis umzusetzen und von den Vorteilen von CI zu profitieren.

Um diesen Praxisbezug herzustellen, bezieht sich die Ist-Analyse und die Integration in den Softwareentwicklungsprozess auf die Oldenburgische Landesbank AG (OLB). Nach der Einleitung werden die OLB und der organisatorische Aufbau ihrer IT-Abteilung beschrieben. Ebenfalls werden die Besonderheiten bei der Softwareentwicklung in der OLB in diesem Abschnitt aufgezeigt.

Im darauffolgenden Kapitel wird der Begriff Continuous Integration definiert und der Ablauf anhand eines Schaubildes erklärt. In diesem Kapitel wird auch darauf eingegangen, auf welchen Prinzipien CI basiert und wie diese funktionieren.

Es folgt die Skizzierung des Ist-Zustandes im Hinblick auf die aktuellen Arbeitsabläufe und die Erläuterung der Schnittstellen der eingesetzten Systeme. Der Verbesserungsbedarf des Ist-Zustandes wird zum Abschluss dieses Kapitels aufgezeigt.

Im Anschluss wird die Integration eines CI-Systems in den Softwareentwicklungsprozess beschrieben. Die Beschreibung umfasst die Systemübersicht und die zukünftigen Arbeitsabläufe. Des Weiteren wird aufgezeigt, wie mit dem modifizierten Softwareentwicklungsprozess die Softwareentwicklung in der OLB verbessert werden kann.

Abschließend erfolgt ein Fazit der erarbeiteten Erkenntnisse bezüglich der Einführung eines Continuous Integration Systems in einer Bank.

VWA Leer e.V. 2 Projektumfeld


2 Projektumfeld

2.1 Vorstellung der OLB AG

Die Oldenburgische Landesbank AG (OLB) ist eine im Nordwesten Deutschlands tätige Universalbank, die im Jahr 1869 gegründet wurde. An mehr als 200 Standorten zwischen Nordsee, Teutoburger Wald, Ems und Weser ist die Bank präsent (siehe Abbildung 2.1). Der Vertrieb von Bankprodukten erfolgt über die Filialen und zunehmend auch über das Internet.

Die Zentrale der OLB befindet sich in der Stadt Oldenburg. Von hier aus werden die Filialen technisch betreut und durch Backoffice-Tätigkeiten entlastet. Die technische Betreuung erfolgt durch die IT-Abteilung der OLB.

2.2 Vorstellung der IT-Abteilung

Die Abteilung Informationstechnologie ist in fünf Gruppen aufgeteilt, die wiederum aus Teams bestehen. Die Gruppen sind „Basisdienste“, „Kernbanksysteme“, „Kundensysteme“, „Steuerungssysteme“ und „Produktion“.

Die Gruppe Basisdienste plant, realisiert und betreut die gesamte technische Infrastruktur in der OLB. Dazu zählen die Netzwerkkomponenten, die Datenbanken, die Server und die Systeminstallationen.

Die Gruppe Kernbanksysteme beschäftigt sich mit dem Kernbankensystem KORDOBA1 und der Bereitstellung der Grunddaten dieses Systems für andere Systeme. Ebenfalls werden von dieser Gruppe die Anwendungen für das Wertpapiergeschäft betreut.

Die Gruppe Kundensysteme ist zuständig für das Online-Banking und den Zahlungsverkehr, sowie für mehrere Querschnitts- und Vertriebssysteme.

Die Gruppe Steuerungssysteme ist in drei Teams unterteilt. Das Team Kreditsysteme entwickelt die Systeme für die gesamte Kreditabwicklung. Diese startet vom Kreditantrag mit dem Übergang zum Kreditbestand, der wiederum von Risikofrüherkennungssystemen überwacht wird, bis zur Abwicklung von notleidenden Krediten. Das Team Abrechnungs- und Steuerungssysteme betreut das Datawarehouse und Systeme für das Controlling der OLB. Die Systeme des Teams Risikosysteme und Meldewesen dienen dazu, regulatorische Anforderungen zu erfüllen. Dazu zählen zum Beispiel die Berechnung und Bildung einer Risikovorsorge und die Erstellung des Jahresabschlusses.

Die Gruppe Produktion stellt den Produktivbetrieb der Anwendungen in der OLB sicher. Insbesondere betrifft dies die automatisierte Verarbeitung technischer Abläufe (Batchbetrieb).

1 „Kundenorientiertes Dialogsystem für Bankgeschäfte“ – Softwaresystem der Fidelity Information Services

GmbH zur Abwicklung grundlegender Kernprozesse einer Bank

Abbildung 2.1: OLB Geschäftsgebiet

VWA Leer e.V. 3 Continuous Integration (CI)


2.3 Entwicklungsumfeld

In diesem Abschnitt werden die in der OLB eingesetzten Programmiersprachen und Datenbanksysteme aufgezeigt, um die Komplexität des Entwicklungsumfeldes zu verdeutlichen. Eine Beschreibung der Systeme, die im Softwareentwicklungsprozess eingesetzt werden, ist dem Kapitel 4 zu entnehmen.

Die OLB begann bereits in den 1960er Jahren mit der elektronischen Verarbeitung von Daten. Neben dem Betrieb eines eigenen Rechenzentrums wurden auch am gekauften Kernbankensystem OLB-spezifische Änderungen durch die eigene IT vorgenommen. Dadurch etablierte sich die Programmiersprache Cobol in der OLB. Diese wird auch heute noch für das Customizing des Kernbankensystems verwendet.

Da immer mehr Prozesse technisch unterstützt werden sollten und keine passende Standardsoftware auf dem Markt war, entschied man sich, für diese Bereiche eigene Software zu entwickeln. Nach einer Analyse der möglichen Architekturen entschied man sich für eine Client-Server-Architektur. Aufgrund dieser Architektur müssen vorgenommene Änderungen nur auf den Servern veröffentlicht werden und nicht auf allen Clients. Die Clients greifen auf die Server zu und verwenden so automatisch die geänderte Software. Für diese Client-Server-Systeme kam die Programmiersprache PHP in Verbindung mit dem Datenbankmanagementsystem Oracle zum Einsatz. Durch den Einsatz von Oracle ergab sich die Möglichkeit, Batchprogramme direkt auf der Datenbank auszuführen. Diese Möglichkeit wurde mit der Programmiersprache PL/SQL genutzt.

Im Laufe der Jahre wurden weitere Programmiersprachen und Technologien getestet und es wurde geprüft, ob sich diese für den Produktivbetrieb in der OLB eignen. So hielt die Programmiersprache Java Einzug in die OLB. Java wurde zunächst nur für Batchverarbeitungen verwendet. Nach positiven Erfahrungen im Batchbetrieb wurde ein Framework zur Oberflächengestaltung lizenziert. Danach wurden die ersten Webanwendungen in Java erstellt.

Durch den Einsatz verschiedener Standardsoftware für bestimmte Bereiche wurden weitere Datenbankmanagementsysteme benötigt, da Oracle nicht von den jeweiligen Herstellern unterstützt wurde. Ebenfalls wurden weitere Ablaufbetriebssysteme benötigt.

3 Continuous Integration (CI) In diesem Kapitel wird zunächst erläutert, was unter Continuous Integration zu verstehen ist und wie dieser Prozess abläuft. Danach wird auf die Bedeutung des Versionskontrollsystems für CI eingegangen. Es folgt die Beschreibung des Build-Prozesses. Dazu wird erst der Aufbau von Software erklärt und anschließend beschrieben, wie die Abhängigkeiten der Komponenten aufgelöst werden können. Damit festgestellt werden kann, ob ein Build-Prozess erfolgreich durchlaufen wurde, wird die Möglichkeit des selbsttestenden Builds aufgezeigt. Im darauffolgenden Abschnitt werden Kriterien zur Festlegung des optimalen Build-Intervalls entwickelt. Abschließend wird dargestellt, wie der Zugriff auf die Build-Ergebnisse erfolgen sollte.



3.1 Begriffsbestimmung und Ablauf

Die kontinuierliche Integration ist ein Prozess in der Softwareentwicklung, der von mehreren Entwicklergruppen unabhängig voneinander entwickelt wurde. Die eigentliche Begriffsprägung „Continuous Integration“ (CI) erfolgte mutmaßlich durch Martin Fowler in seinem gleichnamigen Artikel [Wies11, S.13]. CI ist eine Methode des „extreme programming“2.

Zur Veranschaulichung des Ablaufes von kontinuierlicher Integration dient die Abbildung 3.1.

Abbildung 3.1: Ablauf der kontinuierlichen Integration (in Anlehnung an [Wies11, S.14], [Flat15])

Die Entwickler erstellen gemeinsam eine Anwendung. Die Codeänderungen erfolgen zunächst lokal auf den Computern der Entwickler. Nach dem Einchecken in das Versionskontrollsystem (1) bemerkt der CI-Server die Änderungen des Quellcodes (2). Dieser wiederum startet einen Build-Prozess3 auf dem Build-Server, der sich den Quellcode aus dem Versionskontrollsystem auscheckt (3) und dann die Anwendung aus ihren Komponenten zusammenfügt. Die Ergebnisse des Build werden an den CI-Server übertragen (4). Über geeignete Kommunikationskanäle, wie zum Beispiel E-Mail, werden die Entwickler über den Verlauf des Build („erfolgreich“ oder „fehlerhaft“) informiert (5). Dadurch können Probleme schnell entdeckt und behoben werden. Aber auch weitere Projektmitglieder können sich mit Hilfe der Rückmeldungen und weiteren Daten, die der CI-Server bereitstellt, einen Überblick über den Entwicklungsstand einer Anwendung machen. [Wies11, S.14f.]

2 Zusammenstellung von Praktiken der Softwareentwicklung von Kent Beck 3 Als Build-Prozess bezeichnet man alle Aktivitäten zusammengefasst, die für die Bereitstellung einer

lauffähigen Anwendung nötig sind.



3.2 Versionskontrollsystem

Ein Versionskontrollsystem dient zur Verwaltung von Dateien. Alle Dateien, die dort abgelegt wurden, werden gespeichert. Das System stellt sicher, dass alle vorherigen Versionen wiederherstellbar sind. Ebenfalls dokumentiert es, wer und zu welchem Zeitpunkt Änderungen an einer Datei vorgenommen hat.

Im Rahmen von Continuous Integration dient das Versionskontrollsystem als zentraler Ablageort für den Quellcode und andere relevante Dateien, die für den Build der Software benötigt werden. Dies können unter anderem Build-Skripte, Konfigurationsdateien oder Ähnliches sein.

Alle zuständigen Entwickler haben lesenden und schreibenden Zugriff auf das System. Somit ist sichergestellt, dass alle Entwickler eine gemeinsame Codebasis haben. Möchte ein Entwickler eine Änderung an bestehendem Quellcode durchführen, so checkt er zunächst den aktuellsten Stand aus. Damit es nicht zu konkurrierenden Änderungen kommt, kann er die Datei im Versionskontrollsystem zur alleinigen Bearbeitung reservieren. Danach ändert er die Datei lokal auf seinem Computer. Abschließend erfolgt der Commit in das Versionskontrollsystem. Dadurch wird automatisch die Bearbeitung für andere Entwickler wieder freigegeben. Bei der Erstellung einer neuen Datei entfällt der Checkout und es wird nur die neue Datei eingecheckt.

Bei dem Einsatz von CI merkt der Build-Server jede Veränderung im Versionskontrollsystem. Diese Änderungen werden auf dem Server ausgecheckt und der Build-Prozess durchlaufen. Durch dieses Vorgehen wird sichergestellt, dass nur der Code Einfluss auf den Build hat, der aus der gemeinsamen Codebasis stammt.

3.3 Build-Prozess

Damit Software kontinuierlich integriert werden kann, muss der Build-Prozess automatisiert werden. Um diese Automatisierung zu erläutern, wird zunächst der typische Aufbau von Software beschrieben. Auf dieser Basis wird der Build-Prozess erklärt. Ebenfalls wird beschrieben, wie dieser die Abhängigkeiten der Komponenten einer Software auflöst. Nach der Erläuterung der notwendigen Grundlagen, wird im letzten Abschnitt dieses Kapitels auf die Automatisierung des Build-Prozesses eingegangen.

Aufbau von Software

Eine Software besteht häufig aus mehreren Komponenten, die voneinander abhängig sind. Um diesen Aufbau anschaulich zu erklären, wird als Beispiel der Aufbau eines Systems aus der OLB in der Abbildung 3.2 dargestellt.



Abbildung 3.2: Aufbau Limitüberwachung

Das dargestellte System „Limitüberwachung“ ermittelt im nächtlichen Batchbetrieb, unter Verwendung eines Regelwerks, bearbeitungspflichtige Aufgaben. Diese Aufgaben werden in der Weboberfläche dargestellt und müssen dort von einem Mitarbeiter bearbeitet werden.

Die Systemarchitektur besteht dabei aus mehreren Schichten. Diese Schichten sind eigenständige Projekte in der Entwicklungsumgebung. Lauffähig sind nur die Komponente „Weboberfläche“ und „Batch“. Die anderen Komponenten dienen zur Strukturierung des Quellcodes und zur Wiederverwendbarkeit der implementierten Funktionalitäten.

Die Weboberfläche ist direkt abhängig von den Komponenten „Berechtigungen“ und „Regelwerk“. Die Komponente „Berechtigungen“ ist ein Webservice und stellt die Berechtigungen für die User bereit. Diese Komponente wird in vielen Systemen der OLB eingesetzt. Sie ist in diesem Schaubild die einzige Komponente, die anwendungsunabhängig verwendet werden kann. Die Komponente „Regelwerk“ stellt die Anwendungslogik bereit. Diese Logik wird ebenfalls in der Batchverarbeitung benötigt. Die Komponente „Datenbankzugriff“ wird ebenfalls von der Weboberfläche und der Batchverarbeitung benutzt. „Datenbankzugriff“ und „Regelwerk“ sind wiederum direkt abhängig von der Komponente „Business Objects“. Die „Business Objects“ bilden die realen Geschäftsobjekte im System ab. Indirekt, also über die anderen Komponenten, sind auch die Komponenten „Weboberfläche“ und „Batch“ von den „Business Objects“ abhängig.

Build-Prozess

Der Build-Prozess umfasst alle notwendigen Aktivitäten zur Bereitstellung einer lauffähigen Anwendung. Dabei muss analysiert werden, welche Abhängigkeiten unter den Komponenten bestehen, um eine Reihenfolge der Builds der Komponenten festzulegen. Dabei hilft die Abbildung 3.2, die im vorherigen Abschnitt erläutert wurde. Aus dieser kann die Reihenfolge der Builds einfach abgelesen werden. Die Komponenten der untersten Ebene, die von keinen anderen Komponenten anhängig sind, müssen als erstes gebaut werden. Danach folgt die darüber liegende Ebene und danach wiederrum die darüber liegende Ebene. So können die Abhängigkeiten von beliebig komplexen Anwendungen dargestellt und für den Build der Anwendung aufgelöst werden. Der Build der Komponenten auf einer Ebene kann parallel ausgeführt werden, sofern der jeweilige CI-Server dies unterstützt.



Die Auflösung der Abhängigkeiten ist Teil des Build-Prozesses. Im Prozess in der Abbildung 3.3 wird diese jedoch nicht dargestellt. Dieser Prozess legt den Fokus auf die Aktionen, die für den Build einer Komponente erfolgen müssen.

Abbildung 3.3: Ablauf des Build-Prozesses



Der Start des Build-Prozesses kann über verschiedene Ereignisse erfolgen. Diese werden im Kapitel 3.5 näher erläutert. In diesem Prozess wird davon ausgegangen, dass die Build-Reihenfolge bereits festgelegt wurde und lediglich nach dem Bau jeder Komponente geprüft werden muss, ob die Anwendung vollständig zusammengefügt wurde.

Sofern die Anwendung noch nicht vollständig zusammengefügt wurde, wird die nächste Komponente der festgelegten Reihenfolge gebaut. Dazu werden statische Tests ausgeführt, der Quellcode kompiliert und danach Unit-Tests ausgeführt. Sollte in einem dieser drei Schritte ein Fehler auftreten, wird der gesamte Build-Prozess abgebrochen. An dieser Stelle wurde zur Vereinfachung der Fehlerfall nur nach dem letzten Schritt modelliert. Tatsächlich kann nach jedem Schritt der Build abbrechen. In Kapitel 3.4 werden die Tests genauer beschrieben, die im Build-Prozess ausgeführt werden.

Wenn keine Fehler aufgetreten sind, wird jede Komponente gebaut, bis die Anwendung vollständig zusammengefügt wurde. Danach wird ein Systemtest ausgeführt. Tritt dabei kein Fehler auf, wird der Build-Prozess erfolgreich beendet. Sollte bei dem Systemtest ein Fehler auftreten, erfolgt der Abbruch des Builds.

Beim Abbruch des Build-Prozesses wird der zuständige Entwickler über die Fehler informiert. Im Versionskontrollsystem ist gespeichert, welcher Entwickler die Änderungen eingecheckt hat. Daher kann dieser als zuständig ermittelt werden.

Automatisierung des Build-Prozesses

Soll eine kontinuierliche Integration erfolgen ist es unerlässlich, den Build-Prozess zu automatisieren. Dazu muss dieser genau definiert werden. Der Prozess ist so zu gestalten, dass dieser auf dem Build-Server, aber auch lokal auf den Computern der Entwickler, ausgeführt werden kann. So können die Entwickler vor dem Einchecken den Build testen und vermeiden, dass dieser auf dem Server fehlschlägt. Damit die gleichen Build-Skripte zum Einsatz kommen können, müssen die umgebungsspezifischen Konfigurationen in Konfigurationsdateien ausgelagert werden. Eine solche umgebungsspezifische Konfiguration sind beispielweise lokale Dateipfade. Damit der Verlauf jedes Build-Prozesses nachvollziehbar ist, sollte dieser seine Arbeitsschritte in angemessenem Umfang protokollieren.

Neben der Notwendigkeit für CI bietet die Definition des Build-Prozesses weitere folgende Vorteile:

Der Build-Prozess kann von jedem Entwickler, auch ohne spezielles Fachwissen, ausgeführt werden.

Der Build-Prozess ist durch die Definition dokumentiert und für jeden einsehbar.

Es wird immer der gleiche Build-Prozess durchlaufen. Es kommt nicht zu unterschiedlichen Builds, weil die Computer der Entwickler unterschiedlich konfiguriert sind.

3.4 Selbsttestender Build

Ein selbsttestender Build prüft während des Build-Prozesses, ob dieser erfolgreich war. Unter erfolgreich ist dabei zu verstehen, dass es nicht zu Fehlern im Prozess kommt und die definierten Qualitätsziele erreicht werden. Ein mögliches Qualitätsziel ist dabei die Wartbarkeit der Software. Diese kann unter anderem damit erreicht werden, dass der Code gut lesbar strukturiert ist. Dafür ist es notwendig, dass alle Entwickler sich an die gleichen Konventionen beim Schreiben des Quellcodes halten. Die Einhaltung der Konventionen kann während des Builds überprüft werden. Sollten die gesetzten Qualitätsziele nicht erreicht



werden oder ein anderer Fehler beim Testen des Builds auftreten, bricht dieser ab. Bei dem Testen von Software ist zu beachten, dass mit Tests immer nur die Anwesenheit von Fehlern, nicht jedoch die Abwesenheit von Fehlern festgestellt werden kann [Spil12, S.37].

Man unterscheidet zwischen statischen und dynamischen Tests. Bei statischen Tests wird das zu testende Programm nicht gestartet. Es wird lediglich im Hinblick auf die Datentypen, die Kompilierbarkeit und den theoretischen Durchlauf des Programms geprüft. Bei dynamischen Tests, wie dem Unit-Test und dem Systemtest, werden Ergebnisse zu bestimmten Eingabedaten vorausgesagt, das Programm ausgeführt und die ermittelten Ergebnisse mit den vorausgesagten verglichen.

Fowler weist darauf hin, dass es besser ist, unvollständige Tests zu haben, die regelmäßig durchlaufen werden, als perfekte Tests, die nie geschrieben werden [Fowl06].

Die automatisierten Tests können in verschiedenen Variationen erfolgen. Die schnelleren Tests werden bei jedem Build durchlaufen. Die zeitlich anspruchsvolleren Tests werden nur einmal nächtlich oder manuell ausgeführt. Auf die unterschiedlichen Variationen von Tests wird im Folgenden eingegangen. Dieser Überblick enthält dabei nur die Tests, die für den Einsatz von CI relevant sind.

3.4.1 Compiler

Der erste und einfachste Test erfolgt durch den Compiler. Dieser statische Test ist einfach, da kein Implementierungsaufwand für den Entwickler besteht. Es ist jedoch festzulegen, wie mit Warnungen des Compilers umgegangen werden soll. In der Praxis hat es sich etabliert, dass bereits bei einer Warnung des Compilers der Build abbricht [Wies11, S.37]. Die Voraussetzung für den Compiler-Test ist eine kompilierbare Programmiersprache. Andernfalls kann nur die Syntax der Programmiersprache geprüft werden.

Besonders bei Programmiersprachen, für die Entwicklungsumgebungen mit hoher Unterstützung existieren, treten beim Kompilieren selten Fehler auf, da die Entwicklungsumgebung den Entwickler bereits auf Fehler hinweist. Bei Programmiersprachen mit geringer Unterstützung der Entwicklungsumgebung ist das erfolgreiche Kompilieren hingegen eine wichtige Überprüfung.

3.4.2 Unit-Tests

Die Unit-Tests (auch Modultests genannt) testen funktionale Einzelteile einer Software. Sie müssen vom Entwickler erstellt werden. Dieser muss bereits bei der Erstellung der Software darauf achten, dass der Code durch Unit-Tests überprüfbar ist. Dazu müssen Schnittstellen zwischen den Modulen klar definiert sein, damit diese durch Mocks4 ersetzt werden können. Da nur das Modul getestet wird und die Schnittstellen nicht tatsächlich angesprochen werden, haben diese Tests in der Regel eine kurze Laufzeit. Daher werden sie oftmals im Anschluss an das Kompilieren ausgeführt.

Der Ablauf eines Unit-Tests lässt sich in drei Phasen unterteilen. Zunächst wird die gewünschte Situation bzw. Datenkonstellation initialisiert. Im zweiten Schritt wird das Modul oder Teile des Moduls durchlaufen, um die Datenkonstellation zu verändern. In der letzten Phase werden die im Unit-Test erwarteten Daten mit den im Ablauf ermittelten Daten verglichen. Es ist auch möglich, dass im Unit-Test nur definiert wird, welche Datenkonstellation als Ergebnis unzulässig ist. Dann schlägt der Test fehl, falls diese Datenkonstellation eintritt.

4 Ein Mock-Objekt bildet das Verhalten eines realen Objektes nach [vgl. ItWi16].



3.4.3 Systemtest

Der Systemtest testet die gesamte Software. Der Test erfolgt in der Integrationsumgebung mit anonymisierten Produktionsdaten und wird deshalb auch Integrationstest genannt. Beim Systemtest werden die gleichen Schnittstellen wie im Produktionssystem verwendet. In der OLB wurde unabhängig von dem Einsatz eines CI-Systems geprüft, wie ein Systemtest automatisiert werden kann. Dabei wird zwischen Anwendungen mit grafischer Benutzeroberfläche und Batchanwendungen unterschieden. Die erarbeiteten Vorgehensweisen und festgestellten Probleme der Automatisierung des Systemtests werden im Folgenden erläutert.

Für eine Software mit grafischer Benutzeroberfläche bedeutet der Systemtest, dass die Funktionalitäten der Oberfläche vollständig getestet werden. Mit vollständig ist gemeint, dass alle Funktionalitäten der Oberfläche getestet werden, aber auch alle erdenklichen möglichen Eingaben eines Anwenders. Sollte der Anwender beispielsweise in ein nummerisches Feld einen Buchstaben eingeben, muss die definierte Fehlermeldung angezeigt werden. Um den Test einer grafischen Oberfläche automatisieren zu können, werden Tools wie z.B. Selenium5 benötigt. Generell ist der Oberflächentest kritisch zu betrachten, da die theoretische Vorgehensweise nur schwer in die Praxis umgesetzt werden kann. Das liegt zum einen an den vielen Möglichkeiten, wie ein User das gewünschte Ergebnis in der Oberfläche erreichen kann. Er kann sich beispielsweise nur mit der Tastatur durch eine Eingabemaske bewegen, aber auch die Maus benutzen, um die Eingabefelder zu wechseln. Dabei könnte die Oberfläche unterschiedlich reagieren und es müssten beide Möglichkeiten durch Tests abgedeckt werden. Zum anderen müssen die jeweiligen Eingabe- und Aktionselemente vom Tool erkannt werden. Dies erfolgt entweder über Positionsangaben, die sich bei nahezu jeder Änderung der Oberfläche ändern oder über die Erkennung durch IDs. Diese werden von vielen Oberflächenframeworks zur Laufzeit zufällig generiert und eignen sich daher häufig nicht zur Erkennung der Elemente. Es können jedoch die Schnittstellen getestet werden, die in der Oberfläche verwendet werden. Dazu müssen die Schnittstellen so implementiert sein, dass die Anwendungslogik und die Datenvalidierung von diesen bereitgestellt werden und nicht nur in der Oberfläche umgesetzt sind. Anders als im Unit-Test werden hier alle Schnittstellen tatsächlich angesprochen und nicht durch Mocks ersetzt.

Bei einer Batch-Anwendung wird beim Systemtest der gesamte Datenbestand testweise verarbeitet. So können alle Konstellationen getestet werden, die auch in der Produktionsumgebung vorhanden sind. Sofern immer aktuelle, anonymisierte Daten aus der Produktionsumgebung verwendet werden, kann das Gesamtergebnis nur mit unverhältnismäßig hohem Aufwand prognostiziert werden. Um mit diesem Problem umzugehen, existieren zwei Möglichkeiten.

Zum einen kann immer derselbe Datenbestand für den Test herangezogen werden. Das hat den Vorteil, dass die erwarteten Ergebnisse nur einmal festgelegt werden müssen und immer wieder nach dem Testdurchlauf zur Überprüfung herangezogen werden können. Nachteilig ist jedoch, dass Datenkonstellationen, die neu im Produktionssystem auftreten, erst durch den Anwender dort getestet werden.

Die zweite Möglichkeit ist, dass immer mit aktuellen Daten aus der Produktionsumgebung (in der Integrationsumgebung) getestet wird. Dazu ist es erforderlich, den Datenexport in die Integrationsumgebung, sowie die Anonymisierung dieser Daten zu automatisieren, sodass dieser Prozess bei Bedarf nur gestartet werden muss. Damit nicht immer alle erwarteten Ergebnisse festgelegt werden müssen, sollte eine hinreichend große Stichprobe zur Prüfung

5 Testumgebung für Webanwendungen der Firma ThoughtWorks



herangezogen werden. Um dies zu automatisieren, müssen Kriterien für Testfälle festgelegt werden, die in den Datenkonstellationen vor dem Test vorliegen müssen. Für die definierten Eingangskriterien müssen erwartete Ergebnisse für den Abgleich festgelegt werden. Um die Testfälle richtig zuordnen zu können, müssen diese anhand einer eindeutigen Identifikation identifizierbar sein. Dabei ist sicherzustellen, dass für neue Datenkonstellationen in der Produktionsumgebung weitere Testfälle erstellt werden. Aber selbst wenn kein weiterer Testfall erstellt wird, wird diese Datenkonstellation bereits im Integrationssystem verarbeitet. Damit wird sichergestellt, dass diese Datenkonstellation in der Produktionsumgebung nicht zu Programmabbrüchen führt. Aus diesem Grund ist diese Möglichkeit zur Beschaffung der Testdaten zu bevorzugen.

Aufgrund des vollumfänglichen Tests des Systems dauert dieser Test im Verhältnis zum Compiler- und Unit-Test länger.

Im Gegensatz zum Unit-Test wird der Systemtest nicht vom Entwickler selbst erstellt. Er wird in der Regel durch den Auftraggeber oder durch den Systemverantwortlichen in der Fachabteilung erstellt. Für die Automatisierung des Tests ist ggf. die Unterstützung des Entwicklers notwendig.

3.5 Build-Intervall

In diesem Kapitel wird die Frage diskutiert, wann bzw. wie häufig ein Build-Prozess gestartet werden sollte. Dazu erfolgt zunächst eine Übersicht über die Möglichkeiten zum Starten eines Builds und anschließend werden Kriterien zur Unterstützung zur Festlegung des optimalen Build-Intervalls entwickelt.

Start des Build-Prozesses

Ein Build-Prozess lässt sich entweder manuell oder automatisiert starten. Der manuelle Start eines Build-Prozesses muss durch einen Entwickler in der Oberfläche des CI-Systems ausgelöst werden oder durch den Aufruf einer Schnittstelle des CI-Systems. Für das automatisierte Starten können verschiedene Ereignisse definiert werden. Diese unterschiedlichen Ereignisse schließen sich nicht gegenseitig aus.

Build-Prozesse können zeitgesteuert gestartet werden. Dazu muss der Startzeitpunkt im CI-Server für den Build-Prozess festgelegt werden. Damit ist es möglich, dass beispielweise jede Stunde oder jeden Tag der Build-Prozess gestartet wird.

Ebenfalls ist es möglich, dass durch das Einchecken von Änderungen im Versionskontrollsystem ein Build-Prozess gestartet wird. Der CI-Server prüft dabei in festgelegten Zeitabständen, ob Änderungen vorgenommen wurden. Manche Versionskontrollsysteme, wie zum Beispiel Subversion, bieten die Möglichkeit von Post-Commit-Operationen. Diese Operationen werden unmittelbar nach dem Einchecken einer Änderung ausgeführt. Über eine Schnittstelle des CI-Servers kann der Build-Prozess, durch die Operation des Versionskontrollsystems gestartet werden.

Festlegen des optimalen Build-Intervalls

Das Build-Intervall legt fest, wann bzw. wie häufig der Build-Prozess durchlaufen werden soll. Ein optimales Intervall ist dabei stark abhängig von der Software und ihrer Entwicklung. Entwickeln mehrere Entwickler eine Software gemeinsam, sollte häufiger der Build-Prozess durchlaufen werden, als wenn ein Entwickler alleine eine Software entwickelt. Umso mehr Änderungen durchgeführt wurden, desto schwerer ist es im Fehlerfall nachzuvollziehen, durch welche Änderungen der Fehler ausgelöst wurde.



Das Build-Intervall kann zwischen der Ausführung des Build-Prozesses nach jeder Änderung im Versionskontrollsystem bis hin zur einmal nächtlichen Ausführung variieren. Es ergeben sich unterschiedliche Vor- und Nachteile aus den Variationen. Wird der Build nach jeder Änderung ausgeführt, so kann jeder Fehler einer Änderung direkt zugeordnet werden und der zuständige Entwickler kann den Fehler umgehend beheben. In der Praxis kann dies jedoch bei hoher Änderungsfrequenz und langer Build-Zeit zu einem enormen Rückstau an Builds führen [Wies11, S.38]. Wird der Build dagegen nur einmal nächtlich ausgeführt, stört eine längere Laufzeit nicht, da die Entwickler erst am nächsten Morgen die Ergebnisse des Builds einsehen. Wurden jedoch mehrere Änderungen durchgeführt und es tritt ein Fehler beim Build auf, lässt sich dieser nicht mehr direkt auf eine Änderung zurückführen. Unter Abwägung der Vor- und Nachteile muss daher ein Kompromiss aus beiden Varianten gefunden werden.

Dazu müssen die Schritte des Build-Prozesses analysiert werden und überprüft werden, welche Phasen am längsten dauern. Diese Schritte beziehen sich dabei auf die Abbildung 3.3 auf der Seite 7. Es lässt sich keine Aussage treffen, die für alle Build-Prozesse gültig ist. Für die meisten Build-Prozesse wird die beschriebene Vorgehensweise jedoch zutreffen.

In der Regel sind die Tests, die während des Build-Prozesses durchlaufen werden, die Schritte, die verhältnismäßig viel Zeit in Anspruch nehmen. Vor allem der Systemtest nimmt besonders viel Zeit in Anspruch. Daher sollte dieser automatisiert nur nächtlich ausgeführt werden. Sollte es während des Tages erforderlich sein, den Systemtest in einem Build-Prozess zu durchlaufen, muss dieser manuell gestartet werden.

Daraus ergibt sich, dass der Build-Prozess nächtlich vollständig durchlaufen werden sollte und während des Tages der Systemtest ausschließlich manuell gestartet wird. Das genaue Intervall für die Build-Prozesse hängt auch von der Laufzeit des Builds ab. Also muss beim automatisierten Start durch Änderungen im Versionskontrollsystem geprüft werden, wann der letzte Build-Prozess gestartet wurde. Wurde dieser kürzlich gestartet, sollte der zweite Build-Prozess nicht ausgeführt werden. Die durchgeführten Änderungen werden dann erst mit der nächsten Änderung im Versionskontrollsystem vom CI-System verarbeitet.

3.6 Zugriff auf Build-Ergebnisse

Im Regelfall müssen die Build-Ergebnisse nur eingesehen werden, wenn der Build-Prozess fehlgeschlagen ist. Nur in diesem Fall soll der CI-Server aktiv benachrichtigen. Diese Benachrichtigung wird nur an die Entwickler versandt, die Änderungen ins Versionskontrollsystem eingecheckt haben. Die Benachrichtigung kann dabei auf unterschiedliche Weise erfolgen, wie zum Beispiel per E-Mail-Versand, dem Erstellen eines Tickets in einem Ticketsystem oder eine Nachricht in der Entwicklungsumgebung.

Wenn die Ergebnisse eines erfolgreichen Builds eingesehen werden sollen, erfolgt der Zugriff über die Weboberfläche des CI-Servers. Über diese können die Entwickler unter anderem nachvollziehen, welche Änderungen von anderen Entwicklern durchgeführt wurden und ob es dabei zu Problemen kam.

Die anderen Projektbeteiligten, wie der Projektleiter und die Tester in der Fachabteilung, haben häufig nur indirekt Interesse an den Build-Ergebnissen. Für sie ist relevant, welche Anforderungen umgesetzt wurden und ob diese in der erstellten Version getestet werden können. Da diese Anforderungen in der Regel in einem Ticketsystem erfasst werden, das über Schnittstellen mit dem CI-System verbunden ist, können sie anhand des Ticketstatus erkennen, ob die jeweilige Anforderung umgesetzt wurde.

VWA Leer e.V. 13 Ist-Zustand


4 Ist-Zustand In diesem Kapitel wird auf den aktuellen Softwareentwicklungsprozess der OLB eingegangen. Dazu wird dieser zunächst in Form eines Aktivitätsdiagramms dargestellt und beschrieben. Im darauffolgenden Abschnitt wird das System beschrieben, das den Softwareentwicklungsprozess hauptsächlich unterstützt. Danach erfolgt eine Systemübersicht über alle Systeme, die im Kontext der Softwareentwicklung verwendet werden. Abschließend wird der Verbesserungsbedarf des Ist-Zustandes beschrieben.

4.1 Softwareentwicklungsprozess

Der in der Abbildung 4.1 dargestellte Prozess verdeutlicht die Arbeitsweise in der Softwareentwicklung in der OLB. Eine Beschreibung der Systeme, die den Anwender in diesem Prozess unterstützen, folgt in den darauffolgenden Abschnitten.

Wenn eine Änderung an einer bestehenden Anwendung vorgenommen oder eine neue Anwendung entwickelt werden soll, muss durch die zuständige Fachabteilung ein Antrag zur Umsetzung dieser Anforderung angelegt werden. Die Anlage erfolgt in dem System „Platon“, das im Kapitel 4.2 genauer beschrieben wird. Danach müssen die Anforderungen im Antrag definiert werden. Der Antrag muss über Platon bei der IT eingereicht werden.

Der zuständige Teamleiter, dessen Team die Anwendung betreut, prüft den Antrag. Diese Prüfung kann er auch an einen Entwickler delegieren. Bei der Prüfung wird festgestellt, ob die Anforderungen technisch umsetzbar sind. Sollten diese nicht umsetzbar sein, wird der Antrag abgelehnt. Sofern die Anforderungen nur unvollständig oder unverständlich beschrieben wurden, wird der Antrag zur Nachbearbeitung an die Fachabteilung zurückgegeben. Werden keine Probleme bei der Prüfung des Antrages festgestellt, wird ein Zieltermin für die Umsetzung angegeben. Dabei ist die Arbeitsbelastung der Entwickler durch andere Tätigkeiten zu berücksichtigen. Anschließend wird für jeden Entwickler, der Anforderungen des Antrages umsetzen soll, ein Auftrag mit seinen Arbeitsanweisungen erstellt.

Sobald der Entwickler Zeit für die Umsetzung des Auftrages hat, beginnt er damit, den Auftrag umzusetzen und legt das Testverfahren des Auftrages fest. Wenn er die Anforderungen vollständig umgesetzt hat und seine Änderungen selbst getestet hat, fügt er die Anwendung aus ihren Komponenten lokal auf seinem Computer zusammen. Dadurch erzeugt er eine Version, die er in die Integrationsumgebung übergibt. Dann versendet er die Freigabeaufforderung an den Prüfer, der vom ausgewählten Testverfahren abhängig ist. Auf die möglichen Testverfahren wird in Kapitel 4.2 näher eingegangen. Der Prüfer testet die durchgeführten Änderungen bzw. bei größeren Änderungen die geänderte Komponente oder die gesamte Anwendung. Sollte es während des Tests zu Fehlern kommen, gibt er den Auftrag zur Nachbesserung an den Entwickler zurück.

Sofern keine Probleme beim Test aufgetreten sind, gibt er den Auftrag frei. Der Entwickler wird über die Freigabe informiert und übergibt die Änderungen in die Produktionsumgebung. Somit ist die Anforderung vollständig umgesetzt und produktiv im Einsatz.



Abbildung 4.1: Softwareentwicklungsprozess



4.2 Softwareentwicklungssystem

Die OLB betreibt ein selbsterstelltes System, das bei der Organisation der Softwareentwicklung unterstützt und sicherstellt, dass die gesetzlichen Anforderungen an die Softwareentwicklung in Banken eingehalten werden. Dieses System heißt Platon. Die Funktionalitäten werden im Folgenden erläutert.

Antrags- und Auftragsverwaltung

Platon bietet Funktionalitäten zur Antrags- und Auftragsverwaltung. Die Anträge und Aufträge müssen immer einer Anwendung zugeordnet werden.

Ein Antrag wird von der Fachabteilung in Platon erfasst, wenn Anforderungen durch die IT umgesetzt werden sollen. Die Bearbeitung der Anträge erfolgt in der IT. Diese lehnt die Anträge ab oder erstellt zu den Anträgen die Aufträge für die jeweiligen Entwickler. Durch die Auftragserstellung gilt der Antrag als angenommen.

Die Aufträge sind die Arbeitsgrundlage der Entwickler. Aus diesen entnehmen sie die genauen Arbeitsanweisungen. Sind aufgrund der Zuständigkeiten zwei Entwickler mit der Umsetzung des Antrages befasst, so wird für beide ein eigener Auftrag erstellt und mit dem Antrag verknüpft. Wenn mit einem Auftrag mehrere Anträge umgesetzt werden, kann der Auftrag weiteren Anträgen zugeordnet werden.

Daraus ergibt sich die Beziehungssicht der Abbildung 4.2 zwischen Anträgen und Aufträgen.

Abbildung 4.2: Beziehungssicht Antrag - Auftrag

Zu einem Antrag wird erst ein Auftrag erstellt, wenn der Antrag zur Umsetzung angenommen wurde. Daher gibt es Anträge ohne Aufträge. Ein Auftrag bezieht sich immer auf mindestens einen Antrag.

Alle Anträge und Aufträge, die jemals in Platon erfasst wurden, können über die Suche oder über die Detailansicht der jeweiligen Anwendung aufgerufen werden. Es werden alle Daten der Anträge und Aufträge dauerhaft gespeichert.

Rollenkonzept

Damit nicht jeder Mitarbeiter der OLB Anwendungen in Platon erstellen, Aufträge erteilen oder andere Funktionen der Anwendung nutzen kann, gibt es in Platon verschiedene Rollen im Entwicklungsbereich. Damit Anträge eingereicht werden können, muss zunächst eine Anwendung in Platon angelegt werden. Die Anlage erfolgt durch Mitarbeiter mit der Rolle „IT Teamleiter“. Ein Teamleiter erhält ebenfalls Änderungsanträge, die durch den Fachbereich erfasst wurden. Die Änderungsanträge leitet der Teamleiter entsprechend der freien Kapazitäten an die jeweiligen Mitarbeiter zur Umsetzung weiter. Diese Mitarbeiter haben die Rolle „Entwickler“. Sie erhalten durch diese Rolle für die jeweilige Anwendung Zugriff auf die Archive im Versionskontrollsystem und die Berechtigung Aufträge zu bearbeiten. Die letzte für den Entwicklungsbereich relevante Rolle ist der „Fachprüfer“. Dieser erstellt Anträge und prüft diese im Rahmen der Produktionsfreigabe.



Informationen zu allen Anwendungen und IT-Systemen

In Platon werden alle Anwendungen der OLB geführt. Da die Softwareübergabe in die Integration und Produktion über Platon erfolgt, ist sichergestellt, dass nur Anwendungen in den Integrativ- und Produktivbetrieb gelangen, wenn diese in Platon existieren. Dies gilt sowohl für selbst erstellte Software, als auch für Fremdsoftware.

Zu jeder Anwendung wird festgelegt, welche Schnittstellen und IT-Systeme sie benutzt. Unter Schnittstellen werden dabei lesende und schreibende Zugriffe auf andere Anwendungen gefasst. Dazu definiert der Entwickler, der Anwendung auf die zugegriffen werden soll, eine Schnittstelle in Platon. Der Entwickler der anderen Anwendung legt in Platon bei seiner Anwendung fest, dass er diese Schnittstelle benutzt. Dadurch sind alle Schnittstellen dokumentiert und es lässt sich jederzeit eine aktuelle Systemsicht generieren. Diese Verknüpfung erfolgt auch zu den IT-Systemen, auf denen die Anwendung abläuft oder die sie benutzt. Diese IT-Systeme werden ebenfalls in Platon gepflegt. Zur Kategorisierung dienen verschiedene Systemarten, wie beispielsweise DB-Schema oder Ablaufserver. Zur Veranschaulichung dient die Abbildung 4.3. Sie zeigt die Anwendung „Kompetenzmodul“ mit ihren Schnittstellen zu anderen Anwendungen und die verwendeten IT-Systeme.

Abbildung 4.3: Platon-Systemsicht für die Anwendung „Kompetenzmodul“



Schutzbedarf und Schutzfestlegung

Jedes IT-System in der OLB hat eine Schutzfestlegung im Hinblick auf die Leistungsfähigkeit der Schutzziele. Die Schutzziele sind Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität. Die Festlegung der Leistungsfähigkeit erfolgt durch den zuständigen Systemadministrator anhand eines Prüfschemas.

Durch die Schutzfestlegung kann ein Abgleich zwischen diesem und dem Schutzbedarf erfolgen. Der Schutzbedarf wird durch die Fachabteilung an der jeweiligen Anwendung festgelegt. Ergeben sich beim regelmäßigen Abgleich negative Abweichungen (Schutzbedarf höher als existenter Schutz), wird das Security-Management informiert. Die Mitarbeiter des Security-Managements stellen sicher, dass die Abweichungen unverzüglich beseitigt werden.

Dokumentation

Für jede Anwendung müssen die notwendigen Dokumentationen hinterlegt werden. Ein automatisierter Lauf prüft regelmäßig das Vorhandensein der Dokumente. So kann sichergestellt werden, dass alle regulatorisch notwendigen Dokumente vorhanden sind. Unter diese Dokumentation fallen beispielsweise das Fachkonzept und das Anwenderhandbuch.

Testverfahren

Um einen reibungslosen Produktionsbetrieb sicherzustellen, muss jede Neuentwicklung und jede Änderung vor dem Produktionseinsatz getestet werden. Um den laufenden Betrieb nicht zu gefährden oder zu stören, erfolgen diese Tests in der Integrationsumgebung. Die Tests werden nach unterschiedlichen Testverfahren durchgeführt. Die Festlegung des Testverfahrens für einen Auftrag erfolgt nach der Sichtung und Beurteilung des Auftrages durch den Entwickler. Für den Entwicklungsbereich sind die vier folgenden Testverfahren vorgesehen:

4-Augen-IT: Wurden zur Umsetzung des Auftrages nur Bagatelländerungen durchgeführt, die durch den Fachbereich nicht sinnvoll testbar sind, können die Änderungen durch einen weiteren Entwickler geprüft und freigegeben werden. Eine mögliche Änderung ist beispielweise die Anpassung der Datenbankkonfiguration nach einem Update des Datenbankmanagementsystems.

4-Augen-Fachbereich: Wurden zur Umsetzung des Auftrages nur Bagatelländerungen durchgeführt, die durch den Fachbereich testbar sind, können die Änderungen durch einen Mitarbeiter der Fachabteilung geprüft und freigegeben werden. Eine mögliche Änderung ist beispielweise die Anpassung von Hilfetexten in der Anwendung.

Komponententest: Wurde eine Anwendung um eine Komponente erweitert oder in einem klar abgrenzbarem Teil einer Komponente erhebliche Änderungen vorgenommen, muss die gesamte Komponente durch einen Mitarbeiter der Fachabteilung geprüft und freigegeben werden. Eine mögliche Erweiterung um eine Komponente wäre zum Beispiel die Erstellung einer Weboberfläche zur Einsicht von Daten, die in der Batchverarbeitung der Anwendung ermittelt werden.

Volltest: Wurden erhebliche Änderungen an einer Anwendung vorgenommen, bei denen davon ausgegangen werden muss, dass diese sich in nahezu allen Komponenten der Anwendung auswirken, muss ein Mitarbeiter der Fachabteilung die gesamte Anwendung prüfen und freigeben. Dies ist ebenfalls der Fall, wenn eine komplett neue Anwendung entwickelt wurde.

Die Auswahl des passenden Testverfahrens wird regelmäßig im Stichprobenverfahren durch die Revisionsabteilung geprüft.



Produktionsfreigabe

Wenn der Entwickler die Anforderungen eines Auftrags umgesetzt und das Testverfahren festgelegt hat, versendet er eine Freigabeaufforderung. Der Entwickler kann den Mitarbeiter auswählen, der die Umsetzung prüfen soll. Die mögliche Auswahl ergibt sich aus den für die Anwendung zuständigen Mitarbeitern und dem ausgewählten Testverfahren. Nach dem Versenden der Freigabeaufforderung kann keine weitere Änderung der Software mit dem Auftrag übergeben werden.

Der ausgewählte Mitarbeiter erhält eine E-Mail, dass ein Auftrag zur Prüfung bereitsteht. Die Durchführung des Tests wird in den Testunterlagen dokumentiert und diese am Auftrag gespeichert. Danach wird der Auftrag freigegeben. Sollte es zu einem Fehler bei dem Test der Anwendung kommen, wird der Auftrag an den Entwickler zurückgegeben. Dieser behebt den Fehler und versendet die Freigabeaufforderung erneut.

Systemumgebungen und Softwareübergabe

Neben dem eigenen Anspruch und der betriebswirtschaftlichen Notwendigkeit, Software störungsfrei zu betreiben, fordert dies auch die MaRisk6. Dort steht unter AT7 7.2 3.:

„Die IT-Systeme sind vor ihrem erstmaligen Einsatz und nach wesentlichen Veränderungen zu testen und von den fachlich sowie auch von den technisch zuständigen Mitarbeitern abzunehmen. Hierfür ist ein Regelprozess der Entwicklung, des Testens, der Freigabe und der Implementierung in die Produktionsprozesse zu etablieren. Produktions- und Testumgebung sind dabei grundsätzlich voneinander zu trennen.“ [MaRi16]

Die Trennung in der OLB erfolgt dabei in die Entwicklungs-, die Integrations- und die Produktionsumgebung. Diese Umgebungen werden in der Abbildung 4.4 im Zusammenhang mit dem Verlauf der Softwareentwicklung schematisch dargestellt.

Abbildung 4.4: Verlauf der Softwareentwicklung

Auf die Entwicklungsumgebung kann der Entwickler direkt zugreifen. Er kann Programme in dieser Umgebung direkt ändern oder dorthin übertragen. Der Entwicklungsserver ist wie der Integrations- und der Produktionsserver konfiguriert.

Auf die Integrationsumgebung hat der Entwickler keinen direkten Zugriff. Bevor er über Platon die Software in die Integrationsumgebung übertragen kann, muss er diese in das Versionskontrollsystem einchecken. Danach wählt er in Platon explizit aus, was er übertragen

6 Mindestanforderungen an das Risikomanagement von Kreditinstituten und Finanzdienstleistungsunternehmen 7 Allgemeiner Teil



möchte. Dazu sind in Platon die möglichen Quellen (Archive im Versionskontrollsystem) mit den Ablaufverzeichnissen der jeweiligen Integrations- und Produktionsserver verknüpft. Dadurch ist sichergestellt, dass nur Software übergeben werden kann, die im Versionskontrollsystem vorhanden ist. Ebenfalls ist sichergestellt, dass die Software nur auf den festgelegten Servern an den definierten Pfaden im Ablaufbetriebssystem abgelegt und zur Verwendung bereitgestellt wird. Die Verknüpfung der Quellen mit den Servern erfolgt durch einen Systemadministrator nach der Beauftragung durch den Entwickler.

Da alle Informationen zur Softwareübergabe in Platon hinterlegt sind, kann der Entwickler die Softwareübergabe allein ausführen. Es ist kein Eingriff durch die Produktion notwendig. Dies entlastet die Produktion und stellt durch den standardisierten Prozess sicher, dass es nicht zu Fehlern kommt.

4.3 Systeme im Softwareentwicklungsprozess

Die Abbildung 4.5 zeigt die Systeme, die im Softwareentwicklungsprozess aktuell verwendet werden.

Abbildung 4.5: Systeme im Softwareentwicklungsprozess (Ist-Zustand)

Neben dem System Platon, das im Kapitel 4.2 beschrieben wurde, werden zwei weitere Systeme zur Softwareentwicklung eingesetzt. Diese beiden Systeme werden im Folgenden beschrieben.

Entwicklungsumgebung

Die Entwicklungsumgebung vereint die wichtigsten Werkzeuge zur Software-Entwicklung in einem Programm. Diese sind der Texteditor mit Syntaxhervorhebung und der Quellcodeformatierung, sowie der Compiler. Des Weiteren stellt die Entwicklungsumgebung eine Schnittstelle zum Versionskontrollsystem bereit. Ebenfalls bietet die Entwicklungsumgebung einen deutlich höheren Komfort als die Benutzung eines einfachen Texteditors. Sie fasst Arbeitsschritte zusammen und macht diese durch einen Klick oder ein Tastenkürzel ausführbar. [vgl. Heis16]

In der OLB wird Eclipse als Entwicklungsumgebung für Java-Programme eingesetzt. Neben der Bearbeitung des Quellcodes, fügt der Entwickler in Eclipse auch die Anwendung aus ihren Komponenten zusammen. Die Schnittstelle zum Versionskontrollsystem wird verwendet, um den Quellcode, Skripte, sowie die gebauten Anwendungen dort abzulegen.

Versionskontrollsystem

Die Funktionalitäten eines Versionskontrollsystems sind dem Kapitel 3.2 zu entnehmen. In der OLB kommt Subversion (SVN) als Versionskontrollsystem zum Einsatz. Für jede



Anwendung wird ein Archiv im SVN bereitgestellt. Innerhalb dieser Archive erfolgt die Strukturierung durch die Anlage von Ordnern, wie in einem Dateisystem. Die Archive werden von den Entwicklern selbst strukturiert. Im Java Entwicklungsumfeld hat sich die folgende Struktur etabliert:

Projects: Enthält den Quellcode der einzelnen Komponenten einer Anwendung, die in der Entwicklungsumgebung auch als Projekte bezeichnet werden.

DB: Enthält alle Skripte und Statements zur Erzeugung der Datenbanktabellen.

Batch: Enthält alle Skripte, die zur automatisierten Ausführung der Anwendung benötigt werden, sowie die Anwendung selbst, sofern es sich um eine Batchanwendung handelt.

Web: Enthält alle Skripte, die zum Starten und Stoppen, sowie der Konfiguration des Servers benötigt werden und die Anwendung selbst, sofern es sich um eine Webanwendung handelt.

Da die Anwendung mit ihren dazugehörigen Konfigurationen in Form eines zip-Archives übergeben wird, sind in den Ordnern Batch und Web ebenfalls Skripte zum Entpacken der Anwendung enthalten.

Das Konzept von Subversion sieht vor, dass verschiedene Versionen einer Datei parallel zu einander gespeichert werden können. Diese verschiedenen Versionen werden wie folgt kategorisiert:

Trunk: Der Trunk ist die Hauptentwicklungslinie einer Anwendung.

Branch: Der Branch ist eine separate Entwicklungslinie für neue Funktionalitäten, damit die Hauptentwicklungslinie im Ursprungszustand bleibt, falls der Quellcode aufgrund von Fehlern angepasst werden muss. Nach Fertigstellung der Funktionalität werden die geänderten Dateien wieder in den Trunk eingefügt. Es können beliebig viele Branches gleichzeitig erstellt werden.

Tag: Ein Tag bietet die Möglichkeit, die Version einer Anwendung zu markieren. So kann beispielweise bei der Veröffentlichung einer neuen Version einer Software der enthaltene Quellcode als Tag markiert werden. Dadurch ist es möglich auf einen Blick zu erkennen, welche Versionen der Quellcode-Dateien in der Version der Software verwendet werden.

In SVN bezieht sich die Versionsnummer von Inhalten des Versionskontrollsystems nicht auf einzelne Dateien, sondern auf das ganze Projektarchiv. Dieses bekommt bei jeder Änderung eine neue „Revisionsnummer“ zugeordnet. [vgl. Apac16]

Über eine Schnittstelle kann Platon lesend auf Subversion zugreifen. Dadurch können in Platon die Dateien ausgewählt werden, die in die Integrations- bzw. Produktionsumgebung übergeben werden sollen. Diese werden dann aus Subversion an die in Platon hinterlegten Zielsysteme übertragen.

4.4 Verbesserungsbedarf

In diesem Kapitel wird der Verbesserungsbedarf des Ist-Zustandes beschrieben. Dieser wird unterteilt in technischen und organisatorischen Verbesserungsbedarf.



4.4.1 Technischer Verbesserungsbedarf

Zusammenfügen der Anwendung

Soll eine Programmversion in die Integrationsumgebung übergeben werden, so muss diese zunächst erstellt werden. Das Zusammenfügen der Komponenten erfolgt lokal auf dem Computer eines Entwicklers. Wird dieser Vorgang bei der nächsten Version auf dem Computer eines anderen Entwicklers mit einer geringfügig anderen Konfiguration durchgeführt, können sich große Abweichungen ergeben. Des Weiteren ist nicht sichergestellt, dass nur der Quellcode in den Build eingeht, der im Versionskontrollsystem vorhanden ist. Dies kann ebenfalls zu Abweichungen der Builds von verschiedenen Entwicklern führen.

Probleme bei der Nachvollziehbarkeit von übergebenem Quellcode

Wie im Kapitel 4.2 beschrieben, erfolgt bei der Entwicklung mit Java die Übergabe über Platon als zip-Archiv mit dem bereits kompilierten Quellcode. Dadurch kann der Prüfer, insbesondere bei dem Testverfahren „4-Augen-IT“, nicht einsehen, welche Änderungen tatsächlich vorgenommen wurden. Er kann nur den Quellcode im Versionskontrollsystem mit der Vorversion vergleichen und die Anwendung in der Integrationsumgebung testen. Es ist nicht sichergestellt, dass alle Quellcodeänderungen tatsächlich eingecheckt wurden.

Einhaltung der Programmierrichtlinien

Programmierrichtlinien sind Vorgaben zur Strukturierung des Quellcodes. Sie dienen dazu, die Verständlichkeit des Quellcodes zu erhöhen. Dadurch können Entwickler, insbesondere die, die den Quellcode nicht selbst geschrieben haben, diesen schneller verstehen und effizienter Änderungen vornehmen. Daraus ergibt sich, dass diese Vorgaben ebenfalls die Wartbarkeit der Software erhöhen.

In der OLB wird die Einhaltung der aufgestellten Programmierrichtlinien technisch nicht unterstützt oder geprüft. Die Prüfung erfolgt stichprobenweise in Form eines Code-Reviews durch einen anderen Entwickler. Die Stichproben ermittelt Platon zufallsbasiert. Durch die mangelnde technische Unterstützung werden nicht alle Änderungen der Prüfung unterzogen. Darunter leiden die beiden oben genannten Qualitätsziele – die Verständlichkeit und die Wartbarkeit des Quellcodes.

4.4.2 Organisatorischer Verbesserungsbedarf

Änderung der Anforderungen im laufenden Projekt

Bereits zu Beginn des Projektes müssen alle Anforderungen an ein System erarbeitet und strukturiert in einem Fachkonzept definiert werden. Häufig werden im Laufe des Projektes, auch noch nach der Fertigstellung des Fachkonzeptes, neue Erkenntnisse gewonnen, die Änderungen an den Systemanforderungen mit sich bringen. In der Implementierungsphase wird regelmäßig festgestellt, dass die zum Beginn des Projektes definierten Anforderungen nicht mehr in den Gesamtkontext aller Systeme in der OLB passen und somit die Prozesse, die die Anwendung unterstützen soll, geändert werden müssen.

Probleme aufgrund von zu großen Aufträge

In einem Antrag in Platon werden häufig viele Anforderungen zur Umsetzung beschrieben. Sofern mehrere Entwickler an der Bearbeitung beteiligt sind, erhält jeder Entwickler einen Auftrag mit den Anforderungen, die er umsetzen soll. Sofern ein Entwickler die Umsetzung seines Auftrages abgeschlossen hat und keine weiteren Aufträge für ihn zur Umsetzung

VWA Leer e.V. 22 Integration in den Softwareentwicklungsprozess


bereitstehen, werden Entwicklerkapazitäten nicht effektiv genutzt. Dies beruht auf zu großen Aufträgen, mit denen die Umsetzung von Anforderungen nicht flexibel auf andere Entwickler verteilt werden kann. Die zu großen Aufträge haben ebenfalls den Nachteil, dass sehr viel Quellcode geändert wird. Dadurch ist es nur sehr schwer möglich, einen Code-Review für den gesamten Auftrag durchzuführen und die Änderungen den Anforderungen zuzuordnen. Ein Code-Review ist von einem anderen Entwickler durchzuführen und sollte nicht mehr als die Prüfung von 400 Zeilen Code umfassen [Smar16]. Diese Grenze wird aufgrund der Auftragsgröße häufig überschritten.

5 Integration in den Softwareentwicklungsprozess Continuous Integration, als Methode des extreme programming, ist eine von vielen agilen Methoden. Es ist sinnvoll, neben CI weitere agile Methoden einzuführen, um die vollen Vorteile von CI nutzen zu können. Dabei beschränken sich agile Methoden nicht nur auf die Vorgehensweise des extreme programming. In diesem Kapitel wird der Einsatz von Continuous Integration in Kombination mit weiteren für die OLB passenden agilen Methoden verschiedener Vorgehensweisen beschrieben. Es sollen mehr agile Methoden im Softwareentwicklungsprozess eingesetzt werden, um die im Ist-Zustand beschriebene Situation zu verbessern. Dazu wird im ersten Abschnitt darauf eingegangen, was unter agilem Vorgehen zu verstehen ist. Danach wird eine Systemübersicht dargestellt, die alle Systeme des zukünftigen Entwicklungsprozesses enthält. Darauf folgt die Beschreibung des zukünftigen Entwicklungsprozesses unter der Einbeziehung von agilen Methoden.

Seitens der IT-Leitung wurde bereits entschieden, dass das CI-System Bamboo des Herstellers Atlassian eingesetzt werden soll. Der für die OLB relevante Funktionsumfang der in der Vorstudie betrachteten CI-Systeme ist identisch. Da in der OLB bereits weitere Produkte von Atlassian eingesetzt werden und diese über Standard-Schnittstellen miteinander verbunden werden können, wurde die Entscheidung für Bamboo getroffen. Dieses CI-System wurde bereits lizenziert. Das für den Einsatz notwendige Fachkonzept liefert diese Arbeit.

5.1 Agiles Vorgehen

Beim agilen Vorgehen soll auf Anforderungsänderungen während der Projektlaufzeit flexibel reagiert werden können. Dies wird durch möglichst häufige Softwareauslieferungen und darauf folgende Rückkopplungen erreicht. Diese Vorgehensweise unterscheidet sich stark von dem Wasserfallmodell nach Boehm. Beim Wasserfallmodell bedingt der Beginn der nächsten Phase den Abschluss der vorherigen Phase. Es müssen zunächst alle Anforderungen an ein System definiert sein, bevor die Implementierungsphase beginnt. Bei agilem Vorgehen werden nicht alle Einzelheiten eines Systems genau geplant. Es erfolgt eine genaue Definition der Anforderungen, die im nächsten Zyklus entwickelt werden sollen. Dieser Zyklus wird so lange wiederholt, bis das System alle Funktionalitäten bereitstellt, die von diesem System benötigt werden. Deshalb spricht man von einem zyklischen iterativen Vorgehen.

Abbildung 5.1: Systemeinsatz als Überprüfung (in Anlehnung an [Wolf11, S.9])



Die Abbildung 5.1 zeigt schematisch das agile Vorgehen und ist dabei als sich wiederholender Prozess zu sehen. In der Abbildung wird insbesondere auf die Prüfbarkeit des Softwareentwicklungsprozesses eingegangen. Die Geschäftsziele sollen mit der Verwendung des Systems erreicht werden. Es müssen Anforderungen an das System definiert werden, damit die Geschäftsziele erreicht werden können. Diese Anforderungen werden dann im System implementiert und können durch Tests geprüft werden. Dazu wird für jede Anforderung geprüft, ob diese im System wie beschrieben umgesetzt wurde. Ob die Geschäftsziele tatsächlich mit den Anforderungen erfüllt werden können, kann während der Definition der Anforderungen nur sehr schwer oder gar nicht geprüft werden. Deshalb wird, nach jeder Umsetzung einer Anforderung, das System produktiv eingesetzt, um zu prüfen ob das jeweilige Geschäftsziel erreicht wird.

Zusammenfassend lässt sich sagen, dass beim agilen Vorgehen ein System möglichst früh und häufig ausgeliefert werden sollte, damit regelmäßig eine Rückkopplung durch die Anwender erfolgt. Diese Rückkopplung fordert eine ehrliche und offene Kommunikation zwischen allen Projektbeteiligten. Wird offen und frühzeitig über Probleme des Systems oder der Anforderungen gesprochen, so können diese Probleme meistens schnell behoben werden. Die Projektbeteiligten lernen im Projektverlauf ständig hinzu. Vor allem lernen sie voneinander und können so gemeinsam die tatsächlichen Anforderungen und Bedürfnisse erkennen.

Da in einer Bank die Geschäftsziele, die mit einer Software erreicht werden sollen, häufig auf gesetzlichen Anforderungen beruhen, ist diese Vorgehensweise kritisch zu sehen. Sofern eine Anwendung produktiv eingesetzt wird, muss sichergestellt sein, dass die Anforderungen zu den Geschäftszielen passen und diese Anforderungen fehlerfrei umgesetzt wurden. Daher eignet sich der produktive Systemeinsatz nicht. Das frühe und häufige Ausliefern in die Integrationsumgebung bietet jedoch einen ähnlich hohen Nutzen. Dadurch erfolgt der Test nicht im Produktionsbetrieb durch die Anwender, sondern durch die Tester in der Integrationsumgebung. In dieser Umgebung ist es unproblematisch, wenn die Anforderungen die Geschäftsziele noch nicht vollständig erfüllen.

5.2 Systemübersicht

Die Abbildung 5.2 zeigt die Systeme, die zukünftig im Softwareentwicklungsprozess verwendet werden sollen.

Abbildung 5.2: Systeme im Softwareentwicklungsprozess (Soll-Zustand)



Die dargestellten Systeme sind, bis auf Platon, weit verbreitete Standardanwendungen. Die Schnittstellen zwischen diesen Systemen sind standardisiert und müssen lediglich konfiguriert werden. Diese Konfiguration kann anhand der herstellerseitigen Dokumentation erfolgen. Deshalb wird nicht auf die Konfiguration eingegangen, sondern der Fokus auf die Datenbeziehungen zwischen den Systemen gelegt.

Das Ticketsystem wurde bisher nicht im Softwareentwicklungsprozess verwendet. Daher erfolgt die Beschreibung des Ticketsystems im ersten Abschnitt. Darauf folgt die Darstellung der Datenbeziehungen. Auf dieser Grundlage werden die zu implementierenden Schnittstellen zwischen Platon und dem Ticketsystem beschrieben. Abschließend wird auf die Berechtigungen der Anwender in den Systemen eingegangen.

Ticketsystem

Ein Ticketsystem dient zur Verwaltung von zu bearbeitenden Vorgängen. Diese Vorgänge werden auch als Tickets bezeichnet. Das Ticketsystem sorgt für die Nachvollziehbarkeit der Bearbeitungswege von der Erstellung bis zur Lösung eines Tickets. Wird ein Ticket erstellt, so kann es einer anderen Person zur Bearbeitung zugewiesen werden. Anhand des Ticket-Status ist erkennbar, in welchem Zustand sich das Ticket befindet.

Im Rahmen des Softwareentwicklungsprozesses soll das Ticketsystem für die Definition der Anforderungen dienen und deren Umsetzung nachvollziehbar machen. In der OLB wird bereits das Ticketsystem „JIRA“ des Herstellers Atlassian eingesetzt. Dieses bietet Funktionalitäten und Schnittstellen, die zukünftig im Softwareentwicklungsprozess genutzt werden sollen.

In JIRA müssen Tickets einem Projekt zugeordnet werden. Für jede Anwendung in Platon wird ein Projekt in JIRA angelegt. Dadurch ist es bei der Antragsgenerierung möglich, das Ticket einer Anwendung zuzuordnen.

Damit erkannt werden kann, in welchem Zustand sich ein Ticket befindet, muss ein Ticketstatus vergeben werden. Dieser wird durch JIRA beim Ausführen einer Aktion geändert. Mögliche Aktionen sind zum Beispiel das Anlegen des Tickets (Status „Neu“) oder der Beginn ein Ticket zu bearbeiten (Status „In Arbeit“). Für die Entwicklung in der OLB reichen die Standard-Status von JIRA nicht aus. Daher ist es erforderlich, weitere Status zu ergänzen. Die für die OLB benötigten Status werden im Folgenden erläutert:

Neu: Das Ticket wurde neu erstellt.

Anforderungsprüfung: Das Ticket wurde der IT zur Überprüfung der Anforderungen zugewiesen.

Unvollständig: Bei der Prüfung seitens der IT wurde festgestellt, dass das Ticket unvollständig oder unverständlich ist.

Abgelehnt: Die Anforderungen des Tickets sind technisch oder sachlich nicht umsetzbar.

ToDo: Das Ticket wurde zur Umsetzung angenommen und wird bearbeitet, sobald freie Kapazitäten vorhanden sind.

In Arbeit: Das Ticket wird vom Entwickler umgesetzt.

Build fehlerhaft: Sollte der Build-Prozess mit den Änderungen abbrechen, die diesem Ticket zugehörig sind, wird dieser Status gesetzt.

Abnahmeprüfung: Die Freigabeaufforderung wurde versandt.

Wiedereröffnet: Die Anforderungen wurden unvollständig oder fehlerhaft umgesetzt.



Produktionsübergabe: Die Umsetzung des Tickets war korrekt und die Freigabeaufforderung erteilt. Es wird darauf gewartet, dass der Entwickler die Produktionsübergabe ausführt.

Behoben: Die Bearbeitung des Tickets ist vollständig abgeschlossen und die Software wurde in die Produktionsumgebung übergeben.

Um Tickets zu kategorisieren, wird jedem Ticket ein Typ zugeordnet. Die möglichen Typen sind:

Fehler: Fehler in der Anwendung, der behoben werden soll.

Neue Funktion: Neu zu implementierende Anwendungsfunktion.

Aufgabe: Aufgabe, die durch ein Projektmitglied ausgeführt werden soll.

Verbesserung: Verbesserung einer Funktionalität in der Anwendung.

Des Weiteren unterstützt JIRA, neben der einfachen Listenansicht von Tickets, auch Ansichten für agile Entwicklung.

Abbildung 5.3: Screenshot JIRA Agile Ansicht [Droo16]

Die Abbildung 5.3 zeigt ein Kanban8-Board, das von JIRA bereitgestellt wird. Die Tickets werden anhand ihres Status einer der Spalten zugeordnet. So kann übersichtlich dargestellt werden, welche Tickets im Iterationszyklus noch zu bearbeiten sind, welche abgeschlossen sind und welche Tickets sich in einem Zustand dazwischen befinden. Ein Ticket durchläuft die Spalten von links nach rechts. Der Screenshot in Abbildung 5.3 stammt nicht aus dem JIRA der OLB. Daher enthält dieser nicht die Ticket-Status der OLB. Die Ansicht kann jedoch in JIRA so konfiguriert werden, dass diese den Ticket-Status der OLB entsprechen.

8 Vorgehensmodell in der agilen Softwareentwicklung



Datenbeziehungen

Im gesamten Softwareentwicklungsprozess entstehen viele Daten, die in den verschiedenen Systemen abgelegt werden. Dabei handelt es sich häufig um IDs, die über die Schnittstellen ausgetauscht werden und auf die eigentlichen Daten referenzieren. In diesem Abschnitt soll anhand einer Matrix veranschaulicht werden, welche Daten in welchem System verfügbar sind. Diese Matrix ist nicht vollumfänglich, sondern enthält nur die relevanten Daten.

Daten im System verfügbar

Datenbezeichnung JIR

A

Pla

ton

SV

N

Bam

boo

Ecl

ipse

JIR

A Ticketnummer X X X X X

Ticketstatus X X X

Ticketdetails (1) X X X X

Pla

ton

Antragsnummer X X

Antragsdetails (2) X

Auftragsnummer X X

Auftragsdetails (3) X

SV

N

Quellcode X X X X

Datei-Autor X X X

Revisionsnummer X X X X X

Commit-Message X X X X

Bam

boo

Buildnummer X X X

Buildstatus X X

Buildprozessdefinition X

Buildablaufdaten (4) X

Tabelle 5.1: Datenbeziehungsmatrix

Die Spalte vor den Datenbezeichnungen gibt an, in welchem System die Daten originär erzeugt bzw. gespeichert werden. Die folgenden Erklärungen dienen zum Verständnis der Datenbezeichnungen:

(1) Unter Ticketdetails werden alle Daten gefasst, die zur Bearbeitung des Tickets erforderlich sind. Dazu gehören unter anderem die Anforderungen, der Ersteller und der Tickettyp.

(2) Die Antragsdetails enthalten alle weiteren Daten, die am Antrag gespeichert werden, neben der Antragsnummer. Diese Daten werden nur in Platon verwendet und lediglich über die Antragsnummer auf sie referenziert.

(3) Die Auftragsdetails enthalten alle weiteren Daten, die am Auftrag gespeichert werden, neben der Auftragsnummer. Diese Daten werden nur in Platon verwendet und es wird



lediglich über die Auftragsnummer auf sie referenziert.

(4) Die Buildablaufdaten verbleiben ausschließlich im CI-System. Falls in einem Build-Prozess Fehler aufgetreten sind, ist in den Buildablaufdaten gespeichert, wo dieser Fehler aufgetreten ist. Ebenfalls werden weitere Informationen, wie zum Beispiel die Build-Dauer, unter dieser Bezeichnung gefasst.

Die in der Tabelle 5.1 beschriebenen Daten werden strukturiert in den Systemen abgelegt. Im SVN ist es nicht möglich, Daten strukturiert abzulegen. Daher werden diese unstrukturiert in der Commit-Message abgelegt.

Schnittstelle Platon - Ticketsystem

Für die Kommunikation zwischen Platon und dem Ticketsystem JIRA müssen zwei Schnittstellen definiert werden. Platon muss eine Schnittstelle bereitstellen, die es ermöglicht Anträge und Aufträge aus einem JIRA-Ticket zu erstellen oder ein JIRA-Ticket mit einem existierenden Auftrag zu verknüpfen. Die Schnittstelle zum Setzen des Ticketstatus ist in JIRA bereits vorhanden. Diese muss von Platon angesprochen werden. Dazu müssen die Daten definiert werden, die Platon übergeben soll.

Damit in Platon ein Antrag mit einem Auftrag generiert werden kann, werden die in der Tabelle 5.2 aufgeführten Daten benötigt. In der Tabelle werden den erforderlichen Daten die Daten aus JIRA zugeordnet. Diese Daten dienen zur Erstellung eines Antrages. Der Auftrag wird von Platon beim Erstellen des Antrages aus den Daten des Antrages generiert. Optional kann der Schnittstelle eine Platon-Auftragsnummer übergeben werden, die im JIRA-Ticket erfasst wurde. Dann wird das Ticket dem angegeben Auftrag zugeordnet. Einem Auftrag können beliebig viele JIRA-Tickets zugeordnet werden.

Benötigte Daten in Platon Datenherkunft aus JIRA

Antragssteller Ticketersteller

Anwendung JIRA-Projekt

Anforderungsbeschreibung Ticketbeschreibung

Kurzbeschreibung Ticketkurzbeschreibung

Ticketnummer Ticketnummer

Optional: Auftragsnummer Platon-Auftragsnummer

Tabelle 5.2: Daten der Schnittstelle Platon - Ticketsystem

Damit Platon den Ticketstatus in JIRA verändern kann, muss bei der Erstellung des Antrages die Ticketnummer mit übergeben werden. Dadurch ist es möglich, die REST9-Schnittstelle von JIRA aufzurufen. Der Schnittstelle müssen die Ticketnummer, sowie der neue Status übergeben werden. Dafür ist es erforderlich, dass Platon die Ticketstatus kennt, die Platon setzen soll. Optional kann bei der Statusänderung ein Kommentar übergeben werden, der am Ticket gespeichert wird.

9„Representational State Transfer (abgekürzt REST) bezeichnet ein Programmierparadigma für verteilte

Systeme, insbesondere für Webservices.“ [WiRe16]



Berechtigungen der Anwender

Um sicherzustellen, dass nur Mitarbeiter die Softwareentwicklungssysteme verwenden können, die dazu berechtigt sind, muss ein Berechtigungskonzept erstellt werden. Dabei muss berücksichtigt werden, dass die Mitarbeiter nur für bestimmte Anwendungen zuständig sind. Die Zuordnung der Mitarbeiter zur Anwendung kann aus dem Rollenkonzept von Platon (beschrieben in Kapitel 4.2) abgeleitet werden. Daher enthalten die beiden folgenden Tabellen diese Rollen.

Zur Veranschaulichung der Berechtigungen in den Softwareentwicklungssystemen dient die Tabelle 5.3. Die administrativen Funktionalitäten sind im Entwicklungsbereich nicht vorhanden und werden deshalb in der Tabelle nicht berücksichtigt.

Rolle in Platon

System/Funktionalität IT-T

eam

leit

er

En

twic

kle

r

Fach

prü

fer

JIR

A Ticket einsehen X X X

Ticket erstellen/bearbeiten X X X

Ticket prüfen/zur Umsetzung annehmen X X

Pla

ton

Anträge/Aufträge einsehen X X X

Anträge/Aufträge anlegen X X X

Freigabeaufforderung versenden X X

Freigaben erteilen X X X

Produktionsübernahmen ausführen X X

SV

N Dateien einsehen X X

Dateien ändern/einchecken X X

Dateien als gelöscht markieren X X

Bam

boo

Build-Prozess erstellen X X

Build-Prozess starten X X

Build-Ergebnisse einsehen X X

Tabelle 5.3: Berechtigungen in den Softwareentwicklungssystemen

Die Tabelle zeigt die Funktionalitäten der Softwareentwicklungssysteme und die Berechtigungsrollen, mit denen diese Funktionalitäten verwendet werden können. Weiterhin wird die Verwendung der Berechtigungen so eingeschränkt, dass die Funktionalitäten von den Mitarbeitern nur für die Anwendungen verwendet werden können, für die sie zuständig sind. Die Tabelle 5.4 zeigt die Zuordnung der Mitarbeiter zu den Anwendungen, für die sie zuständig sind. Die Tabelle dient zur übersichtlichen Darstellung und stellt keine



Modellierung der Datenbank dar.

Anwendung Teamleiter Entwickler Fachprüfer

Limitüberwachung Müller Meyer

Schulze

Schneider

Weber

Kompetenzmodul Richter Wolf

Krause

Lehmann

Tabelle 5.4: Zuordnung Mitarbeiter - Anwendungen

Die Daten der dargestellten Tabelle sind in Platon bereits vorhanden und können in den anderen Softwareentwicklungssystemen verwendet werden. Dies stellt sicher, dass die Mitarbeiter in den Systemen nur auf die Anwendungen zugreifen können, für die sie ein berechtigtes Interesse haben. Ebenfalls werden die Systeme übersichtlicher, da nur die Anwendungen angezeigt werden, auf die der jeweilige Mitarbeiter zugreifen darf.

5.3 Softwareentwicklungsprozess

In der Abbildung 5.4 wird der zukünftige Softwareentwicklungsprozess dargestellt.

Wie bereits aus der Datenbeziehungsmatrix (Tabelle 5.1) erkennbar ist, orientiert sich der neue Softwareentwicklungsprozess an der Abarbeitung eines Tickets. Bei der Ausführung einiger Prozessschritte ändert sich automatisiert der Ticketstatus. Der Status nach der Ausführung der Aktion wird in blau und umrandet in der jeweiligen Aktion dargestellt. Die grau unterlegten Aktionen werden vollständig automatisiert ausgeführt. Die Aktionen sind in Swimlanes gruppiert, um zu verdeutlichen, in welchem System die jeweilige Aktion ausgeführt wird.

Das im Folgenden beschriebene Verfahren eignet sich für eine Änderungsanforderung für ein bestehendes System. Sofern mehrere Anforderungen zu einem System existieren, muss der Prozess leicht modifiziert werden. Diese Modifikationen werden nach der Beschreibung des Verfahrens für eine Anforderung erläutert.

Wenn Änderungen an einer bestehenden Anwendung vorgenommen werden sollen oder eine neue Anwendung entwickelt werden soll, müssen durch den Fachbereich Tickets für diese Anforderungen in JIRA erfasst werden. Bei der Erfassung eines Tickets ist zu beachten, dass ein Ticket immer nur eine Anforderung enthalten soll. Auf die Vorteile dieser Vorgehensweise wird in Kapitel 5.5.2 näher eingegangen. Wurde die Anforderung im Ticket definiert, muss das Ticket der IT zur Prüfung zugewiesen werden. Dadurch erhält das Ticket den Status „Anforderungsprüfung“.

Bei der Prüfung des Tickets wird festgestellt, ob die Anforderung technisch umsetzbar ist. Sollte die Anforderung nicht umsetzbar sein, wird das Ticket abgewiesen. Dadurch erhält das Ticket den Status „Abgelehnt“. Wenn die Anforderung unvollständig oder unverständlich beschrieben ist, wird das Ticket der Fachabteilung erneut zugewiesen. Dadurch erhält das Ticket den Status „Unvollständig“. Wird bei der Prüfung der Anforderung kein Problem festgestellt, wird das Ticket zur Umsetzung angenommen. Dadurch erhält das Ticket den Status „ToDo“ und die Schnittstelle zur Erstellung des Antrags und des Auftrags in Platon wird automatisiert aufgerufen.



Abbildung 5.4: Softwareentwicklungsprozess

Sobald der Entwickler Zeit hat, die Anforderung umzusetzen, wählt er das Ticket in der Entwicklungsumgebung aus und beginnt die Ticketbearbeitung. Dadurch erhält das Ticket den Status „In Arbeit“. Er setzt die Anforderungen um und checkt den geänderten Quellcode in das Versionskontrollsystem ein.

Durch das Einchecken merkt der CI-Server automatisiert, dass ein Build-Prozess gestartet werden muss. Aus welchen Bestandteilen der Build-Prozess in der OLB besteht, wird in



Kapitel 5.4 beschrieben. Sollte der Build fehlschlagen, setzt der CI-Server den Ticketstatus auf „Build fehlerhaft“. Dadurch wird dem Entwickler das Ticket in der Entwicklungsumgebung erneut angezeigt. Wenn der Build-Prozess erfolgreich durchlaufen wurde, checkt der CI-Server die erstellte und kompilierte Anwendung in das Versionskontrollsystem ein. Diese wird auch als Quellcode-Artefakt bezeichnet. Die Build-Nummer des Builds ist in der Commit-Message enthalten. In Platon wählt der Entwickler die erstellte Anwendung aus dem Versionskontrollsystem aus und übergibt diese in die Integrationsumgebung. Danach wählt er das Testverfahren aus und versendet die Freigabeaufforderung.

Der Prüfer testet die Umsetzung der Anforderung. Sollte es dabei zu einem Fehler kommen, gibt er den Auftrag in Platon an den Entwickler zurück. Dadurch erhält das Ticket den Status „Wiedereröffnet“. Ist die Anforderung korrekt umgesetzt worden, gibt der Prüfer den Auftrag in Platon frei. Dadurch erhält das Ticket den Status „Produktionsübernahme“.

Abschließend führt der Entwickler die Produktionsübernahme aus. Dadurch erhält das Ticket den Status „Behoben“.

Wenn mehrere Anforderungen zu einem System existieren, muss der beschriebene Prozess modifiziert werden. Anstatt dass für jedes Ticket ein eigener Antrag inkl. einem Auftrag generiert wird, wird ein Platon-Auftrag nur mit dem ersten Ticket angelegt. In jedem weiteren Ticket wird die Platon-Auftragsnummer dieses Auftrages angegeben, sodass die Tickets sich ausschließlich auf einen Auftrag beziehen. Nach der Bearbeitung eines Tickets wird wieder die neueste Version der Software in der Integration zum Testen bereitgestellt. Dadurch können, wie in Kapitel 5.1 detailliert beschrieben, die Anforderungen durch den Systemeinsatz in der Integration validiert werden. Da alle Tickets sich nur auf einen Auftrag beziehen, muss nur dieser nach der Umsetzung aller Anforderungen freigegeben werden. Dabei muss abschließend erneut die Umsetzung aller Anforderungen geprüft werden. Dies ist erforderlich, weil es bei der Entwicklung von weiteren Funktionalitäten zu Seiteneffekten an bereits getesteten Funktionalitäten kommen kann.

Die Beziehung zwischen Platon-Auftrag, Ticket und Quellcode-Artefakt stellt die Beziehungssicht in Abbildung 5.5 übersichtlich dar.

Abbildung 5.5: Beziehungssicht Platon-Auftrag, Ticket, Quellcode-Artefakt

Die Kardinalitäten an den Kanten der Beziehungssicht beziehen sich auf den Datenzustand, nachdem der erste Build-Prozess vom CI-Server ausgeführt wurde.

5.4 Build-Prozess

In Kapitel 5.3 ist der Build-Prozess als eine Aktion dargestellt. Da ein Build-Prozess jedoch viele Aktivitäten umfasst, wird dieser in diesem Kapitel detaillierter beschrieben. Dabei wird nicht der vollständige Build-Prozess erklärt und es erfolgt auch keine detaillierte Anleitung, wie ein Build-Prozess in Bamboo erstellt werden kann. Letzteres ist der Herstellerdokumentation zu entnehmen. In diesem Kapitel wird eine Orientierungshilfe gegeben, wie ein Build-Prozess in der OLB gestaltet werden kann. Als Grundlage dieser Orientierungshilfe dienen die abstrakten Erklärungen des Kapitels 3, die in diesem Kapitel in Bezug auf die OLB konkretisiert werden.



Selbsttestender Build

Damit eine Beziehung zwischen dem geänderten Quellcode und einem Ticket hergestellt werden kann, muss die Ticketnummer in der Commit-Message der Änderungen enthalten sein. Daher wird zunächst geprüft, ob die Ticketnummer in der Commit-Message enthalten ist. Falls diese fehlt, bricht der Build-Prozess ab.

Sofern die Ticketnummer enthalten ist, werden die statischen und dynamischen Tests ausgeführt. Gerade zur Einführung eines CI-Systems ist es wichtig, dass schnell erste Erfolge mit dem System erzielt werden, um die Akzeptanz zu erhöhen. Daher wäre es hinderlich, wenn bereits zur Einführung sehr restriktive Vorgaben in diesen Tests vorhanden sind und dadurch kein Build-Prozess erfolgreich durchlaufen würde. Im Wesentlichen sollen zwei Tests durchgeführt werden. Zum einen soll eine statische Code-Analyse erfolgen und zum anderen sollen Unit-Tests ausgeführt werden.

Bei der statischen Code-Analyse wird geprüft, ob die vorgegebenen Programmierrichtlinien eingehalten wurden. Dazu wird so vorgegangen, wie es [Riet16] in seinem Artikel beschreibt. Die bisher vorgegebenen Programmierrichtlinien werden in Abstimmung mit allen Entwicklern analysiert und es wird geprüft, welche Richtlinien tatsächlich benötigt werden und welche ggf. noch fehlen. So kann von den Kenntnissen jedes Entwicklers profitiert werden. Da ein vollständiger Konsens unwahrscheinlich ist, erfolgt für jede Regel zur Einführung eine einmalige Abstimmung. Diese festgelegten Regeln müssen konsequent eingehalten werden. Daher führt jeder Regelverstoß zu einem Build-Abbruch. Dies gilt für neue als auch für bestehende Anwendungen. Mit dem Unterschied, dass für bestehende Anwendungen ein Stichtag festgelegt wird, ab dem keine neuen Regelverstöße stattfinden dürfen.

Der zweite Test ist der Unit-Test. Jedes Modul sollte durch einen Unit-Test überprüft werden. Es kann durch den CI-Server automatisiert ermittelt werden, wie hoch die Testabdeckung10 ist. Es wird geprüft, ob jede Funktion eines Moduls entsprechend mit einem Test versehen ist. Daraus ergibt sich ein prozentualer Wert. Hier ist ein Schwellwert zu definieren, der erreicht werden muss, damit der Build-Prozess nicht abbricht. Dieser ist in der Einführungsphase niedrig anzusetzen und dann im Laufe der Zeit zu erhöhen.

Systemtests sind ebenfalls sehr wichtig, jedoch ist der Aufwand für einen hinreichenden Systemtest nicht zu unterschätzen [vgl. Spil12, S.62]. Daher sollten diese zunächst nur für neue Anwendungen verpflichtend sein. Sofern freie Ressourcen zur Verfügung stehen, können nach und nach Systemtests für Bestandsanwendungen erstellt werden.

Build-Intervall

In Anbetracht der bisherigen Entwicklung von Anwendungen wird aufgrund der Größe der Entwicklerteams und der Änderungshäufigkeit von Anwendungen zunächst das Build-Intervall nicht eingeschränkt. Der CI-Server soll dauerhaft das Versionskontrollsystem überwachen und bei jeder Änderung einen Build-Prozess starten. Dabei sollen alle Tests außer der Systemtest ausgeführt werden. Sollte dies zu einem Rückstau an Builds führen, muss ein größeres Intervall festgelegt werden.

Zusätzlich zum Build direkt nach dem Einchecken von Änderungen sollen nächtlich die Anwendungen gebaut werden, die tagsüber geändert wurden. Im nächtlichen Build sollen alle Tests ausgeführt werden, da die durch den Systemtest bedingte längere Ausführungszeit

10 Die Testabdeckung bezeichnet den durch automatisierte Tests abgedeckten Quellcodeanteil im Verhältnis zum

gesamten Quellcode.



unproblematisch ist.

5.5 Verbesserungen

In diesem Kapitel wird der in der Beschreibung des Ist-Zustandes aufgezeigte Verbesserungsbedarf aufgegriffen und erläutert, wie der modifizierte Softwareentwicklungsprozess die Softwareentwicklung in der OLB verbessern kann.

5.5.1 Technische Verbesserungen

Zusammenfügen der Anwendung

Eine Anwendung wird zukünftig durch den CI-Server aus ihren Komponenten zusammengefügt. Dieser bezieht den Quellcode aus dem Versionskontrollsystem. Daher ist sichergestellt, dass nur dieser Quellcode in einen Build eingeht. Da das Zusammenfügen der Anwendung immer auf dem CI-Server erfolgt, kann es nicht zu Abweichungen aufgrund unterschiedlicher Konfigurationen der Computer der Entwickler kommen.

Nachvollziehbarkeit von übergebenem Quellcode

Es wird über zwei Wege sichergestellt, dass genau festgestellt werden kann, welcher Quellcode in die kompilierte Anwendung eingegangen ist. Zum einen wird dies durch den CI-Server dokumentiert und gespeichert. Zum anderen wird der Build-Prozess so konfiguriert, dass zusätzlich der unkompilierte Quellcode im erstellten zip-Archiv mit abgelegt wird.

Einhaltung der Programmierrichtlinien

Wie im Kapitel 5.4 beschrieben, wird bei jedem Build-Prozess der Quellcode durch eine statische Analyse geprüft. Die für den CI-Server erstellte Konfiguration zur Prüfung der Programmierrichtlinien wird den Entwicklern bereitgestellt, sodass sie diese in ihrer Entwicklungsumgebung einbinden können. Dadurch weist die Entwicklungsumgebung bereits bei der Erstellung des Quellcodes auf Verstöße gegen die Richtlinie hin. Grundlage dieser Konfiguration ist die vorhandene, textuell beschriebene, Programmierrichtlinie der OLB.

5.5.2 Organisatorische Verbesserungen

Änderung der Anforderungen im laufenden Projekt

Die Änderungen der Anforderungen im laufenden Projekt beruhen häufig darauf, dass der Fachbereich diese Anforderungen nicht im Gesamtkontext einer Anwendung betrachtet und wenig Erfahrung mit der Erstellung von Fachkonzepten hat. Durch nicht vollständig beschriebene Anforderungen ergeben sich seitens der Entwickler regelmäßig Rückfragen in der Implementierungsphase. Dadurch ergibt sich ein erhöhtes Kommunikationsaufkommen zwischen dem Fachbereich und den Entwicklern, die erst zu diesem Zeitpunkt mehr über den Hintergrund der Anforderungen erfahren.

Dies soll zukünftig verhindert werden, indem die Entwickler die Fachabteilung bei der Erstellung des Fachkonzeptes unterstützen. Durch den frühen Austausch von Informationen bereits zu Beginn des Projektes verstehen die Entwickler besser den Hintergrund der jeweiligen Anforderung und können bereits zu diesem Zeitpunkt prüfen, ob diese technisch umsetzbar ist. Des Weiteren können die Entwickler auf technisch neue Möglichkeiten hinweisen, die der Fachabteilung bisher nicht bekannt waren. Die Entwickler können die Strukturierung des Fachkonzeptes dahingehend unterstützen, dass die Anforderungen, die technisch in einer Komponente umgesetzt werden, auch im Fachkonzept an einer Stelle beschrieben werden.

VWA Leer e.V. 34 Fazit


Das Fachkonzept muss nicht vollständig sein, bevor die Entwicklung der Anwendung beginnen kann. Alle Anforderungen sollten jedoch grob spezifiziert sein. Die detaillierte Spezifikation kann im Ticket erfolgen. Diese Details sind unverzüglich ins Fachkonzept zu überführen, sodass zu jedem Zeitpunkt ein aktuelles Fachkonzept mit allen bisherigen Anforderungen vorliegt.

Probleme aufgrund von zu großen Aufträgen

Wie in Kapitel 5.3 beschrieben, wird für jede Anforderung ein Ticket erstellt. Dies bietet die Möglichkeit, die Umsetzung der Anforderungen flexibel auf die Entwickler der Anwendung zu verteilen. Ebenfalls ist die Umsetzung einer Anforderung mit einer überschaubaren Änderung des Quellcodes möglich. Dadurch kann zukünftig ein Code-Review effektiver durchgeführt werden.

6 Fazit Ziel dieser Arbeit war es, ein Fachkonzept zur Einführung eines Continuous Integration Systems in einer Bank zu erstellen. Dazu wurde der bisherige Softwareentwicklungsprozess analysiert und dokumentiert. Die Erstellung dieser Arbeit hat dazu beigetragen, den bisherigen Entwicklungsprozess kritisch zu betrachten und zu reflektieren. Dabei wurde Verbesserungsbedarf aufgedeckt. Durch den Einsatz eines CI-Systems und andere organisatorische Änderungen lassen sich diese Verbesserungen herbeiführen.

Bei der Entwicklung des zukünftigen Softwareentwicklungsprozesses wurde festgestellt, dass der alleinige Einsatz eines CI-Systems keinen großen Mehrwert bietet. Erst durch die Anpassung der Arbeitsweise zu kleineren Arbeitspaketen und der Verwendung eines Ticketsystems ergeben sich größere Synergieeffekte.

Die detaillierte Darstellung der bisherigen Arbeitsweise, sowie des zukünftigen Softwareentwicklungsprozesses bietet den Lesern dieser Arbeit die Möglichkeit, den Entwicklungsprozess in ihrem Umfeld mit diesen Darstellungen zu vergleichen. Dabei können sie die Schwachstellen ihres Entwicklungsprozesses analysieren und die beschriebenen Arbeitsweisen in der Form einsetzen, wie diese am besten in ihr Umfeld passen.

Zusammenfassend lässt sich sagen, dass in dieser Arbeit ein zeitgemäßer Softwareentwicklungsprozess für die OLB entwickelt wurde, der vor allem durch agiles Vorgehen einen deutlichen Mehrwert gegenüber dem bisherigen Entwicklungsprozess bietet.

VWA Leer e.V. 35 Literaturverzeichnis


Literaturverzeichnis [Apac16] Apache, Apache Subversion Features, https://subversion.apache.org/features.html (aufgerufen am

14.07.2016)

[Buba16] Deutsche Bundesbank, Glossar, https://www.bundesbank.de/Redaktion/DE/Glossareintraege/U/universalbank.html (aufgerufen am 14.07.2016)

[Droo16] JIRA des Business Rules Management Systems Drools, https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=3362&view=detail&selectedIssue=DEVELOPER-3214

[Flat15] Icons selbsterstellter Grafiken, www.flaticon.com (designed by Freepik) (aufgerufen am 14.07.2016)

[Fowl06] Fowler, Martin: Continuous Integration, http://www.martinfowler.com/articles/continuousIntegration.html (aufgerufen am 14.07.2016)

[Heis16] Heise, Entwicklungsumgebung, http://www.heise.de/download/products/programmierung/entwicklungsumgebung (aufgerufen am 14.07.2016)

[ItWi16] ITWissen, Mock-Objekt, http://www.itwissen.info/definition/lexikon/Mock-Objekt-mock-object.html (aufgerufen am 14.07.2016)

[MaRi16] Bundesanstalt für Finanzdienstleistungsaufsicht, Rundschreiben 10/2012 (BA) - Mindestanforderungen an das Risikomanagement – MaRisk, https://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Rundschreiben/rs_1210_marisk_ba.html (aufgerufen am 14.07.2016)

[Riet16] Rietmüller, Daniel: Clean Code erfolgreich einführen – Softwarequalität nach neuestem Stand liefern, http://www.encoway.de/magazin/technologie/clean-code-erfolgreich-einfuehren-softwarequalitaet-nach-neuestem-stand-liefern/ (aufgerufen am 14.07.2016)

[Smar16] SmartBear Software, Best practices for code review, https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/ (aufgerufen am 14.07.2016)

[Spil12] Spillner, Andreas; Linz, Tino: Basiswissen Softwaretest, 5. Auflage, dpunkt.verlag et al 2012

[Wies11] Wiest, Simon: Continuous Integration mit Hudson, 1. Auflage, dpunkt.verlag et al 2011.

[WiRe16] Wikipedia, Representational State Transfer, https://de.wikipedia.org/wiki/Representational_State_Transfer (aufgerufen am 14.07.2016)

[Wolf11] Wolf, Henning; Bleek, Wolf-Gideon: Agile Softwareentwicklung, 2. Auflage, dpunkt.verlag et al 2011

VWA Leer e.V. 36 Erklärung


Erklärung „Hiermit versichere ich, dass ich die vorliegende Arbeit von mir selbstständig und ohne unerlaubte Hilfe angefertigt worden ist, insbesondere, dass ich alle Stellen, die wörtlich oder annähernd wörtlich aus Veröffentlichungen entnommen worden sind, durch Zitate als solche kenntlich gemacht habe.“

______________________ ___________________________ Ort, Datum Unterschrift

einführung eines continuous integration systems in einer ... · continuous integration (ci) wird...

Documents