Ihr Daten-Template für den Softwareentwicklungslebenszyklus
Ihr Daten-Template für den Softwareentwicklungslebenszyklus
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Anleitung zur Datenextraktion
Attribute des Softwareentwicklungslebenszyklus
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
Activity
|
Die Bezeichnung des konkreten Prozessschritts oder Ereignisses, etwa „Issue erstellt“ oder „Merge Request zusammengeführt“. | ||
|
Beschreibung
Das Attribut Aktivität erfasst die einzelnen Ereignisse, die bei einem Entwicklungselement auftreten. In GitLab sind diese nicht in einem einzelnen Feld gespeichert, sondern werden aus verschiedenen Aktionen und Timestamp-Feldern in Issues, Merge Requests und CI/CD-Pipelines abgeleitet. Dazu zählen beispielsweise das Erstellen eines Issues, das Übertragen eines Commits, das Fehlschlagen einer Pipeline oder die Freigabe eines Merge Requests. Dieses Attribut ist grundlegend für den Aufbau der Prozesslandkarte, die Visualisierung des Workflows und die Analyse der Reihenfolge und Häufigkeit von Ereignissen. Es dient dazu, Abweichungen, Engpässe zwischen Prozessschritten und häufige Prozessabläufe zu erkennen.
Warum das wichtig ist
Das Attribut legt die Schritte in der Prozesslandkarte fest und ermöglicht so die Visualisierung und Analyse des Entwicklungs-Workflows von Anfang bis Ende.
Woher beziehen
Abgeleitet aus Ereignistypen und Statusänderungen im GitLab-Ereignisstrom oder durch Auswertung von Timestamp-Feldern wie
Beispiele
Issue erstelltEntwicklung begonnenMerge Request zusammengeführtPipeline fehlgeschlagenIn Produktion bereitgestellt
|
|||
|
Entwicklungselement
DevelopmentItem
|
Der eindeutige Bezeichner einer Arbeitseinheit, etwa einer Funktion, Fehlerbehebung oder Aufgabe. Er dient als primäre Case-ID. | ||
|
Beschreibung
Das Entwicklungselement steht für eine einzelne, nachverfolgbare Arbeitseinheit, die den Softwareentwicklungslebenszyklus durchläuft. Es verknüpft alle zugehörigen Aktivitäten von der Erstellung bis zur endgültigen Bereitstellung zu einem zusammenhängenden Case. In GitLab wird es üblicherweise durch die interne ID (IID) des Issues dargestellt, die innerhalb eines Projekts eindeutig ist. Die Analyse nach Entwicklungselement ermöglicht die Messung der Zykluszeit von Anfang bis Ende, die Ermittlung von Engpässen und die Konformitätsprüfung. Sie bildet die Grundlage dafür, zu verstehen, wie effizient Arbeit vom Konzept bis zur Produktion bereitgestellt wird.
Warum das wichtig ist
Dies ist die erforderliche Case-ID, die alle Prozessereignisse miteinander verknüpft. So lässt sich der gesamte Lebenszyklus eines Arbeitselements nachvollziehen.
Woher beziehen
Dabei handelt es sich üblicherweise um die interne ID (IID) eines GitLab-Issues. Sie ist in der Antwort der Issues API im Feld
Beispiele
1024512PRJ-2345
|
|||
|
Startzeit
StartTime
|
Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis begonnen hat. | ||
|
Beschreibung
StartTime bezeichnet das genaue Datum und die Uhrzeit, zu der eine bestimmte Aktivität stattgefunden hat. Bei Ereignissen in GitLab wird dieser Wert in verschiedenen Timestamp-Feldern erfasst. Für die Aktivität „Issue erstellt“ ist StartTime beispielsweise der Timestamp Dieser Timestamp ist die zentrale Zeitangabe im Process Mining. Er dient dazu, Ereignisse chronologisch zu ordnen, Zeitspannen zwischen Aktivitäten zu berechnen, Zykluszeiten zu messen und die Prozessleistung im Zeitverlauf zu analysieren.
Warum das wichtig ist
Dieses Attribut gibt die chronologische Reihenfolge der Ereignisse an. Das ist entscheidend, um alle zeitbasierten Kennzahlen zu berechnen und den Prozessablauf zu verstehen.
Woher beziehen
Extrahiert aus verschiedenen Timestamp-Feldern in GitLab, etwa
Beispiele
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-15T09:00:00Z
|
|||
|
Endzeit
EndTime
|
Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis abgeschlossen wurde. | ||
|
Beschreibung
EndTime bezeichnet das genaue Datum und die Uhrzeit, zu der eine Aktivität abgeschlossen wurde. Bei vielen einzelnen Ereignissen in GitLab, etwa „Issue erstellt“, entspricht EndTime der StartTime. Bei Aktivitäten mit einer Dauer, etwa einem Code-Review, gibt EndTime den Abschlusszeitpunkt an, zum Beispiel den Zeitpunkt der letzten Freigabe. Dieses Attribut ist wichtig, um die Dauer einzelner Aktivitäten (Verarbeitungszeit) präzise zu berechnen. Es unterstützt eine detaillierte Engpassanalyse, indem es die aktive Bearbeitungszeit einer Aufgabe von der Wartezeit zwischen Aufgaben unterscheidet.
Warum das wichtig ist
Ermöglicht die präzise Berechnung der Aktivitätsdauer (Verarbeitungszeit), die entscheidend ist, um ineffiziente Prozessschritte zu erkennen.
Woher beziehen
Bei einzelnen Ereignissen entspricht dieser Wert der StartTime. Bei Aktivitäten mit einer Dauer muss er anhand eines passenden Abschlussereignisses in den Daten abgeleitet werden.
Beispiele
2023-10-26T10:00:00Z2023-11-01T18:00:15Z2023-11-15T11:30:00Z
|
|||
|
Projektname
ProjectName
|
Der Name des GitLab-Projekts, zu dem das Entwicklungselement gehört. | ||
|
Beschreibung
Dieses Attribut identifiziert das Code-Repository oder Projekt, in dem die Arbeit ausgeführt wird. In GitLab gehört jedes Issue und jeder Merge Request zu einem Projekt. Die Analyse nach Projektname ermöglicht Leistungsvergleiche zwischen verschiedenen Produkten, Komponenten oder Services. Sie kann zeigen, ob die SDLC-Prozesse bestimmter Projekte besser funktionieren als andere. Außerdem lassen sich Dashboards auf einen bestimmten Bereich eingrenzen.
Warum das wichtig ist
Ermöglicht die Segmentierung der Prozessanalyse nach Produkt, Anwendung oder Komponente und unterstützt so gezielte Verbesserungsmaßnahmen.
Woher beziehen
Abgerufen aus den Feldern
Beispiele
platform/api-gatewayfrontend/customer-portalmobile/ios-app
|
|||
|
Schweregrad
Severity
|
Der Schweregrad des Entwicklungselements, üblicherweise bei Fehlern oder Vorfällen. | ||
|
Beschreibung
Der Schweregrad gibt die Auswirkungen eines Fehlers oder Problems an und reicht von kritisch bis geringfügig. GitLab bietet kein eigenes Feld für den Schweregrad. Daher wird dieser fast immer über Labels abgebildet, etwa Dieses Attribut ist wichtig für das Dashboard „Trends bei Eskalationen des Schweregrads“ und die zugehörige Kennzahl. Die Analyse von Änderungen des Schweregrads im Lebenszyklus kann Probleme aufdecken, deren Auswirkungen zunächst unterschätzt wurden, oder Prozesse, die Probleme verschärfen.
Warum das wichtig ist
Hilft dabei, Arbeit zu priorisieren und zu analysieren, ob Elemente mit hohem Schweregrad schneller bearbeitet werden. Die Erfassung von Änderungen unterstützt die Kennzahl „Häufigkeit von Eskalationen des Schweregrads“.
Woher beziehen
Abgeleitet aus den Labels eines GitLab-Issues. Eine Zuordnung ist erforderlich, um Labels wie
Beispiele
1 - Kritisch2 - Hoch3 - Mittel4 - Niedrig
|
|||
|
Typ des Entwicklungselements
DevelopmentItemType
|
Die Klassifizierung des Entwicklungselements, etwa „Funktion“, „Fehler“, „Aufgabe“ oder „Wartung“. | ||
|
Beschreibung
Dieses Attribut kategorisiert die Art der ausgeführten Arbeit. In GitLab wird es üblicherweise über Labels an einem Issue umgesetzt. Teams verwenden Labels, um neue Funktionen, Fehlerbehebungen, technische Schulden und andere Arbeitsarten zu unterscheiden. Die Analyse nach Typ des Entwicklungselements ermöglicht den Vergleich von Prozessabläufen und Zykluszeiten für verschiedene Arbeitsarten. So lässt sich beispielsweise untersuchen, ob Fehler schneller behoben werden als Funktionen entwickelt werden oder ob Aufgaben zu technischen Schulden einem anderen Prüfprozess folgen.
Warum das wichtig ist
Die Segmentierung des Prozesses nach Arbeitsart hilft zu erkennen, ob bestimmte Arbeiten häufiger zu Verzögerungen, Nacharbeit oder Abweichungen führen.
Woher beziehen
Üblicherweise abgeleitet aus den Labels eines GitLab-Issues. Eine Zuordnungslogik ist erforderlich, um bestimmte Labels in standardisierte Typen zu überführen.
Beispiele
FunktionFehlerAufgabeTechnische Schulden
|
|||
|
Zuständige Person
Assignee
|
Der Benutzer, dem das Issue oder der Merge Request zum Zeitpunkt des Ereignisses zugewiesen ist. | ||
|
Beschreibung
Die zuständige Person ist der Entwickler oder Benutzer, der zu einem bestimmten Zeitpunkt im Prozess für das Arbeitselement verantwortlich ist. In GitLab wird dies im Feld Die Analyse nach zuständiger Person ist entscheidend für das Dashboard „Arbeitslast und Ressourcenverteilung der Entwickler“. Sie hilft, die Ressourcenauslastung zu verstehen, überlastete Einzelpersonen oder Teams zu erkennen und Übergaben zwischen verschiedenen Personen zu analysieren.
Warum das wichtig ist
Erfasst, wer die Arbeit ausgeführt hat. Das ermöglicht die Analyse der Arbeitslast und der Effizienz der Ressourcenverteilung sowie die Ermittlung von Verzögerungen durch Übergaben.
Woher beziehen
Abgerufen aus den Feldern
Beispiele
jdoeasmithr.williams
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der angibt, wann die Daten zu diesem Ereignis zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut erfasst Datum und Uhrzeit, zu denen die Ereignisdaten zuletzt extrahiert oder im Process-Mining-Datensatz aktualisiert wurden. Es gibt nicht an, wann das Ereignis stattgefunden hat, sondern wann der Ereignisdatensatz zuletzt synchronisiert wurde. Diese Information ist wichtig, um die Aktualität der Daten einzuschätzen und zu prüfen, ob die Prozessanalyse zeitnah erfolgt. Sie hilft Benutzern darauf zu vertrauen, dass Dashboards und Kennzahlen auf aktuellen Daten beruhen, und macht mögliche Verzögerungen zwischen Quellsystem und Analyse sichtbar.
Warum das wichtig ist
Macht die Aktualität der Daten transparent, damit Benutzer wissen, wie aktuell die Prozessanalyse ist.
Woher beziehen
Dieser Timestamp wird vom Datenextraktionstool oder ETL-Prozess bei der Datenaktualisierung erzeugt und gespeichert.
Beispiele
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
|
|||
|
Meilenstein-Titel
MilestoneTitle
|
Der Titel des Meilensteins oder Sprints, dem das Entwicklungselement zugeordnet ist. | ||
|
Beschreibung
Ein Meilenstein in GitLab dient dazu, Arbeit an einem bestimmten Ziel oder innerhalb eines festgelegten Zeitraums zu verfolgen, etwa an einem Sprint oder einer Release-Version. Dieses Attribut erfasst den Namen oder Titel des Meilensteins. Damit lässt sich die Prozessleistung im Kontext bestimmter Sprints oder Planungszeiträume analysieren. Sie können beispielsweise prüfen, ob sich die Zykluszeiten von Sprint zu Sprint verbessern, oder die Prozessansicht auf Arbeiten für ein bevorstehendes Release beschränken.
Warum das wichtig ist
Ordnet Entwicklungsarbeiten Planungszyklen wie Sprints oder Releases zu und ermöglicht so den Abgleich der Leistung mit geplanten Zeiträumen.
Woher beziehen
Wird aus dem Feld „milestone.title“ der Antworten der GitLab-Issues- oder Merge-Requests-API abgerufen.
Beispiele
Release für Q4 2023Sprint 23.11Phase 1: MVP
|
|||
|
Merge-Request-Status
MergeRequestStatus
|
Der Status des zugehörigen Merge Requests, zum Beispiel „Opened“, „Merged“ oder „Closed“. | ||
|
Beschreibung
Dieses Attribut erfasst den Status eines Merge Requests (MR) zum Zeitpunkt eines Ereignisses. GitLab-MRs haben die Status „opened“, „closed“, „merged“ oder „locked“. Dieser Status ist unabhängig vom Gesamtstatus des Entwicklungselements. Der MR-Status ist entscheidend für die Analyse der Code-Integration im SDLC. Er unterstützt direkt Dashboards wie „Zykluszeit und Durchsatz bei Code Reviews“ und hilft, Verzögerungen zwischen dem Erstellen, Prüfen, Freigeben und Zusammenführen eines MR zu erkennen.
Warum das wichtig ist
Macht den Code-Review- und Merge-Prozess sichtbar, der im SDLC häufig einen kritischen Engpass darstellt.
Woher beziehen
Wird aus dem Feld „state“ der Antwort der GitLab-Merge-Requests-API abgerufen.
Beispiele
offenmergedgeschlossenlocked
|
|||
|
Nacharbeit
IsRework
|
Ein boolesches Kennzeichen, das angibt, ob eine Aktivität Teil einer Nacharbeitsschleife ist. | ||
|
Beschreibung
Dieses berechnete Attribut kennzeichnet Aktivitäten, die einen Rückschritt im Prozess darstellen, etwa wenn nach Beginn der Tests erneut Entwicklungsarbeit anfällt. Die Kennzeichnung basiert in der Regel auf der Erkennung bestimmter Aktivitätsfolgen. Ein Beispiel: Für denselben Case tritt „Entwicklung gestartet“ nach „Pipeline fehlgeschlagen“ oder „QA-Tests gestartet“ auf. Dieses Attribut bildet die Grundlage für das Dashboard „Analyse von Nacharbeit und erneuten Pipeline-Ausführungen“ sowie die KPI „Nacharbeitsquote nach dem Testen“. Damit lässt sich Nacharbeit einfach filtern und quantifizieren. Teams können so Häufigkeit, Ursachen und Auswirkungen auf Projektzeitpläne besser verstehen.
Warum das wichtig ist
Kennzeichnet und quantifiziert Nacharbeit direkt. So lassen sich Ursachen und Auswirkungen ineffizienter Abläufe und Qualitätsprobleme leichter analysieren.
Woher beziehen
Das Process-Mining-Tool berechnet die Kennzahl, indem es die Aktivitätsfolge jedes Cases analysiert und Muster erkennt, die auf Nacharbeit hindeuten.
Beispiele
truefalse
|
|||
|
Pipeline-Status
PipelineStatus
|
Der Status der CI/CD-Pipeline-Ausführung, zum Beispiel „Success“, „Failed“ oder „Running“. | ||
|
Beschreibung
Dieses Attribut gibt das Ergebnis einer CI/CD-Pipeline-Ausführung an, die einem Commit oder Merge Request zugeordnet ist. Zu den gängigen Statuswerten in GitLab gehören „running“, „pending“, „success“, „failed“, „canceled“ und „skipped“. Diese Daten sind für das Dashboard „Analyse von Nacharbeit und erneuten Pipeline-Ausführungen“ unverzichtbar. Häufige Pipeline-Fehler können erhebliche Nacharbeit und Verzögerungen verursachen. Um die Entwicklungseffizienz und Codequalität zu verbessern, müssen Häufigkeit, Auftreten und Auswirkungen dieser Fehler analysiert werden.
Warum das wichtig ist
Erfasst erfolgreiche und fehlgeschlagene automatisierte Builds und Tests. So werden Nacharbeitsschleifen sowie Probleme mit der Codequalität oder Testautomatisierung sichtbar.
Woher beziehen
Wird aus dem Feld „status“ der Antwort der GitLab-CI/CD-Pipelines-API abgerufen.
Beispiele
successfailedrunningcanceled
|
|||
|
Quellsystem
SourceSystem
|
Gibt an, aus welchem System die Daten stammen. | ||
|
Beschreibung
Dieses Attribut gibt die Herkunft der Prozessdaten an. In diesem Datenmodell lautet der Wert immer „GitLab“. Das Attribut ist wichtig, wenn Prozessdaten aus mehreren Systemen zusammengeführt werden, etwa aus Jira für die Planung und GitLab für die Ausführung. Es ermöglicht Filterungen und Segmentierungen und hilft, die Datenherkunft nachzuvollziehen.
Warum das wichtig ist
Sorgt für Klarheit über die Datenherkunft. Das ist wichtig für die Data Governance und die Integration von Daten aus mehreren Unternehmenssystemen.
Woher beziehen
Dies ist ein statischer Wert, „GitLab“, der bei der Datentransformation hinzugefügt wird.
Beispiele
GitLab
|
|||
|
Release-Version
ReleaseVersion
|
Das geplante oder tatsächliche Softwareversions-Tag der Bereitstellung. | ||
|
Beschreibung
Dieses Attribut gibt an, zu welchem konkreten Software-Release ein Entwicklungselement gehört. In GitLab kann die Zuordnung über einen Meilenstein, ein geschütztes Tag oder einen Eintrag in der Releases-Funktion erfolgen. Das Attribut ist für das Dashboard „Einhaltung des Release-Zeitplans verfolgen“ unverzichtbar. Durch den Vergleich des tatsächlichen Bereitstellungsdatums mit dem für die Release-Version geplanten Datum können Unternehmen messen, wie zuverlässig sie Zeitpläne einhalten, und die Ursachen für Release-Verzögerungen ermitteln.
Warum das wichtig ist
Ordnet Entwicklungselemente einem bestimmten Software-Release zu. Das ist entscheidend, um den Release-Fortschritt und die Einhaltung des Zeitplans zu verfolgen.
Woher beziehen
Die Datenquelle kann GitLab Releases, der Name eines Git-Tags oder der Titel eines für die Release-Planung verwendeten Meilensteins sein.
Beispiele
v1.2.0v3.0.0-beta2023.4.1
|
|||
|
Status des Entwicklungselements
DevelopmentItemStatus
|
Der Status des Entwicklungselements zum Zeitpunkt des Ereignisses, etwa „Offen“, „In Bearbeitung“ oder „Geschlossen“. | ||
|
Beschreibung
Dieses Attribut gibt den Status des primären Arbeitselements wieder, üblicherweise eines Issues in GitLab. GitLab-Issues haben einen Die Erfassung von Statusänderungen ist wichtig, um den Lebenszyklus eines Cases zu verstehen. Sie zeigt, wie lange Arbeitselemente in den einzelnen Status verbleiben, und ermöglicht es, in Dashboards wie „SDLC-Zykluszeit von Anfang bis Ende“ laufende oder abgeschlossene Arbeiten zu filtern.
Warum das wichtig ist
Zeigt den Status des Cases zu einem bestimmten Zeitpunkt. So lässt sich analysieren, wie lange Arbeit in den einzelnen Phasen verbleibt, und laufende Arbeit von abgeschlossener Arbeit unterscheiden.
Woher beziehen
Der primäre Status stammt aus dem Feld
Beispiele
offengeschlossenIn BearbeitungIn Prüfung
|
|||
|
Teamname
TeamName
|
Das Entwicklungsteam, das dem Projekt oder der zuständigen Person zugeordnet ist. | ||
|
Beschreibung
Teamname bezeichnet die Gruppe oder das Squad, das für das Entwicklungselement verantwortlich ist. Diese Information ist in GitLab üblicherweise kein Standardfeld. Sie wird häufig aus Namenskonventionen für Projekte, Gruppenstrukturen oder einer externen Referenztabelle abgeleitet, die zuständige Personen ihren Teams zuordnet. Mit diesem Attribut lässt sich die Prozessleistung auf Teamebene analysieren. Es hilft, Effizienz, Arbeitslast und Prozesseinhaltung verschiedener Teams zu vergleichen und unterstützt teambezogene Dashboards wie „Engpassanalyse nach Prozessphase“.
Warum das wichtig ist
Ermöglicht den Leistungsvergleich und die Prozessanalyse verschiedener Teams. So lassen sich teamspezifische Engpässe und bewährte Vorgehensweisen erkennen.
Woher beziehen
Wird häufig abgeleitet, indem der Projektname oder die zuständige Person einer außerhalb von GitLab definierten Teamstruktur zugeordnet wird. Alternativ kann die Zuordnung aus der GitLab-Gruppenhierarchie abgeleitet werden.
Beispiele
Frontend-AlphaBackend-ServicesPlattform-Infrastruktur
|
|||
|
Wartezeit bei Übergaben
HandoffWaitTime
|
Berechnete Leerlaufzeit zwischen zwei aufeinanderfolgenden Aktivitäten, die von unterschiedlichen zuständigen Personen ausgeführt werden. | ||
|
Beschreibung
Diese Kennzahl misst die Zeitspanne zwischen dem Abschluss einer Aktivität und dem Beginn der nächsten, sofern sich die zuständige Person ändert. Sie erfasst zum Beispiel die Zeit zwischen dem Abschluss der Entwicklungsarbeit und dem Beginn des Code Reviews. Sie ist die zentrale Kennzahl für die KPI „Durchschnittliche Wartezeit bei Übergaben“. Damit lassen sich verborgene Ineffizienzen bei der Ressourcenzuteilung und der Kommunikation zwischen Teams oder einzelnen Personen aufdecken. Sichtbar werden Verzögerungen, in denen niemand aktiv an der Arbeit ist.
Warum das wichtig ist
Quantifiziert Leerlaufzeiten bei Übergaben zwischen Personen oder Teams und macht so verborgene Verzögerungen und Kommunikationsengpässe sichtbar.
Woher beziehen
Das Process-Mining-Tool berechnet die Kennzahl. Dazu analysiert es aufeinanderfolgende Ereignisse innerhalb eines Cases, prüft, ob sich die „Assignee“-Angabe unterscheidet, und berechnet anschließend die Zeitdifferenz.
Beispiele
1 Tag 2 Stunden15 Minuten8 Stunden
|
|||
|
Ziel-Branch
TargetBranch
|
Der Name des Ziel-Branchs eines Merge Requests. | ||
|
Beschreibung
Der Ziel-Branch ist der Branch, in den Änderungen übernommen werden sollen, zum Beispiel „main“, „develop“ oder ein Release-Branch wie „release/1.5“. Diese Angabe gehört zu den grundlegenden Informationen eines Merge Requests. Eine Analyse nach Ziel-Branch kann unterschiedliche Prozessabläufe für Code aufzeigen, der in verschiedene Ziel-Branches übernommen wird. Für Merges in „main“ gelten möglicherweise strengere Freigabeprozesse und längere Zykluszeiten als für Merges in einen Feature-Branch. Außerdem lassen sich so Produktionsbereitstellungen von anderen Formen der Code-Integration unterscheiden.
Warum das wichtig ist
Ermöglicht den Vergleich verschiedener Entwicklungs- und Release-Workflows, da sich Prozesse je nach Ziel-Branch deutlich unterscheiden können.
Woher beziehen
Wird aus dem Feld „target_branch“ der Antwort der GitLab-Merge-Requests-API abgerufen.
Beispiele
maindeveloprelease/v2.1.0hotfix/user-auth-bug
|
|||
|
Zykluszeit
CycleTime
|
Die gesamte Zeitspanne vom ersten bis zum letzten Ereignis eines Entwicklungselements. | ||
|
Beschreibung
Die Zykluszeit ist eine berechnete Kennzahl für die Gesamtdauer eines Cases. Sie wird üblicherweise als Zeitdifferenz zwischen dem ersten Ereignis (z. B. „Issue erstellt“) und dem letzten Ereignis (z. B. „In Produktion bereitgestellt“) eines einzelnen Entwicklungselements berechnet. Diese zentrale KPI misst die Effizienz des Gesamtprozesses. Sie ist die wichtigste Kennzahl in Dashboards wie „SDLC-Zykluszeit von Anfang bis Ende“ und dient dazu, Verbesserungen zu verfolgen sowie lang laufende Cases zu erkennen, die auf systemische Probleme hindeuten können.
Warum das wichtig ist
Diese zentrale Process-Mining-KPI misst die Effizienz des Entwicklungslebenszyklus von Anfang bis Ende.
Woher beziehen
Das Process-Mining-Tool berechnet die Kennzahl, indem es für jede eindeutige CaseId den kleinsten StartTime-Wert vom größten StartTime-Wert abzieht.
Beispiele
10 Tage 4 Stunden23 Stunden 15 Minuten35 Tage
|
|||
Aktivitäten im Softwareentwicklungslebenszyklus
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
In Produktion bereitgestellt
|
Diese Aktivität markiert die erfolgreiche Bereitstellung des Codes in der Produktivumgebung, sodass er für Endbenutzer verfügbar ist. Sie wird erfasst, wenn ein bestimmter Job zur Bereitstellung in der Produktion in einer GitLab-CI/CD-Pipeline erfolgreich abgeschlossen wird. | ||
|
Warum das wichtig ist
Dies ist das primäre End-Event des Prozesses und zeigt an, dass der Nutzen bereitgestellt wurde. Es ist entscheidend, um die gesamte SDLC-Zykluszeit von Anfang bis Ende und die Release-Häufigkeit zu messen.
Woher beziehen
Das Ereignis wird anhand des Timestamps
Erfassung
Verwenden Sie den Timestamp
Ereignistyp
explicit
|
|||
|
Issue erstellt
|
Diese Aktivität markiert den Beginn des Entwicklungslebenszyklus: Ein neues Arbeitselement, etwa eine Funktion, ein Fehler oder eine Aufgabe, wird erstellt. Das Ereignis wird explizit erfasst, wenn ein Benutzer in GitLab ein neues Issue anlegt. Dabei wird der Erstellungszeitpunkt gespeichert. | ||
|
Warum das wichtig ist
Dies ist das primäre Start-Event des End-to-End-Prozesses. Die Zeit zwischen der Erstellung des Issues und der Bereitstellung zeigt die Zykluszeit des gesamten SDLC.
Woher beziehen
Dieses explizite Ereignis wird anhand des Timestamps
Erfassung
Verwenden Sie den Timestamp
Ereignistyp
explicit
|
|||
|
Merge Request erstellt
|
Dieses Ereignis zeigt an, dass die erste Entwicklungsarbeit abgeschlossen und der Code zur Prüfung und Integration bereit ist. Es ist ein explizites Kernelement des GitLab-Workflows und wird erfasst, wenn ein Entwickler einen neuen Merge Request (MR) öffnet. | ||
|
Warum das wichtig ist
Dieser wichtige Meilenstein markiert die Übergabe von der Entwicklung an Prüfung und Tests. Er ist der Ausgangspunkt für die Analyse des gesamten Code-Review- und CI/CD-Pipeline-Zyklus.
Woher beziehen
Dieses explizite Ereignis wird anhand des Timestamps
Erfassung
Verwenden Sie den Timestamp
Ereignistyp
explicit
|
|||
|
Merge Request zusammengeführt
|
Diese Aktivität kennzeichnet den erfolgreichen Abschluss der Codeprüfung und Integration. Sie tritt als explizites Ereignis auf, wenn ein Benutzer den Branch des Merge Requests in den Ziel-Branch integriert. | ||
|
Warum das wichtig ist
Dieser wichtige Meilenstein zeigt an, dass Entwicklung und Prüfung abgeschlossen sind. Er markiert das Ende der Entwicklungszykluszeit und den Beginn der Messung der Bereitstellungszeit.
Woher beziehen
Dieses explizite Ereignis wird anhand des Timestamps
Erfassung
Verwenden Sie den Timestamp
Ereignistyp
explicit
|
|||
|
Bereitstellung gestartet
|
Dieses Ereignis bezeichnet den Beginn der Codebereitstellung in einer bestimmten Umgebung, etwa Staging oder Produktion. In GitLab entspricht dies dem Start eines `deploy`-Jobs innerhalb einer CI/CD-Pipeline. | ||
|
Warum das wichtig ist
Die Erfassung des Bereitstellungsstarts hilft, die Dauer der Bereitstellungsphase zu bestimmen. Sie ist entscheidend, um die Bereitstellungszeit zu messen und zu optimieren.
Woher beziehen
Das Ereignis wird anhand des Timestamps
Erfassung
Verwenden Sie den Timestamp
Ereignistyp
explicit
|
|||
|
Code-Review begonnen
|
Dieses Ereignis markiert den Beginn des Peer-Review-Prozesses für einen Merge Request. Es wird anhand der ersten prüfungsbezogenen Aktion abgeleitet, etwa des ersten Kommentars oder Diskussionsbeitrags einer anderen Person als des Autors. | ||
|
Warum das wichtig ist
Die Zeit zwischen der Erstellung des MR und dem Beginn der Prüfung zeigt Wartezeiten auf. Diese zu verkürzen ist entscheidend, um den gesamten Code-Review-Zyklus zu verkürzen.
Woher beziehen
Das Ereignis wird anhand des Timestamps des ersten Kommentars oder Diskussionsbeitrags zum Merge Request abgeleitet, der nicht vom Autor des MR stammt. Diese Daten sind über Systemnotizen oder die Notes API verfügbar.
Erfassung
Ermitteln Sie den Timestamp des ersten Kommentars eines anderen Benutzers als des Autors zu einem MR.
Ereignistyp
inferred
|
|||
|
Entwicklung begonnen
|
Diese Aktivität kennzeichnet den Beginn der aktiven Programmierarbeit am Issue. Sie wird üblicherweise anhand des ersten Code-Commits auf einem mit dem Issue verknüpften Branch abgeleitet, da GitLab keine explizite Schaltfläche zum Starten der Entwicklung bietet. | ||
|
Warum das wichtig ist
Damit lässt sich der genaue Beginn der wertschöpfenden Entwicklungsarbeit bestimmen. So können Sie die reine Programmierphase präzise messen und von Planungs- oder Wartezeiten abgrenzen.
Woher beziehen
Das Ereignis wird abgeleitet, indem der Timestamp des ersten Commits auf einem mit dem Issue verknüpften Feature-Branch ermittelt wird. Dazu müssen Issues mit Branches verknüpft werden, häufig über Namenskonventionen oder Metadaten.
Erfassung
Ermitteln Sie den Timestamp des ersten Commits auf einem Branch, der mit der Issue-ID verknüpft ist.
Ereignistyp
inferred
|
|||
|
Freigabe hinzugefügt
|
Dieses Ereignis bezeichnet die formelle Freigabe der Codeänderungen in einem Merge Request durch einen Reviewer. GitLab erfasst es explizit, wenn ein Benutzer auf die Schaltfläche „Approve“ klickt. | ||
|
Warum das wichtig ist
Freigaben sind wichtige Qualitätskontrollen. Ihre Erfassung hilft, die Zeit bis zu den erforderlichen Freigaben zu analysieren und die Einhaltung der Review-Richtlinien sicherzustellen.
Woher beziehen
Das Ereignis wird anhand der Freigabeereignisse des Merge Requests erfasst. Diese sind über die Approvals API verfügbar oder im Verlauf des MR einsehbar.
Erfassung
Verwenden Sie den Timestamp aus dem Freigabeereignis des Merge Requests.
Ereignistyp
explicit
|
|||
|
Issue geschlossen
|
Diese Aktivität bezeichnet den abschließenden administrativen Abschluss des Arbeitselements, üblicherweise nachdem die Änderungen bereitgestellt und überprüft wurden. GitLab erfasst dieses Ereignis explizit, wenn ein Benutzer das Issue schließt. | ||
|
Warum das wichtig ist
Das Schließen eines Issues markiert häufig das endgültige Ende aller damit verbundenen Arbeiten. Ein Vergleich mit dem Bereitstellungszeitpunkt kann Verzögerungen bei der Validierung nach der Bereitstellung oder bei administrativen Abläufen aufdecken.
Woher beziehen
Dieses explizite Ereignis wird anhand des Timestamps
Erfassung
Verwenden Sie den Timestamp
Ereignistyp
explicit
|
|||
|
Issue zugewiesen
|
Diese Aktivität bezeichnet die Zuweisung eines Issues an einen bestimmten Entwickler oder ein Team. Damit ist festgelegt, wer für die Arbeit verantwortlich ist. GitLab protokolliert dieses Ereignis explizit, sobald das Feld für die zuständige Person eines Issues ausgefüllt oder geändert wird. | ||
|
Warum das wichtig ist
Die Erfassung von Zuweisungen ist wichtig, um die Ressourcenverteilung, die Arbeitslast der Teams und Übergabezeiten zu analysieren. Sie hilft, Verzögerungen zwischen der Erstellung und der Übernahme einer Aufgabe zu erkennen.
Woher beziehen
Das Ereignis wird aus den GitLab-Systemnotizen zum Issue ermittelt. Darin wird protokolliert, wann eine zuständige Person hinzugefügt oder geändert wird. Der Timestamp des Ereignisses steht in der Notiz.
Erfassung
Extrahieren Sie Ereignisse zur Änderung der zuständigen Person aus den Systemnotizen des Issues.
Ereignistyp
explicit
|
|||
|
Pipeline fehlgeschlagen
|
Diese Aktivität tritt auf, wenn eine CI/CD-Pipeline in einer beliebigen Phase fehlschlägt, etwa aufgrund eines Build-Fehlers oder eines fehlgeschlagenen Tests. GitLab erfasst den Endstatus jeder Pipeline explizit, sodass sich Fehler leicht erkennen lassen. | ||
|
Warum das wichtig ist
Fehlgeschlagene Pipelines sind eine häufige Ursache für Nacharbeit. Die Analyse ihrer Häufigkeit, Dauer und Ursachen hilft, Qualitätsprobleme, instabile Tests und Engpässe in der Rückmeldung an Entwickler zu erkennen.
Woher beziehen
Das Ereignis wird anhand des Status
Erfassung
Filtern Sie Pipeline-Datensätze mit dem Status
Ereignistyp
explicit
|
|||
|
Pipeline gestartet
|
Dieses Ereignis bezeichnet den Start einer automatisierten CI/CD-Pipeline, die üblicherweise Builds, Tests und Sicherheitsprüfungen ausführt. GitLab erstellt bei jeder ausgelösten Pipeline explizit einen Pipeline-Datensatz mit Startzeitpunkt, zum Beispiel nach einem Commit oder beim Erstellen eines MR. | ||
|
Warum das wichtig ist
Die Ausführung von Pipelines zu verfolgen ist wichtig, um Zustand und Effizienz automatisierter Tests und Integrationsprozesse zu überwachen. So lässt sich erkennen, wie viel Zeit die automatisierte Validierung beansprucht.
Woher beziehen
Das Ereignis wird anhand des Timestamps
Erfassung
Verwenden Sie den Timestamp aus dem Pipeline-Ausführungsdatensatz, der dem Branch des MR zugeordnet ist.
Ereignistyp
explicit
|
|||
Anleitungen zur Datenextraktion
Möchten Sie loslegen?
Bereiten Sie Ihre Daten mit diesem Template vor und beginnen Sie, Ihren Softwareentwicklungslebenszyklus zu optimieren. Verbessern Sie Ihren Prozess noch heute!
Verbessern Sie Ihren Softwareentwicklungslebenszyklus: Beginnen Sie jetzt mit der Optimierung
Beseitigen Sie SDLC-Engpässe, verkürzen Sie die Zykluszeit um 30 % und verbessern Sie die Qualität.
Keine Kreditkarte erforderlich. Beginnen Sie sofort mit der Optimierung.