Ihr Daten-Template für den Softwareentwicklungszyklus

Der Aktivitätsname bezeichnet einen bestimmten Schritt oder Statuswechsel im Entwicklungsprozess. Diese Aktivitäten bilden die Knoten in der Prozessübersicht und stehen für wichtige Meilensteine wie „Element für die Entwicklung freigegeben“, „Code zur Prüfung eingereicht“ oder „QA-Tests abgeschlossen“.

Dieses Attribut ist entscheidend, um den Prozessablauf zu visualisieren und die Reihenfolge der Ereignisse zu verstehen. Durch die Analyse der verschiedenen Aktivitäten können Teams häufige Abläufe erkennen, Prozessabweichungen entdecken und die Dauer einzelner Phasen messen. Das Attribut bildet die Grundlage für Engpassanalysen, die Erkennung von Nacharbeit und Konformitätsprüfungen anhand eines Sollprozessmodells.

Das Attribut legt die Prozessschritte fest und ermöglicht so die Visualisierung und Analyse des Entwicklungs-Workflows.

Das Attribut wird häufig aus Statusänderungsprotokollen, Ereignisströmen oder Änderungshistorien zu Entwicklungsarbeitselementen abgeleitet.

Die ID des Entwicklungselements ist der Primärschlüssel, der jede Case-Instanz über den gesamten Softwareentwicklungslebenszyklus hinweg eindeutig identifiziert. Jede ID steht für eine eigenständige Arbeit, etwa eine User Story, Aufgabe oder Fehlerbehebung, von der Erstellung bis zur abschließenden Lösung oder Bereitstellung.

In der Process-Mining-Analyse ist dieses Attribut entscheidend, um den durchgängigen Ablauf jedes Arbeitselements zu rekonstruieren. Es ermöglicht dem Tool, alle zugehörigen Aktivitäten wie „Entwicklung begonnen“, „Codeprüfung abgeschlossen“ und „In Produktion bereitgestellt“ zu einem zusammenhängenden Prozessablauf zu verknüpfen. Die Analyse des Lebenszyklus einzelner Entwicklungselemente hilft, Abweichungen, Verzögerungen und Nacharbeitsschleifen bei bestimmten Arbeitselementen zu erkennen.

Dies ist die grundlegende Case-ID, die erforderlich ist, um den gesamten Lebenszyklus jedes Entwicklungsarbeitselements von Anfang bis Ende nachzuverfolgen.

Dieses Feld findet sich üblicherweise in den Haupttabellen für Arbeitselemente oder Issues eines Softwareentwicklungsmanagementsystems.

Die Startzeit des Ereignisses gibt das genaue Datum und die Uhrzeit an, zu der eine Aktivität begonnen hat. Sie legt die chronologische Reihenfolge aller Ereignisse innerhalb eines einzelnen Case fest und ist damit entscheidend für die korrekte Rekonstruktion des Prozessablaufs.

Timestamps bilden die Grundlage für alle zeitbasierten Process-Mining-Analysen. Sie dienen zur Berechnung wichtiger Kennzahlen wie Zykluszeiten, Wartezeiten und Verarbeitungszeiten zwischen Aktivitäten. Ihre Analyse hilft, Engpässe zu lokalisieren, die Prozesseffizienz zu messen und die Dauer verschiedener Phasen im Entwicklungslebenszyklus zu verstehen. So können Verzögerungen im Prüfprozess sichtbar werden, wenn Sie etwa die Zeit zwischen „Code zur Prüfung eingereicht“ und „Codeprüfung abgeschlossen“ untersuchen.

Dieser Timestamp ist entscheidend, um Ereignisse korrekt zu ordnen und alle zeitbasierten Kennzahlen wie Zykluszeiten und Engpässe zu berechnen.

Der Timestamp ist in Event Logs, Audit-Trails oder Änderungshistorien verfügbar, in denen Änderungen an Entwicklungsarbeitselementen protokolliert werden.

Das Attribut „Letzte Datenaktualisierung“ erfasst Datum und Uhrzeit der letzten Extraktion oder Aktualisierung der Daten aus dem Quellsystem. So lässt sich erkennen, wie aktuell und relevant die Daten sind.

Diese Information ist wichtig, damit Analysen und Dashboards auf aktuellen Daten basieren. Beteiligte sehen auf einen Blick, wie aktuell die Prozessansicht ist, und können die daraus gewonnenen Erkenntnisse besser einordnen. Das Attribut liefert wichtige Metadaten für die Verwaltung von Datenpipelines und die Planung von Datenaktualisierungen.

Das Attribut zeigt, wie aktuell die Daten sind, und unterstützt zeitnahe, relevante Entscheidungen.

Dieser Wert wird in der Regel von der ETL-Pipeline (Extraktion, Transformation und Laden) erzeugt und gespeichert.

Das Attribut „Quellsystem“ bezeichnet die Anwendung oder Plattform, in der die Daten zum Entwicklungslebenszyklus ursprünglich erfasst wurden. Das ist besonders nützlich, wenn mehrere Entwicklungstools zum Einsatz kommen, zum Beispiel Jira für die Issue-Verwaltung und GitLab für die Verwaltung des Quellcodes.

In der Analyse hilft die Angabe des Quellsystems bei der Datenvalidierung und liefert Kontext zu den Prozessdaten. Sie ermöglicht den Vergleich von Prozessen, die in unterschiedlichen Systemen verwaltet werden, und unterstützt die korrekte Interpretation der Daten, da Feldnamen und Prozesskonventionen variieren können. Außerdem lässt sich die Analyse auf den Datensatz eines bestimmten Tools beschränken.

Das Attribut gibt Aufschluss über die Herkunft der Daten. Das ist wichtig für die Datenvalidierung und Analysen, die mehrere integrierte Systeme umfassen.

In der Regel wird während der Datenextraktion ein statischer Wert hinzugefügt, um die Herkunft der Datensätze anzugeben.

Die Endzeit des Ereignisses markiert den Abschluss einer Aktivität. Viele Prozessschritte werden als Ereignisse ohne Dauer erfasst, bei denen Start- und Endzeit identisch sind. Andere Aktivitäten haben eine messbare Dauer. So können für eine Aktivität wie „Code Review“ unterschiedliche Start- und Endzeiten vorliegen.

Dieses Attribut ist entscheidend, um die aktive Verarbeitungszeit einzelner Aufgaben zu berechnen und von Leerlauf- oder Wartezeiten abzugrenzen. Vergleichen Analysten die Zeit zwischen Start- und Endzeit eines Ereignisses, können sie den Aufwand für wertschöpfende Aktivitäten messen. So lässt sich die Ressourcennutzung genauer analysieren und feststellen, welche Aufgaben die meiste aktive Arbeitszeit beanspruchen.

Ermöglicht die Berechnung der aktiven Verarbeitungszeit einzelner Aktivitäten. So lässt sie sich von Wartezeiten abgrenzen und der Arbeitsaufwand besser einschätzen.

Der Wert ist in Event Logs zu finden oder lässt sich aus dem Timestamp der nächsten Aktivität desselben Arbeitselements ableiten.

Das Attribut „Priorität“ gibt die geschäftliche oder technische Dringlichkeit eines Arbeitselements an. Übliche Werte sind „Hoch“, „Mittel“ und „Niedrig“. Sie helfen Teams bei der Entscheidung, woran sie als Nächstes arbeiten.

Im Process Mining ist die Priorität eine wichtige Analysedimension. Teams können damit prüfen, ob Elemente mit hoher Priorität tatsächlich schneller bearbeitet werden als solche mit niedriger Priorität. Der Vergleich der Zykluszeiten nach Prioritätsstufe zeigt, ob der Prozess geschäftliche Prioritäten berücksichtigt. Werden Elemente mit hoher Priorität häufig verzögert, kann das auf Probleme bei der Planung, der Ressourcenzuweisung oder der Workflow-Gestaltung hindeuten.

Hilft zu prüfen, ob Arbeit mit hoher Priorität den Prozess schneller durchläuft, und zeigt Engpässe auf, die kritische Elemente besonders stark betreffen.

Ein Standardfeld im Arbeitselement oder Vorgang der meisten Entwicklungsmanagementsysteme.

Der Projektname ordnet Arbeitselemente einem bestimmten Produkt, einer Initiative oder einer Codebasis zu und liefert so wichtigen Kontext. Entwicklungspraktiken und Zykluszeiten können sich je nach Projekt deutlich unterscheiden, etwa zwischen einem Altsystem und einer neu entwickelten Anwendung.

Dieses Attribut ermöglicht eine übergeordnete Zusammenfassung und den Vergleich von Entwicklungsprozessen in verschiedenen Bereichen der Organisation. Durch die Filterung nach Projekt können Verantwortliche die Prozessgesundheit und Effizienz der einzelnen Entwicklungsvorhaben beurteilen. Das Attribut ist außerdem wichtig, um die Prozessleistung im jeweiligen Projektkontext und technischen Umfeld zu verstehen.

Ermöglicht die Prozessanalyse nach Produkt oder Initiative aufzuschlüsseln und Leistungsunterschiede im jeweiligen Projektkontext sichtbar zu machen.

Ein Standardfeld im Arbeitselement oder Vorgang oder der Name des Repositorys in Systemen wie Git.

Der Status des Entwicklungselements gibt an, in welchem Zustand sich ein Arbeitselement zu einem bestimmten Zeitpunkt befindet. Während der Aktivitätsname das Ereignis einer Statusänderung erfasst, beschreibt dieses Attribut den Status selbst. Damit lässt sich beispielsweise der Zustand der Arbeit zum Zeitpunkt eines Ereignisses analysieren.

Dieses Attribut wird häufig zur Erstellung des Aktivitätsnamens verwendet, liefert aber zusätzlichen Kontext. Anhand des Statusfelds lässt sich etwa untersuchen, wie lange Elemente in einem bestimmten Zustand wie „Blockiert“ oder „Wartet auf Review“ verbleiben. Die Zeit in nicht produktiven Zuständen zu verstehen, ist entscheidend, um systembedingte Verzögerungen zu erkennen und den Arbeitsfluss zu verbessern.

Ermöglicht die Analyse der Verweildauer in verschiedenen Status und hilft, Verzögerungen sowie Zeiten in nicht wertschöpfenden Status wie „Blockiert“ zu erkennen.

Als primäres Feld im Arbeitselement oder Vorgang verfügbar und im Verlauf des Elements erfasst.

Dieses Attribut bezeichnet das Team, die Squad oder die Gruppe, die für die Bereitstellung des Entwicklungselements zuständig ist. In größeren Organisationen verteilt sich die Arbeit häufig auf spezialisierte Teams wie „Frontend“, „Backend“, „Mobile“ oder „Plattform“.

Die Analyse nach Teamname ermöglicht Leistungsvergleiche und den Austausch bewährter Vorgehensweisen zwischen Teams. Sie hilft bei Fragen wie: „Welches Team hat die kürzeste Zykluszeit?“ oder „Muss ein Team häufiger Nacharbeit leisten als andere?“ So lassen sich Unterschiede bei Workflows, Kompetenzen oder verfügbaren Ressourcen erkennen, die sich auf die Lieferleistung auswirken. Daraus ergeben sich Ansatzpunkte für gezielte Prozessverbesserungen.

Ermöglicht Leistungsvergleiche zwischen Teams und hilft, bewährte Vorgehensweisen sowie Verbesserungspotenziale zu erkennen.

Häufig mit dem zugewiesenen Benutzer verknüpft oder als direktes Feld im Projekt- oder Arbeitselementdatensatz vorhanden.

Dieses Attribut ordnet die Art der ausgeführten Arbeit ein. Für verschiedene Arten von Arbeitselementen gelten oft unterschiedliche Prozessabläufe und Leistungserwartungen. Ein Bug kann beispielsweise eine schnelle Hotfix-Behebung erfordern, während eine Funktion den üblichen Entwicklungs- und Testzyklus durchläuft.

Mit diesem Attribut können Analysten Prozessabläufe und Leistung für verschiedene Arbeitstypen vergleichen. So lässt sich etwa klären: „Beheben wir Bugs schneller, als wir Funktionen entwickeln?“ oder „Führen technische Schulden zu mehr Nacharbeit?“ Das Attribut ist eine wichtige Dimension, um Daten gezielt aufzuschlüsseln und konkrete Erkenntnisse zu gewinnen.

Ermöglicht den Vergleich von Prozessen und Leistung in verschiedenen Arbeitskategorien und zeigt Ineffizienzen auf, die bestimmte Arten der Entwicklung betreffen.

Ein Standardfeld im Arbeitselement oder Vorgang der meisten Entwicklungsmanagementsysteme.

Dieses Attribut gibt an, welche Person oder Gruppe für den aktuellen Schritt oder das gesamte Arbeitselement zuständig ist. Im Laufe des Lebenszyklus kann die Zuständigkeit mehrfach wechseln, etwa bei Übergaben zwischen Entwicklern, QA-Testern und Reviewern.

Die Analyse des Attributs „Zuständig“ ist wichtig, um die Arbeitsauslastung des Teams, die Effizienz von Übergaben und die Zusammenarbeit zu verstehen. Mit diesem Attribut können Sie die Prozesslandkarte nach der Arbeit einer bestimmten Person oder eines Teams filtern und so ressourcenbezogene Engpässe erkennen. Eine Netzwerkanalyse der Übergaben zwischen den Zuständigen kann Kommunikationslücken oder unnötig komplexe Zusammenarbeitsstrukturen aufzeigen.

Ermöglicht die Analyse der Ressourcenauslastung, der Häufigkeit von Übergaben und der Zusammenarbeit. So können Sie die Effizienz des Teams verbessern.

Zu finden im Arbeitselement oder Vorgang, häufig im Verlauf oder Audit-Log des Elements.

Das Attribut „Ersteller“ bezeichnet die Person, die das Arbeitselement angelegt hat. Das kann ein Produktmanager sein, der eine User Story erstellt, ein QA-Tester, der einen Bug meldet, oder ein Kundenservice-Mitarbeiter, der ein Kundenproblem erfasst.

Die Analyse der Ersteller von Arbeitselementen gibt Aufschluss darüber, woher die Arbeit kommt. Eine hohe Zahl von Bugs, die von Endbenutzern gemeldet werden, kann beispielsweise auf Qualitätsprobleme in aktuellen Versionen hindeuten. Außerdem lässt sich die Klarheit und Qualität der ursprünglichen Anforderungen untersuchen, indem der Ersteller mit späterer Nacharbeit oder Verzögerungen verglichen wird.

Hilft, die Urheber von Arbeit zu ermitteln und so die Quellen von Nachfrage, Bugs oder Funktionsanfragen zu verstehen.

Ein Standardfeld wie „Melder“ oder „Autor“ im Erstellungsdatensatz eines Arbeitselements.

Das Attribut „Geplante Version“ ordnet ein Entwicklungselement einem bestimmten Liefertermin oder einer Version zu. Bei der Release-Planung werden so häufig Funktionen und Fehlerbehebungen für eine gemeinsame Bereitstellung gebündelt.

Die Analyse nach geplanter Version hilft, die Vorhersagbarkeit und Zuverlässigkeit des Release-Prozesses zu beurteilen. Durch den Vergleich der geplanten Version mit dem tatsächlichen Bereitstellungsdatum lässt sich die termingerechte Lieferung verfolgen. Außerdem unterstützt das Attribut die Umfangsplanung und zeigt, wie die Arbeit für ein bestimmtes Release voranschreitet. So werden mögliche Risiken und Verzögerungen sichtbar, die den Liefertermin gefährden könnten.

Verknüpft die Entwicklungsarbeit mit Lieferterminen und ermöglicht die Analyse termingerechter Lieferungen sowie der Vorhersagbarkeit von Releases.

Ein Standardfeld wie „Fix Version“, „Zielversion“ oder „Iterationspfad“ in agilen Planungs- und Entwicklungstools.

Der Nacharbeitsindikator ist ein abgeleitetes boolesches oder kategoriales Attribut, das Ereignisse in einem Nacharbeitszyklus kennzeichnet. Ein solcher Zyklus lässt sich typischerweise daran erkennen, dass der Prozessablauf zurückspringt, zum Beispiel von „QA-Test“ zu „Entwicklung in Bearbeitung“. Auch bestimmte Aktivitäten wie „Nacharbeit in QA festgestellt“ können darauf hinweisen.

Dieses Attribut ist für die Qualitäts- und Effizienzanalyse besonders wertvoll. Es ermöglicht, Nacharbeitsquoten direkt zu berechnen und die Prozessbereiche mit dem größten Nacharbeitsaufkommen zu erkennen. Filtern Teams nach Nacharbeitsaktivitäten, können sie die Ursachen dafür untersuchen, warum Qualitätsprobleme nicht früher erkannt werden. Weniger Nacharbeit ist ein wichtiger Ansatzpunkt, um sowohl die Entwicklung zu beschleunigen als auch die Produktqualität zu verbessern.

Quantifiziert die Nacharbeit direkt. Teams können damit ihre Häufigkeit messen, Ursachen untersuchen und Qualitätsverbesserungen im Zeitverlauf verfolgen.

Wird üblicherweise bei der Datentransformation abgeleitet, indem Rücksprünge im Prozessablauf oder bestimmte Aktivitätsnamen für Fehler erkannt werden.

Der Schweregrad unterscheidet sich von der Priorität: Er misst die technischen Auswirkungen eines Problems, während die Priorität angibt, wie dringend es behoben werden muss. Ein Tippfehler auf einer selten besuchten Seite kann beispielsweise einen niedrigen Schweregrad und eine niedrige Priorität haben. Ein kritischer Fehler, der Daten beschädigt, hätte dagegen einen hohen Schweregrad und eine hohe Priorität.

Dieses Attribut ist für die Qualitätsanalyse besonders wichtig, wenn Sie Prozesse zur Bug-Behebung untersuchen. Teams können damit beurteilen, ob sie die schwerwiegendsten Probleme zuerst angehen. Durch den Vergleich der Zykluszeiten nach Schweregrad können Organisationen sicherstellen, dass kritische Systemprobleme schnell behoben werden und die Auswirkungen auf Kunden möglichst gering bleiben.

Ermöglicht zu analysieren, wie effektiv das Team Probleme entsprechend ihrer technischen Auswirkungen behebt, damit kritische Probleme zeitnah gelöst werden.

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