500g Hackfleisch, Tomaten, Karotten, Zwiebeln und Knoblauch hinzugeben, vermischen und anbraten. Fertig ist die Spaghetti Bolognese Soße!
Automation Engineers denken beim Abarbeiten dieses Rezeptes nicht nur an die entstehende leckere Soße, sondern eventuell auch an die ihnen so bekannten Batchvorgänge (Automatisierungsvorgänge). Schließlich lassen sich Rezepte jeglicher Art leicht automatisieren.

Prozessbeschreibungen liefern

In einem Kundenprojekt durften wir bei der Entwicklung einer produktübergreifenden Softwareplattform unterstützen. Das Ziel war es, den Entwicklungsabteilungen innerhalb von wenigen Wochen erste Beschreibungen der beabsichtigten Automatisierungssequenzen des Produkts zu liefern.
In der Unternehmensbranche unseres Kunden hat sich die ISA-88 Norm durchgesetzt, welche einen Rahmen für die Spezifikation und Dokumentation von Automatisierungsprozessen vorgibt. Die ISA-88 Norm [1] fordert u.a. sogenannte „process actions“, die aus einer geordneten Menge von Prozessschritten bestehen.
Mit Hilfe der agilen Praktik „Use Case 2.0“ schafften wir es, eine effiziente, geordnete und nicht überspezifizierte Prozessbeschreibung zu liefern.

Use Case 2.0 - The Guide to Succeeding with Use Cases

Use Case 2.0

Prinzipien von Use Case 2.0

Eine vom „Vater“ der Use Cases (Ivar Jacobson) weiterentwickelte agile Praktik – Use Case 2.0 [2] – lieferte anhand ihrer Prinzipien die Grundlagen, die das Projektteam brauchte:

  • Beschreibe Dinge einfach – mit Geschichten
  • Stelle den Nutzen in den Mittelpunkt
  • Verstehe das „Big Picture“
  • Baue scheibchenweise auf („Slices“)
  • Liefere in Inkrementen

Das „Big Picture“

Bevor das Projektteam mit dem Spezifizieren von einzelnen process actions starten konnten, musste zunächst das Big Picture erstellt werden, an dem sich das Team jederzeit orientieren konnte. Dieses war für uns die Festlegung der Reihenfolge (z.B. 1. Installation, 2. Prozessvorbereitung, 3. Prozessausführung, 4. Abbau) des zu beschreibenden Gesamtprozesses. Dieses Grundgerüst konnte nun mit process actions befüllt werden.
Dieses Big Picture ermöglichte es jederzeit eine Übersicht darüber zu bekommen, wie weit wir mit unserer Arbeit gekommen sind, und wann wir fertig sein würden.

Beschreibe Dinge einfach, stelle Nutzen in den Mittelpunkt

Wir beschlossen, process actions in Form von Tabellen zu beschreiben. Allerdings sollten es nicht die klassischen, mit Informationen überladenen Use Case-Beschreibungen sein, sondern leichtgewichtige Darstellungen, die möglichst schnell ersichtlich den Zweck der beschriebenen Funktion verdeutlichen. Eine kurze Sequenz aus Schritten, z.B. wie die Software des Produkts darauf reagieren soll, wenn der Benutzer einen Sensor anschließt, reichte schon aus um dem Entwicklungsteam zu implementierende Grundfunktionalitäten schnellstmöglich zu liefern.
Neben dieser simplen Darstellung der Grundfunktionalität einigten wir uns im Projektteam darauf, in jeder process action relevante Fehlerabfangroutinen zu spezifizieren (z.B. angeschlossener Sensor liefert keine Werte), so dass die zu implementierenden process actions auch robust umgesetzt werden.

Baue Scheibchenweise auf („Slices“)
Die atomare Darstellung von process actions hat zur Folge, dass mehrere process actions aufeinander aufbauen können (bspw. Folgt auf eine process action „Anschließen eines Sensors“ die process action „Kalibrierung eines Sensors“). Allerdings bieten atomare und allgemein spezifizierte process actions, den Vorteil, wiederverwendbar zu sein. Daher lassen sich process actions, die z.B. in einem „Pool-Projekt“ erstellt werden, in verschiedenen Projekten derselben Projektfamilie ohne Änderung übernehmen.

Liefere in Inkrementen

Eine inkrementelle Lieferung von process actions bietet den Vorteil, möglichst frühzeitig Feedback aus der Entwicklungsabteilung zu bekommen. Fragen der Entwickler können daraufhin geklärt werden, so dass eine Aufwandsabschätzung zur Umsetzung abgegeben werden kann, und der Implementierung nichts mehr im Weg steht.

Dieses Projekt zeigt, dass eine Anwendung der Use Case 2.0-Prinzipien nicht eine Menge zusätzlichen Aufwand bedeutet, bevor mit der eigentlichen Arbeit begonnen werden kann. Es verleitet das Team dazu, sich eine agile Arbeitsweise anzueignen, durch die Spezifikationsinkremente zunächst ohne unnötige Details geliefert werden, um zeitnah umgesetzt werden zu können.

Sind Sie neugierig geworden? Dann haben Sie die Möglichkeit sich in unserem Use Case 2.0 Training intensiv mit dieser agilen Praktik auseinanderzusetzen.

 

[1] ISA88, Batch Control, https://www.isa.org/isa88/ (zuletzt aufgerufen am 19.04.2018)
[2] Use Case 2.0 Ebook, https://www.ivarjacobson.com/publications/white-papers/use-case-ebook (zuletzt aufgerufen am 19.04.2018)