Mein Projektantrag :)

[Tom87]

Hallo zusammen,

bitte um Meinungen zu meinem Projektantrag.

Danke

1. Thema der Projektarbeit

Implementierung eines Bugzilla-Clients.

2. Geplanter Bearbeitungszeitraum

Beginn:

Ende:

3. Projektbeschreibung

Ausgangssituation

Aufträge zum Anpassen von Kundensoftware werden von Kunden der *** GmbH im Bugtrackingtool Bugzilla erfasst. Bugzilla verfügt über ein Webinterface, über welches die Mitarbeiter der *** GmbH Tickets des Kunden einsehen können.

Das Webinterface lässt aus ***-Sicht einige Anpassungsmöglichkeiten vermissen, unter anderem eine Einstellmöglichkeit der Spaltenbreiten in Buglisten.

Die serverbasierende Bugzillainstanz bietet zudem keine Möglichkeit für einen Offlinezugriff, welcher z.B. für Außendienstmitarbeiter sinnvoll wäre.

Eine OpenSource-Client-Lösung wäre wünschenswert, um eine weitgehende Anpassbarkeit an zukünftige Anforderungen zu gewährleisten. Aktuell verfügbare OpenSource-Lösungen werden jedoch nicht mehr gepflegt oder entsprechen nicht den Anforderungen.

Zielsetzung

Das Projektziel besteht darin, einen einfachen Bugzilla-Client zu implementieren, der anpassungsfähig sowie leicht zu warten und zu erweitern ist.

Dieser sollte außerdem die Möglichkeit bieten, bei Bedarf Tickets für einen Offlinezugriff in einer lokalen Datenbank abzulegen.

Geplante Funktionen:

Kommunikation mit der Bugzilla-Instanz

• Anzeige von Tickets
  
• Vom Benutzer anpassbare GUI zum Auflisten der Tickets insbesondere hinsichtlich Spaltenbreite und Sortierung
  
• Möglichkeit zum Speichern von Kopien einzelner Tickets in einer Datenbank
  
• Möglichkeit zum Laden der einzelner Tickets aus dieser Datenbank
  
• Möglichkeit zum Suchen und Gruppieren von Tickets
  

Konsequenzen bei Nichtverwirklichung

Bei Nichtverwirklichung des Projekts wird das Unternehmen auf einen kommerziellen Bugzilla-Client zurückgreifen.

Interne Erweiterungsmöglichkeiten wären dadurch nicht mehr gegeben.

Die dadurch anfallenden Lizenzkosten wären höher als die Kosten einer Eigenentwicklung.

4. Projektumfeld

• Eine bestehende Bugzilla-Instanz in einem externen Kundennetzwerk
  
• Zugriff auf die Bugzilla-Instanz per VPN
  
• Entwicklerarbeitsplätze basieren auf den Plattformen: Linux, Windows und OS X
  
• Teammitglieder zum Teil im Außendienst
  

5. Projektphasen mit Zeitplanung

Auftragserfassung [Gesamtaufwand: 6 h]

[3 h] Gespräche mit den zukünftigen Anwendern

[3 h] Erstellen der Spezifikationen

Planungsphase [Gesamtaufwand: 10 h]

[1 h] Erstellung Projekt- & Kostenplan

[3 h] Planung und Anfertigung der Programmabläufe

[3 h] Planung der Klassen nach MVC

[2 h] Datenbankplanung

[1 h] Fortlaufende Dokumentation der Planung

Realisierung/Umsetzung [Gesamtaufwand: 38 h]

[20 h] Implementierung des Clients

[10 h] Implementierung der Schnittstelle zu Bugzilla

[5 h] Erstellen der Datenbank

[3 h] Fortlaufende Dokumentation

Qualitätssicherung [Gesamtaufwand: 11 h]

[3 h] Erstellen eines Testplanes

[2 h] Definition von Testmaßnahmen und -Kriterien

[2 h] Generieren von Testdaten

[3 h] Testphase

[1 h] Erfassung der Testergebnisse und -Protokoll

Projektübergabe [Gesamtaufwand: 5 h]

[4 h] Verfassen eines Nutzerhandbuch

[1 h] Mitarbeitereinweisung

Gesamtaufwand: 70 h

Ergebnis

Das angestrebte Ergebnis entspricht einem einfachen Bugzilla-Client, bei dem die Ansicht angepasst werden kann und die Tickets bei Bedarf lokal abgelegt werden können.

Benötigte technische Unterlagen/Dokumente

Folgende Dokumente/Unterlagen werden zur Projektumsetzung benötigt:

Dokumentation Bugzilla API

Dokumentation zur API der Implementierungssprache

6. Dokumentation zur Projektarbeit

1. Inhaltsverzeichnis

2. Projektbeschreibung

- 1. Ausgangslage

- 2. Gründe für die Umsetzung des Projekts

- 3. Projektziele

3. Projektplanung

- 1. Ist-Analyse

- 2. Soll-Konzept

- 3. Vorüberlegung zur Umsetzung

-- 1. Anfertigung eines Programmablaufplan

-- 2. Anfertigung eines Klassendiagramm

-- 3. Auswahl von Implementierungssprache(n)/Framework

-- 4. Datenbankplanung

- 4. Vorbereitungsgespräche

4. Projektumsetzung

- 1. Einrichten einer Versionsverwaltung

- 2. Implementierung des Clients

- 3. Implementierung der Schnittstelle zu Bugzilla

- 4. Datenbank

5. Tests

- 1. Generieren der Testdaten

- 2. Testvorgang

- 3. Testprotokoll

5. Projektabschluss

- 1. Erstellen der internen Dokumentation

- 2. Soll-Analyse

6. Glossar

7. Anhang

- 1. Quelltexte

- 2. Screenshots

7. Anlagen

Keine

8. Präsentationsmittel

• Beamer
  
• Flipchart
  

[flashpixx]

Also mal salopp gesagt, nur weil man die "Spaltenbreite" nicht anpassen kann, soll ein eigener Client entwickelt werden. Das Projekt erscheint mir bedenklich, weil ich die Synchronisation der Daten definitiv ein Problem wird, vor allem wenn ein Ticket online neuere Informationen enthält als z.B. das Offlinesyste, d.h. der Merge ist schwierig.

Ich würde hier sagen, implementiere die Funktionalität in Bugzilla direkt und nutze ein System wie VPN damit sich darauf verbinden kann bzw. https. Die Entwicklung für einen Client sehe ich nicht, denn wenn man ein Webinterface hat, warum soll man eine eigene Anwendung haben? Außerdem ist bei einer Anwendung direkt die Fage, wie kommuniziert sie mit Bugzilla, hierzu würde man einen Webservice einsetzen und darüber verlierst Du kein Wort im Antrag, Du hast somit noch eine Kommunikationsschicht in der Anwendung

[Tom87]

Hallo Flashpixx,

eine Implementierung in das Bugzilla-Webinterface ist in diesem Fall nicht möglich, da das System vom Kunden verwaltet und gehostet wird.

In der Praxis wird vom Team für den Zugriff ein Bugzilla-Client eingesetzt, dieser befindet sich gerade in der Evaluierungsphase und wird von den meisten als Vorteil gegenüber dem Webinterface gesehen.

Wie im Projektantrag beschrieben, entspricht dieser zwar, bis auf die Weiterentwicklungsmöglichkeiten die bei einer OpenSource Lösung gegeben ist, dem Anforderungsprofil, ist aber wegen der Lizenzkosten eher der Plan B (falls das Projekt von mir scheitern sollte).

Soweit ich weiss, bietet Bugzilla einen WebService mit dem mittels REST mit der Bugzillainstanz kommuniziert werden kann.

Der angestrebte Client ist natürlich nur ein Startpunkt und soll weiter ausgebaut werden.

[Schiller256]

Einen Bugzilla Client baust du mit Sicherheit nicht in 70 Std. Zumal deine Begründung weshalb du das machen willst schon etwas an den Haaren herbeigezogen klingt. Denn nur weil ich eine Spaltenbreite nicht ändern kann fange ich doch nicht an einen neuen Client zu bauen.

Das Offline Thema darfst du auch nicht unterschätzen. Wenn das bugzilla nicht unterstützt müsstest du den merge von Hand selbst machen.

Also Open Source Alternative kannst du dir eclipse mylyn anschauen. Dort gibt es auch einen connector für bugzilla.

Bearbeitet 12. September 2013 von Schiller256

[Tom87]

Bitte versteift euch doch nicht so auf die Spaltenbreite, da dieses in dem Zusammenhang nur als Beispiel für die unflexible Handhabung des Webinterfaces.

Danke aber für den Hinweis darauf, ich werde es im Antrag diesbezüglich umschreiben.

Es ist hoffentlich auch aus dem Projektantrag ersichtlich, dass ich keinen vollwertigen Bugzillaclient schreiben möchte, sondern nur eine Gui mit einer Offlinefähigen Ansicht einer Ticketversion.

In dem Projekt ist nicht geplant ein Ticketupdate in irgendeiner Form zu mergen.

Bearbeitet 12. September 2013 von Tom87

[Schiller256]

Selbst wenn du noch 5 weitere Gründe aufführen würdest das kannst du in 70 Std. nicht mal ansatzweise leisten. Was du schaffst ist eine DB wo du lokal deinen Tickets abgelegt bekommst und vielleicht wieder angezeigt. Schon wenn du eine Möglichkeit bieten willst das diese Daten auch geändert werden sollen musst du dir Gedanken machen was passiert wenn er gerade keine Netzverbindung hast.

Weitere Punkte die du ganz dringend betrachten musst sind. Was passiert bei Datenmodelländerungen in Bugzilla in deinem Client? Wie migrierst du deine Tickets auf das neue DB Modell? Was machst du wenn in deinem Server neue Attribute hinzu kommen? Wann sind sie dann in deinem Client auch abrufbar? Also das Thema kannst du niemals in 70 Std. auch nur ansatzweise vernünftig bearbeiten.

Hinzu kommt es es bereits fertige Software gibt die dir einen Client wie du ihn haben willst bieten sowohl open source siehe mylyn als auch als Kaufsoftware. Auch hier wirst du nur sehr schwer überhaupt kaufmännisch argumentieren können weshalb eine Eigenentwicklung auf Dauer billiger ist als eine Kaufprodukt.

[Tom87]

Selbst wenn du noch 5 weitere Gründe aufführen würdest das kannst du in 70 Std. nicht mal ansatzweise leisten. Was du schaffst ist eine DB wo du lokal deinen Tickets abgelegt bekommst und vielleicht wieder angezeigt.

Im Prinzip steht das ja auch so im Antrag...

Hinzu kommt es es bereits fertige Software gibt die dir einen Client wie du ihn haben willst bieten sowohl open source siehe mylyn als auch als Kaufsoftware. Auch hier wirst du nur sehr schwer überhaupt kaufmännisch argumentieren können weshalb eine Eigenentwicklung auf Dauer billiger ist als eine Kaufprodukt.

Das Problem bei mylyn sehe ich in der Plattformabhängigkeit des Tools. Wenn kein Eclipse sondern zum Beispiel IntellJ verwendet wird, gibt es hierzu keine passende Alternative:

Mylyn alternative for IntelliJ IDEA? - Stack Overflow

[flashpixx]

Das Problem bei mylyn sehe ich in der Plattformabhängigkeit des Tools. Wenn kein Eclipse sondern zum Beispiel IntellJ verwendet wird, gibt es hierzu keine passende Alternative:

Mylyn alternative for IntelliJ IDEA? - Stack Overflow

Wenn man mal die kostenpflichten Angebote anschaut, dann sollte man dafür eine Lösung finden, denn im Businessumfeld sollte dies möglich sein, denn man ist ja nicht auf Opensource gebunden. Aber wie schon hier mehrfach gesagt, sprengt ein solches Projekt die 70h bei weitem. Ich sehe ein massives Problem auf fachlicher Seite, dass Du nicht weißt wie Bugzilla die Daten bereit stellt, alleine das Konzept und die Implementation eines Webservice sprengt den Umfang von 70h. Das Datenmodell + entsprechende Strukturen, um ein fehlerfreies Mergen der Daten zu erreichen ebenso.

Im Grunde sehe ich bei diesem Antrag fachliche Probleme, die Du aktuell überhaupt nicht sinnvoll strukturieren kannst.

[Schiller256]

Das Problem bei mylyn sehe ich in der Plattformabhängigkeit des Tools. Wenn kein Eclipse sondern zum Beispiel IntellJ verwendet wird, gibt es hierzu keine passende Alternative:

Mylyn alternative for IntelliJ IDEA? - Stack Overflow

Das Problem löst du etwas auch noch in deinem Projekt? Wie willst du denn bitte plugins für eclipse und IntelliJ noch bauen?

Hast du dir vielleicht mal überlegt ob es nicht vielleicht möglich wäre eine auf eclipse basierendes Produkt zu erstellen welches erstmal nur mylyn enthält? Du brauchst nicht eine komplette IDE für mylyn ausrollen du kannst auch nur eine eclipse Basis mit dem mylyn plugins ausliefern und dann hättest du dein Projekt auch damit erschlagen.

[Tom87]

Ok, danke ich such mir was neues.