Dies ist die zweite Folge des Devlogs, meines wöchentlichen Entwicklungstagebuchs für das SaaS für Trainer. Das Ziel: Alles, was ich in meiner Beratung und in meinen Trainings so "predige", selbst in die Praxis umzusetzen und zu sehen, wie weh oder wie gut es tut.

Domäne umreißen

Ich empfehle meinen Kunden ja meist Domain-Driven Design (zumindest den Kunden, deren Geschäftsprozesse und -logik genügend kompliziert sind). Sie sollten diese Methode verwenden, um sicherzustellen, dass wirklich die Software herauskommt, die die Anwender brauchen.

Beim vorigen Devlog-Eintrag hatte ich ja zuerst einmal herausfinden wollen, was die Domäne eigentlich ist, indem ich einen Fachexperten (Trainer) virtuell interviewt habe. Dabei kam eine lange Liste von Sätzen in Domänensprache (hier also: Trainersprache) heraus, eine Beschreibung des grundsätzlichen Vorgehens beim Design neuer Trainings.

Erste Stories finden

Als Nächstes habe ich diese Woche überlegt, bei welchen der Schritte, die der Trainer beschrieben hat, ihn ein SaaS unterstützen könnte. Ich habe mir also ein User Story Mapping-Werkzeug genommen, um ein paar Stories zu planen, die den trainer hoffentlich glücklich machen werden.

(Im realen Leben würde ich stattdessen Event Storming empfehlen, um die Sicht mehrerer Fachexperten konflikt-bereinigt unter einen Hut und in alle Köpfe des Teams zu bekommen. Doch ich bin ja im Moment remote unterwegs, da funktioniert das mit dem Event Storming auf Überblicks-Ebene nicht so gut. Ich werde Event Storming deshalb erst bei der Prozessmodellierung und beim Software-Design einsetzen, die in späteren Folgen des Devlogs kommen werden.)

Beim Mapping kam ich auf die folgenden Aktivitäten:

Aktivität Wieso?
Login Naja, muss man haben, damit jeder Trainer nur an "sein" Material kommt. Außerdem muss man sich als User im System ja irgendwie registrieren können.
Collect raw material Der Trainer hatte ja gesagt, dass er erst einmal gern sein Rohmaterial einsammen würde.
Analyze raw material Der Trainer wollte ja die wichtigen Stellen in seinem Rohmaterial "anstreichen" und diese Highlights dann nach Bedeutung gruppieren.
Establish learning goals Die Lernziele, die im Training erreicht werden sollen, wollte der Trainer irgendwo festhalten, um sie mit dem Rohmaterial vergleichen und daraus Units erstellen zu können.
Create training Das eigentliche Zusammensetzen eines neuen Trainings, aus Units, Modules und Time Slots.
Manage trainings Immer, wenn man "viel" von irgendetwas erzeugt, muss man diese "Vielheit" verwalten können. Wenn z.B. eine Vorlesungsreihe erstellt werden soll, dann wäre das eigentlich schon ein Project, für das man auch fast schon ein Team brauchen könnte. Also sehe ich Projekte und Teams vor.

Wir die Story Map zeigt, besteht jede der Aktivitäten aus mehreren Aufgaben, die der User gern mit dem System gemeinsam ausführen möchte. Tippen Sie mit der Maus hinein und nutzen Sie sie zum Zoomen:

Wenn Sie die Story Map oben betrachten, sehen Sie, dass Collect Raw Material und Establish Learning Goals auf dieselben Tasks verweisen. Beim Modellieren der Stories fiel mir nämlich auf, dass die Tätigkeiten sehr ähnlich sind: Sowohl Rohmaterial als auch Lernziele könnte man mit Hilfe von Notizen (notes) in einem WYSIWYG-Editor abbilden, so dass man eine Art Dokumente bekommt, in denen auch Links, Bilder und Videos eingebettet sein können. Der Trainer könnte mit diesen notes sowohl Rohmaterial als auch Lernziele beschreiben.

Keine Releaseplanung

Eine Aufteilung in Releases, die mit dieser Story Map ja eigentlich auch möglich wäre, wollte ich nicht machen (woher soll ich wissen, welche Kapazität zum Entwickeln ich in welcher Woche haben werde?). Außerdem möchte ich sowieso ständig "releasen", also was soll der Begriff Release eigentlich noch?

Qualitäten festlegen

OK, das war die funktionale Seite der Anforderungen. Wenn ich jetzt noch wüsste, welche Qualitäten gefordert sind, dann könnte ich daran gehen, eine erste Architektur festzulegen und etwas Code zu schreiben, um festzustellen, ob ich träume oder ob das alles realisierbar sein wird. Auch würde ich dann merken, was noch fehlt.

Also muss ich mir jetzt ein paar Gedanken machen zu...

  • Funktionaler Eignung
  • Effizienz
  • Kompatibilität
  • Benutzbarkeit
  • Verlässlichkeit
  • Sicherheit
  • Wartbarkeit
  • Übertragbarkeit

Ich will nicht alles komplett festschreiben, doch ein paar Vorgaben finde ich wichtig:

Effizienz

Antwortzeit ist mir wichtig, damit es sich für die Trainer frisch und schnell anfühlt. Ich hätte gern weniger als 0,5 Sekunden Reaktionszeit im GUI, es sei denn, es kämen größere Funktionen wie z.B. Auswertungen oder Reports. Die dürfen von mir aus bis zu 20 Sekunden dauern, nur muss dann dem User ein Fortschritt angezeigt werden.

Speicherverbrauch ist mir wichtig, damit mir die Kosten für die Cloud nicht aus dem Ruder laufen. Mehr als 1GB pro Serverinstanz soll die Anwendung nicht brauchen.

Der Batteriestromverbrauch auf mobilen Clients soll gering sein, nicht mehr als für übliches Surfen im Web.

Benutzbarkeit

Erlernbarkeit ist mir wichtig: Ein Trainer sollte nicht mehr als 15 Minuten brauchen, um erste notes erfassen und farblich markieren zu können.

Ästhetik des UIs ist mir wichtig. Es soll minimalistisch und klar aussehen. Die Informationsarchitektur sollte für die User klar und einfach ersichtlich sein.

Die üblichen Anforderungen an die Verständlichkeit stelle ich auch. Ich möchte, dass die User jederzeit Antwort auf die üblichen drei Fragen geben können:

  • Wo, also in welcher Funktion, bin ich gerade?
  • Was würde der nächste Schritt bewirken?
  • Wie kann ich einen Schritt rückgängig machen?

Verlässlichkeit

Verfügbarkeit: Die Anwendung sollte höchstens wenige Minuten in der Woche off-line sein müssen, wenn ich vielleicht Wartung machen muss. Am liebsten nicht einmal das!

Fehlertoleranz: Die Anwendung sollte kein Fehlverhalten zeigen, selbst wenn User falsche Daten eingeben. Es sollten ordentliche Fehlermeldungen kommen, und die Anwendung sollte weiterarbeiten.

Wiederanlauffähigkeit: Falls einer der Server in der Cloud einmal abstürzt, sollten keine Daten verloren gehen, sondern ein anderer Server derselben Anwendung sollte halt das nächste Request verarbeiten können.

Sicherheit

Vertraulichkeit: Ich möchte, dass keine Hacker einbrechen können, um Daten zu stehlen. Zahlungsdaten (z.B. Kreditkartennummern) sollen überhaupt nicht in der Anwendung gespeichert sein, sondern bei einem Zahlungsdienstleister, damit sie hier gar nicht erst gestohlen werden können.

Authentizität: Es muss jederzeit klar sein, wer der aktuell eingeloggte User ist. Es muss auch sichergestellt sein, dass er nur an seine eigenen Daten kommt, nicht an die Daten anderer Trainer – es sein denn, mehrere Trainer entschließen sich, als Team gemeinsam an denselben Trainings zu arbeiten.

Wartbarkeit

Modularität: Die Anwendung soll modular erstellt werden, damit die Auswirkungen von Änderungen, die ich mache, gering bzw. lokal beschränkt bleiben.

Analysierbarkeit: Falls ein Fehler vorliegt, möchte ich ihn schnell finden können, am besten in weniger als 30 Minuten nach Beginn der konzentrierten Fehlersuche.

Modifizierbarkeit: Ich möchte Modifikationen mutig vornehmen können, ohne befürchten zu müssen, dass gleich alles zusammenbricht. Daher sollte die Software gut entworfen sein (z.B. SOLID- oder Clean-Code-Prinzipien) und ein robuste Architektur haben. Auch die Testabdeckung muss einigermaßen hoch sein, zumindest bei den kritischen Stellen, nicht bei den trivialen.

Übertragbarkeit

Ich möchte die Anwendung auf einer VM schreiben, die auf mehreren Plattformen läuft. Die Server dürfen einheitlich Linux sein, Windows braucht als Server nicht unterstützt zu werden.

Die Clients sollten aktuelle Browser sein, da fordere ich immerhin Chrome, Firefox und Safari.

Die Datenbank darf ruhig festgelegt sein, es muss nicht auf "allen" Datenbanken laufen, sondern ich fange mit PostgreSQL an.

Was mit unterschiedlichen Sprachen, Datumsformaten, Währungen, usw. sein wird, ist mir noch nicht so klar. Da könnte noch etwas auf mich zukommen, doch ich fange einmal mit Englisch als Sprache, ISO-Datumsformat und US-Dollar als Währung an.

Konflikte zwischen obigen Merkmalen

Sollten einmal zwei der obigen Merkmale im Konflikt stehen, priorisiere ich von oben nach unten (weiter oben Stehendes hat Vorrang):

  1. Wartbarkeit
  2. Sicherheit
  3. Benutzbarkeit
  4. Verlässlichkeit
  5. Effizienz

Bei den anderen Merkmalen "schau'n wir mal". Auf jeden Fall kommen die oben beschriebenen Qualitäten mit in mein Entwicklungsbacklog für das Saas für Trainer.

Nächste Schritte

Gut, das war eine Menge Grundlagenarbeit. Jetzt kann ich eine erste Architektur festlegen und etwas Code schreiben, um festzustellen, ob ich träume oder ob das alles realisierbar sein wird. Auch werde ich dann merken, was in den Festlegungen noch fehlt (also welche Entscheidungen gefällt werden müssen).

In der nächsten Folge des Devlogs wird es also wahrscheinlich um Softwarearchitektur (fachlich und technisch) gehen. Für diesmal: Kommentieren Sie bitte unten – Kommentare zum Artikel sind jederzeit willkommen!

Und natürlich: "Stay tuned".

, Devlog