Ihr Daten-Template für den Softwareentwicklungslebenszyklus

Dieses Attribut erfasst den Namen jedes Meilensteins oder Tasks, der im Softwareentwicklungszyklus abgeschlossen wurde. Diese Aktivitäten bilden die aufeinanderfolgenden Prozessschritte von der Erstellung bis zur Bereitstellung.

Die Analyse der Abfolge und Häufigkeit dieser Aktivitäten ist die zentrale Aufgabe von Process Mining. Sie ermöglicht die Erstellung der Prozessdarstellung, hilft Engpässe zwischen Schritten zu erkennen und macht Abweichungen von Vorgaben oder ineffiziente Prozessvarianten sichtbar. Die festgelegten Aktivitäten umfassen wichtige Phasen wie Entwurf, Entwicklung, Testen und Bereitstellung.

Das Attribut legt die Schritte in der Prozessdarstellung fest. So lassen sich der Prozessfluss analysieren, Engpässe erkennen und Abweichungen vom Standard-SDLC aufdecken.

Dieses Attribut wird üblicherweise abgeleitet, indem Statusänderungen, Ereignisdatensätze oder Audit-Trail-Einträge einer standardisierten Liste von Aktivitätsnamen zugeordnet werden. Eine Änderung des Felds „state“ auf „In Progress“ kann beispielsweise der Aktivität „Entwicklung begonnen“ zugeordnet werden.

Das Entwicklungselement dient als primäre Case-ID und steht für eine klar abgegrenzte Arbeitseinheit, deren Verlauf erfasst wird. Es verknüpft alle Aktivitäten für dieses Element, von der ersten Idee und Planung über Entwicklung und Tests bis zur Bereitstellung.

In der Process-Mining-Analyse ist dieses Attribut grundlegend, um den End-to-End-Verlauf jedes Arbeitselements zu rekonstruieren. Es ermöglicht die Visualisierung von Prozessabläufen, die Berechnung der gesamten Zykluszeiten und die Ermittlung von Prozessvarianten für einzelne Funktionen oder Fehlerbehebungen. Jedes Ereignis im Event Log muss einem Entwicklungselement zugeordnet sein, damit sich der Prozessablauf schlüssig abbilden lässt.

Diese zentrale Kennung verknüpft alle zugehörigen Entwicklungsaktivitäten zu einer einzelnen Prozessinstanz. So lässt sich der gesamte Lebenszyklus jedes Arbeitselements analysieren.

Diese Kennung ist üblicherweise der Primärschlüssel aus Tabellen für Stories, Bugs oder Tasks, etwa den Tabellen „rm_story“, „rm_bug“ oder „task“ in ServiceNow.

Dieses Attribut enthält Datum und Uhrzeit, zu denen jede Aktivität im Entwicklungslebenszyklus erfasst wurde. Es ist entscheidend, um Ereignisse chronologisch zu ordnen und zeitbasierte Analysen durchzuführen.

Beim Process Mining dient die Startzeit dazu, die Dauer zwischen Aktivitäten zu berechnen, Wartezeiten zu ermitteln und die gesamte Zykluszeit des Prozesses zu messen. Sie ist eine wichtige Grundlage für Dashboards zur Leistungsanalyse, etwa für die Analyse der SDLC-End-to-End-Zykluszeit, und für Kennzahlen wie die Durchlaufzeit von Code-Reviews.

Dieser Zeitstempel ist entscheidend, um Ereignisse korrekt zu ordnen und alle Leistungskennzahlen zu berechnen, darunter Zykluszeiten, Dauern und Wartezeiten.

Steht üblicherweise in systemgenerierten Zeitstempelfeldern wie „sys_updated_on“ oder „sys_created_on“ in Audit-Trail- oder Task-Tabellen.

Dieses Attribut erfasst, wann der Datensatz zuletzt aus ServiceNow DevOps extrahiert oder aktualisiert wurde. Es gilt für den gesamten Datensatz und nicht für einzelne Ereignisse.

Dieser Zeitstempel ist wichtig, um die Aktualität der Analyse einzuschätzen. Er zeigt Benutzern, wie aktuell die Prozesserkenntnisse sind, und hilft bei der Planung von Datenaktualisierungen. Wird diese Information in Dashboards angezeigt, liefert sie den Kontext für alle Kennzahlen und Visualisierungen. So beruhen Entscheidungen auf aktuellen Daten.

Liefert wichtigen Kontext zur Aktualität der Daten, damit Benutzer einschätzen können, wie aktuell die Prozessanalyse ist.

Dieser Zeitstempel wird während der Datenextraktion erzeugt und ergänzt. Er hält fest, wann die Extraktion ausgeführt wurde.

Dieses Attribut gibt das Ursprungssystem der Ereignisdaten an. Für diesen Prozess lautet der Wert immer „ServiceNow DevOps“.

Auch wenn der Wert statisch erscheint, ist die ausdrückliche Angabe des Quellsystems für die Data Governance wichtig, insbesondere wenn Daten aus mehreren Systemen wie Jira oder Azure DevOps zusammengeführt werden. Sie schafft Klarheit über die Herkunft der Daten und hilft, Probleme mit der Datenqualität oder der Extraktion zu untersuchen.

Sichert die Rückverfolgbarkeit der Daten und trägt zur Datenintegrität bei, insbesondere wenn Daten aus mehreren Entwicklungstools zusammengeführt werden.

Dies ist ein statischer Wert, der während der Datenextraktion und -transformation ergänzt werden sollte.

Dieses Attribut ordnet die Entwicklungsarbeit dem betroffenen Teil des Systems zu. Dabei kann es sich um einen bestimmten Microservice, eine UI-Komponente oder eine Backend-Anwendung handeln.

Die Aufschlüsselung des Prozesses nach Modul oder Komponente ist wichtig, um lokale Engpässe zu erkennen. Das Dashboard „Erkenntnisse zu komponentenspezifischen Engpässen“ und die KPI „Durchschnittliche Phasendauer nach Komponente“ verwenden dieses Attribut, um festzustellen, ob bestimmte Teile der Codebasis regelmäßig mit längeren Entwicklungszyklen, mehr Nacharbeit oder häufigeren Bereitstellungsfehlern verbunden sind. So können Verbesserungsmaßnahmen gezielt dort ansetzen, wo sie am dringendsten gebraucht werden.

Ermöglicht die Aufschlüsselung der Analyse nach Anwendung oder Komponente, sodass sich Engpässe und Qualitätsprobleme in bestimmten Systembereichen gezielt untersuchen lassen.

Dabei handelt es sich häufig um ein benutzerdefiniertes Feld oder einen Verweis auf die Configuration Management Database (CMDB), der das Arbeitselement mit einem „cmdb_ci“-Datensatz verknüpft. Weitere Informationen finden Sie in der ServiceNow-DevOps-Dokumentation.

Dieses abgeleitete Attribut kennzeichnet Aktivitäten, die auftreten, nachdem der Prozess zu einer früheren Phase zurückgekehrt ist. Wird beispielsweise für dasselbe Element nach der Aktivität „QA-Test abgeschlossen“ die Aktivität „Entwicklung gestartet“ erfasst, wird sie als Nacharbeit gekennzeichnet.

Das Kennzeichen ist wichtig, um Nacharbeit zu quantifizieren und sichtbar zu machen. Es unterstützt direkt das Dashboard „Analyse des Nacharbeits- und Ablehnungsflusses“ und dient zur Berechnung der KPI „Nacharbeitsquote nach dem Test“. Analysten können die gekennzeichneten Ereignisse filtern und Häufigkeit, Ursachen sowie Auswirkungen der Nacharbeit auf die gesamte Zykluszeit untersuchen.

Mit diesem Kennzeichen lässt sich Nacharbeit einfach quantifizieren und analysieren. So können Sie die Prozessqualität messen und die Ursachen wiederholter Arbeit erkennen.

Dieses Attribut wird im Process-Mining-Tool berechnet. Dazu wird die Aktivitätsreihenfolge für jeden Case analysiert, um Rückschritte im Prozessablauf zu erkennen.

Dieses Attribut ordnet Entwicklungselemente nach ihrer geschäftlichen Dringlichkeit. Prioritätsstufen helfen Teams, sich auf die wichtigsten Aufgaben zu konzentrieren, und dienen häufig dazu, SLAs und Erwartungen der Stakeholder zu steuern.

Beim Process Mining ist die Priorität eine wichtige Dimension für Vergleichsanalysen. Sie ermöglicht es, die Prozessdarstellung zu filtern und zu prüfen, ob Elemente mit hoher Priorität einen schnelleren oder anderen Ablauf nehmen. Sie ist entscheidend für das Dashboard und die Kennzahl „Bereitstellungszeit für Funktionen mit hoher Priorität“ und hilft zu überprüfen, ob kritische Elemente tatsächlich bevorzugt bearbeitet werden.

Ermöglicht es, Prozesse nach Prioritätsstufen zu filtern und zu vergleichen. So lässt sich prüfen, ob Elemente mit hoher Priorität schneller und effizienter bearbeitet werden.

Dies ist ein Standardfeld in ServiceNow, das in Tabellen mit Aufgabenbezug häufig „priority“ heißt.

Dieses Attribut gibt den offiziellen Status des Entwicklungselements in ServiceNow wieder. Aktivitäten bilden abgeleitete Prozessschritte ab, während der Status die formale Phase im Workflow des Systems bezeichnet.

Der Status ist häufig die Grundlage für die Ableitung von Aktivitäten. Er lässt sich zur Datenvalidierung und für einfachere, übergeordnete Prozessansichten verwenden. So zeigt die Analyse der Verweildauer in den einzelnen Statuswerten eine andere Perspektive auf Engpässe als die Analyse der Zeit zwischen Aktivitäten. Außerdem lassen sich damit Elemente erkennen, deren Bearbeitung ins Stocken geraten ist oder die bereits abgeschlossen wurden.

Gibt den offiziellen Systemstatus eines Arbeitselements an. Dieser dient häufig als Grundlage für die Ableitung von Aktivitäten und kann zur Validierung sowie für übergeordnete Statusanalysen verwendet werden.

Dies ist ein Standardfeld in ServiceNow, das in Tabellen mit Aufgabenbezug meist „state“ oder „stage“ heißt.

Dieses Attribut unterscheidet die verschiedenen Arten von Arbeit, die den SDLC-Prozess durchlaufen. Die Behebung eines kritischen Fehlers kann beispielsweise einem anderen und schnelleren Ablauf folgen als die Entwicklung einer neuen Funktion.

Die Analyse nach Arbeitselementtyp ermöglicht ein differenzierteres Verständnis der Prozessleistung. Sie hilft bei Fragen wie: „Ist die Nacharbeitsquote bei Fehlern höher als bei neuen Funktionen?“ oder „Ist unsere Zykluszeit für den Abbau technischer Schulden akzeptabel?“. Diese Aufschlüsselung liefert genauere Erkenntnisse als eine einheitliche Prozessansicht für alle Arbeitselemente.

Unterscheidet verschiedene Arbeitsarten wie Funktionen und Fehler, für die unterschiedliche Prozessabläufe, Prioritäten und erwartete Bearbeitungszeiten gelten können.

Der Typ lässt sich anhand der Quelltabelle des Datensatzes bestimmen, zum Beispiel „rm_story“ oder „rm_bug“, oder über ein Feld „type“ in einer generischen Aufgabentabelle.

Dieses Attribut gibt an, wer für die Ausführung eines bestimmten Tasks oder einer Aktivität verantwortlich ist. Es kann sich ändern, wenn das Entwicklungselement verschiedene Phasen und Teams durchläuft.

Das Attribut ist wichtig für die Analyse der Ressourcenzuweisung, der Arbeitslast und der Übergaben. Es unterstützt direkt das Dashboard „Arbeitslast und Übergaben der Entwickler“ sowie die Kennzahl „Aktivitätsvolumen pro Entwickler“. Durch die Erfassung von Änderungen dieses Felds lassen sich Übergabezeiten messen und Engpässe in der Zusammenarbeit zwischen Entwicklern oder zwischen Entwicklungs- und QA-Teams erkennen.

Unverzichtbar für ressourcenbezogene Analysen, etwa zur Verteilung der Arbeitslast und zur Effizienz von Übergaben. Außerdem lassen sich damit Leistungsmuster einzelner Teams erkennen.

Diese Information steht üblicherweise im Feld „assigned_to“ entwicklungselementbezogener Tabellen in ServiceNow.

Dieses Attribut kennzeichnet das Team, dem ein Arbeitselement zugewiesen ist, zum Beispiel „Frontend-Entwicklung“, „Backend-Services“ oder „Qualitätssicherung“. Im Verlauf der Bearbeitung wird ein Arbeitselement häufig zwischen verschiedenen Zuweisungsgruppen übergeben.

Die Zuweisungsgruppe zu erfassen, ist wichtig, um die teamübergreifende Zusammenarbeit und Übergaben zu verstehen. So lassen sich systembedingte Verzögerungen erkennen, die beim Wechsel der Arbeit von einem Team zum anderen entstehen. Das Attribut unterstützt die Analyse der Teamleistung und Arbeitsauslastung und zeigt, welche Teams den Gesamtprozessfluss bremsen.

Zeigt, welches Team für die Arbeit verantwortlich ist. Damit lassen sich Teamleistung, Arbeitsauslastung und die Effizienz von Übergaben zwischen Teams analysieren.

Diese Information steht im Feld „assignment_group“, einem Standardfeld in Tabellen mit Aufgabenbezug in ServiceNow.

Dieses Attribut ist eine berechnete Kennzahl für die durchgängige Dauer eines einzelnen Entwicklungselements. Dazu wird für jeden Case die Differenz zwischen dem Timestamp der ersten und dem der letzten Aktivität ermittelt.

Diese Kennzahl ist ein zentraler Leistungsindikator für den gesamten SDLC-Prozess und bildet die Grundlage für die KPI „Durchschnittliche SDLC-Zykluszeit“. Sie gibt einen übergeordneten Überblick über Geschwindigkeit und Effizienz des Prozesses. Wird die Kennzahl im Zeitverlauf und nach verschiedenen Dimensionen wie Priorität oder Team analysiert, lässt sich die Wirkung von Prozessverbesserungen verfolgen.

Gibt die gesamte Durchlaufzeit eines Arbeitselements an und ist damit eine wichtige Kennzahl für die Effizienz und Geschwindigkeit des Gesamtprozesses.

Dieses Feld ist im Quellsystem nicht vorhanden. Das Process-Mining-Tool berechnet den Wert für jeden Case, indem es den kleinsten StartTime-Wert vom größten StartTime-Wert abzieht.

Dieses Attribut erfasst das Ergebnis einer Bereitstellung in einer bestimmten Umgebung. Es ist wichtig, um die Zuverlässigkeit und Stabilität des Release-Prozesses zu beurteilen.

Das Attribut ist eine zentrale Grundlage für das Dashboard „Trends bei erfolgreichen und fehlgeschlagenen Bereitstellungen“ sowie für die KPI „Fehlerquote bei Bereitstellungen“. Durch die Analyse der Häufigkeit und Entwicklung von Bereitstellungsfehlern können Unternehmen grundlegende Probleme beim Testen, in der Infrastruktur oder bei der Release-Koordination erkennen. So lassen sich Maßnahmen gezielt auf eine höhere Qualität und Zuverlässigkeit der Softwarebereitstellung ausrichten.

Misst direkt den Erfolg von Bereitstellungen. Das ist entscheidend, um die Fehlerquote bei Bereitstellungen zu berechnen und die Stabilität von Releases zu analysieren.

Dieser Status wird üblicherweise in Aufgaben zur Nachverfolgung von Bereitstellungen oder in Ausführungsdatensätzen von CI/CD-Pipelines erfasst, die in ServiceNow DevOps integriert sind.

Dieses Attribut stellt eine direkte Verbindung zwischen einem Entwicklungselement und der zugehörigen Codeänderung im Quellcode-Repository, etwa Git, her. Es wird erfasst, wenn die Aktivität „Code committet“ auftritt.

Beim Process Mining ergänzt die Commit-ID die Analyse, indem sie Prozessdaten mit Engineering-Daten verknüpft. Analysten können damit eine problematische Bereitstellung bis zur konkreten Codeänderung zurückverfolgen oder Kennzahlen zur Codekomplexität mit Entwicklungszykluszeiten vergleichen. Das ermöglicht eine deutlich detailliertere technische Ursachenanalyse.

Verknüpft das Prozessereignis mit einer konkreten Codeänderung. So lassen sich Prozesskennzahlen mit Details auf Codeebene abgleichen und Ursachen genauer analysieren.

Diese Information wird über ServiceNow-DevOps-Integrationen mit Quellcodeverwaltungssystemen wie Git oder SVN erfasst. Die Daten stehen in verknüpften Tabellen zum Entwicklungselement.

Dieses Attribut enthält Datum und Uhrzeit, zu denen jede Aktivität im Entwicklungslebenszyklus abgeschlossen wurde. Besonders nützlich ist es für Aktivitäten mit messbarer Dauer, etwa „Code-Review durchgeführt“ oder „QA-Test“.

Beim Process Mining ermöglichen Start- und Endzeit die genaue Berechnung der Verarbeitungszeit einer Aktivität. So lässt sie sich von der Wartezeit zwischen Aktivitäten unterscheiden. Dadurch erkennen Sie, ob Verzögerungen durch langwierige Aufgaben oder durch Wartezeiten auf Ressourcen entstehen. Bei Ereignissen ohne Dauer, etwa „Build gestartet“, kann die Endzeit der Startzeit entsprechen.

Ermöglicht die genaue Berechnung der Verarbeitungszeit einer Aktivität. So lässt sich unterscheiden, wie viel Zeit auf die Arbeit und wie viel auf das Warten entfällt.

Dieser Wert muss möglicherweise abgeleitet werden. Dafür kann der Zeitstempel der Startzeit der nächsten Aktivität verwendet werden. Alternativ lässt er sich einem separaten Feld für das Enddatum entnehmen, sofern das Quellsystem ein solches Feld enthält.

Dieses Attribut verknüpft ein Entwicklungselement mit einem geplanten Release, zum Beispiel „Version 2.3“ oder „Release Q4 2023“. Es ist ein wichtiger Bestandteil des Projekt- und Release-Managements.

Für Process Mining ist dieses Attribut entscheidend für das Dashboard „Überwachung der Einhaltung des Release-Plans“. Durch den Abgleich der tatsächlichen Abschlussdaten mit den geplanten Release-Terminen können Teams die Termineinhaltung messen, gefährdete Elemente erkennen und die Ursachen für Release-Verzögerungen analysieren. So wird der Entwicklungsprozess auf niedriger Ebene direkt mit übergeordneten Geschäftszielen verknüpft.

Verknüpft Entwicklungsarbeit mit bestimmten Releases und ermöglicht so die Analyse der Termineinhaltung sowie der Auswirkungen von Prozessverzögerungen auf den Release-Zeitplan.

Diese Information steht üblicherweise in einem Feld namens „release“ oder „planned_release“, das häufig auf eine Release-Management-Tabelle in ServiceNow verweist. Weitere Informationen finden Sie in der ServiceNow-DevOps-Dokumentation.

Wenn ein Element die Qualitätssicherung (QA) oder den Abnahmetest (UAT) nicht besteht, erfasst dieses Attribut den Grund dafür. Das kann eine bestimmte Fehlerkategorie, ein Missverständnis bei den Anforderungen oder ein Problem mit der Testumgebung sein.

Diese Information liefert wichtigen Kontext für das Dashboard „Analyse des Nacharbeits- und Ablehnungsflusses“. Analysten erfahren nicht nur, dass Nacharbeit angefallen ist, sondern auch warum. Dadurch lassen sich gezielte Verbesserungen umsetzen, etwa präzisere Anforderungen, bessere Unit-Tests oder stabilere Testumgebungen, um die Nacharbeitsquote insgesamt zu senken.

Liefert qualitative Erkenntnisse zu den Ursachen von Nacharbeit. So können gezielte Prozessverbesserungen die Qualität erhöhen und wiederholte Arbeitsschleifen reduzieren.

Der Grund kann bei einem fehlgeschlagenen Test im Feld „close_notes“ oder in einem eigens dafür vorgesehenen benutzerdefinierten Feld „rework_reason“ erfasst werden. Weitere Informationen finden Sie in der ServiceNow-DevOps-Dokumentation.