Seite 1 Machbarkeitsstudie Sprinter Dieses Beispiel führt

Machbarkeitsstudie Sprinter
Dieses Beispiel führt exemplarisch einige der Technologien rund um das Thema JEE vor. Dabei liegt der
Schwerpunkt darauf, kompakt den Ansatz vorzustellen, ohne im Detail alle Möglichkeiten aufzuzeigen.
Weiterhin werden die Techniken teilweise in einem nicht optimalen Kontext eingesetzt, so dass die
Idee „wie es funktioniert“ deutlich vor „wo ist der beste Einsatz“ bei der Entwicklung stand. Weiterhin
stand bei der Entwicklung die Software-Architektur nicht im Mittelpunkt. Etwas erfahrene Entwickler
sollten schnell den Drang nach einer Zwischenschicht oder der Aufteilung einer Klasse spüren. Positiv
formuliert steht der einfache Einsatz der Technologien im Mittelpunkt, der bei der Entwicklung eigener
Programme sicherlich viele übertragbare Ideen aufzeigt.
Dieses Dokument zeigt, wie das Projekt unter NetBeans 8.0.1 mit dem Glassfish-Server 4.1 gestartet
werden kann, eine Übertragung auf Eclipse ist leicht möglich.
Das Projekt selbst realisiert eine Web-basierte Software zur Verwaltung von Sprints des agilen
Vorgehensmodells Scrum. Sehr vereinfacht beschreibt ein Sprint die konkreten Projektaufgaben (hier
Backlog-Elemente genannt), die in einem festen Zeitrahmen von den Mitarbeitern des Teams
bearbeitet werden sollen. Zu jeder Aufgabe gibt es eine Aufwandsschätzung und jeder Bearbeiter der
Aufgabe hält kontinuierlich, z.B. täglich, fest, zu welchem Prozentanteil die Aufgabe abgeschlossen ist
und viele Stunden mit der Bearbeitung verbracht wurden. Weitere Informationen zu Scrum und Sprints
findet man z. B. in [Kle13]. Gibt man dann einen gewissen Zeitrahmen für einen Sprint vor, unterstützt
das Werkzeug dabei festzustellen, ob die Arbeiten im kalkulierten Zeitrahmen abgeschlossen werden
können. Eine informelle Anforderungsanalyse befindet sich am Ende des Dokuments.
Bei der folgenden Darstellung der Installation wird davon ausgegangen, dass einige Grundkenntnisse
in
NetBeans
vorliegen,
Details
kann
man
z.
B.
http://home.edvsz.hsosnabrueck.de/skleuker/querschnittlich/NetbeansNutzung.pdf entnehmen.
Abbildung 1: Einrichtung der Datenbank
Nachdem das Projekt in NetBeans geöffnet wurde, muss eine Datenbank angelegt und integriert
werden. Dazu wird auf dem üblichen Weg eine Datenbank angelegt, es sollte dazu ein Nutzer mit
Passwort angegeben werden, wie es in Abbildung 1 angedeutet ist.
Seite 1
Abbildung 2: Einrichtung der Datenbankverbindung
Im nächsten Schritt muss die Datei persistence.xml angelegt werden, was über einen Rechtsklick auf
dem Projekt erfolgt (New… > Other > Persistence > Persistence Unit). Zunächst muss der Persistence
Unit Name „SprinterPU“ sein. Der Persistence Provider ist EclipseLink (JPA 2.1). Unter Data Source wird
rechts zunächst „Create New Data Source“ ausgewählt. Dann wird als JNDI Name
„java:app/jdbc/SprinterDB“ eingetragen und bei der Database Connection die zuvor angelegte
Datenbank ausgewählt, wie es Abbildung 2 zeigt.
Abbildung 3: Übersicht über Verbindungsdaten
Abbildung 3 zeigt den gesamten Eintrag für die neue Persistence Unit.
Abbildung 4: Neu entstandener Ordner Server Resources
Die gerade vorgenommen Einstellungen werden in NetBeans 8.0.1 in einem neu entstehenden Ordner
Server Resources abgespeichert. Die Einstellungen liegen in der Server-individuellen Datei glassfishresources.xml, wie Abbildung 4 zeigt.
Seite 2
Abbildung 5: Vorbereitung zum Kopieren von glassfish-resources.xml
Diese Datei muss allerdings nach dem Standard im Ordner WEB-INF liegen. Im konkreten Fall wird die
Datei einfach in den passenden Ordner kopiert. Dazu wird ein Rechtsklick auf der Datei gemacht und
„Copy“ ausgewählt, wie es Abbildung 5 zeigt.
Abbildung 6: Einfügen der kopierten Datei
Danach wird mit einem Rechtsklick auf dem Ordner WEB-INF die Datei mit „Paste“ eingefügt, wie in
Abbildung 6 dargestellt.
Abbildung 7: Aktualisiertes WEB-INF-Verzeichnis
Ein Ausschnitt aus Endergebnis zeigt Abbildung 7.
Seite 3
Man beachte, dass Änderungen in der persistence.xml, die die Data Source betreffen, immer in der
Datei glassfish-resources.xml im falschen Ordner gespeichert werden, so dass die Datei nach der
Änderung erneut in den richtigen Ordner zu kopieren ist. Dazu ist die alte Datei vorher zu löschen.
Danach kann das Projekt mit „Run“ einfach gestartet werden, Server und Datenbank werden
mitgestartet, dürften aber auch schon vorher gestartet werden.
Abbildung 8: Erneute Übersetzung des Projekts
Sollte die Applikation nicht starten und der Glassfish eine Fehlermeldung werfen, könnten die
Probleme bei Start von Glassfish liegen (Problem wurde mit NetBeans 8.0.1 eingeführt). Die Meldung
sieht dann ähnlich zu folgendem Text aus.
Incrementally redeploying Sprinter
GlassFish Server 4.1, redeploy, null, false
F:\workspaces\NetbeansWork_WS14\Sprinter\nbproject\build-impl.xml:1051: The module has not been
deployed.
Zunächst ist das Projekt vor dem erneuten Startversuch neu zu übersetzen, wie es Abbildung 8 zeigt.
Abbildung 9: Notwendiger Restart bei Server-Problemen
Der Server ist dann unter „Services“ neu zu starten, wie es Abbildung 9 zeigt. Es ist vorher zu prüfen,
dass die Datenbank läuft.
[Kle13] S. Kleuker, Grundkurs Software-Engineering mit UML, 3. aktualisierte Auflage, Springer Vieweg,
Wiesbaden, 2013
Seite 4
Anhang: Anforderungsspezifikation „Sprinter“
Bei unserer Sprintplanung wird festgelegt, welche Backlog-Elemente in dem aktuellen Sprint
abgearbeitet werden sollen. Zusammen mit den Mitarbeitern wird dazu jeweils der Aufwand in
Stunden geschätzt und dem Element ein Titel gegeben. Weiterhin wird festgelegt, welcher
Mitarbeiter mit welcher Stundenanzahl an dem Element arbeitet.
Während des Sprints sollen die Mitarbeiter möglichst täglich für ihre Backlog-Elemente festhalten,
wieviele Stunden sie insgesamt schon daran gearbeitet haben und wie sie für ihren Teil den
Fertigstellungsgrad beurteilen.
Zu erstellen ist ein kleines Verwaltungswerkzeug, das festhält, welche Mitarbeiter an welchen
Backlog-Elementen arbeiten und es ermöglicht, die verbrauchten Stunden und den
Fertigstellungsgrad zu erfassen. Aus den eingegebenen Daten soll für ein Backlog-Element berechnet
werden, wie hoch der Fertigstellungsgrad ist, wieviele Stunden bereits daran gearbeitet wurde und
wie der daraus prognostizierte finale Aufwand ist. Weiterhin ist sicherzustellen, dass maximal so viele
Stunden auf die Mitarbeiter verteilt werden, wie für das jeweilige Backlog-Element geschätzt
wurden. Die auf die Mitarbeiter verteilte Stundenzahl muss nicht genau dem Aufwand des BacklogElements entsprechen, da wir so Risikopuffer einplanen.
Zur Verwaltung müssen die Mitarbeiter mit Namen und Mitarbeiternummer und die BacklogElemente erfasst werden können. Diese Eingaben sollen alle editierbar und löschbar sein.
Da das Unternehmen wächst und mehrere Software-Produktentwicklungen parallel stattfinden, soll
das Werkzeug auch die Verwaltung mehrerer Sprints erlauben, die mit ihren Start- und Endterminen
zu erfassen sind. Jedem Sprint werden dann mehrere Backlog-Elemente zugeordnet, weiterhin hat
jeder Sprint einen maximal zur Verfügung stehenden Aufwand an Stunden.
Neben dem Anlegen und Verändern von Sprints soll die Software auch prüfen, dass nur der zur
Verfügung stehende Aufwand auf die Backlog-Elemente verteilt wird. Weiter soll auch für Sprints
berechnet werden können, wie hoch der Fertigstellungsgrad ist, wieviele Stunden bereits daran
gearbeitet wurde und wie der daraus prognostizierte finale Aufwand ist. Auch Sprints können
Risikopuffer enthalten, so dass nicht der gesamte Aufwand auf Backlog-Elemente verteilt sein muss.
Die Software soll durch eine Visualisierung mit Hilfe eines Kanban-Brettes aktualisiert werden, dabei
wird jedem Backlog-Element einer der in der Kopfzeile genannten Zustände zugeordnet. Es ist
sicherzustellen, dass der Zustand „fertig“ nur angenommen wird, wenn der Fertigstellungsgrad bei
100% liegt.
Seite 5