Rezepte gemäß ISA-88 mit Use Case 2.0 agil umsetzen

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.

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)

Pedro Ferreira

Kontaktieren Sie Pedro Ferreira

Pedro Ferreira ist als Consultant und Trainer bei der HOOD GmbH im Bereich Requirements Engineering tätig. Seine Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehörigen Werkzeugen (z.B. DOORS). Zu seinen Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, die Erstellung von objektorientierten Modellen unter Einsatz der UML und das Spezifizieren von Testfällen. Erfahrungen konnte Pedro Ferreira bisher in der IT-, Automobil- und in der Luftfahrtindustrie sammeln. Als Trainer hat er sich auf die gute Formulierung von textuellen Anforderungen und auf die Methoden zur Erhebung von Anforderungen aus der UX Domäne spezialisiert.