open oose - der 3. und leider letzte Tag

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Und zum Schluss unserer kleinen Blogserie zu open oose 2017 finden Sie hier die Eindrücke vom dritten Tag. Wer neugierig auf Tag 1 und Tag 2 ist, darf gerne dort stöbern.

Die Macht der Karten - Mapping-Techniken im Requirements Engineering

Mit 25 motivierten Teilnehmern haben wir aus auf die Reise begeben, die Welt der Karten zu erkunden. Aus einem kurzen Einstieg zum Thema Mapping im Kontext von Requirements Engineering, User Experience Design und Design Thinking und den unterschiedlichen „Kartenarten“ Customer Journey, Service Blueprint oder Experience Map ging es an eine konkrete Fragestellung. In fünf Gruppen haben die Teilnehmer*innen die Design Challenge bearbeitet, wie ein optimaler Wochenendeinkauf aussehen kann. Anhand von Personas haben die Gruppen jeweils den Ablauf eines typischen Einkaufs kartographiert und dafür innovative Ideen entwickelt und Optimierungspotentiale identifiziert. Aus den Favoriten der Innovationsideen haben die Gruppen  schließlich ein Beispiel als Produktvisionsbox gestaltet. Und zum Schluss gab es eine launige Vorstellung der Produktvision für den  potentiellen Investor im Format „Die Höhle der Löwen“. Als Gewinner des Tages wurde gekürt: Die „me@tMe - Liebe geht durch den Magen“-App, die das Einkaufserlebnis mit einer Partnervermittlung kombiniert! Einfach Großartig. [abschnitt/]

 

Als die Modelle laufen lernten

Als Neil Armstrong, Buzz Aldrin und Michael Collins am 20. Juli 1969 mit Apollo 11 zum ersten Mal den Mond besuchten, da war Systems Engineering bei der NASA schon längst kein neues Thema mehr. Das Apollo-Raumfahrtprogramm war eines der ersten großen Einsatzgebiete von Systems Engineering Prozessen, Methoden und Techniken. Hingegen das Model-Based Systems Engineering (MBSE), und erst recht die Sprache SysML, waren noch gänzlich unbekannt. Für uns bei oose natürlich kein Grund, um 48 Jahre danach das Apollo 11 Projekt nicht doch noch in SysML zu modellieren. In unserer Session „Als die Modelle laufen lernten“ haben wir mit den Teilnehmern ein Systemmodell betrachtet und z.T. auch erstellt, das nicht nur die physische Struktur der Saturn V Rakete, des Command/Service Moduls und der Mondlandefähre enthielt, sondern das auch die verschiedenen Phasen der Mission als Aktivitäts- und Zustandsdiagramm abgebildet hat. Diese Phasen haben wir auch simuliert, wobei die wohl wichtigste Erkenntnis war, dasws sehr gute Kenntnisse über das Modellierungswerkzeug und seine Simulationsfunktionen erforderlich sind, um nicht zu stolpern. Zu guter Letzt haben wir auch noch konzeptionell gezeigt, wie man für komplexe kontinuierliche Simulationen eine Brücke von der SysML zur Modellierungssprache Modelica schlägt, so dass wir zum Ende sagen konnten: „Houston, Tranquility Base here. The Eagle has landed.“ [abschnitt/]

 

Modelling Microservices - Wege in die Welt der Microservices

Microservice-basierte Systeme werden schnell sehr komplex. Wir haben uns anhand eines Beispiels mit der Abbildung eines fachlichen Modells auf Microservice-Architekturen auseinandergesetzt. Die Teilnehmer haben dazu Beispielarchitekturen modelliert, deren Vor- und Nachteile im Plenum intensiv diskutiert wurden. Weitere Themen waren Schnittstellen und Infrastrukturaspekte wie Load Balancing und Skalierung. Durch den Einsatz von Modellen, die unterschiedliche Aspekte einer Microservice-Architektur repräsentieren, ergibt sich eine kompakte Architekturdokumentation. Diese stellt eine gute Grundlage für die weitere Architektur-Verfeinerung, die Stakeholder-Kommunikation, das Einarbeiten neuer Projektmitarbeiter sowie Betrieb und Wartung eines Microservice-Systems dar.

 

Das Ende ist nah: End-to-End-Decision - DMN mit und ohne BPMN

Geschäftsprozesse waren gestern, heute beschäftigen wir uns mit Entscheidungen, um das Geschäft zu unterstützen. So könnte man - zugegebenermaßen etwas überspitzt - die Sichtweise der End-to-End-Entscheidungen charakterisieren. Nachdem sich diese Sichtweise in dem Workshop anfangs als sehr ungewohnt und sperrig erwies, waren sich am Ende alle einig, dass sich diese über kurz oder lang ausbreiten wird und die DMN (Decision Modell and Notation) dabei sehr hilfreich sein kann. Aber natürlich müssen wir das noch etwas relativieren: Auch weiterhin gibt es viele Probleme, bei denen die Prozesssicht am besten weiterhilft. Nur müssen wir den Blick dafür schärfen, dass bei anderen Problemen wir das Ganze von der zentralen Entscheidung her betrachten sollten - z.B. was ist des beste Finanzprodukt für unseren Kunden?

 

Über die Sinnfreiheit von scriptbasiertem Testen

Gemeinsam gingen etwa 20 Teilnehmer Fragen zum Thema Testen nach. Müssen gute Softwaretester gelernte Programmierer sein? Kann es hinderlich sein, Details über den Quellcode zu kennen, etwa bei Blackbox Tests? Was zeichnet einen guten Testfall aus? Sind 100 Zeilen Script für einen automatisierten Testfall noch verständlich, einfach wartbar und leicht zu erstellen? Die Gruppe scheute sich nicht, vermeintlich „Althergebrachtes“ kritisch zu hinterfragen. Als eine neue Lösung für die effektive und einfache Erstellung von wartbaren und verständlichen Testfällen wurde Modulbasiertes Testen vorgestellt. Dies zeigt eine Alternative zu den Testscripten. So können auch Personen, die keine Programmierer sind, Testfälle automatisieren. In einer humorvollen und lockeren Atmosphäre bekamen die Teilnehmer einen Einblick in eine neue und andere Art des Testens.

[abschnitt/]

Das oose-Team sagt "Danke" an alle Teilnehmer*innen für das Mitmachen, den Austausch, die Diskussionen und die Aufgeschlossenheit.