Ihr Software Development Lifecycle Daten-Template

Dieses Attribut erfasst den Namen jedes Meilensteins oder Tasks, der innerhalb des Software Development Lifecycle abgeschlossen wurde. Diese Aktivitäten bilden die sequenziellen Schritte des Prozesses, von der Erstellung bis zum Deployment.

Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten ist die primäre Funktion von Process Mining. Es ermöglicht den Aufbau der Prozesslandkarte, hilft Bottlenecks zwischen den Schritten zu identifizieren und hebt nicht-konforme oder ineffiziente Prozessvarianten hervor. Die definierte Menge an Aktivitäten umfasst Schlüsselphasen wie Design, Entwicklung, Testing und Deployment.

Es definiert die Schritte in der Prozesslandkarte und ermöglicht die Analyse des Prozessflusses, die Identifizierung von Bottlenecks sowie die Erkennung von Abweichungen vom Standard-SDLC.

Dies wird typischerweise durch das Mapping von Statusänderungen, Event-Datensätzen oder Audit-Trail-Einträgen auf eine standardisierte Liste von Aktivitätsnamen abgeleitet. Zum Beispiel könnte ein 'state'-Feld, das sich zu 'In Progress' ändert, auf 'Development Started' abgebildet werden.

Das Development Item dient als primärer Case-Identifier und repräsentiert eine zu verfolgende, eigenständige Arbeitseinheit. Es verknüpft alle Aktivitäten, von der initialen Konzeption und Planung über Entwicklung, Testing und Deployment für dieses spezifische Item.

In der Process Mining Analyse ist dieses Attribut fundamental für die Rekonstruktion der End-to-End-Journey jedes Work Items. Es ermöglicht die Visualisierung von Prozessflüssen, die Berechnung der gesamten Zykluszeiten und die Identifizierung von Prozessvarianten für einzelne Funktionen oder Bugfixes. Jedes Event im Log muss mit einem Development Item verknüpft sein, um eine kohärente Prozesslandkarte zu erstellen.

Dies ist der zentrale Identifier, der alle zusammenhängenden Entwicklungsaktivitäten zu einer einzigen Prozessinstanz verbindet und es somit ermöglicht, den gesamten Lifecycle jedes Work Items zu analysieren.

Dieser Identifier ist typischerweise der Primärschlüssel aus Tabellen, die Stories, Bugs oder Tasks verwalten, wie die Tabellen 'rm_story', 'rm_bug' oder 'task' in ServiceNow.

Dieses Attribut liefert Datum und Uhrzeit, wann jede Aktivität im Software Development Lifecycle aufgezeichnet wurde. Es ist essenziell für die chronologische Reihenfolge der Events und für alle zeitbasierten Analysen.

Im Process Mining wird die Start Time verwendet, um Dauern zwischen Aktivitäten zu berechnen, Wartezeiten zu identifizieren und die gesamte Zykluszeit des Prozesses zu messen. Es ist eine kritische Komponente für Dashboards, die die Performance analysieren, wie die SDLC End-to-End Cycle Time Analysis, und für die Berechnung von Key Performance Indicators wie Code Review Lead Time.

Dieser Timestamp ist essenziell für die korrekte Reihenfolge der Events und die Berechnung aller Performance-Metriken, einschließlich Zykluszeiten, Dauern und Wartezeiten.

Typischerweise in systemgenerierten Timestamp-Feldern wie 'sys_updated_on' oder 'sys_created_on' aus dem Audit-Trail oder Task-Tabellen zu finden.

Dieses Attribut zeichnet auf, wann der Datensatz zuletzt aus ServiceNow DevOps extrahiert oder aktualisiert wurde. Es bezieht sich auf den gesamten Datensatz und nicht auf einzelne Events.

Dieser Timestamp ist entscheidend für das Verständnis der Aktualität der Analyse. Er informiert Benutzer darüber, wie aktuell die Process Erkenntnisse sind, und hilft bei der Planung von Datenaktualisierungen. Die Anzeige dieser Informationen auf Dashboards bietet Kontext zu allen Metriken und Visualisierungen und stellt sicher, dass Entscheidungen auf Basis zeitnaher Daten getroffen werden.

Bietet wichtigen Kontext zur Aktualität der Daten und stellt sicher, dass Benutzer verstehen, wie aktuell die Prozessanalyse ist.

Dieser Timestamp wird während des Datenextraktionsprozesses generiert und hinzugefügt, wobei aufgezeichnet wird, wann die Extraktion ausgeführt wurde.

Dieses Attribut gibt das Ursprungssystem für die Event-Daten an. Für diesen Prozess wird es durchgängig 'ServiceNow DevOps' sein.

Obwohl es statisch erscheinen mag, ist die explizite Angabe des Quellsystems entscheidend für die Data Governance und in Umgebungen, in denen Daten aus mehreren Systemen, wie Jira oder Azure DevOps, zusammengeführt werden könnten. Es gewährleistet Klarheit über die Datenherkunft und hilft bei der Diagnose von Datenqualitäts- oder Extraktionsproblemen.

Gewährleistet die Datenrückverfolgbarkeit und ist wesentlich für die Aufrechterhaltung der Datenintegrität, insbesondere bei der Integration von Daten aus mehreren Entwicklungstools.

Dies ist ein statischer Wert, der während des Datenextraktions- und Transformationsprozesses hinzugefügt werden sollte.

Dieses Attribut identifiziert das einem Work Item zugewiesene Team, z. B. 'Frontend Developers', 'Backend Services' oder 'QA Team'. Im Verlauf eines Work Items wird es oft zwischen verschiedenen Zuweisungsgruppen übergeben.

Die Verfolgung der Zuweisungsgruppe ist entscheidend für das Verständnis der abteilungsübergreifenden Zusammenarbeit und Übergaben. Sie hilft, systemische Verzögerungen zu identifizieren, die auftreten, wenn Arbeit von einem Team zum anderen wechselt. Dieses Attribut unterstützt die Analyse der Teamleistung, der Workload und die Identifizierung, welche Teams Bottlenecks im Gesamtfluss darstellen.

Verfolgt, welches Team für die Arbeit verantwortlich ist, und ermöglicht die Analyse der Teamleistung, des Workload-Ausgleichs und der Effizienz von Übergaben zwischen Teams.

Diese Informationen werden im Feld 'assignment_group' gespeichert, das ein Standardfeld in Task-bezogenen Tabellen in ServiceNow ist.

Dieses Attribut kategorisiert die Entwicklungsarbeit nach dem Teil des Systems, den sie betrifft. Dies könnte ein spezifischer Microservice, eine UI-Komponente oder eine Backend-Anwendung sein.

Die Segmentierung des Prozesses nach Modul oder Komponente ist entscheidend für die Identifizierung lokalisierter Bottlenecks. Das 'Component-Specific Bottleneck Erkenntnisse' Dashboard und der 'Avg Stage Duration by Component' KPI stützen sich auf dieses Attribut, um festzustellen, ob bestimmte Teile der Codebasis konsistent mit längeren Entwicklungszyklen, höheren Nacharbeitsraten oder häufigeren Deployment-Fehlern verbunden sind. Dies hilft, Verbesserungsmaßnahmen dort zu konzentriert werden, wo sie am dringendsten benötigt werden.

Ermöglicht die Segmentierung der Analyse nach Anwendung oder Komponente, um Bottlenecks oder Qualitätsprobleme, die spezifisch für bestimmte Systemteile sind, zu isolieren.

Dies ist oft ein benutzerdefiniertes Feld oder eine Referenz zur Configuration Management Database (CMDB), die das Work Item mit einem 'cmdb_ci'-Datensatz verknüpft. Konsultieren Sie die ServiceNow DevOps Dokumentation.

Dieses Attribut ist eine berechnete Metrik, die die End-to-End-Dauer für ein einzelnes Entwicklungselement darstellt. Es wird berechnet, indem die Differenz zwischen dem Timestamp der allerersten Aktivität und der allerletzten Aktivität für jeden Case ermittelt wird.

Dies ist ein primärer Key Performance Indicator für den gesamten SDLC-Prozess und unterstützt direkt den 'Average SDLC Cycle Time' KPI. Es bietet ein High-Level-Maß für die Prozessgeschwindigkeit und -effizienz. Die Analyse dieser Metrik über die Zeit und über verschiedene Dimensionen, wie Priorität oder Team, hilft, die Auswirkungen von Prozessverbesserungsinitiativen zu verfolgen.

Stellt die gesamte End-to-End-Dauer für ein Work Item dar, eine Schlüsselmetrik zur Messung der gesamten Prozesseffizienz und -geschwindigkeit.

Dies ist kein Feld im Quellsystem. Es wird im Process Mining Tool berechnet, indem die minimale StartTime von der maximalen StartTime für jede CaseId subtrahiert wird.

Dies ist ein abgeleitetes Attribut, das Aktivitäten identifiziert, die auftreten, nachdem ein Prozess zu einer früheren Phase zurückgekehrt ist. Zum Beispiel, wenn eine 'Development Started' Aktivität nach einer 'QA Testing Completed' Aktivität für dasselbe Element auftritt, wird es als Nacharbeit gekennzeichnet.

Dieses Flag ist essentiell für die Quantifizierung und Visualisierung von Nacharbeit. Es unterstützt direkt das 'Rework and Rejection Flow Analysis' Dashboard und wird zur Berechnung des 'Rework Rate after Testing' KPI verwendet. Durch das Kennzeichnen dieser Events können Analysten einfach nach der Häufigkeit, Ursachen und Auswirkungen von Nacharbeit auf die gesamte Zykluszeit filtern und diese analysieren.

Dieses Flag erleichtert die Quantifizierung und Analyse von Nacharbeit und hilft dabei, die Prozessqualität zu messen und die Ursachen wiederholter Arbeit zu identifizieren.

Dieses Attribut wird innerhalb des Process Mining Tools berechnet, indem die Abfolge der Aktivitäten für jeden Case analysiert wird, um Rückwärtsbewegungen im Prozessfluss zu erkennen.

Dieses Attribut kategorisiert Entwicklungselemente basierend auf ihrer geschäftlichen Dringlichkeit. Prioritätsstufen helfen Teams, sich auf die kritischsten Aufgaben zu konzentrieren, und werden oft zur Verwaltung von SLAs und Stakeholder-Erwartungen verwendet.

Im Process Mining ist die Priorität eine Schlüsseldimension für die vergleichende Analyse. Sie ermöglicht es, die Prozesslandkarte zu filtern, um zu sehen, ob hochpriorisierte Items einen schnelleren oder anderen Pfad nehmen. Sie ist essentiell für das 'High-Priority Feature Delivery Time' Dashboard und KPI, um zu validieren, ob kritische Elemente tatsächlich beschleunigt werden.

Ermöglicht das Filtern und Vergleichen von Prozessen für verschiedene Prioritätsstufen, um zu überprüfen, ob hochprioritäre Elemente schneller und effizienter verarbeitet werden.

Dies ist ein Standardfeld, oft 'priority' genannt, in Task-bezogenen Tabellen in ServiceNow.

Dieses Attribut spiegelt den offiziellen Status des Entwicklungselements innerhalb von ServiceNow wider. Während Aktivitäten abgeleitete Prozessschritte sind, repräsentiert der Zustand die formale Phase im Workflow des Systems.

Der Zustand ist oft die Quelle, aus der Aktivitäten abgeleitet werden. Er kann zur Datenvalidierung und zur Erstellung einfacherer, High-Level-Ansichten des Prozesses verwendet werden. Zum Beispiel kann die Analyse der in jedem Zustand verbrachten Zeit eine andere Sicht auf Bottlenecks bieten als die Analyse der Zeit zwischen Aktivitäten. Er ist auch nützlich, um Elemente zu identifizieren, die ins Stocken geraten oder gelöst wurden.

Gibt den offiziellen Systemstatus eines Work Items an, der oft die Quelle für die Ableitung von Aktivitäten ist und zur Validierung sowie für eine High-Level-Statusanalyse genutzt werden kann.

Dies ist ein Standardfeld, üblicherweise 'state' oder 'stage' genannt, in Task-bezogenen Tabellen in ServiceNow.

Dieses Attribut unterscheidet zwischen verschiedenen Arten von Arbeiten, die den SDLC-Prozess durchlaufen. Zum Beispiel könnte der Prozess zur Behebung eines kritischen Bugs anders und schneller sein als der Prozess zur Entwicklung eines neuen Funktionen.

Die Analyse des Prozesses basierend auf dem Work Item Typ ermöglicht ein nuancierteres Verständnis der Performance. Sie hilft, Fragen zu beantworten wie: 'Haben Bugs eine höhere Nacharbeitsrate als neue Funktionen?' oder 'Ist unsere Zykluszeit zur Reduzierung technischer Schulden akzeptabel?'. Diese Segmentierung bietet tiefere Erkenntnisse als eine allgemeine Prozessansicht.

Unterscheidet zwischen verschiedenen Arten von Arbeiten, wie Funktionen und Bugs, die unterschiedliche Prozesspfade, Prioritäten und erwartete Dauern haben können.

Dies kann aus der Quelltabelle des Datensatzes (z. B. 'rm_story' vs. 'rm_bug') oder aus einem 'type'-Feld in einer generischen Task-Tabelle bestimmt werden.

Dieses Attribut identifiziert die für die Ausführung einer bestimmten Task oder Aktivität verantwortliche Person. Es ist dynamisch und kann sich ändern, wenn das Entwicklungselement zwischen verschiedenen Phasen und Teams wechselt.

Dieses Attribut ist entscheidend für die Analyse von Ressourcenallokation, Workload und Übergaben. Es unterstützt direkt das 'Developer Workload and Handoffs' Dashboard und den 'Activity Volume per Developer' KPI. Durch die Verfolgung von Änderungen in diesem Feld ist es möglich, Übergabezeiten zu messen und Kollaborations-Bottlenecks zwischen Entwicklern oder zwischen Entwicklungs- und QA-Teams zu identifizieren.

Dies ist essenziell für ressourcenbasierte Analysen, einschließlich Workload-Verteilung, Übergabeeffizienz und der Identifizierung teamspezifischer Performance-Muster.

Diese Informationen werden typischerweise im Feld 'assigned_to' in Task-bezogenen Tabellen in ServiceNow gespeichert.

Dieses Attribut erfasst das Ergebnis eines Deployments in eine bestimmte Umgebung. Es ist eine kritische Information für das Verständnis der Zuverlässigkeit und Stabilität des Release-Prozesses.

Dieses Attribut ist essentiell für das 'Deployment Success and Failure Trends' Dashboard und den 'Deployment Failure Rate' KPI. Durch die Analyse der Häufigkeit und Trends von Deployment-Fehlern können Organisationen zugrunde liegende Probleme in ihrem Testing, ihrer Infrastruktur oder Release-Koordination identifizieren. Es hilft, Anstrengungen auf die Verbesserung der Qualität und Zuverlässigkeit der Softwareauslieferung zu konzentrieren.

Misst direkt den Erfolg von Bereitstellungsaktivitäten, was entscheidend für die Berechnung der Bereitstellungsfehlerquote und die Analyse der Release-Stabilität ist.

Dieser Status wird typischerweise in Deployment Tracking Tasks oder CI/CD Pipeline Ausführungsdatensätzen erfasst, die in ServiceNow DevOps integriert sind.

Dieses Attribut bietet eine direkte Verknüpfung von einem Entwicklungselement zu der spezifischen Code-Änderung im Source Code Repository, wie Git. Es wird erfasst, wenn eine 'Code Committed' Aktivität auftritt.

Im Process Mining bereichert die Commit ID die Analyse, indem sie Prozessdaten mit Engineering-Daten verbindet. Sie ermöglicht es Analysten, ein problematisches Deployment auf die exakte Code-Änderung zurückzuführen oder Code-Komplexitätsmetriken mit Entwicklungszykluszeiten zu korrelieren. Dies bietet eine viel tiefere, technischere Ebene der Root Cause Analysis.

Verknüpft das Process Event mit einer spezifischen Code-Änderung und ermöglicht eine tiefere Ursachenanalyse, indem Prozessmetriken mit Code-Ebene-Details korreliert werden.

Dies wird durch ServiceNow DevOps-Integrationen mit Source Code Management Systemen wie Git oder SVN erfasst. Die Daten befinden sich in verwandten Tabellen, die mit dem Entwicklungselement verknüpft sind.

Dieses Attribut liefert Datum und Uhrzeit, wann jede Aktivität im Software Development Lifecycle abgeschlossen wurde. Es ist besonders nützlich für Aktivitäten mit messbarer Dauer, wie 'Code Review Performed' oder 'QA Testing'.

Im Process Mining ermöglicht das Vorhandensein von Start- und Endzeit eine präzise Berechnung der Aktivitätsbearbeitungszeiten, wodurch diese von der Wartezeit zwischen Aktivitäten unterschieden werden. Dies hilft festzustellen, ob Verzögerungen auf lange Tasks oder lange Wartezeiten auf Ressourcen zurückzuführen sind. Für Events, die als augenblicklich gelten, wie 'Build Triggered', kann die End Time identisch mit der Start Time sein.

Ermöglicht die präzise Berechnung der Aktivitätsbearbeitungszeit, was hilft, zwischen Arbeitszeit und Wartezeit zu unterscheiden.

Dies muss möglicherweise abgeleitet werden. Es könnte der Timestamp der Startzeit der nächsten Aktivität sein, oder es könnte aus einem separaten 'end date'-Feld stammen, falls im Quellsystem verfügbar.

Dieses Attribut verknüpft ein Entwicklungselement mit einem spezifischen, geplanten Release, wie 'Version 2.3' oder 'Q4 2023 Release'. Es ist ein Schlüsselelement für Projektmanagement und Release-Planung.

Für Process Mining ist dieses Attribut entscheidend für das 'Release Plan Adherence Monitoring' Dashboard. Durch den Vergleich der tatsächlichen Abschlussdaten mit den geplanten Release-Daten können Teams die Termintreue messen, Elemente identifizieren, die Gefahr laufen, ein Release zu verpassen, und die Ursachen von Release-Verzögerungen analysieren. Es stellt eine direkte Verbindung zwischen dem Low-Level-Entwicklungsprozess und High-Level-Geschäftszielen her.

Verbindet Entwicklungsarbeit mit spezifischen Releases und ermöglicht die Analyse der Termineinhaltung und des Einflusses von Prozessverzögerungen auf Release-Zeitpläne.

Diese Informationen werden typischerweise in einem 'release'- oder 'planned_release'-Feld gespeichert, das oft auf eine Release Management Tabelle in ServiceNow verweist. Konsultieren Sie die ServiceNow DevOps Dokumentation.

Wenn ein Element QA oder UAT fehlschlägt, erfasst dieses Attribut den Grund für den Fehler. Dies könnte eine spezifische Bug-Kategorie, ein Missverständnis der Anforderungen oder ein Umgebungsproblem sein.

Diese Informationen liefern kritischen Kontext für das 'Rework and Rejection Flow Analysis' Dashboard. Anstatt nur zu wissen, dass Nacharbeit aufgetreten ist, können Analysten verstehen, warum sie aufgetreten ist. Dies ermöglicht gezielte Verbesserungen, wie bessere Anforderungsdefinitionen, erweitertes Unit Testing oder stabilere Testumgebungen, um die gesamte Nacharbeitsrate zu reduzieren.

Bietet qualitative Einblicke, warum Nacharbeit auftritt, und ermöglicht gezielte Prozessverbesserungen zur Steigerung der Qualität und Reduzierung von Nacharbeits-Schleifen.

Dies kann in einem 'close_notes'-Feld erfasst werden, wenn ein Test fehlschlägt, oder in einem dedizierten benutzerdefinierten Feld 'rework_reason'. Konsultieren Sie die ServiceNow DevOps Dokumentation.