Projektstudie der Datenmigration und Prozessumstellung zwischen zwei Issue–Tracking–Systemen

Inhaltsverzeichnis

1 Einleitung

2 Motivation
2.1 Beweggründe der Untersuchung
2.2 Möglicher Gewinn der Umstellung

3 Produktanalyse
3.1 Grundsätzliches zu Issue Tracking Systemen
3.2 Produktanalyse: Avensoft Perfect Tracker 7
3.2.1 Einleitung
3.2.2 Architektur
3.2.3 Zusammenfassung
3.3 Produktanalyse: Atlassian JIRA 4
3.3.1 Einleitung
3.3.2 Architektur
3.3.3 Lizenzierung
3.3.4 Zusammenfassung
3.4 Identifikation möglicher Problemquellen
3.4.1 Umstellung Produktorientierung/Projektorientierung
3.4.2 Abhängige Tracks
3.4.3 Andere Probleme

4 Strukturanalyse
4.1 Analyse der Datenmodelle
4.1.1 Einführung
4.1.2 Avensoft Perfect Tracker 7
4.1.3 Atlassian JIRA 4
4.1.4 Vergleich der Datenmodelle
4.2 Analyse der Systeme
4.2.1 Systemanalyse Avensoft Perfect Tracker 7
4.2.2 Systemanalyse Atlassian JIRA 4

5 Verhaltensanalyse
5.1 Grundsätzliches zur Verhaltensweise
5.2 Ist-Erhebung des Workflows
5.2.1 Workflow des Customer Services
5.2.2 Workflow des Bug Trackings
5.3 Ist-Analyse
5.3.1 Analyse des Customer Service-Workflows
5.3.2 Analyse der Bug Tracking-Workflows

6 Projektstudie
6.1 Produktorientierung
6.2 Umsetzung der Workflows
6.2.1 Grundsätzliches zu Workflows in JIRA
6.2.2 Umsetzung des Customer Service
6.2.3 Umsetzung des Bug Tracking
6.3 Umsetzung der Rollen und Sichten
6.4 Formularfelder
6.5 Notwendige Plugins
6.5.1 Grundsätzliches zu den notwendigen Plugins
6.5.2 Link New Issue Operation
6.5.3 Produktbaum-Plugin
6.6 Entwurf einer Anwendung zur Migration der Ticket-Daten
6.6.1 Zweck des Entwurfs
6.6.2 Ablauf der Migration
6.6.3 Aufwandsabschätzung

7 Resümee
7.1 Generelle Machbarkeit der Umstellung
7.2 Schwierigkeiten der Umstellung
7.3 Gewinne der Umstellung
7.4 Bewertung der Umstellung

Abbildungsverzeichnis

Tabellenverzeichnis

Glossar

Akronyme

Literaturverzeichnis

Anhänge

1 Einleitung

Meir M. Lehman formulierte ab 1974 Gesetze, die Eigenheiten der Evolution von Softwa­reprodukten definieren, Lehman’s laws of software evolution. Zu diesem Zweck unterteilte er Programme in drei unterschiedliche Kategorien [SCW06]:

S—type programs are those that can be specified formally.

P—type programs cannot be specified. Instead, an iterative process is used to find a working solution.

E—type programs are embedded in the real world and become part of it, thereby changing it. This leads to a feedback system where the program and its environment evolve in concert.

Fast alle Anwendungen, die von Firmen entwickelt werden, können als Typ E kategorisiert werden. Sie finden im „echten Leben” Anwendung und verändern es damit einhergehend. Die ersten beiden darauf anwendbaren Gesetze lauten:

„An E—type program that is used must be continually adapted else it becomes progressively less satisfactory.”

(etwa: „Programme vom Typ E müssen ständig angepasst werden, sonst werden sie progressiv weniger zufriedenstellend")

und

„As a program is evolved its complexity increases unless work is done to maintain or reduce it.”

(etwa: „Da ein Programm [vom Typ E] ständiger Veränderung unterliegt, steigt seine Komplexität, es sei denn, es wird Arbeit zur Erhaltung oder Re­duktion [der Komplexität] betrieben")

Weiterhin muss man davon ausgehen, dass jede Software von Natur aus fehlerhaft ist. Steve McConnell ging 1993 von „about 15 — 50 errors per 1000 lines of delivered code” aus [McC93]. Auch wenn diese Zahl, bedingt duch die unklare Zählweise und den geringen Informationsgehalt, als kein Maß für Softwarequalität im Allgemeinen genutzt werden kann¹, illustriert sie doch die Problematik des „Menschlichen Makels” in der Softwareentwicklung.

Viele Unternehmen nutzen heute verschiedene Systeme, um eingehende Anfragen nach neuen Funktionen eines Produkts, Fehlermeldungen und Verbesserungsvorschläge auf­zunehmen und zu verwalten. Dieses Systeme werden häufig als Bug Tracking Systems, Issue Tracking Systems oder Requirement Management Systems bezeichnet. Aber auch diese Systeme unterliegen den oben erläuterten Problemen. Änderungen im Workflow, die Einführung neuer Systeme im Unternehmen oder ein wachsender Markt an leistungsfähi­geren Standardsystemen machen die Umstellung auf ein anderes Produkt häufig sinnvoller als die Anpassung der bestehenden Systeme.

In dem hier untersuchten Fall soll das bisher verwendete System Powertracker 7 aus dem Jahr 2004 gegen ein neueres System ausgetauscht werden. Diese Arbeit beschäftigt sich mit der Evaluation von Atlassians JIRA 4 als Alternative zu Avensofts Perfect Tracker 7 und einer Analyse der Umstellungsmöglichkeiten.

2 Motivation

2.1 Beweggründe der Untersuchung

Die Firma IVU Traffic Technologies AG plant die Umstellung des bisher verwendeten Bugtrackers auf ein moderneres System. Die erste Frage, die sich stellt, wenn ein solches Projekt zur Diskussion steht, ist die nach der Notwendigkeit der Umstellung: „Wieso sollte das eingesetzte System durch ein anderes ersetzt werden?”. Der betriebswirtschaftliche Aufwand einer Umstellung nimmt oftmals erhebliche Dimensionen an, Schulungen der Mitarbeiter und der Verlust der Routine in der Benutzung mindern die Produktivität. Ohne triftige Gründe wären Änderungen an einem bewährten, produktiv laufenden System nicht nötig. Gründe für die Umstellung liegen in dem untersuchten Fall jedoch zur Genüge vor. Interviews mit den Mitarbeitern der Firma offenbarten folgende Schwächen:

Mangelhaftes Reporting Die Anzeige aller Tickets, die einer Menge von speziellen Kriterien entspricht (z. B. keine Änderungen im letzten Jahr, Status nicht geschlos­sen, einem bestimmten Kunden zugeordnet), ist mit dem im Perfect Tracker imple­mentierten Reporting nicht oder nur sehr eingeschränkt möglich. Projektleiter und Management vermissen die Möglichkeit, aus der großen Menge von Tickets einige spezielle zu selektieren und anzuzeigen.

Fehlende Massenbearbeitung Änderungen an größeren Mengen von Daten (z. B. die Zuordnung von Tickets nach einer Entlassung) lassen sich nur unter hohem manuel­len Aufwand durchführen.

Statischer Workflow Änderungen im Workflow erfordern die Entwicklung und Anpas­sungen von Webseiten und Formularen. Es gibt keine Möglichkeit, den Workflow innerhalb der Benutzeroberfläche zu modifizieren. Die Verwendung von kunden­spezifischen Workflows ist ohne eine komplette Neuentwicklung des Systems nicht möglich.

Ungenügende Konfigurierbarkeit Es existiert keine Administrationsoberfläche, mit der Zustände, Status, Prioritäten oder Integrationen verwaltet oder in andere Systeme konfiguriert werden könnten. Alle Änderungen müssen im Quellcode vorgenommen werden.

Mangelhafte Erweiterbarkeit Erweiterungen der Anwendung müssen direkt im Quell­code durchgeführt werden. Die Möglichkeit, Plugins einzubinden oder externe Systeme (Wikis, Version Control Systems (VCS),... ) zu integrieren, ist nicht gege­ben.

Mangelnder Funktionsumfang Funktionen wie eine ticketbasierte Zeiterfassung sind nicht möglich; da die Verwendung von Plugins oder Erweiterungen nicht möglich ist, kann auch keine externe Zeiterfassung eingebunden werden. Eine Eigenentwicklung würde die Umstellung aller Formulare sowie die Anpassung der Datenbank bedeuten.

Diese und andere Gründe (ästhetisches Erscheinungsbild, Benutzerfreundlichkeit) haben die Notwendigkeit der Umstellung in der jüngeren Vergangenheit schon des öfteren akut, fehlende Ressourcen eine Evaluation der Situation jedoch bislang unmöglich gemacht.

2.2 Möglicher Gewinn der Umstellung

Neben der Behebung der in Kapitel 2.1 erkannten Schwächen erhofft sich der Auftraggeber weiterhin folgende Gewinne:

Erhöhte Kunden-/Mitarbeiterakzeptanz Durch die Verwendung eines Systems mit einer höheren Benutzerfreundlichkeit und einem übersichtlicheren Interface werden Kunden und Mitarbeiter das Issue Tracking System häufiger und selbstständiger verwenden.

Erhöhte Prozessqualität Da Änderungen in den Prozessen (z.B. im Workflow) der Firma mit sehr geringem Aufwand in das System übernommen werden können, kann sich das Issue Tracking System der betriebswirtschaftlichen Realität anpassen und nicht umgekehrt.

Verbesserte Prozessdokumentation Durch die verbesserte Abbildung der Prozesse im Issue Tracking System können Abläufe genauer dokumentiert und Schwachstellen leichter erkannt werden, das Nachvollziehen der Geschehnisse wird erleichtert.

3 Produktanalyse

3.1 Grundsätzliches zu Issue Tracking Systemen

Issue Tracking Systeme, ehemals auch Trouble Ticket Systeme genannt, dienen dazu, unterschiedliche Kundenwünsche und -anfragen zu einem Produkt zu erfassen, zu ver­walten und zu bearbeiten sowie dem Kunden eine Informationsbasis zu dem aktuellen Stand des Wunsches oder der Anfrage zu geben. Die Erfassung dieser Anfragen findet dabei normalerweise über ein Graphical User Interface (GUI) statt und resultiert in einem sogenannten Ticket. Tickets sind elektronische Abbildungen dieser Anfragen und sollten dabei vom Ersteller mit möglichst allen relevanten Informationen zu dem korrelierenden Ereignis versehen werden. Das erstellte Ticket befindet sich nun am Beginn des im In­formationssystem hinterlegten Workflows. Ein Beispiel für einen solchen Prozess könnte dabei wie folgt aussehen:

Beschreibung eines exemplarischen Workflows

Ein Kunde der Firma Software AG stellt eine Fehlfunktion in der für ihn entwickelten Anwendung fest. Aus diesem Grund öffnet er ein Ticket im Issue Tracking System (ITS) der Software AG, in welchem er die Umstände der Fehlfunktion erläutert (Transition /Open Ticket). Ein Mitarbeiter der Software AG weist das Ticket nun dem Quality Management zu (/Assign). Dieses untersucht die gemeldete Störung und versucht nachzuvollziehen, ob es sich um einen Benutzerfehler oder einen Softwarefehler handelt. Wenn es sich um einen Softwarefehler handelt, wird das Ticket einem Entwickler zuge­wiesen (/To Development). Dieser ermittelt nun die Fehlerquelle innerhalb des Programmcodes und korrigiert diese. Das Ticket wird nun zurück in das Quality Management gegeben, wo der produzierte Code getestet wird (/Test).

Nach erfolgreichen Tests wird ein Patch erstellt (/Test Successful) und an den Kunden ausgeliefert (/Deliver). Der Vorgang ist damit abgeschlossen (/Close).

Innerhalb dieses Workflows werden dem Ticket relevante Informationen wie Kundengespräche, (mögliche) Fehlerursachen, Konsequenzen, resultierende Tickets (Sub-Tasks) und andere angehängt. Der Kunde hat dabei begrenzte Einsicht in den Status des Tickets und kann sich so selbstständig über den Stand der Fehlerbehebung informieren (Siehe Abb. 3.1, Seite 6).

Zustandsdiagramm des exemplarischen Workflows

Die Zustände des oben beschriebenen Ablaufs können wie folgt aussehen, die Swimlanes illustrieren die Gruppe oder Person, der das Ticket in dem Prozessschritt wahrscheinlich zugeordnet ist (gewählter Ablauf hervorgehoben):

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Exemplarischer Workflow der Software AG.

3.2 Produktanalyse: Avensoft Perfect Tracker 7

3.2.1 Einleitung

Perfect Tracker 7 war ein webbasiertes ITS der kalifornischen Firma Avensoft aus dem Jahr 1997, welches vor einiger Zeit durch das Nachfolgeprodukt nService ersetzt wurde.

Die Anwendung, die einen eigenen Webserver mitbrachte, wurde von vielen Unternehmen weltweit genutzt. Unter den Kunden der Firma Avensoft befinden sich unter anderen die Unternehmen IBM und Nestle sowie die Yale-Universität.

3.2.2 Architektur Systemarchitektur

Der Perfect Tracker benötigt ein Relational Database Management System (RDBMS) wie Microsoft Access, den Microsoft SQL Server, Orace RDBMS oder Sybase IQ. Perfect Tra­cker 7 läuft, bedingt durch den mitgelieferten Webserver, ausschließlich auf Windows­Systemen (ab Windows 95 aufwärts). Die Anwendung wurde in der von Avensoft entwi­ckelten Scriptsprache Simple Server Pages (SSP) programmiert und kann mittels Einsatz derer den eigenen Bedürfnissen angepasst und erweitert werden. Dies ist jedoch die ein­zige Methode, die Funktionalität der Anwendung anzupassen, da es keine Application Programming Interface (API) gibt und Remote Procedure Calls (RPCs) vom System nicht vorgesehen sind.

Erweiterbarkeit

Die Möglichkeiten, das System zu erweitern, sind durch die Eigenentwicklung verhältnis­mäßig vielfältig. Der Entwickler hat die Möglichkeit, sämtliche Formulare und Webseiten der Anwendung zu modifizieren und so den Vorgaben anzupassen. Dies setzt jedoch den Zugriff auf den Quelltext voraus und kann nicht aus dem Administrationsbereich der Anwendung heraus durchgeführt werden. Weiterhin erfordert die Anpassung das Erlernen einer neuen Scriptsprache, welche nur wenig Ähnlichkeit mit anderen gängigen Sprachen hat und daher einen gewissen Extraaufwand bereitet. Ein Verzeichnis, in welchem Plug­ins oder Erweiterungen verfügbar wären, existiert nicht; sämtliche Anpassungen müssen händisch vorgenommen werden.

Systemintegration

Eine Integration von anderen Systemen, wie sie von den meisten aktuellen Issue Tracking Sys­teme bekannt ist, existiert nicht. Die Einbindung eines VCS ist beispielsweise nur durch den Einsatz eines post-commit-hooks[BCSP08] möglich. Eine Anbindung an ein Wiki ist auch hier nur durch die Anpassung der Quelltexte und Systemfunktionen möglich.

Im vorliegenden System wurde zur Realisierung der im Workflow notwendigen beiden unterschiedlichen Tracks (intern und extern) eine weitere Instanz des Perfect Trackers integriert. Auch dies konnte nur durch massive Anpassungen der vorliegenden Systemen umgesetzt werden.

SSP

Die meisten Anpassungen am System werden direkt im Quelltext der Anwendung vorge­nommen. Avensoft hat zu diesem Zweck die Scriptsprache SSP entwickelt, welche vom Perfect Tracker-Server interpretiert wird. SSP orientiert sich dabei entfernt (Komparatoren, Zuweisungen, Kontrollstrukturen) an Microsofts VBScript².

3.2.3 Zusammenfassung Stärken

Die größten Stärken der Anwendung sind sicherlich die umfangreichen Möglichkeiten, das System gemäß den eigenen Vorgaben anzupassen. SSP (Siehe Kapitel 3.2.2, Seite 8) erlaubt den kompletten Umbau der Benutzerführung, des Workflows und anderer elementarer Bedienprinzipen. Auch die Entwicklung eigener Komponenten durch einen Programmierer ist somit möglich.

Schwächen

Die Stärke des Systems ist gleichzeitig ein großer Mangel; sämtliche Anpassungen müssen durch Quelltextänderungen erfolgen, der Einrichtungs- und Administrationsaufwand steigt damit erheblich. Weiterhin werden für sämtliche Anpassungen Kenntnisse der Scriptspra­che SSP vorausgesetzt, ein einfacherer oder komfortablerer Weg wurde nicht vorgesehen. Durch den Betrieb auf dem mitgelieferten proprietären Webserver ist der Betrieb oder eine Portierung der Software auf andere Systeme unmöglich. Der Lizenznehmer ist weiterhin an die geringen Möglichkeiten des Servers gebunden und hat beispielsweise keine Mög­lichkeit, das System zu Lastverteilungszwecken auf mehreren Servern parallel einzusetzen.

Besonderheiten

Der Perfect Tracker operiert im Gegensatz zu JIRA 4 produktorientiert. Dies bedeutet, dass die höchste logische Einteilung nicht ein (kundenspezifisches) Projekt ist, sondern ein 1) Produkt. Dieses kann unterschiedlichen Kunden zugewiesen werden. Ein Produkt kann in Module und Versionen unterteilt werden; Module gliedern ein Produkt dabei in kleinere Bestandteile auf, Versionen in verschiedene Programmveröffentlichungen. Zu jedem Produkt können nun produktbezogene 2) Issues inklusive einer Zuordnung zu einer Produktversion und einem Produktmodul eröffnet werden.

Abbildung in dieser Leseprobe nicht enthalten

Eine weitere Besonderheit des Perfect Trackers ist die Tatsache, dass die Software durch einen Nachfolger ersetzt wurde und nicht mehr weiterentwickelt wird. Der Nachfolger nService setzt auf Microsofts ASP.NET und eliminiert einige der Schwächen des Vorgän­gers.

3.3 Produktanalyse: Atlassian JIRA 4

3.3.1 Einleitung

Die Anwendung JIRA ist ein webbasiertes ITS der australischen Firma Atlassian. Die erste Version des in Java geschriebenen Systems wurde im Oktober 2004 veröffentlicht und zählt damit, im Vergleich zu GNATS (1992) oder Bugzilla (1998), zu den jüngeren ITS wie Trac (2006). Über 20 000 Kunden weltweit nutzen Produkte der Firma Atlassian, darunter bekannte Softwareentwickler wie Adobe, die Apache Foundation und Electronic Arts.

3.3.2 Architektur Systemarchitektur

JIRA wurde komplett in Java entwickelt und benötigt zur Auslieferung der Servlets einen Application Server wie Apache Tomcat, Redhat JBoss oder Eclipse Jetty sowie ein auf dem Server installiertes Java Developers Kit (JDK) der Version 1.6. Zur Speicherung der Daten kann JIRA die meisten RDBMS verwenden. Das zu Evaluationszwecken mitgelieferte Database Management System (DBMS) ist die in Java geschriebene Hyper Structured Query Language Database (HSQLDB), die im Produktivbetrieb jedoch durch ein leistungs­fähigeres DBMS ersetzt werden muss. Mögliche DBMS sind dabei unter anderem MySQL, Oracle RDBMS oder der Microsoft SQL Server.

JIRA stellt zwei Schnittstellen bereit: SOAP und Extensible Markup Language (XML)- RPC.

Erweiterbarkeit

JIRA lässt sich durch eine Vielzahl von teils kostenlosen, teils kommerziellen Plugins erweitern. Zum momentanen Zeitpunkt lassen sich über 200 Plugins mit unterschiedli­chen Funktionen herunterladen. Die Funktionen dieser Plugins reichen dabei von trivialen Änderungen im GUI über komplexere Ergänzungen in den Funktionsweisen (z. B. dem Tagging von Issues) bis zu komplett neuen Programmbestandteilen wie einer aufwändigen Arbeitszeiterfassung.

Mittels der bereitgestellten Schnittstellen lassen sich eigene Plugins entwickeln, um spe­ziellen Anforderungen an das Issue Tracking System gerecht zu werden. Die verfügbare Java-API dürfte dabei den leistungsfähigsten Ansatz repräsentieren, sie umfasst über 4 000 Klassen, welche die Modifikation der meisten Funktionen des Systems ermöglichen.

Systemintegration

JIRA stellt eine große Menge an Integrationsmöglichkeiten für externe Systeme bereit. Konnektoren für die gängigen VCS sind entweder bereits in der Anwendung enthalten oder als Plugin verfügbar. Momentan existieren unter anderem Konnektoren für CVS, SVN, Git, Perforce und ClearCase.

Durch Plugins lassen sich viele Integrated Development Environments (IDEs) direkt mit JIRA verbinden. So können Commits direkt mit Issues verknüpft werden.

Weiterhin ermöglicht JIRA die Einbindung anderer Anwendungen der Firma Atlassian wie FishEye, Crucible, Confluence oder GreenHopper durch interne Verlinkung und Informationsaustausch.

Anpassbarkeit

Besonderes Augenmerk wurde bei der Entwicklung von JIRA auf die Anpassbarkeit der Anwendung an möglichst viele Situationen gelegt. Aus diesem Grund wurde zur Benutzerverwaltung und -authentifizierung die OSUser-Bibliothek³ des OpenSymphony- Projekts ausgewählt, welche für die Anbindung an unterschiedliche Datenbanken sowie das eigentliche Management von Gruppen und Benutzern eine gut getestete und flexible Grundlage schafft. Rollen ermöglichen eine projektspezifische Zuordnung von Rechten zu Benutzern und Benutzergruppen.

Benutzern, Gruppen und Rollen können nun mit einer hohen Granularität unterschiedliche Rechte in Projekten zugeordnet werden. So lassen sich z. B. Statusübergänge im Workflow mit Benutzer-, Gruppen- oder Rollenrestriktionen versehen. Auch der Workflow kann völlig frei definiert werden.

3.3.3 Lizenzierung

Das Lizenzmodell gliedert sich in die drei Grundkategorien für die kommerziellen Nutzung, die akademische Nutzung und die Verwendung in Non-Profit- oder Open Source-Projekten. Während die Nutzung von JIRA in Non-Profit- und Open Source-Projekten komplett kostenlos ist, zahlen akademische Institutionen wie Schulen, Universitäten, Bibliotheken und Museen 50% des Preises für die kommerzielle Verwendung. Die Miete eines gehosteten JIRA ist nur bei kommerzieller Nutzung möglich. Grundsätzlich richten sich die Preise für die Lizenzierung nach der maximal möglichen Anzahl der Benutzer.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3: Benutzer, Gruppen und Rollen in JIRA-Projekten

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.4: Standard-Workflow JIRA

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.1: Lizenzmatrix JIRA (Quelle: Pix Software GmbH)

3.3.4 Zusammenfassung Stärken

Bei der Entwicklung von JIRA wurde besonderes Augenmerk auf ein leistungsfähiges Reporting-System gelegt. Atlassian entwickelte zu diesem Zweck die JIRA Query Langua­ge (JQL) und führte diese mit JIRA 4.0 offiziell ein [Jam09]. Mittels JQL ist der Benutzer in der Lage, komplexe Ausdrücke zur Abfrage und Suche von Issues zu erstellen und zu speichern. Für einfache Abfragen kann der Benutzer ein Formular verwenden, in dem Abfragen durch die Auswahl verschiedener Suchparameter erzeugt werden. Komplexere Ausdrücke lassen sich in einer Textbox erstellen, wobei das System den Benutzer durch die automatische Vervollständigung der eingegebenen Kommandos unterstützt.

Als Beispiel dient der Ausdruck in Listing 3.1 (Seite 14), welcher alle Issues des Projekts Projekt 1 auflistet, die folgende Kriterien erfüllen:

Priorität „Hotfix”, die dringendste im System hinterlegte Priorität.

Bearbeiter nicht zugeordnet Berichterstatter „Kundel”

Status „Open” (siehe Abb. 3.4, Seite 12)

Erstellt vor höchstens einer Woche

Listing 3.1: Beispielabfrage JQL

Abbildung in dieser Leseprobe nicht enthalten

Weitere Stärken des Issue Trackers JIRA 4 ist die Anpassung und die Erweiterung des Anwendungsumfangs an spezielle Bedürfnisse durch den Einsatz von existierenden Plug­ins³ oder die Entwicklung eigener Plugins mittels der bereitgestellten API^{4 5}. Durch den Einsatz von Tastaturkürzeln lässt sich das System sehr schnell und oft ohne die Benutzung der Maus bedienen.

Schwächen

Die größte Schwäche des Systems offenbart sich in der starren Einteilung von Issues in nur vier hierarchisch angeordneten Ebenen (Siehe Abb. 3.5, Seite 15): 1) Projektkategorien, die einer Kategorisierung der Projekte dienen; 2) Projekte; 3) Issues, die einem Projekt zugeordnet sind und einer oder mehreren Versionen zugeordnet sein können; und 4) Sub­Tasks als Möglichkeit, Issues in mehrere Teile zu zerlegen; eine tiefere Schachtelung ist nicht möglich. Weiterhin operiert JIRA 4, anders als der bisher eingesetzte Perfect Tracker 7 (siehe Kapitel 3.2.3, Seite 9), projektorientiert. Dies könnte bei der Migration der verwendeten Hierarchie zu Problemen führen.

3.4 Identifikation möglicher Problemquellen

3.4.1 Umstellung Produktorientierung/Projektorientierung

Die Umstellung des bisher produktorientierten auf ein nun projektorientiertes Tracking wird vermutlich den größten Anpassungsaufwand nach sich ziehen. Zur Abbildung der bisherigen Strukturen des Perfect Trackers in JIRA 4 wird die Entwicklung eines Plugins von Nöten sein, welches die fehlenden Funktionen in JIRA ergänzt:

- Erzeugung und Speicherung eines Produktbaums mit Modulen und Submodulen sowie Versionen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.5: Projektebenen JIRA

- Darstellung der zugeordneten Produkte in einer hierarchischen Form zur Auswahl in einem Issue

Die Zuordnung der Produkte, Module, (Sub-)Komponenten und Versionen zu den Projekten findet dabei extern über die datenbankseitige Zuordnung von Lizenzen zu Kunden statt.

3.4.2 Abhängige Tracks

Der bisherige Workflow sieht zwei Tracks vor:

Customer Service (CS) Dieser Track wird von den Kunden der Firma genutzt, um Tickets zu eröffnen. Er dient als Informationsbasis für den Kunden und kann als solche von ihnen eingesehen werden.

Bug Tracking (ВТ) Wenn alle Voraussetzungen erfüllt sind und das Ticket in die Entwicklung gegeben wird, wird ein neues Ticket im BT eröffnet. Dieser Track dient dazu, den internen Workflow abzubilden, ohne dem Kunden unmittelbare Einsicht in den Vorgang zu ermöglichen. Sobald die interne Entwicklung abgeschlossen ist, wird der Kunde über den (extern einsehbaren) CS über eine Statusänderung benachrichtigt.

Da JIRA keine Möglichkeit bietet, diese Funktion zu übernehmen, muss hier eine gleich­wertige Lösung geschaffen werden.

3.4.3 Andere Probleme Datenschutz

Der Datenschutz ist ein wichtiger Aspekt im Verhalten des Systems. Folgende Überlegun­gen müssen berücksichtigt und umgesetzt werden:

- Tickets des CS-Tracks dürfen ausschließlich von Mitarbeitern des entsprechenden Kunden und der IVU eingesehen werden können. Dies hat folgende Gründe:
- Tickets können sensible Informationen wie betriebswirtschaftliche Kennzahlen, Budgets oder Benutzernamen enthalten.
- Gemeldete Fehler können unter Umständen alle ausgelieferten Systeme betref­fen. Eine Korrektur kann so vorgenommen werden, ohne andere Kunden auf den Fehler aufmerksam zu machen.
- Es soll verhindert werden, dass die Reaktions- und Entwicklungszeiten der Issues von anderen Personen einsehbar sind.
- Informationen über den internen Vorgang (BT) sollen nicht vom Kunden eingesehen werden können.

4 Strukturanalyse

4.1 Analyse der Datenmodelle

4.1.1 Einführung

Zur Vorbereitung der Datenmigration ist es erforderlich, eine Abschätzung der Machbarkeit und des Aufwandes zu erheben. Zu diesem Zweck werden die Datenmodelle der in Frage kommenden Systeme untersucht und hinsichtlich ihres Nutzens und der Komplexität ihrer Verwendung analysiert. Gegendstand der Untersuchung ist hierbei die zweckdienlichste Art und Weise des Zugriffs, welche, abhängig von den zur Verfügung gestellten Mitteln, die Verwendung der API, die Verwendung eines Services (z. B. ein XML-RPC-Webservice), oder der direkte Zugriff auf die Datenbank sein kann. Da zur Eruierung des Migrationsauf­wandes als erstes die Menge und Art der zu migrierenden Daten bekannt sein muss, wird mit der Evaluation des Quellsystems Perfect Tracker 7 (PT7) begonnen. Im zweiten Schritt wird das Zielsystem auf die Möglichkeiten der Abbildung der eventuell transformierten Daten untersucht. Aus den Ergebnissen dieser Untersuchungen wird nun die generelle Machbarkeit sowie die Komplexität der Datenmigration abgeschätzt.

4.1.2 Avensoft Perfect Tracker 7 Datenstruktur und -umfang

Da der Perfect Tracker keinerlei Methoden zum gekapselten Datenzugriff (wie eine API o. ä.) bereitstellt, ist der gewählte Weg der direkte Zugriff auf die Tabellen der Datenbank. Der Perfect Tracker, wie er momentan verwendet wird, speichert die erzeugten Daten in insgesamt 54 Tabellen, wovon 15 in ähnlicher oder gleicher Form für die beiden verwendeten Tracks (CS & BT) existieren. Abzüglich der Tabellen für nicht oder nicht mehr verwendete Funktionen im System ( grau hinterlegt) lässt sich diese Datenmenge auf neun doppelt vorhandene Tabellen reduzieren (siehe Tabelle 4.1, Seite 18). Die Tabellen beginnen jeweils mit dem Präfix „pt7bt_” (BT-Track) respektive „pt7cs_” (CS-Track) und enden auf die in der Tabelle vermerkten Namen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.1: Beschreibung der gemeinsamen Tabellen im Perfect Tracker 7

Weiterhin existieren sechs Tabellen, die ausschließlich dem BT dienen (siehe Tabellen 4.2, Seite 19), eine Tabelle des CS-Tracks (siehe Tabelle 4.3, Seite 19) und eine Tabelle (pt7_registry) zur Verwaltung der PT7-Lizenzen.

Abzüglich der irrelevanten Tabellen müssen demnach die Informationen der folgenden 20 Tabellen migriert werden:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.2: Tabellenbeschreibung Bug Tracking Perfect Tracker 7, Präfix pt7bt_

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4.3: Tabellenbeschreibung Customer Service Perfect Tracker 7, Präfixpt7cs_

Datenkomplexität

Die Komplexität der Datenstrukturen im Perfect Tracker 7 ist von unterschiedlicher Qua­lität. Mehr als die Hälfte der Tabellen befindet sich nur in der 2. Normalform und muss während einer Migration manuell korrigiert und in die 3. Normalform [Cod71] gebracht werden.

Besonderheiten

Eine Besonderheit des Perfect Trackers ist, dass die Dateianhänge der Tickets in der Da­tenbank gespeichert sind. Diese müssten bei einer Migration aus der Datenbank extrahiert und im Dateisystem des JIRA-Servers gespeichert werden.

4.1.3 Atlassian JIRA 4 Einleitung

Das Datenbankschema JIRAs umfasst 107 Tabellen und wird, da der Hersteller Atlassian eine API bereitstellt, in diesem Fall nicht direkt datenbankenseitig, sondern mittels der Java-API⁷ angesprochen. Diese umfasst über 4400 Klassen in knapp 500 Paketen, die zur Entwicklung von Erweiterungen oder zur Migration von Daten verwendet werden können.

4.1.4 Vergleich der Datenmodelle

Die genauere Betrachtung der Datenstrukturen des Perfect Trackers scheint eine Migration unter vertretbarem Aufwand möglich zu machen. Viele der vorhandenen Strukturen sind in gleicher oder ähnlicher Form auch in JIRA verwendet worden. So lässt sich z. B. die Tabelle pt7cs_ttype in JIRA als Custom Field darstellen. Auch die relevanten Attribute Benutzerkennung, E-Mail, Name und Passwort der Benutzer in pt7cs_user und pt7bt_user lassen sich unter Verwendung des UserService der JIRA API migrieren. Die den Benut­zer über den user_type zugeordneten Berechtigungen können über Gruppen und Rollen abgebildet werden. Ein als inaktiv gekennzeichneter Benutzer des Perfect Trackers wird als solcher durch die Nichtmitgliedschaft in der Gruppe jira-users dargestellt. Die unter­schiedlichen Tracks des Perfect Trackers können in JIRA durch je ein kundenspezifisches (Customer Support) und ein gemeinschaftlich genutztes (Bug Tracking) Projekt abgebildet werden. Die Tickets lassen sich mittels JIRAs IssueService übernehmen. Die Dateianhänge der Tickets werden bei der Migration aus der Datenbank extrahiert und unter Verwendung des AttachmentManagers als Referenz auf das Dateisystem abgelegt. Die Abbildung des Produktbaums erfordert die Entwicklung einer wenig komplexen Erweiterung für JIRA.

4.2 Analyse der Systeme

4.2.1 Systemanalyse Avensoft Perfect Tracker 7

Der Perfect Tracker 7 wird als Komplettpaket ausgeliefert und bringt einen eigenen Web- und Anwendungsserver mit sich. Eine Trennung dieser Architektur zum Zweck der Komponentensubstitution oder -ergänzung ist nicht möglich. Die Verwendung des Issue Tracking Systems in einer bestehenden Web- und Anwendungsserverlandschaft ist somit unter Umständen nicht möglich oder erfordert weitere Maßnahmen zur Integration. Diese Architektur unterbindet weiterhin die Möglichkeit der Verteilung des Systems z. B. zu Zwecken des Loadbalancing. Dadurch wird sowohl ein Bottleneck als auch ein Single point of Failure geschaffen. Eine Erweiterung der Kapazitäten durch das Zuschalten eines zweiten Anwendungsservers ist nicht vorgesehen, eine Verteilung der Datenbank ist auf.

[...]

---

¹ Siehe auch: http ://en.wikipedia.org/wiki/Source_lines_of_code

¹ MS VBScript User’s Guide:

² http://msdn.microsoft.com/en-us/library/t0aew7h6.aspx

³ http://www.opensymphony.com/osuser/

⁴ https://plugins.atlassian.com/search/by/jira

⁵ https://does.atlassian.com/jira/4.2/

⁶ https://confluence.atlassian.com/display/JIRA/JIRA+RPC+Services

⁷ Atlassian JIRA 4.2 API: http ://does .atlassian.com/ software/ jira/ docs/api/4.2/