Home

18. Dezember 2017

Übungen zur Vorlesung Software Engineering I WS 2017 / 2018

Mid-Term (Freiwillige Bearbeitung und Abgabe bis: Donnerstag, den 25 .01.2018, 18:00 Uhr)

Zusammenfassung: In der Übung Nr. 4-2 sowie 8-2 haben sie das Prio-Tool entwickelt, mit dem man User Stories verwalten kann. In diesem Mid-Term soll es ihre Aufgabe sein, dieses Tool um eine Funktionalität zur Analyse der Qualität von User Stories zu erweitern.

Motivation und Problemstellung: In der Vorlesung haben sie in Kapitel 3 eine Struktur zur Beschreibung einer User Story nach (Cohn, 2004) kennengelernt (vgl. Kapitel 3, Folie 18). Diese Struktur bzw. Template dient dazu, eine einheitliche syntaktische Beschreibung einer User Story zu erhalten, um insbesondere den Mehrwert einer User Story Ausdruck zu geben. Demnach soll eine User Story auch immer aus Sichtweise eines (bekannten) Akteurs aktiv geschrieben werden (vgl. auch Kapitel 3, Folie 29). Auch die gewünschte funktionale Anforderung soll klar umfasst sein. Eine qualitativ gute User Stories muss somit diese drei Bereiche enthalten! Fehlt einer dieser Bereiche, so reduziert sich die Qualität der User Story entsprechend. Auch unscharfe Formulierungen, die Verwendung von unbekannten Akteuren oder die Verwendung von Bandwurmsätzen (vgl. Kapitel 3, Folie 29) kann die Qualität nachhaltig reduzieren.

Zielsetzung: Ihre zu entwickelnde Analyse-Funktion soll die Qualität von eingegeben User Stories anhand einer Metrik bewerten. Diese Metrik (eine Funktion) nimmt eine User Story als Eingabe und liefert ein Maß für die Qualität der User Story.

Funktionale Anforderungen: US_MD_1: Als Anwender möchte ich eine bereits eingegebene User Story analysieren können, um ihre Qualität festzustellen, und um somit auch die Qualität aller User Stories langfristig zu optimieren und sicherzustellen.

Details: Die Ausführung der Analyse-Funktion soll mit Hilfe des Befehls analyze mit der Angabe einer bekannten ID einer User Story erfolgen.

Eine Ausgabe soll dann die bewertete Qualität der User Story in Prozent (%) ausdrücken. Beispiel (Die Zahl 1 entspricht der ID einer gegebenen User Story):

> analyze 1
Die User Story mit der ID 1 hat folgende Qualität:
 100% (sehr gut)

Der Befehl analyze kann auch mit Parameter verwendet werden. Der Parameter – all dient dazu, die durchschnittliche Qualität aller User Stories zu bewerten. Beispiel:

> analyze – all
Ihre 13 User Stories haben durchschnittlich folgende Qualität:
 87,5% (gut)

Die genaue bzw. vollständige prozentuale Verteilung zur Bewertung der Qualität sollten sie im Rahmen ihrer Metrik selber definieren.

Mit dem Parameter – details lassen sich die identifizierten Defizite bei der Analyse einer User Story ausgeben.

Beispiel Nr. 1:

> analyze 2 – details
Die User Story mit der ID 2 hat folgende Qualität:
 70 % (befriedigend)

Details:
 Kein schriftlicher Mehrwert zu erkennen (- 30 %)

Beispiel Nr. 2:

> analyze 1 – details
Die User Story mit der ID 1 hat folgende Qualität:
 100% (sehr gut)

Details:
 Alles ok

Beispiel Nr. 3: Mit dem Parameter – hints können zusätzliche Hinweise (engl.: hints ) zur Optimierung ausgegebenen werden:

> analyze 3 – details – hints
Die User Story mit der ID 3 hat folgende Qualität:
50 % (ausreichend)

Details:
 Kein schriftlicher Mehrwert zu erkennen (- 30 %)
 Akteur („Student“) ist nicht bekannt (- 20%)

Hints:
Fügen sie einen schriftlichen Mehrwert hinzu!
Registrieren sie einen neuen Akteur!

Weitere Defizite, die zu einer prozentualen Herabstufung der Qualität einer User Story führen, können sie gerne selber definieren und als Algorithmus implementieren.

Falls ein Akteur in einer User Story nicht bekannt ist, so kann er in ihrem System hinzugefügt werden. Dazu dient folgende User Story:

US_MD_2: Als Anwender möchte ich Bezeichnungen für Akteure in das Prio-Tool registrieren, um die Qualitätsanalyse bei einer User Story zu optimieren.

Detail: Zur Eintragung von Bezeichnungen für Akteure soll der Befehl addElement dienen. Ein Akteur kann mit dem zusätzlichen Parameter – actor registriert werden.

Zusammenhängendes Beispiel (in Zusammenhang mit dem obigen Beispiel):

> analyze 3 – details – hints
Die User Story mit der ID 3 hat folgende Qualität:
 50 % (ausreichend)

Details:
 Kein schriftlicher Mehrwert zu erkennen (- 30%)
 Akteur („Student“) ist nicht bekannt (- 20%)

Hints:
 Fügen sie einen schriftlichen Mehrwert hinzu!
 Registrieren sie einen neuen Akteur!

> addElement – actor Student
Der Akteur Student wurde im System registriert!

> analyze 3 – details
Die User Story mit der ID 3 hat folgende Qualität:
 30 % (befriedigend)

Details:
 Kein schriftlicher Mehrwert zu erkennen (- 30%)

Die aktuell registrierten Akteure können mit dem Befehl actors ausgeben werden. Beispiel:

> actors
Student
Professor

US_MD_3: Als Anwender möchte ich den zuletzt eingegebenen Befehl rückgängig machen, damit ich falsch eingegebene Eingaben löschen kann. Damit soll allgemein die Usability (Bedienbarkeit) des Tools verbessert werden.

Details: Das Rückgängigmachen von Befehlen soll durch den Befehl undo erfolgen. In dieser Version des Prio-Tools soll das Eintragen von User Stories sowie von Akteuren rückgängig gemacht werden.

Zusammenhängendes Beispiel:

> addElement – actor Student
Der Akteur Student wurde im System registriert!

> actors
Student
Professor

> undo

> actors
Professor

> undo
nothing to undo!

Technische Anforderungen: Ø Die prototypische Entwicklung soll, analog zur Aufgabe 4-2, auf der Grundlage der Sprache Java erfolgen.

Ø Als Grundlage zur Umsetzung aller Kommandos des Prio-Tools soll das Command Pattern verwendet werden.

Ø Neue Algorithmen zur Überprüfung der Qualität und somit zur Aufdeckung von Defiziten einer User Story sollen flexibel in das System integriert werden können. Welches Pattern könnte hier für eine Umsetzung dieser Anforderung nützlich sein?

Ø Welche Elemente könnten mit dem Befehl addElement für eine Überprüfung der Qualität noch hinzugefügt werden? Bitte zumindest theoretisch reflektieren.

Ihre Aufgaben, erwartete Ergebnisse (engl.: deliverables): Liefern sie eine prototypische Implementierung der oben beschrieben funktionalen und technischen Anforderungen. Laden sie den Source Code der Implementierung „gezipt“ auf LEA hoch (Assignment: Mid-Term)

Modellieren sie das resultierende Klassendiagramm unter Verwendung der notwendigen Muster anhand eines UML-Klassendiagramms. Upload als PDF ebenfalls auf LEA!

Der Vorgang einer Überprüfung der Qualität einer User Story soll mit einem UML Sequenzdiagramm anhand eines konkreten Szenarios modelliert werden. Upload als PDF ebenfalls auf LEA!

Laden sie das resultierende bzw. aktualisierte UML Paketdiagramm auf LEA hoch (vgl. auch Aufgabe 8-2).

Einen schriftlich beschriebenen Akzeptanztest (vgl. Kapitel 3, Abschnitt 3.3), der von „ihrem“ Kunden eigenständig ausgeführt werden kann. Upload ebenfalls auf LEA!

Vorstellung der Ergebnisse: Die Studierenden tragen mir ihre Ergebnisse am Freitag, den 26.01.2018 im Rahmen eines 10-minütigen Vortrags vor. Die Gestaltung des Vortrags obliegt ihnen! Es sollte aber auf jeden Fall eine Demo der Anwendung gegeben werden. Ich werde dann den schriftlichen Akzeptanztest verwenden, um die Abnahme des Tools „offiziell“ durchzuführen. Ein Beamer wird nicht bereitstehen, der Vortrag kann an einem Laptop präsentiert werden. Weitere Unterlagen (z.B. die UML-Modelle) können gerne als Handout mitgebracht werden.

Eine Bearbeitung und Vorstellung des Mid-Term-Projekts ist durch eine Gruppe von bis zu 3 Studierenden möglich!

Zum Vortrag registrieren sie sich bitte in eine dafür vorgesehene Liste ein, die an der Türe meines Büros C 218 aushängt. Eine Anmeldung per E-Mail ist nicht erwünscht.