Ihre Software-Entwicklungslebenszyklus-Daten-Template

Der Aktivitätsname beschreibt einen spezifischen Schritt oder eine Statusänderung im Entwicklungsprozess. Diese Aktivitäten bilden die Knoten in der Prozesslandkarte und repräsentieren Schlüsselmeilensteine wie 'Element für Entwicklung genehmigt', 'Code zur Überprüfung eingereicht' oder 'QA-Tests abgeschlossen'.

Dieses Attribut ist entscheidend für die Visualisierung des Prozessflusses und das Verständnis der Ereignissequenz. Durch die Analyse der verschiedenen Aktivitäten können Teams die häufigsten Pfade identifizieren, Prozessabweichungen entdecken und die in verschiedenen Phasen verbrachte Zeit messen. Es bildet die Grundlage für Engpassanalyse, Nacharbeitserkennung und Konformitätsprüfung gegenüber einem Zielprozessmodell.

Es definiert die Schritte im Prozess und ermöglicht die Visualisierung und Analyse des Entwicklungsworkflows.

Oft abgeleitet aus Statusänderungsprotokollen, Event Streams oder Audit-Historientabellen, die mit Entwicklungsarbeitselementen verbunden sind.

Die Entwicklungselement-ID ist der Primärschlüssel, der jede Case-Instanz über den gesamten Software Development Lifecycle eindeutig identifiziert. Jede ID repräsentiert eine eigenständige Arbeitseinheit, wie eine User Story, einen Task oder einen Bugfix, von ihrer Erstellung bis zu ihrer endgültigen Lösung oder Bereitstellung.

In der Process Mining-Analyse ist dieses Attribut essenziell, um die End-to-End-Reise jedes Arbeitselements zu rekonstruieren. Es ermöglicht dem Tool, alle zusammenhängenden Aktivitäten, wie 'Entwicklung gestartet', 'Code-Review abgeschlossen' und 'In Produktion bereitgestellt', zu einem kohärenten Prozessfluss zu verknüpfen. Die Analyse des Lifecycles einzelner Entwicklungselemente hilft, Variationen, Verzögerungen und Nacharbeitschleifen im Zusammenhang mit spezifischen Arbeitseinheiten zu identifizieren.

Dies ist der fundamentale Case Identifier, der erforderlich ist, um den gesamten Lebenszyklus jedes Entwicklungselementes von Anfang bis Ende nachzuvollziehen.

Typischerweise in den Haupt-Arbeitselement- oder Issue Tracking-Tabellen eines Software-Entwicklungsmanagementsystems zu finden.

Die Event Start Time markiert das genaue Datum und die Uhrzeit, zu der eine Aktivität begann. Sie liefert die chronologische Reihenfolge für alle Events innerhalb eines einzelnen Cases, was für die genaue Rekonstruktion des Prozessflusses unerlässlich ist.

Timestamps sind die Grundlage aller zeitbasierten Process Mining-Analysen. Sie werden verwendet, um wichtige Performance-Indikatoren wie Zykluszeiten, Wartezeiten und Bearbeitungszeiten zwischen Aktivitäten zu berechnen. Die Analyse von Timestamps hilft, Engpässe zu identifizieren, die Prozesseffizienz zu messen und die Dauer verschiedener Phasen im Entwicklungs-Lifecycle zu verstehen. Zum Beispiel kann die Zeit zwischen 'Code zur Überprüfung eingereicht' und 'Code-Review abgeschlossen' Verzögerungen im Review-Prozess aufdecken.

Dieser Timestamp ist essenziell, um Events korrekt zu ordnen und alle zeitbasierten Metriken, wie Cycle Time und Bottlenecks, zu berechnen.

Verfügbar in Event Logs, Audit Trails oder Historientabellen, die Änderungen an Entwicklungsarbeitselementen aufzeichnen.

Das Attribut 'Letzte Datenaktualisierung' zeichnet Datum und Uhrzeit der letzten Extraktion oder Aktualisierung der Daten aus dem Quellsystem auf. Dies gibt einen klaren Hinweis auf die Aktualität und Relevanz der Daten.

Diese Information ist entscheidend, um sicherzustellen, dass Analysen und Dashboards auf aktuellen Informationen basieren. Stakeholder können auf einen Blick sehen, wie aktuell die Prozessansicht ist, was Vertrauen in die abgeleiteten Erkenntnisse schafft. Es ist ein wichtiges Metadaten-Element für die Verwaltung von Datenpipelines und die Planung von Datenaktualisierungen.

Gibt die Aktualität der Daten an und stellt sicher, dass die Analyse zeitnah und relevant für die Entscheidungsfindung ist.

Dieser Wert wird typischerweise von der Data Extraction, Transformation und Loading (ETL)-Pipeline generiert und gespeichert.

Das Source System-Attribut identifiziert die Ursprungsanwendung oder -plattform, auf der die Daten des Entwicklungslebenszyklus aufgezeichnet wurden. Dies ist besonders nützlich in Umgebungen, in denen mehrere Entwicklungstools verwendet werden, beispielsweise Jira für das Issue Tracking und GitLab für das Quellcode-Management.

Bei der Analyse hilft die Angabe des Quellsystems bei der Datenvalidierung und liefert Kontext für die Prozessdaten. Sie ermöglicht eine vergleichende Analyse von Prozessen, die in verschiedenen Systemen verwaltet werden, und stellt sicher, dass die Dateninterpretation korrekt ist, da Feldnamen und Prozesskonventionen zwischen Systemen variieren können. Es kann auch verwendet werden, um die Analyse auf den Datensatz eines spezifischen Tools zu filtern.

Bietet Kontext zum Ursprung der Daten, was entscheidend für die Datenvalidierung und für Analysen ist, die mehrere integrierte Systeme umfassen.

Dies ist typischerweise ein statischer Wert, der während des Datenextraktionsprozesses hinzugefügt wird, um den Ursprung der Datensätze zu identifizieren.

Die Event End Time markiert den Abschluss einer Aktivität. Während viele Prozessschritte als augenblickliche Events erfasst werden, bei denen Start- und Endzeit identisch sind, haben einige Aktivitäten eine messbare Dauer. Zum Beispiel könnte eine 'Code Review'-Aktivität eine eigenständige Start- und Endzeit haben.

Dieses Attribut ist essenziell für die Berechnung der aktiven Bearbeitungszeit spezifischer Aufgaben, um sie von Leerlauf- oder Wartezeiten zu unterscheiden. Durch den Vergleich der Dauer zwischen Event Start Time und Event End Time können Analysten den Aufwand für wertschöpfende Aktivitäten messen. Dies ermöglicht eine granularere Analyse der Ressourcenauslastung und hilft zu identifizieren, welche Aufgaben die meiste aktive Arbeitszeit beanspruchen.

Ermöglicht die Berechnung der aktiven Bearbeitungszeit für einzelne Aktivitäten, trennt diese von der Wartezeit und bietet eine klarere Sicht auf den Aufwand.

Kann in Event Logs gefunden oder durch die Übernahme des Timestamps der nächsten Aktivität in der Sequenz für dasselbe Arbeitselement abgeleitet werden.

Das Attribut Priorität zeigt die geschäftliche oder technische Dringlichkeit eines Arbeitselements an. Dies wird typischerweise auf Werte wie 'Hoch', 'Mittel' oder 'Niedrig' gesetzt und hilft Teams, zu entscheiden, woran als Nächstes gearbeitet werden soll.

Im Process Mining ist die Priorität eine leistungsstarke Dimension für die Analyse. Sie ermöglicht es Teams, zu überprüfen, ob Elemente mit hoher Priorität tatsächlich schneller verarbeitet werden als solche mit niedriger Priorität. Der Vergleich der Durchlaufzeiten über verschiedene Prioritätsstufen hinweg kann aufzeigen, ob der Prozess die Geschäftsprioritäten berücksichtigt. Werden hochpriorisierte Elemente häufig verzögert, kann dies auf Probleme in der Planung, Ressourcenallokation oder im Workflow-Design hinweisen.

Hilft zu überprüfen, ob hochpriorisierte Arbeit schneller durch den Prozess läuft, und identifiziert Engpässe, die kritische Elemente überproportional beeinflussen.

Ein Standardfeld im Arbeitselement- oder Problemdatensatz der meisten Entwicklungsmanagementsysteme.

Der Projektname bietet Kontext, indem er Arbeitselemente gruppiert, die zu einem bestimmten Produkt, einer Initiative oder einer Codebasis gehören. Entwicklungspraktiken und Cycle Times können zwischen Projekten erheblich variieren, beispielsweise zwischen einem Altsystem und einer neuen Greenfield-Anwendung.

Dieses Attribut ermöglicht eine hochrangige Aggregation und den Vergleich von Entwicklungsprozessen in verschiedenen Bereichen der Organisation. Durch das Filtern der Analyse nach Projekten können Manager die Gesundheit und Effizienz jedes Entwicklungsaufwands bewerten. Es ist auch unerlässlich, um zu verstehen, wie die Prozessleistung mit dem spezifischen Kontext und der technischen Umgebung eines Projekts zusammenhängt.

Ermöglicht die Segmentierung der Prozessanalyse nach Produkt oder Initiative, wodurch Leistungsunterschiede im Zusammenhang mit dem Projektkontext aufgedeckt werden.

Ein Standardfeld im Arbeitselement- oder Problemdatensatz, oder der Name des Repositorys in Systemen wie Git.

Der Status des Entwicklungselements repräsentiert den Zustand eines Arbeitselements zu einem bestimmten Zeitpunkt. Während der Aktivitätsname das Event der Statusänderung erfasst, erfasst dieses Attribut den Zustand selbst. Dies kann nützlich sein, um den Arbeitszustand zum Zeitpunkt eines Events zu analysieren.

Dieses Attribut wird oft zur Erstellung des Aktivitätsnamens verwendet, kann aber zusätzlichen Kontext liefern. Zum Beispiel ermöglicht die Analyse des Statusfeldes eine Daueranalyse, wie lange Elemente in einem bestimmten Zustand verweilen, wie 'Blockiert' oder 'Warten auf Review'. Das Verständnis der in unproduktiven Zuständen verbrachten Zeit ist entscheidend für die Identifizierung systemischer Verzögerungen und die Verbesserung der Flusseffizienz.

Es ermöglicht die Analyse der in verschiedenen Zuständen verbrachten Zeit und hilft, Verzögerungen sowie die in nicht wertschöpfenden Status wie 'Blockiert' verbrachte Zeit zu identifizieren.

Verfügbar als Primärfeld im Arbeits- oder Problemdatensatz und wird in dessen Historie verfolgt.

Dieses Attribut identifiziert das spezifische Team, die Squad oder Gruppe, die für die Lieferung des Entwicklungselements verantwortlich ist. In größeren Organisationen wird die Arbeit oft auf mehrere spezialisierte Teams wie 'Frontend', 'Backend', 'Mobile' oder 'Platform' verteilt.

Die Analyse nach Team Name ermöglicht einen Leistungsvergleich und den Austausch von Best Practices zwischen den Teams. Sie hilft, Fragen zu beantworten wie: 'Welches Team hat die kürzeste Cycle Time?' oder 'Erfährt ein Team mehr Nacharbeit als andere?'. Diese Analyse kann Unterschiede in Workflows, Fähigkeiten oder der Ressourcenverfügbarkeit aufdecken, die sich auf die gesamte Lieferleistung auswirken, und bietet Möglichkeiten für gezielte Prozessverbesserungen.

Ermöglicht Leistungs-Benchmarking zwischen verschiedenen Teams und hilft, Best Practices und Bereiche für Verbesserungen zu identifizieren.

Oft verbunden mit dem zugewiesenen Benutzer oder als direktes Feld im Projekt- oder Arbeitselementdatensatz.

Dieses Attribut kategorisiert die Art der ausgeführten Arbeit. Verschiedene Typen von Arbeitselementen folgen oft unterschiedlichen Prozesspfaden und haben unterschiedliche Leistungserwartungen. Zum Beispiel könnte ein 'Bug' einen schnellen Hotfix-Prozess erfordern, während ein 'Feature' einem Standard-Entwicklungs- und Testzyklus folgt.

Mithilfe dieses Attributs können Analysten die Prozessflüsse und die Leistung für verschiedene Arten von Arbeit vergleichen. Dies hilft, Fragen zu beantworten wie: 'Ist unser Bugfixing-Prozess schneller als unser Feature-Entwicklungsprozess?' oder 'Erfahren technische Schulden-Elemente mehr Nacharbeit?'. Es ist eine fundamentale Dimension zur Segmentierung der Daten, um spezifischere und umsetzbarere Einblicke zu gewinnen.

Ermöglicht den Vergleich von Prozessen und Leistungen über verschiedene Arbeitskategorien hinweg und deckt Ineffizienzen auf, die spezifisch für bestimmte Entwicklungsarten sind.

Ein Standardfeld im Arbeitselement- oder Problemdatensatz der meisten Entwicklungsmanagementsysteme.

Dieses Attribut identifiziert die Einzelperson oder Gruppe, die für die Fertigstellung des aktuellen Schritts oder des gesamten Arbeitselements verantwortlich ist. Der Beauftragte kann sich im Laufe des Lebenszyklus mehrmals ändern, was die Übergaben zwischen verschiedenen Rollen wie Entwicklern, QA-Testern und Reviewern widerspiegelt.

Die Analyse des Assigned To-Attributs ist entscheidend für das Verständnis der Team-Arbeitslast, der Effizienz von Übergaben und der Kollaborationsmuster. Es ermöglicht das Filtern der Prozesskarte, um die Arbeit einer bestimmten Person oder eines Teams zu sehen, und hilft, ressourcenspezifische Bottlenecks zu identifizieren. Eine Social Network Analysis, basierend auf Übergaben zwischen Beauftragten, kann Kommunikationslücken oder übermäßig komplexe Kollaborationsstrukturen aufdecken.

Es ermöglicht die Analyse der Ressourcen-Arbeitslast, der Übergabehäufigkeit und der Kollaborationsmuster und trägt zur Optimierung der Teameffizienz bei.

Findet sich im Arbeitselement- oder Problemdatensatz, oft in der Historie oder im Audit Log des Elements verfolgt.

Das Attribut 'Ersteller' identifiziert die Person, die das Arbeitselement initiiert hat. Dies könnte ein Produktmanager sein, der eine User Story erstellt, ein QA-Tester, der einen Bug meldet, oder ein Kundendienstmitarbeiter, der ein Kundenproblem meldet.

Die Analyse des Erstellers von Arbeitselementen kann Einblicke in die Ursprünge der Arbeit geben. Zum Beispiel könnte ein hohes Volumen von Bugs, die von Endbenutzern gemeldet werden, auf Qualitätsprobleme in jüngsten Releases hinweisen. Es kann auch verwendet werden, um die Klarheit und Qualität der anfänglichen Anforderungen zu analysieren, indem der Ersteller mit nachgelagerten Nacharbeiten oder Verzögerungen korreliert wird.

Hilft, die Initiatoren der Arbeit zu identifizieren, was analysiert werden kann, um Ursprünge von Anforderungen, Bugs oder Feature-Anfragen zu verstehen.

Ein Standardfeld wie 'Reporter' oder 'Autor' im ursprünglichen Erstellungsdatensatz eines Arbeitselements.

Das Attribut 'Geplantes Release' verknüpft ein Entwicklungselement mit einem bestimmten Lieferplan oder einer Version. Dies wird häufig in der Release-Planung genutzt, um Funktionen und Fehlerbehebungen für eine koordinierte Bereitstellung zu bündeln.

Die Analyse nach 'Geplantes Release' unterstützt die Bewertung der Vorhersehbarkeit und Zuverlässigkeit des Release-Prozesses. Sie ermöglicht die Verfolgung pünktlicher Lieferraten durch den Vergleich des geplanten Releases mit dem tatsächlichen Bereitstellungsdatum. Darüber hinaus hilft sie beim Umfangsmanagement und beim Verständnis des Arbeitsflusses für ein bestimmtes Release, indem sie potenzielle Risiken oder Verzögerungen aufzeigt, die den Lieferzeitplan beeinträchtigen könnten.

Verbindet Entwicklungsarbeit mit Lieferplänen und ermöglicht die Analyse von pünktlichen Lieferraten und Release-Vorhersehbarkeit.

Ein Standardfeld wie 'Fix Version', 'Target Release' oder 'Iteration Path' in agilen Planungs- und Entwicklungstools.

Der Rework Indicator ist ein abgeleitetes boolesches oder kategorisches Attribut, das Events als Teil eines Nacharbeitszyklus kennzeichnet. Dies wird typischerweise identifiziert, wenn sich der Prozessfluss rückwärts bewegt, beispielsweise von 'QA Testing' zurück zu 'Development in Progress', oder wenn spezifische Nacharbeitsaktivitäten wie 'Rework Identified in QA' auftreten.

Dieses Attribut ist äußerst wertvoll für die Qualitäts- und Effizienzanalyse. Es ermöglicht die direkte Berechnung von Nacharbeitsquoten und hebt die Teile des Prozesses hervor, die die meiste Nacharbeit erzeugen. Durch das Filtern nach Nacharbeitsaktivitäten können Teams eine Ursachenanalyse durchführen, um zu verstehen, warum Qualitätsprobleme nicht früher erkannt werden. Die Reduzierung von Nacharbeit ist ein wichtiger Hebel zur Verbesserung sowohl der Entwicklungsgeschwindigkeit als auch der Produktqualität.

Quantifiziert direkt Nacharbeit und ermöglicht es Teams, deren Häufigkeit zu messen, Ursachen zu analysieren und Qualitätsverbesserungen im Laufe der Zeit zu verfolgen.

Typischerweise während der Daten-Transformation abgeleitet, indem Rückwärtsschleifen im Prozessfluss oder spezifische fehlerbezogene Aktivitätsnamen identifiziert werden.

Der Schweregrad unterscheidet sich von der Priorität; er misst die technische Auswirkung eines Problems, während die Priorität die Dringlichkeit der Behebung misst. Zum Beispiel könnte ein Tippfehler auf einer selten besuchten Seite einen geringen Schweregrad und eine niedrige Priorität haben, während ein kritisches Datenkorruptionsproblem einen hohen Schweregrad und eine hohe Priorität hätte.

Dieses Attribut ist entscheidend für die Qualitätsanalyse, insbesondere bei der Analyse von Bug-Fixing-Prozessen. Es ermöglicht Teams zu beurteilen, ob sie die schwerwiegendsten Probleme zuerst effektiv angehen. Durch die Analyse der Cycle Time für verschiedene Schweregrade können Organisationen sicherstellen, dass kritische Systemprobleme schnell gelöst werden, um Kundenbeeinträchtigungen zu minimieren.

Ermöglicht die Analyse, wie effektiv das Team Probleme basierend auf deren technischer Auswirkung angeht, um sicherzustellen, dass kritische Probleme umgehend gelöst werden.

Ein Standardfeld, insbesondere für Arbeitselemente vom Typ 'Bug' oder 'Incident', in Entwicklungsmanagementsystemen.