Zum Hauptinhalt springen
Wissensdatenbankv11.5

Workflow

Wir werden anhand eines Beispiels lernen, wie man benutzerdefinierte Anwendungen erstellt. Wir entwickeln eine einfache Bug-Tracking-Anwendung. Wir gehen von zwei Teams aus: Entwickler – sie beheben Fehler – und QA (kurz für Qualitätssicherung) – sie testen die von den Entwicklern vorgenommenen Korrekturen. Wir modellieren den folgenden Bug-Workflow:

In einfachen Worten ausgedrückt bedeutet das Diagramm:

  • Wenn ein Fehler gemeldet wird, befindet er sich im Status „Neu“.
  • Die Qualitätssicherung prüft den Fehler. Handelt es sich nicht um einen Fehler, wird der Fehlerstatus auf „Geschlossen“ gesetzt; andernfalls auf „Verifiziert“.
  • Ein von einem Entwickler als behoben bestätigter Fehler wird in den Status „Behoben“ verschoben.
  • Die Korrektur wird anschließend von der Qualitätssicherung getestet. Schlägt der Test fehl, wird der Fehler auf „Wieder geöffnet“ gesetzt; andernfalls auf „Geschlossen“.
  • Ein erneut geöffneter Fehler, der vom Entwickler behoben wurde, wird in den Status „Behoben“ verschoben.

Jede Blase repräsentiert eine Phase im Lebenszyklus eines Fehlers, jeder Pfeil eine Aktion des Endbenutzers. Neben jedem Status ist das zuständige Team angegeben. Ein Fehler kann nicht direkt von einem Status in einen anderen wechseln, z. B. kann er nicht direkt von einem Status zum nächsten wechseln

Zu

Wir selbst nutzen eine eigene Bugtracking-Anwendung, die jedoch deutlich mehr Status anzeigt, um beispielsweise zu dokumentieren, ob ein Testfall vorhanden war, ob die Dokumentation aktualisiert oder ein neuer Testfall hinzugefügt wurde. Sie können den Workflow beliebig komplex oder einfach gestalten. Fürs Erste bleiben wir aber bei dem oben beschriebenen einfachen Workflow.

Erstellen einer App

Um eine App zu erstellen, gehen Sie zu VerwaltungAppsApps und klicken Sie auf

Sie sehen ein Formular mit vielen Registerkarten. Wir werden jede Registerkarte im Folgenden erläutern.

Die Registerkarte „Basis“

Dieser Tab definiert einige grundlegende Eigenschaften der App. Darüber hinaus steuert er auch bestimmte Verhaltensweisen der App.

NameDer Name Ihrer App. Hier wird „Bug“ stehen
PluralDie Mehrzahlform des Namens.
Zunächst zuweisen anWählen Sie den Benutzer aus, der neuen Instanzen automatisch zugewiesen werden soll.
Anfordererfeld verwenden?Standardmäßig ist der Ersteller eines App-Elements auch dessen Anforderer. Es kann jedoch Fälle geben, in denen Sie eine App im Namen einer anderen Person erstellen und Benachrichtigungen und Updates an diese Person und nicht an den Ersteller senden möchten. In unserer App sollen unsere Support-Mitarbeiter Fehler im Namen eines Kunden melden können, Updates sollen aber direkt an den Kunden gesendet werden. Daher aktivieren wir diese Option. Ist sie aktiviert, wird beim Erstellen einer neuen App-Instanz das Feld „ Anforderer“ angezeigt
Zeiterfassung zulassenOb die Zeiterfassung für das App-Element erlaubt sein soll. Wir möchten, dass unsere Entwickler und unser QA-Team die Zeit erfassen, daher aktivieren wir diese Option.
Kunden können initiierenOb Sie möchten, dass Ihre Kunden neue Instanzen erstellen. Wir möchten, dass unsere Kunden Fehler melden, daher aktivieren wir diese Option.
BeschreibungEine kurze Beschreibung Ihrer App.
FollowerWählen Sie die Standard-Follower aus. Follower erhalten Benachrichtigungen bei Neuzuweisungen, Statusänderungen oder neuen Kommentaren.
AktivOb Sie Ihre App aktivieren oder deaktivieren möchten. Wenn Sie sie als inaktiv markieren, werden bestehende Instanzen dieser App nicht gelöscht.

Die Registerkarte „Staaten“

Dieser Tab definiert die Zustände der App. Sie können hier auch den Start- und Endzustand im Workflow markieren. Wir haben alle Zustände unseres Bug-Workflows aufgelistet.

StartzustandWenn ein App-Element erstellt wird, wird es in diesen Status versetzt. In unserem Fall ist das der Status „Neu“.
EndzustandWenn ein App-Element diesen Status erreicht, gilt der Prozess als abgeschlossen. In unserem Fall ist er „Geschlossen“.

Die Registerkarte „Workflow“

Dieser Tab definiert alle

Im Workflow-Diagramm stellt jeder Pfeil eine Endbenutzeraktion dar. Weitere Informationen zur Verwendung finden Sie später in der Dokumentation.

AktionDer Name für die Aktion. Dieser wird in Aktionsmenüs für Bugs verwendet.
AusDer Staat, von dem der Pfeil ausgeht.
ZuDer Zustand, in dem der Pfeil endet. Sobald die Aktion ausgeführt wurde, wird unser Fehler in diesen Zustand versetzt.
Zuweisen anDer Benutzer, dem der Workflow nach Ausführung der Aktion zugewiesen wird. Die Eingabeaufforderung in der Rolle „Entwickler“ bedeutet, dass dem Benutzer, der die „Überprüfen“ für den Fehler durchführt, eine Liste von Entwicklern angezeigt wird, aus der er den neuen Bearbeiter auswählen kann.
Benutzer zulassenLegt fest, ob diese Aktion von einem Benutzer ausgeführt werden kann. In manchen Fällen ist es nicht erwünscht, dass Endbenutzer diese Aktion ausführen. Beispielsweise werden in Helpdesk-Systemen Tickets, auf die nicht reagiert wird, nach einigen Tagen Inaktivität automatisch geschlossen.

Die Registerkarte „Trigger“

.

In unserer Bugtracking-App benötigen wir keine Trigger. Betrachten wir jedoch als Beispiel den Workflow unseres Helpdesks . In diesem Fall ist der Anfragende die Person, die eine Frage gestellt hat. Sobald diese Person per E-Mail antwortet, soll das Ticket automatisch in den „Ungelöst“ , damit es dem Support-Team zur Kenntnis gelangt. Anders ausgedrückt: Wir möchten, dass die „Wiedereröffnen “-Übergänge ausgelöst werden. In diesem Fall würden wir unsere Trigger wie folgt definieren:

Registerkarte „Landesmanager“

Ein Statusmanager ist ein Benutzer, der als Manager , wenn sich eine Anwendung in einem bestimmten Status befindet. Er wird benachrichtigt, wenn sich etwas an einem Element in diesem Status ändert. In unserem Beispiel unten ist Mark der QA-Manager und somit für die „Neu“ und „Behoben“ , in denen das QA-Team arbeitet. Statusmanager können auf Projektebene überschrieben werden, falls eine andere Person den jeweiligen Status verwaltet.


Wie geht es weiter?

Wir haben eine benutzerdefinierte App für unseren Bug-Workflow erstellt. Im nächsten Kapitel werden wir dem Bug einige benutzerdefinierte Felder hinzufügen.