Der Reise-Butler ist die Smartphone-App für den wissbegierigen Reisenden und Fallbeispiel für die Methode CARDS+.


In den vergangenen Wochen haben sich Moritz und Richard darum gekümmert, die formalen Vorgaben im SE-Projekt zu erfüllen. Der Rest des Teams hat sich um den Aufbau der Arbeitsumgebung für sie gekümmert und versucht, einen ersten Durchstich der Anwendung zu realisieren. Der Fokus lag dabei vorrangig auf der Automatisierung der Build-Pipeline inklusive Testautomatisierung und einer geskripteten und damit jederzeit wiederholbaren Installation in der Cloud.

Richard hat die Projektbeschreibung erstellt. Um den Aufwand für die Erstellung des Dokumentes so gering wie möglich zu halten, hat er die von eMundo eingereichten Bewerbungsunterlagen für das SE-Projekt weitestgehend wiederverwendet. Die meiste Arbeit steckt er in die Beschreibung der Projektorganisation. Da sich das Team bewusst gegen Scrum entschieden hat, muss Richard unter anderem das kanban-basierte Vorgehen skizzieren, den Regeltermin “Weekly” beschreiben und die formale Abnahme auf Basis der Schätzmethode Use-Case-Points erklären.

21-export-projektbeschreibung

Zusätzlich gehören zur Projektbeschreibung noch die Wiki-Exporte von Glossar und Systembeschreibung (als Pflichtenheft) sowie die vertraglichen Vereinbarungen zwischen Auftraggeber (die Firma eMundo) und Auftragnehmer (das Projektteam der TU) zu den Urheber- und Nutzungsrechten, Schadensersatzansprüchen, Gewährleistung, Wartungsansprüchen, anwendbares Recht, Gerichtsstand und das Ende des Vertragsverhältnisses.

Moritz bezeichnet die Projektbeschreibung als «notwendiges Übel» ohne echten Mehrwert für das Produkt. Darum schreibt Richard ohne Unterstützung von Moritz das Dokument im Teambereich, nicht im Wiki. Es ist nicht Teil der Produktdokumentation. Moritz investiert seine Arbeitszeit in die Pflege der Topics, Epics und Cases. Auf der einen Seite, um ein Pflichtenheft daraus zu generieren, was neben der Projektbeschreibung ebenfalls eine Auflage für die Durchführung eines SE-Projektes ist. Auf der anderen Seite, um das Wissen über den Reise-Butler nachhaltig zu sichern. Bei den Cases lässt er bewusst die Lösung immer offen. Hier wird er das Feedback des Teams einfordern, wenn der Case realisiert wird und damit die Lösung klar ist. So stellt Moritz außerdem sicher, dass die Studenten ihren Beitrag zum Pflichtenheft leisten und sich so ihre — hoffentlich — gute Note verdienen.

Im Weekly präsentiert das Team den Durchstich. Sie haben sich darauf konzentriert, einen ersten Entwurf der Android-App zu machen. Dabei haben sie wie von Moritz gefordert den Fokus auf den Aufbau der Infrastruktur und die Automatisierung von Test und Installation in der Cloud gelegt. Der Durchstich ist darum nicht sehr spektakulär. Er besteht aus dem Screen für die Anmeldung. Allerdings verwendet die App bereits den Service NutzerManager mit einer Datenbank als Komponente der Assistenz.

Der Steckbrief gibt eine sehr kurze Beschreibung zum Zweck des Screens in der Art einer «management summary». Die Spalte Technologie wird dazu benutzt, die UI-Komponenten in diesem Screen aufzuzählen, inklusive der Verlinkung zu https://material.io/guidelines/.

Der Steckbrief gibt eine sehr kurze Beschreibung zum Zweck des Services in der Art einer «management summary». Die Spalte Technologie wird dazu benutzt, alle für die Umsetzung relevanten Module (als Link) aufzulisten. Hier handelt es sich um einen Spring-Boot-Container mit Integration von Apache Kafka (für Messaging) und Apache Cassandra (für Persistenz).

Der Steckbrief gibt eine sehr kurze Beschreibung zum Zweck des Services in der Art einer «management summary». Die Spalte Technologie wird dazu benutzt, alle für die Umsetzung relevanten Module (als Link) aufzulisten. Hier ist es die Datenbank Apache Cassandra.

Moritz ist beeindruckt von der Automatisierung. Das REST-API vom Service NutzerManager wird durch Unit- und Fitnesse-Tests überprüft, die in einer CI-Pipeline automatisch ausgeführt werden. Jeder Docker-Container kann auf Knopfdruck erstellt und in der Cloud installiert werden.

Beim Test der Android-App nutzen sie die Möglichkeiten von Android Studio für Unit- und UI-Tests und folgten im Wesentlichen den Anleitungen und Empfehlungen von Google. Bei dem einfachen Screen für die Anmeldung gab es auch keinerlei Probleme mit diesem Ansatz.

Besonders zufrieden ist Moritz, dass das Team ihre Entscheidungen im Wiki dokumentiert hat. Jedes wichtige Modul haben sie erfasst.

« Ich bin total begeistert, dass ihr euch die Zeit genommen habt, die Module im Wiki zu erfassen. », lobt Moritz.

« Wir waren uns beim Baustein nicht sicher. Eine Entscheidung sollte gemäß der Methode CARDS+ mit dem Baustein Decision beschrieben werden. Aber wir hatten nur eine Lösung betrachtet. Und bei jeder Entscheidung sind ja mindestens zwei Lösungen erforderlich. », antwortet Anne.

« Wir waren uns sicher, dass wir mit unserer Wahl richtig liegen. Wir wollten keine Zeit in die Analyse einer Alternative investieren. », ergänzt Julius.

Moritz antwortet: « In diesem Fall habt ihr alles richtig gemacht. Und Entscheidungen werden in CARDS+ nicht nur mit dem Baustein Decision dokumentiert. Jedes Modul, dass ihr beschreibt, weil ihr es verwendet, dokumentiert eine Entscheidung. Im Baustein Service wird ein Modul als Technologie eingetragen, was ebenfalls eine Entscheidung ist. Gleiches gilt für den Baustein Case. im Abschnitt Lösung legt ihr fest, wie ihr das Problem im Case ganz konkret in der Anwendung löst. »

« Wozu gibt es dann den Baustein Decision? », fragt Anne.

« Es wird immer Situationen geben, wo ihr euch nicht so sicher seid wie jetzt. Und wie du selbst gesagt hast, gibt es nur einen Baustein, wo Alternativen betrachtet werden. Und das ist der Baustein Decision. Die Begründung der Entscheidung ist eine weitere Besonderheit im Baustein. », erklärt Moritz.

Am Beispiel ihrer Entscheidung für Espresso als Grundlage für die Implementierung von UI-Tests zeigt Moritz, warum der Baustein Decision sehr wertvoll sein kann, auch ohne echte Lösungsoptionen.

Gemeinsam haben sie in wenigen Minuten ihre Entscheidung für Espresso dokumentiert, inklusive einer nachvollziehbaren Begründung. Die notwendige alternative Lösung, Selendroid, ist nur Platzhalter. Sollte jemand im Team Kenntnis von weiteren Alternativen bekommen, kann er sie in der Decision ohne weitere Abstimmung eintragen. Die Entscheidung wird dadurch nicht geändert. Sollte sich mit der weiteren Entwicklung des Reise-Butlers herausstellen, dass Espresso doch nicht die beste Entscheidung war, kann die neue Wahl bereits auf besserer Grundlage mit mehreren Alternativen getroffen werden.

Moritz fasst zusammen: « So eine Decision kann Zeit sparen, wenn ihr eine neue Lösung braucht. Ihr kennt den Grund für die bisherige Entscheidung. Ihr habt bereits eine Menge von Lösungsoptionen, aus denen ihr wählen könnt. »

Zuletzt veröffentlichte Beiträge: