Ihr Software Development Lifecycle Daten-Template

Dieses Attribut repräsentiert einen eigenständigen Schritt oder Meilenstein im Softwareentwicklungsprozess. Diese Aktivitäten werden aus Änderungen im Statusfeld des Jira Issue oder anderen signifikanten Events wie Code-Commits oder Reviews abgeleitet.

Im Process Mining bildet die Sequenz dieser Aktivitäten die Prozesslandkarte. Die Analyse von Aktivitäten hilft, den Prozessfluss zu identifizieren, die Dauer spezifischer Phasen zu messen und Abweichungen vom Standard-Workflow zu erkennen, wie Nacharbeitszyklen oder übersprungene Quality Gates.

Activities definieren die Schritte des Process, und ihre Reihenfolge ist entscheidend für die Visualisierung des Prozessflusses, die Identifizierung von Engpässen und die Analyse von Prozessvariationen.

Typischerweise abgeleitet aus den 'Status'-Feldübergängen im Jira Issue-Verlauf oder Changelog. Es kann auch mit Daten aus verbundenen Entwicklungstools angereichert werden.

Das Entwicklungselement dient als primärer Case-Identifikator und repräsentiert eine eigenständige Arbeitseinheit wie ein Feature, Bugfix oder eine Aufgabe. Es verknüpft alle Aktivitäten von der ersten Konzeption und Planung über Entwicklung, Tests und Bereitstellung für dieses spezifische Element. In Jira entspricht dies typischerweise dem Issue Key, zum Beispiel 'PROJ-123'.

Die Analyse dieses Attributs ermöglicht die Nachverfolgung des gesamten End-to-End-Lebenszyklus jedes Arbeitselements. Es ist die Grundlage für die Erstellung von Prozesslandkarten, die Berechnung von Zykluszeiten und die Identifizierung von Variationen, wie verschiedene Elemente den Entwicklungsprozess durchlaufen.

Dies ist der essentielle Schlüssel, um alle zugehörigen Entwicklungsaktivitäten miteinander zu verknüpfen, wodurch es möglich wird, den Weg eines einzelnen Arbeitselements von Anfang bis Ende zu verfolgen.

Dies ist das Standardfeld 'key' für ein Issue im Jira Software Issue API-Objekt.

Event Time ist der timestamp, der aufzeichnet, wann eine Activity stattgefunden hat. Dies ist die zeitliche Grundlage für alle Process Mining Analysen und liefert die chronologische Reihenfolge der Events für jeden Case.

Dieses Attribute ist entscheidend für die Berechnung aller zeitbasierten Metriken, einschließlich Cycle Times, Verarbeitungszeiten und Wartezeiten zwischen Activities. Es ermöglicht die Analyse der Prozess-Performance über die Zeit, wodurch identifiziert werden kann, wann und wo Verzögerungen im Development Lifecycle auftreten.

Dieser Timestamp ist fundamental für die korrekte Sequenzierung von Events und die Berechnung aller dauerbasierten Metriken, die entscheidend für das Verständnis der Prozesseffizienz und die Identifizierung von Verzögerungen sind.

Dies entspricht dem 'created' Timestamp für jeden Eintrag im Changelog oder Verlauf eines Issues.

Dieses Attribut erfasst das Datum und die Uhrzeit der letzten Datenextraktion aus Jira Software. Es bietet Kontext zur Aktualität der analysierten Daten.

Die Kenntnis der letzten Aktualisierungszeit ist wichtig, um die Zeitnähe der Prozesserkenntnisse zu verstehen. Es hilft Analysten und Business-Nutzern zu bestätigen, dass sie aktuelle Daten betrachten und informiert sie über den Stichtag für die in die Analyse einbezogenen Events.

Zeigt die Aktualität der data an, was entscheidend ist, um sicherzustellen, dass Analysen und Dashboards den aktuellsten Zustand des Process widerspiegeln.

Dieser Timestamp wird am Ende des Datenextraktions-, Transformations- und Ladeprozesses (ETL) generiert und aufgezeichnet.

Dieses Attribut identifiziert den Ursprung der Daten. Für diesen Prozess wird es durchgängig 'Jira Software' sein, aber es ist nützlich, um Daten zu unterscheiden, wenn mehrere Quellsysteme in einer größeren Analyse kombiniert werden.

In einer breiteren IT-Landschaft gewährleistet die Angabe des Quellsystems eine klare Datenherkunft und hilft beim Management von Datenqualität und Integrationsbemühungen über verschiedene Plattformen hinweg.

Bietet eine klare Datenherkunft, was entscheidend ist, wenn Daten aus mehreren Systemen integriert werden oder für Data Governance- und Audit-Zwecke.

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

Dieses Attribut spiegelt den spezifischen Status des Entwicklungselements zu einem bestimmten Zeitpunkt wider, z. B. 'In Progress', 'In Review' oder 'Done'. Die Abfolge von Statusänderungen über die Zeit generiert die Aktivitäten für Process Mining.

Während das Attribut 'Activity' das Änderungs-Event darstellt, liefert 'ItemStatus' den Zustand des Elements. Es ist nützlich als Dimension für Filterung und Analyse, um zu sehen, wie viele Elemente sich derzeit in einem bestimmten Zustand befinden oder um die Eigenschaften von Elementen zu analysieren, die lange in einem bestimmten Status verbleiben.

Bietet einen Überblick darüber, wo sich ein Element in seinem Lebenszyklus befindet. Dies ist essenziell für statusbasierte Analysen und das Verständnis des aktuellen Bearbeitungsstands.

Dies ist das Feld 'status' innerhalb des 'fields'-Objekts der Jira Issue API-Antwort.

Der Bearbeiter ist die Person, die für das Arbeitselement in seinem aktuellen Status verantwortlich ist. In Jira ist dies ein Standardfeld, das sich ändert, wenn das Element zwischen verschiedenen Personen und Teams wechselt.

Die Analyse des Bearbeiters ist entscheidend, um Ressourcenzuweisung, Arbeitslastverteilung und Übergabepunkte zu verstehen. Sie hilft bei der Beantwortung von Fragen, welche Entwickler oder Teams in spezifischen Phasen involviert sind, wer ein Engpass ist und wie die Arbeit innerhalb der Organisation verteilt ist.

Identifiziert den verantwortlichen Benutzer oder die Ressource für eine Activity, was eine Workload-Analyse, Resource Management und das Verständnis von Übergaben zwischen Einzelpersonen ermöglicht.

Dies ist das Feld 'assignee' innerhalb des 'fields'-Objekts der Jira Issue API-Antwort.

Item Priority definiert die relative Wichtigkeit oder Dringlichkeit eines Arbeitselements. Jira bietet ein Standard-'priority'-Feld mit konfigurierbaren Stufen wie Highest, High, Medium und Low.

Die Analyse der Priorität ist entscheidend für die Überprüfung der Konformität und die Identifizierung von Engpässen für kritische Elemente. Zum Beispiel basiert das Dashboard 'Priority Item Conformance Check' auf diesem Attribute, um zu überprüfen, ob High-Priority-Elemente wie erwartet beschleunigt werden oder ob sie in denselben Warteschlangen wie Low-Priority-Elemente stecken bleiben.

Hilft bei der Analyse, ob High-Priority-Elemente schneller als Low-Priority-Elemente verarbeitet werden und ob sie einen optimierteren Pfad verfolgen, um die Einhaltung von SLAs sicherzustellen.

Dies ist das Feld 'priority' innerhalb des 'fields'-Objekts der Jira Issue API-Antwort.

Item Type kategorisiert die Art der ausgeführten Arbeit. Jira verwendet ein Standard-'issuetype'-Feld, um zwischen verschiedenen Arten von Arbeitselementen zu unterscheiden, die oft einzigartige Workflows haben.

Dieses Attribute ist wesentlich für die vergleichende Analyse. Es ermöglicht Ihnen, den Process nach spezifischen Arbeitsarten zu filtern, z.B. um den Lifecycle eines 'Bug's' versus einer 'Story' zu vergleichen. Dies hilft zu identifizieren, ob bestimmte Arbeitsarten anfälliger für Verzögerungen, Nacharbeit oder Abweichungen vom Standard-Process sind.

Ermöglicht die Segmentierung der Prozessanalyse, um zu vergleichen, wie verschiedene Arten von Arbeit, wie Bugs versus neue Funktionen, gehandhabt werden und wo sich ihre Processes unterscheiden.

Dies ist das Feld 'issuetype' innerhalb des 'fields'-Objekts der Jira Issue API-Antwort.

In Jira werden alle Arbeitselemente in Projekten organisiert. Der Project Name liefert einen übergeordneten Kontext, der oft einem spezifischen Produkt, Team oder einer Initiative entspricht.

Dieses Attribute ist eine leistungsstarke Dimension für Filterung und Vergleich. Es ermöglicht die Analyse und das Benchmarking des SDLC-Prozesses über verschiedene Projekte oder Produkte hinweg. Dies kann aufzeigen, welche Projekte effizienter sind, welche mehr Nacharbeit aufweisen und ob verschiedene Teams unterschiedliche Prozessvarianten verfolgen.

Ermöglicht die Segmentierung der Prozessanalyse nach Projekt, Produkt oder Team, was Leistungsvergleiche und die Identifizierung von Best Practices erlaubt.

Dies ist das Feld 'project' innerhalb des 'fields'-Objekts der Jira Issue API-Antwort.

Repräsentiert das spezifische agile oder Feature-Team, das dem Entwicklungselement zugewiesen ist. In Jira wird dies oft als benutzerdefiniertes Feld implementiert oder kann aus anderen Informationen wie dem Projekt oder einer spezifischen Komponente abgeleitet werden.

Dieses Attribut ist entscheidend für die Analyse der Teamleistung. Es ermöglicht die Filterung von Dashboards, um Metriken wie Zykluszeit, Nacharbeitsquote und Durchsatz für einzelne Teams anzuzeigen. Dies ist entscheidend für die Dashboards 'Effizienz der Phasenübergaben' und 'Entwickler-Auslastung & Item-Fortschritt'.

Ermöglicht die Leistungsmessung und den Vergleich zwischen verschiedenen Entwicklungsteams, wodurch leistungsstarke Teams identifiziert und Best Practices geteilt werden können.

Dies ist oft ein benutzerdefiniertes Feld in Jira. Konsultieren Sie Ihren Jira-Administrator, um den spezifischen Feldnamen zu identifizieren, der 'Team', 'Squad' oder ähnlich lauten könnte.

Die Bearbeitungszeit ist die Dauer, die ein Element in einem bestimmten Status oder einer Aktivität verbringt. Sie wird als Differenz zwischen EventEndTime und EventTime für ein einzelnes Event im Event Log berechnet.

Diese Metrik ist ein Kernbestandteil der Engpassanalyse und wird direkt im KPI 'Durchschnittliche Bearbeitungszeit pro Phase' verwendet. Durch die Aggregation der Bearbeitungszeit für jede Aktivität erkennen Sie deutlich, welche Phasen des Entwicklungslebenszyklus die meiste Zeit in Anspruch nehmen, was die Konzentration der Verbesserungsbemühungen erleichtert.

Misst direkt die Dauer jeder Activity und ist somit eine primäre Metrik zur Identifizierung, welche Prozessschritte die zeitaufwendigsten Engpässe sind.

Dies ist eine berechnete Metrik, abgeleitet durch Subtraktion des 'EventTime' vom 'EventEndTime' für jede Zeile im Event Log.

Die 'Lösung' erklärt, warum ein Element in einen geschlossenen Zustand überführt wurde. Während ein Status 'Geschlossen' sein kann, könnte die Lösung 'Erledigt', 'Wird nicht gemacht', 'Duplikat' oder 'Nicht reproduzierbar' sein. Dies liefert entscheidenden Kontext zum Ergebnis der Arbeit.

Die Analyse der Lösung hilft, zwischen erfolgreich abgeschlossener Arbeit und Elementen, die abgebrochen oder abgelehnt wurden, zu unterscheiden. Dies ist wichtig für die Qualitätsanalyse und das Verständnis des tatsächlichen Durchsatzes wertvoller Arbeit im Vergleich zum Aufwand für letztendlich verworfene Elemente.

Unterscheidet zwischen erfolgreich abgeschlossenen Elementen und solchen, die aus anderen Gründen geschlossen wurden, was für eine genaue Produktivitäts- und Qualitätsanalyse entscheidend ist.

Dies ist das Feld 'resolution' innerhalb des 'fields'-Objekts der Jira Issue API-Antwort. Es wird typischerweise nur gefüllt, wenn ein Issue geschlossen wird.

Dieses Attribut markiert die Abschlusszeit einer Aktivität. Es ist der Timestamp der nächsten Aktivität in der Sequenz für einen gegebenen Case.

Während der 'EventTime' (StartTime) den Beginn einer Aktivität markiert, markiert der EventEndTime ihr Ende. Die Differenz zwischen diesen beiden Timestamps ist die Bearbeitungszeit für diese Aktivität. Dies ist entscheidend für die Berechnung des KPIs 'Durchschnittliche Bearbeitungszeit pro Phase' und für die Erstellung von Dashboards, die Aktivitätsdauern analysieren.

Definiert den Endpunkt einer Activity und ermöglicht so die Berechnung der Dauer jedes Schritts im Process, was für die Engpassanalyse unerlässlich ist.

Dies ist ein abgeleitetes Attribut. Für ein gegebenes Event ist seine Endzeit die Startzeit des nachfolgenden Events für denselben Case.

Die 'Fix Version' in Jira gibt die Version an, die die abgeschlossene Arbeit für ein Element enthält. Sie markiert das konkrete Ergebnis der Entwicklungsbemühungen.

Dieses Attribut liefert den tatsächlichen Release-Kontext, der mit der 'PlannedReleaseVersion' verglichen werden kann, um die Lieferleistung zu analysieren. Es wird auch verwendet, um alle in einem bestimmten Release gelieferten Elemente für eine konsolidierte Ansicht der erzielten Ergebnisse zu gruppieren.

Bestätigt, in welchem Release ein Arbeitsergebnis enthalten war, und liefert die Grundlage für die Release-Analyse und die Verfolgung gelieferter Funktionen.

Dies entspricht dem Feld 'fixVersions' in der Jira Issue API-Antwort.

Dieses Attribut, oft das Feld 'Affects Version/s' in Jira, gibt das beabsichtigte Release für ein Feature oder einen Fix an. Es dient als Frist oder Ziel für den Abschluss der Arbeit.

Dies ist ein kritisches Attribut für den KPI 'On-Time Release Delivery Rate'. Durch den Vergleich des tatsächlichen Bereitstellungsdatums mit dem geplanten Releasedatum, das dieser Version zugeordnet ist, können Sie die Termineinhaltung und die Vorhersagbarkeit Ihres Release-Prozesses messen.

Definiert das Zieldatum der Lieferung oder des Release, was die Berechnung der pünktlichen Lieferraten und die Analyse der Termineinhaltung ermöglicht.

Dies entspricht den Feldern 'versions' oder 'fixVersions' in der Jira Issue API. Das spezifische Feld für die Planung kann variieren.

Cycle Time misst die Gesamtzeit, die von der Erstellung eines Entwicklungselements bis zu seiner endgültigen Lösung, z.B. der Bereitstellung in der Produktion, vergeht. Sie wird auf Case-Ebene als Differenz zwischen dem timestamp des allerersten event und des allerletzten event berechnet.

Dies ist ein primärer KPI zur Messung der Gesamtprozessgeschwindigkeit und -effizienz. Der KPI 'Durchschnittliche End-to-End Cycle Time' und das Dashboard 'Gesamte SDLC Cycle Time Analyse' basieren direkt auf dieser Berechnung. Die Reduzierung der Cycle Time ist oft ein Hauptziel von Prozessverbesserungsinitiativen.

Misst die End-to-End-Geschwindigkeit des Entwicklungsprozesses und liefert einen wichtigen Leistungsindikator für die Gesamteffizienz und Liefergeschwindigkeit.

Dies ist ein berechnetes Attribut auf Case-Ebene. Es ist der Timestamp des letzten Events minus dem Timestamp des ersten Events für ein gegebenes 'DevelopmentItem'.

Dieses boolesche Attribut ist wahr, wenn eine Aktivität einen Rückschritt im Prozess darstellt, wie die Rückkehr zu 'Entwicklung gestartet', nachdem QA-Tests fehlgeschlagen sind. Es wird durch die Analyse der Abfolge von Aktivitäten für einen Case bestimmt.

Die Identifizierung von Nacharbeit ist grundlegend für die Verbesserung der Prozesseffizienz und -qualität. Dieses Attribut unterstützt direkt den KPI 'Nacharbeitsaktivitätsrate' und das Dashboard 'Häufigkeit und Pfade von Nacharbeitszyklen'. Es ermöglicht die Quantifizierung des vergeudeten Aufwands und die genaue Bestimmung der Ursachen von Qualitätsproblemen, die zu Nacharbeit führen.

Markiert explizit Activities, die Teil ineffizienter Nacharbeitschleifen sind, was eine präzise Messung und Analyse von Prozessverschwendung und Qualitätsproblemen ermöglicht.

Dies ist ein berechnetes Attribut. Es erfordert die Definition des erwarteten Prozessflusses und dann das Markieren jeder Aktivität, die durch den Übergang zu einer früheren Phase abweicht.

Komponenten werden in Jira verwendet, um Issues innerhalb eines Projekts in kleinere, besser verwaltbare Teile zu gruppieren. Dies könnte einen Funktionsbereich wie 'Benutzerauthentifizierung', eine technische Schicht wie 'Backend API' oder ein Modul wie 'Reporting' darstellen.

Die Analyse nach Komponenten ermöglicht eine granularere Sicht auf den Entwicklungsprozess. Sie kann helfen zu identifizieren, ob bestimmte Teile der Anwendung mehr Bugs erzeugen, längere Development Cycles haben oder mehr Nacharbeit erfahren, was auf Bereiche technischer Schulden oder Komplexität hindeutet.

Ermöglicht die Segmentierung des Process nach funktionalen oder technischen Bereichen des Produkts, wodurch ermittelt werden kann, welche Komponenten Quellen für Verzögerungen oder Qualitätsprobleme sind.

Dies ist das Standardfeld 'components' innerhalb des 'fields'-Objekts der Jira Issue API-Antwort.

Der Reporter ist die Person, die das Issue in Jira erstellt hat. Dies könnte ein Entwickler, ein QA-Tester, ein Produktmanager oder sogar ein Kunde über eine Service Desk-Integration sein.

Die Analyse des Reporters kann Einblicke in den Ursprung der Arbeit geben. Sie können zum Beispiel analysieren, ob Bugs, die vom QA-Team gemeldet wurden, einen anderen Lebenszyklus haben als solche, die von Kunden gemeldet wurden. Sie kann auch dazu beitragen, Kommunikationsmuster und den Informationsfluss zu Beginn des Prozesses zu verstehen.

Identifiziert den Ursprung des Arbeitselements, der verwendet werden kann, um Muster basierend darauf zu analysieren, wer Aufgaben erstellt oder Bugs meldet.

Dies ist das Feld 'reporter' innerhalb des 'fields'-Objekts der Jira Issue API-Antwort.

Für Teams, die Scrum nutzen, ist der Sprint ein zeitlich begrenzter Zeitraum, in dem eine bestimmte Menge an Arbeit abgeschlossen wird. Dieses Attribute erfasst den Namen oder die Kennung des Sprints, zu dem ein Element gehört.

Die Analyse nach Sprint ist grundlegend für Agile-fokussiertes Process Mining. Sie hilft bei der Bewertung der Performance einzelner Sprints, dem Verständnis von Übertragungsarbeiten und der Verfolgung des Fortschritts im Hinblick auf Sprint-Ziele. Es bietet einen zeitbasierten Kontext, der spezifischer ist als allgemeine Datumsbereiche.

Bietet einen kritischen Kontext für agile Teams und ermöglicht die Analyse der Prozesseffizienz und des Durchsatzes auf Sprint-Basis.

Diese Information wird typischerweise in einem 'Sprint'-Benutzerdefinierten Feld gespeichert, das von Jira Software (Agile) verwaltet wird. Die Daten sind über die Issue API zugänglich.

Diese Metrik berechnet die Wartezeit oder Queue-Zeit zwischen dem Abschluss einer Aktivität und dem Beginn der nächsten. Sie repräsentiert die Zeit, in der Arbeit untätig auf die Bearbeitung wartet.

Dies ist eine kritische Metrik für den KPI 'Durchschnittliche Übergabewartezeit' und das Dashboard 'Effizienz der Phasenübergaben'. Hohe Übergabezeiten weisen oft auf Koordinationsprobleme, Ressourcenengpässe oder ineffiziente Kommunikation zwischen Teams hin, wie zwischen Entwicklung und QA. Die Minimierung dieser Leerlaufzeit ist ein wichtiger Hebel zur Reduzierung der Gesamtzykluszeit.

Hebt Leerlauf- oder Wartezeiten im Process hervor, deckt Ineffizienzen bei Übergaben zwischen Teams oder Einzelpersonen auf und offenbart Koordinationsprobleme.

Dies ist eine berechnete Metrik. Es ist die Startzeit einer Aktivität minus der Endzeit der vorhergehenden Aktivität für denselben Case.