> Continue verbetering > Software Development Lifecycle > Jira Software > datatemplate

Uw Software Development Lifecycle Data Template

Jira Software

Software Development Lifecycle attributes (22) Software Development Lifecycle Activiteiten (14) Extractie Guides (4)

Uw Software Development Lifecycle Data Template

Deze template biedt een duidelijke roadmap voor het verzamelen van de essentiële data die nodig is om uw Software Development Lifecycle te analyseren. Het schetst de kern data fields om te verzamelen, de kritieke processtappen om te volgen, en praktische begeleiding bij het extraheren van deze informatie uit Jira Software. Gebruik deze gids om uw event log voor te bereiden op effectieve process mining.

Aanbevolen attributen om vast te leggen
Belangrijkste activiteiten om te volgen
Extractiehandleiding voor Jira Software

Nieuw met event logs? Leer hoe je een process mining event log creëert.

Template downloaden

Software Development Lifecycle attributes

Dit zijn de aanbevolen data fields om op te nemen in uw event log voor uitgebreide Software Development Lifecycle analyse.

5 Verplicht 6 Aanbevolen 11 Optioneel

	Naam	Omschrijving
	Activiteit Activity	De naam van een specifieke event of statuswijziging die plaatsvond in de development lifecycle van een item.
Omschrijving Dit attribuut vertegenwoordigt een afzonderlijke stap of mijlpaal in het softwareontwikkelingsproces. Deze activiteiten zijn afgeleid van wijzigingen in het statusveld van de Jira issue of andere belangrijke events zoals code commits of reviews. Bij process mining vormt de sequentie van deze activiteiten de process map. Het analyseren van activiteiten helpt de processtroom te identificeren, de duur van specifieke fasen te meten en afwijkingen van de standaard workflow te detecteren, zoals herstelrondes of overgeslagen kwaliteitspoorten. Het belang Activiteiten definiëren de stappen van het proces, en hun volgorde is essentieel voor het visualiseren van de procesflow, het identificeren van `bottlenecks` en het analyseren van procesvariaties. Vindplaats Typisch afgeleid van de 'status' veldovergangen in de Jira issue historie of changelog. Het kan ook worden verrijkt met data van verbonden ontwikkeltools. Voorbeelden Ontwikkeling GestartCode Review UitgevoerdQA Testen VoltooidDeployed To Production
	Ontwikkelingsobject DevelopmentItem	De unieke identifier voor een enkele werkeenheid, zoals een story, bug of task, binnen Jira Software.
Omschrijving Het Development Item dient als de primaire case identifier, en vertegenwoordigt een afzonderlijke werkeenheid zoals een feature, bug fix of task. Het koppelt alle activiteiten van initiële conceptie en planning via ontwikkeling, testen en deployment voor dat specifieke item. In Jira komt dit typisch overeen met de issue key, bijvoorbeeld 'PROJ-123'. Het analyseren van dit attribuut maakt het mogelijk om de volledige end-to-end lifecycle van elk werkitem te traceren. Het vormt de basis voor het construeren van process maps, het berekenen van cycle times en het identificeren van variaties in hoe verschillende items door het ontwikkelproces stromen. Het belang Dit is de essentiële sleutel voor het samenkoppelen van alle gerelateerde ontwikkelingsactiviteiten, waardoor het mogelijk wordt om de reis van een enkel werkitem van begin tot eind te traceren. Vindplaats Dit is het standaard 'key' veld voor een issue in het Jira Software Issue API object. Voorbeelden PROJ-101CORE-5432API-789
	Tijdstip Gebeurtenis EventTime	De exacte datum en tijd waarop een specifieke ontwikkelingsactiviteit of event plaatsvond.
Omschrijving `Event Time` is de `timestamp` die vastlegt wanneer een `activity` plaatsvond. Dit is de temporele basis voor alle `process mining` analyse, en biedt de chronologische volgorde van `events` voor elke `case`. Dit `attribute` is cruciaal voor het berekenen van alle tijdgebaseerde `metrics`, inclusief `cycle times`, `processing times`, en wachttijden tussen `activities`. Het maakt de analyse van procesprestaties over tijd mogelijk, en helpt te identificeren wanneer en waar vertragingen optreden in de ontwikkelingslifecycle. Het belang Deze timestamp is fundamenteel voor het correct sequencen van events en het berekenen van alle duur-gebaseerde metrics, die essentieel zijn voor het begrijpen van procesefficiëntie en het identificeren van vertragingen. Vindplaats Dit komt overeen met de 'created' timestamp voor elke entry in de changelog of historie van een issue. Voorbeelden 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
	Bronsysteem SourceSystem	Het systeem waaruit de development lifecycle data is geëxtraheerd.
Omschrijving Dit attribuut identificeert de herkomst van de data. Voor dit proces zal het consistent 'Jira Software' zijn, maar het is nuttig voor het onderscheiden van data als meerdere bronsystemen worden gecombineerd in een grotere analyse. In een breder IT-landschap zorgt het specificeren van het bronsysteem voor duidelijke data lineage en helpt het bij het beheren van datakwaliteit en integratie-inspanningen over verschillende platforms heen. Het belang Biedt duidelijke data provenance, wat cruciaal is bij het integreren van data uit meerdere systemen of voor datagovernance- en auditdoeleinden. Vindplaats Dit is een statische waarde die moet worden toegevoegd tijdens het data-extractie- en transformatieproces. Voorbeelden Jira Software
	Laatste data-update LastDataUpdate	De timestamp die aangeeft wanneer de data voor dit proces voor het laatst is ververst vanuit het bronsysteem.
Omschrijving Dit attribuut registreert de datum en tijd van de meest recente data-extractie uit Jira Software. Het biedt context over de versheid van de geanalyseerde data. Weten wat de laatste update tijd is, is belangrijk voor het begrijpen van de actualiteit van de procesinzichten. Het helpt analisten en zakelijke gebruikers te bevestigen dat ze naar actuele data kijken en informeert hen over het cutoff point voor de events die in de analyse zijn opgenomen. Het belang Geeft de actualiteit van de `data` aan, wat essentieel is om te garanderen dat analyses en `dashboards` de meest actuele staat van het proces weerspiegelen. Vindplaats Deze timestamp wordt gegenereerd en vastgelegd aan het einde van het data-extractie-, transformatie- en laadproces (ETL). Voorbeelden 2024-03-15T02:00:00Z2024-03-16T02:00:00Z
	Item Priority ItemPriority	Het prioriteitsniveau dat aan het ontwikkelitem is toegewezen, wat de urgentie aangeeft.
Omschrijving `Item Priority` definieert het relatieve belang of de urgentie van een werkitem. Jira biedt een standaard 'priority'-veld met configureerbare niveaus zoals Highest, High, Medium en Low. Het analyseren van prioriteit is cruciaal voor het controleren van `conformance` en het identificeren van `bottlenecks` voor kritieke items. Zo is het 'Priority Item Conformance Check' `dashboard` direct gebaseerd op dit `attribute` om te verifiëren of `high-priority` items zoals verwacht worden versneld of dat ze vastlopen in dezelfde `queues` als `low-priority` items. Het belang Helpt bij het analyseren of `high-priority` items sneller worden verwerkt dan `low-priority` ones en of ze een meer gestroomlijnd pad volgen, waardoor wordt verzekerd dat `SLA's` worden nageleefd. Vindplaats Dit is het 'priority' veld binnen het 'fields' object van de Jira Issue API response. Voorbeelden HoogsteHoogGemiddeldLaag
	Item Status ItemStatus	De huidige status van het ontwikkelitem binnen zijn workflow.
Omschrijving Dit attribuut weerspiegelt de specifieke fase van het ontwikkelitem op een gegeven moment, zoals 'In Progress', 'In Review' of 'Done'. De sequentie van statuswijzigingen in de loop van de tijd genereert de activiteiten voor process mining. Terwijl het 'Activity' attribuut de change event vertegenwoordigt, biedt de 'ItemStatus' de status van het item. Het is nuttig als dimensie voor filtering en analyse, zodat u kunt zien hoeveel items zich momenteel in een specifieke status bevinden of de kenmerken kunt analyseren van items die lange tijd in een bepaalde status blijven. Het belang Biedt een momentopname van waar een item zich in zijn lifecycle bevindt, wat essentieel is voor statusgebaseerde analyse en het begrijpen van de huidige staat van werk in uitvoering. Vindplaats Dit is het 'status' veld binnen het 'fields' object van de Jira Issue API response. Voorbeelden To DoIn uitvoeringIn beoordelingKlaar
	Posttype ItemType	De classificatie van het ontwikkelitem, zoals Bug, Story, Task of Epic.
Omschrijving `Item Type` categoriseert de aard van het uitgevoerde werk. Jira gebruikt een standaard 'issuetype'-veld om onderscheid te maken tussen verschillende soorten werkitems, die vaak unieke `workflows` hebben. Dit `attribute` is essentieel voor vergelijkende analyse. Het stelt u in staat het proces te filteren op specifieke soorten werk, bijvoorbeeld om de `lifecycle` van een 'Bug' te vergelijken met een 'Story'. Dit helpt te identificeren of bepaalde soorten werk gevoeliger zijn voor vertragingen, `rework` of afwijkingen van het standaardproces. Het belang Maakt het mogelijk om de procesanalyse te segmenteren om te vergelijken hoe verschillende soorten werk, zoals `bugs` versus nieuwe `features`, worden afgehandeld en waar hun processen verschillen. Vindplaats Dit is het 'issuetype' veld binnen het 'fields' object van de Jira Issue API response. Voorbeelden StoryBugTaskEpic
	Projectnaam ProjectName	De naam van het Jira project waartoe het ontwikkelitem behoort.
Omschrijving In Jira zijn alle werkitems georganiseerd in projecten. De Project Name biedt `high-level context`, vaak corresponderend met een specifiek product, team of initiatief. Dit `attribute` is een krachtige dimensie voor filtering en vergelijking. Het maakt het mogelijk om het SDLC-proces te analyseren en te `benchmarken` over verschillende projecten of producten heen. Dit kan onthullen welke projecten efficiënter zijn, welke meer `rework` hebben, en of verschillende teams verschillende procesvarianten volgen. Het belang Maakt het mogelijk om procesanalyse te segmenteren op project, product of team, wat prestatiemetingen en identificatie van `best practices` toelaat. Vindplaats Dit is het 'project' veld binnen het 'fields' object van de Jira Issue API response. Voorbeelden Mobiele App OntwikkelingCore PlatformData Science
	Teamnaam TeamName	Het ontwikkelteam dat verantwoordelijk is voor het werkitem.
Omschrijving Vertegenwoordigt het specifieke agile of feature team dat aan het ontwikkelitem is toegewezen. In Jira wordt dit vaak geïmplementeerd als een custom field, of het kan worden afgeleid uit andere informatie zoals het project of een specifieke component. Dit attribuut is essentieel voor prestatieanalyse op teamniveau. Het stelt dashboards in staat om te filteren en metrics zoals cycle time, rework rate en throughput voor individuele teams te tonen. Dit is cruciaal voor de dashboards 'Inter-Phase Handoff Efficiency' en 'Developer Workload & Item Progress'. Het belang Maakt prestatiemeting en vergelijking tussen verschillende ontwikkelteams mogelijk, wat helpt bij het identificeren van goed presterende teams en het delen van `best practices`. Vindplaats Dit is vaak een custom field in Jira. Raadpleeg uw Jira-beheerder om de specifieke veldnaam te identificeren, die 'Team', 'Squad' of iets dergelijks kan zijn. Voorbeelden Team PhoenixKernservicesUI/UX Avengers
	Toegewezen gebruiker Assignee	De gebruiker die momenteel is toegewezen om het ontwikkelitem af te handelen.
Omschrijving De Assignee is de persoon die verantwoordelijk is voor het werkitem in de huidige fase. In Jira is dit een standaardveld dat verandert naarmate het item tussen verschillende personen en teams beweegt. Het analyseren van de assignee is cruciaal voor het begrijpen van resource-allocatie, workloadverdeling en handoff-punten. Het helpt vragen te beantwoorden over welke ontwikkelaars of teams betrokken zijn bij specifieke fasen, wie een knelpunt is en hoe werk wordt verdeeld over de organisatie. Het belang Identificeert de verantwoordelijke gebruiker of `resource` voor een `activity`, wat `workload` analyse, `resource management`, en inzicht in `handoffs` tussen individuen mogelijk maakt. Vindplaats Dit is het 'assignee' veld binnen het 'fields' object van de Jira Issue API response. Voorbeelden Alice SmithBob JohnsonNiet toegewezen
	`Total Cycle Time` CycleTime	De totale end-to-end duur voor een ontwikkelitem.
Omschrijving `Cycle Time` meet de totale verstreken tijd vanaf de creatie van een ontwikkelingsobject tot de uiteindelijke resolutie ervan, zoals `deployment` naar productie. Het wordt berekend op `case level` als het verschil tussen de `timestamp` van de allereerste `event` en de allerlaatste `event`. Dit is een primaire KPI voor het meten van de algehele procesnelheid en efficiëntie. De 'Average End-to-End Cycle Time' KPI en het 'Overall SDLC Cycle Time Analysis' `dashboard` zijn direct gebaseerd op deze berekening. Het verminderen van de `cycle time` is vaak een belangrijk doel van procesverbeteringsinitiatieven. Het belang Meet de end-to-end snelheid van het ontwikkelproces en biedt een belangrijke prestatie-indicator voor algehele efficiëntie en opleveringssnelheid. Vindplaats Dit is een berekend attribuut op case-niveau. Het is de timestamp van de laatste event minus de timestamp van de eerste event voor een gegeven 'DevelopmentItem'. Voorbeelden 12096002592000604800
	Bewerkingstijd ProcessingTime	De totale actieve tijd besteed aan een specifieke activiteit.
Omschrijving Verwerkingstijd is de duur die een item doorbrengt in een bepaalde status of activiteit. Het wordt berekend als het verschil tussen de EventEndTime en EventTime voor een enkele event in de log. Deze metric is een kerncomponent van knelpuntanalyse en wordt direct gebruikt in de KPI 'Gemiddelde Verwerkingstijd per Fase'. Door de verwerkingstijd voor elke activiteit te aggregeren, kunt u duidelijk zien welke fasen van de ontwikkelingscyclus de meeste tijd verbruiken, wat helpt om verbeteringsinspanningen te richten. Het belang Meet direct de duur van elke `activity`, waardoor het een primaire metriek is voor het identificeren welke processtappen de meest tijdrovende `bottlenecks` zijn. Vindplaats Dit is een berekende metric, afgeleid door de 'EventTime' af te trekken van de 'EventEndTime' voor elke rij in de event log. Voorbeelden 86400360000604800
	Component Component	Een subsectie of functioneel gebied van een project waartoe het item behoort.
Omschrijving Componenten worden in Jira gebruikt om `issues` binnen een project te groeperen in kleinere, beter beheersbare delen. Dit kan een `feature area` vertegenwoordigen zoals 'User Authentication', een technische laag zoals 'Backend API', of een `module` zoals 'Reporting'. Analyseren per component maakt een gedetailleerdere kijk op het ontwikkelproces mogelijk. Het kan helpen identificeren of bepaalde delen van de applicatie meer `bugs` genereren, langere ontwikkel `cycles` hebben, of meer `rework` ervaren, wat wijst op gebieden van `technical debt` of complexiteit. Het belang Maakt het mogelijk om het proces te segmenteren op basis van functionele of technische gebieden van het product, wat helpt te bepalen welke componenten bronnen van vertraging of kwaliteitsproblemen zijn. Vindplaats Dit is het standaard 'components' veld binnen het 'fields' object van de Jira Issue API response. Voorbeelden User InterfaceDatabaseAPI GatewayAuthenticatie
	Eindtijd van het event EventEndTime	De timestamp waarop een activiteit of status is voltooid.
Omschrijving Dit attribuut markeert de voltooiingstijd van een activiteit. Het is de timestamp van de volgende activiteit in de sequentie voor een gegeven case. Terwijl de 'EventTime' (StartTime) het begin van een activiteit markeert, markeert de EventEndTime het einde ervan. Het verschil tussen deze twee timestamps is de verwerkingstijd voor die activiteit. Dit is cruciaal voor het berekenen van de KPI 'Gemiddelde Verwerkingstijd per Fase' en voor het bouwen van dashboards die activiteitsduren analyseren. Het belang Definieert het eindpunt van een `activity`, waardoor het mogelijk wordt de duur van elke stap in het proces te berekenen, wat essentieel is voor `bottleneck` analyse. Vindplaats Dit is een afgeleid attribuut. Voor een gegeven event is de eindtijd de starttijd van de daaropvolgende event voor dezelfde case. Voorbeelden 2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
	Fix Version FixVersion	De softwareversie waarin het ontwikkelitem daadwerkelijk is opgelost en gereleased.
Omschrijving De 'Fix Version' in Jira geeft de release aan die het voltooide werk voor een item bevat. Het markeert het concrete resultaat van de ontwikkelingsinspanning. Dit attribuut biedt de daadwerkelijke release-context, die kan worden vergeleken met de 'PlannedReleaseVersion' om de leveringsprestaties te analyseren. Het wordt ook gebruikt om alle items die in een specifieke release zijn geleverd te groeperen voor een geconsolideerd overzicht van wat is bereikt. Het belang Bevestigt in welke `release` een stuk werk is opgenomen, wat de grondwaarheid biedt voor `release` analyse en het volgen van geleverde `features`. Vindplaats Dit komt overeen met het 'fixVersions' veld in de Jira Issue API response. Voorbeelden v2.1.1 Hotfixv3.0.0 Major Releasev2.2.0
	Geplande Release PlannedReleaseVersion	De beoogde softwareversie of release waarin het item gepland is om te deployen.
Omschrijving Dit attribuut, vaak het 'Affects Version/s' veld in Jira, geeft de beoogde release aan voor een feature of fix. Het dient als een deadline of doel voor de voltooiing van het werk. Dit is een kritiek attribuut voor de KPI 'On-Time Release Delivery Rate'. Door de daadwerkelijke deployment datum te vergelijken met de geplande releasedatum die aan deze versie is gekoppeld, kunt u de naleving van de planning en de voorspelbaarheid van uw releaseproces meten. Het belang Definieert de beoogde leveringsdatum of `release`, waardoor de berekening van `on-time delivery rates` en analyse van de naleving van planningen mogelijk wordt. Vindplaats Dit komt overeen met de 'versions' of 'fixVersions' velden in de Jira Issue API. Het specifieke veld dat voor planning wordt gebruikt, kan variëren. Voorbeelden Versie 2.1Q1 2024 ReleaseLancering Project Phoenix
	Is herstelwerk IsRework	Een vlag die aangeeft of een activiteit deel uitmaakt van een herwerkloop.
Omschrijving Dit boolean attribuut is waar als een activiteit een stap terug in het proces vertegenwoordigt, zoals terugkeren naar 'Development Started' na het falen van QA testing. Het wordt bepaald door de sequentie van activiteiten voor een case te analyseren. Het identificeren van rework is fundamenteel voor het verbeteren van procesefficiëntie en kwaliteit. Dit attribuut ondersteunt direct de KPI 'Rework Activity Rate' en het dashboard 'Rework Loop Frequency and Paths'. Het maakt het mogelijk om de hoeveelheid verspilde inspanning te kwantificeren en de hoofdoorzaken van kwaliteitsproblemen die leiden tot rework aan te wijzen. Het belang Markeert expliciet `activities` die deel uitmaken van inefficiënte `rework loops`, wat nauwkeurige meting en analyse van procesverspilling en kwaliteitsproblemen mogelijk maakt. Vindplaats Dit is een berekend attribuut. Het vereist het definiëren van de verwachte processtroom en vervolgens het markeren van elke activiteit die afwijkt door naar een eerdere fase te gaan. Voorbeelden truefalse
	Item Resolutie ItemResolution	De uiteindelijke uitkomst of reden voor het sluiten van een ontwikkelitem.
Omschrijving Resolution legt uit waarom een item naar een gesloten status is verplaatst. Hoewel een status 'Closed' kan zijn, kan de resolution 'Done', 'Won't Do', 'Duplicate' of 'Cannot Reproduce' zijn. Dit biedt cruciale context over de uitkomst van het werk. Het analyseren van resolution helpt onderscheid te maken tussen succesvol voltooid werk en items die zijn geannuleerd of afgewezen. Dit is belangrijk voor kwaliteitsanalyse en het begrijpen van de werkelijke throughput van waardevol werk versus bestede inspanningen aan items die uiteindelijk zijn weggegooid. Het belang Onderscheidt succesvol afgeronde items van items die om andere redenen zijn afgesloten, wat essentieel is voor nauwkeurige productiviteits- en kwaliteitsanalyse. Vindplaats Dit is het 'resolution' veld binnen het 'fields' object van de Jira Issue API response. Het wordt typisch pas gevuld wanneer een issue wordt gesloten. Voorbeelden KlaarWon't DoDuplicaatNiet reproduceerbaar
	Melder Reporter	De gebruiker die het ontwikkelitem oorspronkelijk heeft aangemaakt of gerapporteerd.
Omschrijving De Reporter is de persoon die de issue in Jira heeft aangemaakt. Dit kan een ontwikkelaar, een QA tester, een productmanager of zelfs een klant zijn via een service desk integratie. Het analyseren van de reporter kan inzichten geven in de oorsprong van het werk. U kunt bijvoorbeeld analyseren of bugs die door het QA team zijn gerapporteerd een andere lifecycle hebben dan die door klanten zijn gerapporteerd. Het kan ook helpen bij het begrijpen van communicatiepatronen en de informatiestroom aan het begin van het proces. Het belang Identificeert de herkomst van het werkitem, wat kan worden gebruikt om patronen te analyseren op basis van wie taken creëert of `bugs` rapporteert. Vindplaats Dit is het 'reporter' veld binnen het 'fields' object van de Jira Issue API response. Voorbeelden Charles DarwinMarie CurieIsaac Newton
	Overdrachtwachttijd HandoffWaitTime	De inactiviteitstijd tussen twee opeenvolgende activiteiten.
Omschrijving Deze metric berekent de wachttijd of queue time tussen de voltooiing van één activiteit en de start van de volgende. Het vertegenwoordigt de tijd dat werk inactief blijft wachten tot iemand het oppakt. Dit is een kritieke metric voor de KPI 'Gemiddelde Handoff Wachttijd' en het dashboard 'Inter-Phase Handoff Efficiency'. Hoge handoff-tijden duiden vaak op coördinatieproblemen, resource-beperkingen of inefficiënte communicatie tussen teams, zoals tussen development en QA. Het minimaliseren van deze inactiviteitstijd is een belangrijke hefboom voor het verminderen van de algehele cycle time. Het belang Benadrukt `idle` of `queue time` in het proces, waardoor inefficiënties in `handoffs` tussen teams of individuen worden blootgelegd en coördinatieproblemen worden onthuld. Vindplaats Dit is een berekende metric. Het is de starttijd van een activiteit minus de eindtijd van de vorige activiteit voor dezelfde case. Voorbeelden 017280043200
	Sprintnaam SprintName	De naam van de agile sprint waaraan het ontwikkelitem is toegewezen.
Omschrijving Voor teams die Scrum gebruiken, is de Sprint een `time-boxed` periode waarin een set werk wordt voltooid. Dit `attribute` legt de naam of `identifier` vast van de `sprint` waartoe een item behoort. Analyseren per `sprint` is fundamenteel voor `agile-focused process mining`. Het helpt bij het evalueren van de prestaties van individuele `sprints`, het begrijpen van `carry-over work`, en het volgen van de voortgang ten opzichte van `sprint goals`. Het biedt een tijdgebaseerde context die specifieker is dan algemene datumbereiken. Het belang Biedt een cruciale context voor agile teams, waardoor analyse van procesefficiëntie en doorvoer op sprint-per-sprint basis mogelijk wordt. Vindplaats Deze informatie wordt typisch opgeslagen in een 'Sprint' custom field, beheerd door Jira Software (Agile). De data is toegankelijk via de Issue API. Voorbeelden PROJ Sprint 1Q4-2023 Sprint 3November PI Sprint 2

Verplicht Aanbevolen Optioneel

Software Development Lifecycle Activiteiten

Dit zijn de belangrijkste processtappen en mijlpalen om vast te leggen in uw event log voor accurate Software Development Lifecycle process discovery.

6 Aanbevolen 8 Optioneel

	Activiteit	Omschrijving
	Deployed To Production	Deze event markeert het moment dat de codewijzigingen die bij het ontwikkelitem horen live zijn in de productieomgeving. Dit kan worden afgeleid uit een uiteindelijke statuswijziging naar 'Done' of 'Released', of worden vastgelegd via een expliciete event van een geïntegreerde CI/CD tool.
Het belang Dit is het primaire succes-eindpunt voor het proces. Het is essentieel voor het berekenen van de totale end-to-end cycle time en het meten van deployment frequentie en throughput. Vindplaats Kan worden afgeleid uit de Jira `issue changelog` wanneer de status verandert naar 'Released' of 'Done'. Voor meer nauwkeurigheid kan het worden vastgelegd via `deployment events` gepusht door `CI/CD tools` zoals Jenkins, Bamboo, of via de `Deployments feature` in Jira. Vastleggen Timestamp van statuswijziging naar 'Done' of 'Released'. Gebeurtenistype inferred
	Ontwikkeling Gestart	Vertegenwoordigt het moment dat een ontwikkelaar actief aan het ontwikkelitem begint te werken. Dit wordt bijna altijd vastgelegd door een statuswijziging binnen de workflow van Jira af te leiden, bijvoorbeeld wanneer de issue-status verandert naar 'In Progress'.
Het belang Dit is een cruciale mijlpaal voor het meten van actieve ontwikkelingstijd. Het helpt onderscheid te maken tussen wachttijd en waardetoevoegend werk, een belangrijke metric voor het identificeren van knelpunten. Vindplaats Afgeleid uit de Jira `issue changelog`. Het is de `timestamp` wanneer het 'status'-veld voor het eerst verandert naar 'In Progress', 'In Development', of een vergelijkbare actieve status. Vastleggen Timestamp van statuswijziging naar 'In Progress'. Gebeurtenistype inferred
	Ontwikkelingsobject Gecreëerd	Dit markeert het begin van de lifecycle, wanneer een nieuw ontwikkelitem, zoals een story, bug of task, formeel wordt gelogd in Jira. Deze event wordt expliciet door het systeem vastgelegd met een creation timestamp voor elke issue.
Het belang Deze activiteit dient als de definitieve start van het proces, wat essentieel is voor het berekenen van end-to-end cycle times en het volgen van het totale volume van inkomend werk. Vindplaats Dit is een fundamentele event voor elke Jira issue. De creation timestamp is opgeslagen in het 'created' veld van het issue record, toegankelijk via de Jira API. Vastleggen Het 'created' timestamp veld op het Jira Issue object. Gebeurtenistype explicit
	QA Testen Gestart	Deze event markeert het begin van de formele Quality Assurance testfase voor het ontwikkelitem. Het wordt afgeleid uit een Jira statuswijziging wanneer de issue wordt verplaatst naar een status zoals 'In QA', 'In Testing' of 'Ready for Testing'.
Het belang Dit is een belangrijke mijlpaal die de kwaliteitsvalidatiecyclus start. Het meten van de tijd van 'Development Completed' tot dit punt belicht handoff-vertragingen tussen Dev- en QA-teams. Vindplaats Afgeleid van de Jira issue changelog. Dit is de timestamp van het moment dat het veld 'status' wijzigt naar een specifieke status voor QA-testen, zoals 'In QA'. Vastleggen Timestamp van statuswijziging naar 'In QA' of 'In Testing'. Gebeurtenistype inferred
	QA Testen Voltooid	Betekent dat het ontwikkelitem alle Quality Assurance checks succesvol heeft doorstaan en klaar is voor de volgende fase, zoals Gebruikersacceptatietest of release. Dit wordt afgeleid uit een statuswijziging vanuit de primaire teststatus.
Het belang Dit markeert de voltooiing van een belangrijke kwaliteitspoort. Het analyseren van de duur van de QA-fase helpt testprocessen en resource-allocatie te optimaliseren. Vindplaats Afgeleid uit de Jira `issue changelog`. Het is de `timestamp` wanneer het 'status'-veld overgaat van 'In QA' naar een volgende status zoals 'Ready for UAT' of 'Ready for Release'. Vastleggen Timestamp van statuswijziging van 'In QA' naar 'Ready for UAT'. Gebeurtenistype inferred
	UAT Goedgekeurd	Vertegenwoordigt de succesvolle voltooiing van de Gebruikersacceptatietest (UAT), wat de goedkeuring van stakeholders voor release aangeeft. Dit wordt afgeleid uit een statuswijziging van 'In UAT' naar een status zoals 'Ready for Release' of 'Done'.
Het belang Deze mijlpaal bevestigt bedrijfsacceptatie en geeft groen licht voor production deployment van het item. Het is een kritieke gate om ervoor te zorgen dat het geleverde werk voldoet aan de gebruikersverwachtingen. Vindplaats Afgeleid uit de Jira `issue changelog`. Het is de `timestamp` van de statuswijziging van 'In UAT' naar de volgende status in de `workflow`, wat goedkeuring betekent. Vastleggen Timestamp van statuswijziging van 'In UAT' naar 'Ready for Release'. Gebeurtenistype inferred
	Code Review Uitgevoerd	Geeft aan dat een `peer` of `lead` de `code` heeft beoordeeld op kwaliteit, standaarden en functionaliteit. Dit kan worden afgeleid uit een statuswijziging, zoals het bewegen van 'In Review' naar 'Ready for QA', of expliciet uit geïntegreerde ontwikkeltools.
Het belang Deze activiteit is een kritieke kwaliteitspoort. Het analyseren van de duur en resultaten, zoals rework, helpt de codekwaliteit te verbeteren en bugs te verminderen die later in het proces worden gevonden. Vindplaats Wordt vaak afgeleid uit de Jira `issue changelog` wanneer de status de 'Code Review'-status verlaat. Het kan ook een expliciete `event` zijn als `code repository tools` zoals Bitbucket of GitHub zijn geïntegreerd. Vastleggen Timestamp van statuswijziging van 'In Review' naar de volgende status. Gebeurtenistype inferred
	Item Klaar voor Ontwikkeling	Geeft aan dat een ontwikkelingsobject volledig is gespecificeerd, beoordeeld en geprioriteerd, waardoor het klaar is voor een ontwikkelaar om aan te beginnen. Dit wordt doorgaans afgeleid uit een statusverandering in de `workflow`, zoals het bewegen van 'Backlog' naar 'To Do' of 'Ready for Dev'.
Het belang Het volgen hiervan helpt de backlog readiness en de tijd dat items wachten voordat de ontwikkeling begint te meten. Het isoleert planning- en verfijningstijd van actieve ontwikkelingstijd. Vindplaats Afgeleid uit de Jira `issue changelog`. Zoek naar een `timestamp` wanneer het 'status'-veld verandert naar een waarde zoals 'Ready for Dev', 'To Do', of 'Selected for Development'. Vastleggen Timestamp van statuswijziging naar een pre-development ready status. Gebeurtenistype inferred
	Ontwikkeling Voltooid	Deze activiteit betekent dat de ontwikkelaar klaar is met coderen en het item klaar is voor de volgende fase, zoals code review of testen. Het wordt afgeleid uit een Jira statuswijziging, zoals het verplaatsen van 'In Progress' naar 'In Review' of 'Ready for QA'.
Het belang Dit markeert het einde van de kernontwikkelingsfase, wat analyse van codeerduur en de efficiëntie van handoffs naar het quality assurance team mogelijk maakt. Vindplaats Afgeleid uit de Jira `issue changelog` door de `timestamp` vast te leggen wanneer het 'status'-veld verandert van een actieve ontwikkelstatus naar een volgende status zoals 'In Review' of 'Ready for QA'. Vastleggen Timestamp van statuswijziging van 'In Progress' naar 'In Review' of 'Ready for QA'. Gebeurtenistype inferred
	Ontwikkelingsobject Afgesloten	Dit is de laatste administratieve actie, die bevestigt dat er geen verder werk wordt verwacht aan het item. Het wordt vaak afgeleid uit een statuswijziging naar 'Closed' en het instellen van een 'Resolution' veldwaarde.
Het belang Vertegenwoordigt het absolute einde van de reis van een item. Een vergelijking hiervan met 'Deployed to Production' kan administratieve vertraging of post-deployment monitoringperiodes onthullen. Vindplaats Afgeleid uit de Jira `issue changelog`. Het is de `timestamp` wanneer het 'status'-veld verandert naar 'Closed' en een resolutie wordt ingesteld. Vastleggen Timestamp van statuswijziging naar 'Closed'. Gebeurtenistype inferred
	Ontwikkelingsobject Geannuleerd	Vertegenwoordigt de beëindiging van een ontwikkelitem vóór voltooiing. Dit wordt afgeleid uit een statuswijziging naar een terminale status zoals 'Canceled', 'Rejected' of 'Won't Do', en gaat vaak gepaard met een specifieke resolution.
Het belang Deze activiteit volgt niet-succesvolle procesresultaten. Het analyseren waarom items worden geannuleerd kan problemen met planning, prioritering of requirement definition onthullen. Vindplaats Afgeleid uit de Jira `issue changelog`. Dit is de `timestamp` wanneer de `issue` 'status' wordt gewijzigd naar 'Canceled' of 'Won't Do' en een corresponderende resolutie wordt ingesteld. Vastleggen Timestamp van statuswijziging naar 'Canceled', 'Rejected' of 'Won't Do'. Gebeurtenistype inferred
	QA Testen Mislukt	Geeft aan dat het `QA-team` een defect heeft gevonden, waardoor het ontwikkelingsobject teruggestuurd moet worden naar ontwikkelaars voor `rework`. Dit wordt afgeleid uit een achterwaartse statusovergang, bijvoorbeeld van 'In QA' terug naar 'In Progress' of 'To Do'.
Het belang Deze activiteit is cruciaal voor het identificeren van herstelrondes. Het volgen van de frequentie helpt de kosten van slechte kwaliteit te kwantificeren en wijst gebieden aan voor verbetering in ontwikkeling of requirements. Vindplaats Afgeleid uit de Jira `issue changelog`. Vastgelegd wanneer het 'status'-veld overgaat van een `testing state` (bijv. 'In QA') naar een eerdere ontwikkelstatus (bijv. 'In Progress'). Vastleggen Timestamp van statuswijziging van een teststatus naar een ontwikkelingsstatus. Gebeurtenistype inferred
	UAT Gestart	Markeert het begin van de Gebruikersacceptatietest (UAT), waarbij business stakeholders of eindgebruikers de nieuwe functionaliteit valideren. Dit wordt afgeleid uit een Jira statuswijziging naar een status zoals 'In UAT' of 'User Acceptance Testing'.
Het belang Deze activiteit volgt het begin van de laatste validatiefase vóór release. Het analyseren van de duur is essentieel voor het begrijpen en verminderen van vertragingen veroorzaakt door beschikbaarheid van stakeholders of feedback cycles. Vindplaats Afgeleid uit de Jira `issue changelog`. Het is de `timestamp` wanneer het 'status'-veld wordt geüpdatet naar 'In UAT' of een vergelijkbare aangewezen status. Vastleggen Timestamp van statuswijziging naar 'In UAT'. Gebeurtenistype inferred
	Voorbereid voor Release	Geeft aan dat het ontwikkelingsobject alle controles heeft doorstaan en is gebundeld in een specifieke software `release` versie, in afwachting van `deployment`. Dit wordt vaak afgeleid wanneer de status van een `issue` verandert naar 'Ready for Release' of wanneer het veld 'Fix Version' is ingevuld.
Het belang Deze activiteit helpt bij het volgen van release readiness en de tijd die items wachten op een deployment window nadat al het ontwikkelings- en testwerk is voltooid. Vindplaats Typisch afgeleid van de Jira issue changelog als een statuswijziging naar 'Ready for Release'. Alternatief kan het worden afgeleid van de timestamp wanneer het 'Fix Version/s' veld is ingesteld. Vastleggen Timestamp van statuswijziging naar 'Ready for Release' of wanneer 'Fix Version' is gevuld. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractie Guides

Hoe u uw `data` uit Jira Software haalt

Stappen

Log in bij uw Jira Software-instantie.
Selecteer in de hoofdnavigatiebalk Issues en klik vervolgens op Search for issues. Dit opent de Issue Navigator.
Schakel op de zoekpagina over van de standaard Basic zoekoptie naar Advanced search om het gebruik van Jira Query Language (JQL) mogelijk te maken.
Voer in de JQL-querybalk de geleverde JQL-query in. Vervang de placeholderwaarden voor de project key en het datumbereik om aan uw specifieke vereisten te voldoen.
Voer de query uit door op het zoekpictogram te klikken of op Enter te drukken. Dit toont een lijst van alle ontwikkelingsobjecten die aan uw criteria voldoen.
Klik in de rechterbovenhoek van de zoekresultatenpagina op het Export-pictogram (dit kan eruitzien als een deelicoon of expliciet gelabeld zijn) en selecteer de XML-optie. Gebruik geen CSV, aangezien het XML-formaat de complete, gestructureerde changelog historie bevat die nodig is voor event log creatie.
Sla het gedownloade XML-bestand op uw lokale machine op. Dit bestand bevat één record voor elke Jira-issue, maar omvat alle historische wijzigingen die erin genest zijn.
Belangrijke Transformatie Stap: Het geëxporteerde XML-bestand is geen vlak event log. U moet een extern script of een ETL tool gebruiken om dit bestand te parsen. Het script moet door elke <item>-tag (die een Jira issue vertegenwoordigt) in de XML itereren.
Voor elke issue moet het script eerst een rij genereren voor de Development Item Created activity met behulp van de timestamp van het created veld.
Vervolgens moet het script de <changelog> data binnen elke issue parsen. Voor elke <changeitem> die een statusovergang vertegenwoordigt, genereert u een nieuwe rij in uw uitvoerbestand. Map de Jira statusovergang (bijv. van 'In Progress' naar 'In Review') naar de overeenkomstige business activity (bijv. 'Development Completed') en gebruik de timestamp van de overgang voor de EventTime.
Het script moet alle vereiste en aanbevolen attributes voor elke rij vullen, waarbij data zoals issue key, issue type, assignee, en project uit de XML-structuur worden geëxtraheerd.
Na het verwerken van alle issues en hun histories, slaat u de getransformeerde data op als een CSV-bestand met headers die overeenkomen met de gespecificeerde attributes, klaar voor upload naar de process mining tool.

Configuratie

JQL-queryfilters: De JQL-query is het primaire hulpmiddel voor het selecteren van data. Belangrijke filters zijn project om specifieke ontwikkelprojecten te targeten, issuetype om alleen relevante items zoals Story, Bug, of Task op te nemen, en created om het tijdsvenster voor de analyse te definiëren.
Datumbereik: Voor initiële analyse wordt aanbevolen data te extraheren voor een periode van 3 tot 6 maanden. Dit biedt voldoende data voor zinvolle patronen terwijl de exportbestandsgrootte beheersbaar blijft. Geef het bereik op met behulp van created >= 'YYYY-MM-DD' en created <= 'YYYY-MM-DD' in uw JQL.
Issue Types: Wees specifiek over de issuetype waarden. Vaak wilt u Story, Bug, Task, en Spike opnemen, maar container issues zoals Epic of granulaire zoals Sub-task uitsluiten als ze niet het primaire case vertegenwoordigen.
Exportformaat: U moet XML selecteren als exportformaat. De standaard CSV-export bevat niet betrouwbaar de gestructureerde changelog data die nodig is om de reeks activities te reconstrueren.
Gebruikersmachtigingen: De gebruiker die de export uitvoert, moet 'Browse Projects'-machtigingen hebben voor de Jira-projecten die zijn gespecificeerd in de JQL-query.

a Voorbeeldquery config

project = "[Your Project Key]" AND issuetype in (Story, Bug, Task) AND created >= "[Start Date in YYYY-MM-DD format]" AND created <= "[End Date in YYYY-MM-DD format]" ORDER BY created DESC

Stappen

Databaseverbinding Tot Stand Brengen: Zorg ervoor dat u alleen-lezen toegangsgegevens en netwerkconnectiviteit hebt tot de backend SQL-database van de Jira-instantie. Deze methode is alleen voor self-hosted Jira-installaties.
Verbinden met een SQL Client: Gebruik een database client tool zoals DBeaver, SQL Server Management Studio of pgAdmin om verbinding te maken met de Jira-database met behulp van de geleverde credentials.
Workflowstatussen Identificeren: Voordat u de query uitvoert, navigeert u naar de workflow-instellingen van uw Jira-project (Project settings > Workflows). Noteer zorgvuldig de exacte namen van de statussen die overeenkomen met elke activity die u moet volgen, bijvoorbeeld, 'Backlog', 'In Progress', 'In Review', 'Done'.
De SQL Query Aanpassen: Kopieer de geleverde SQL-query in uw client. U moet de placeholderwaarden aanpassen. Besteed nauwlettend aandacht aan de statusnamen in de WHERE-clausules voor elk UNION ALL-blok, aangezien deze exact moeten overeenkomen met de workflow van uw project.
Queryparameters Instellen: Pas het datumbereikfilter (WHERE ji.created >= '2023-01-01') aan om de periode te definiëren die u wilt analyseren. Het wordt ook sterk aanbevolen te filteren op een of meer specifieke projecten door het project key-filter (--AND p.pkey IN ('PROJ1', 'PROJ2')) te uncommenten en in te stellen.
Custom Fields Configureren: Identificeer het custom field ID voor 'Team Name' in uw Jira-instantie. U kunt dit vinden door te navigeren naar Jira's Custom Fields administratiepagina. Vervang de placeholder 'customfield_10100' in de query door uw daadwerkelijke ID.
De Query Uitvoeren: Voer de aangepaste SQL-query uit op de Jira-database.
De Output Controleren: Inspecteer kort de geretourneerde data om ervoor te zorgen dat deze rijen bevat voor verschillende activities en dat de kolommen zoals verwacht zijn gevuld.
Het Event Log Exporteren: Exporteer de complete resultaatset van uw SQL client naar een CSV-bestand. Zorg ervoor dat de bestandsencoding UTF-8 is.
Voorbereiden op Upload: Verifieer dat de kolomheaders in het geëxporteerde CSV-bestand overeenkomen met de vereiste attribute namen: DevelopmentItem, Activity, EventTime, SourceSystem, LastDataUpdate, Assignee, ItemType, ItemPriority, ItemStatus, ProjectName, en TeamName.

Configuratie

Databasegegevens: Een alleen-lezen gebruikersaccount voor de Jira-database is vereist om onbedoelde datamodificatie te voorkomen.
Namen van Workflowstatussen: De kern van de query is gebaseerd op het filteren op statusnamen (bijv. 'In Progress', 'Done'). Deze zijn specifiek voor elke Jira-workflow en elk project. U moet de placeholderwaarden in de query vervangen door de exacte namen uit uw configuratie.
Datumbereik: De query bevat een WHERE ji.created >= '[YYYY-MM-DD]'-clausule om de hoeveelheid verwerkte data te beperken. Voor initiële analyse wordt een bereik van 3 tot 6 maanden aanbevolen om een beheersbaar datavolume en snellere query-uitvoering te garanderen.
Projectfilter: Om de analyse te richten, wordt sterk aangeraden te filteren op specifieke projectkeys met behulp van de p.pkey IN ('[YourProjectKey]')-conditie. Het bevragen van alle projecten in een grote Jira-instantie kan erg traag zijn.
Aangepast veld voor Team: De 'Team Name' wordt verondersteld een custom field te zijn. De geleverde query gebruikt een placeholder ID (customfield_10100) die moet worden geüpdatet om overeen te komen met de correcte ID uit de configuratie van uw Jira-instantie.
Prestaties: Directe databasequery's kunnen resource-intensief zijn. Voer deze extractie uit tijdens daluren of, bij voorkeur, tegen een read-replica van de productiedatabase om impact op de prestaties van Jira voor gebruikers te voorkomen.

a Voorbeeldquery sql

WITH EventLogBase AS (
    SELECT
        p.pkey || '-' || ji.issuenum AS DevelopmentItem,
        au.display_name AS Assignee,
        it.pname AS ItemType,
        pr.pname AS ItemPriority,
        p.pname AS ProjectName,
        (SELECT cfv.stringvalue FROM customfieldvalue cfv JOIN customfield cf ON cfv.customfield = cf.id WHERE cf.cfname = 'Team' AND cfv.issue = ji.id LIMIT 1) AS TeamName,
        ji.created AS created_timestamp,
        cg.created AS change_timestamp,
        ci.fieldtype,
        ci.field,
        ci.oldstring,
        ci.newstring,
        s.pname as CurrentItemStatus
    FROM jiraissue ji
    LEFT JOIN project p ON ji.project = p.id
    LEFT JOIN issuetype it ON ji.issuetype = it.id
    LEFT JOIN priority pr ON ji.priority = pr.id
    LEFT JOIN issuestatus s ON ji.issuestatus = s.id
    LEFT JOIN app_user au ON ji.assignee = au.user_key
    LEFT JOIN changegroup cg ON cg.issueid = ji.id
    LEFT JOIN changeitem ci ON ci.groupid = cg.id
    WHERE ji.created >= '2023-01-01' --<<< Set your desired start date here
    --AND p.pkey IN ('PROJ1', 'PROJ2') --<<< Uncomment and set your project keys here
)
-- 1. Development Item Created
SELECT
    b.DevelopmentItem,
    'Development Item Created' AS Activity,
    b.created_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.CurrentItemStatus AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM (
    SELECT DISTINCT DevelopmentItem, created_timestamp, Assignee, ItemType, ItemPriority, CurrentItemStatus, ProjectName, TeamName
    FROM EventLogBase
) b

UNION ALL

-- 2. Item Ready for Development
SELECT DISTINCT
    b.DevelopmentItem,
    'Item Ready for Development' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'Backlog' AND b.newstring = 'To Do' --<<< Adjust status names

UNION ALL

-- 3. Development Started
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 4. Development Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Progress' AND b.newstring = 'In Review' --<<< Adjust status names

UNION ALL

-- 5. Code Review Performed
SELECT DISTINCT
    b.DevelopmentItem,
    'Code Review Performed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Review' AND b.newstring = 'Ready for QA' --<<< Adjust status names

UNION ALL

-- 6. QA Testing Started
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In QA' --<<< Adjust status names

UNION ALL

-- 7. QA Testing Failed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Failed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 8. QA Testing Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'Ready for UAT' --<<< Adjust status names

UNION ALL

-- 9. UAT Started
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In UAT' --<<< Adjust status names

UNION ALL

-- 10. UAT Approved
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Approved' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In UAT' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 11. Prepared For Release
SELECT DISTINCT
    b.DevelopmentItem,
    'Prepared For Release' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 12. Deployed To Production
SELECT DISTINCT
    b.DevelopmentItem,
    'Deployed To Production' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Released' --<<< Adjust status names

UNION ALL

-- 13. Development Item Closed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Closed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Closed' --<<< Adjust status names

UNION ALL

-- 14. Development Item Canceled
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Canceled' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring IN ('Canceled', 'Won''t Do', 'Rejected'); --<<< Adjust status names

Stappen

Vereisten: Zorg ervoor dat Python 3 op uw systeem is geïnstalleerd. Installeer de benodigde libraries, requests voor het uitvoeren van API-calls en pandas voor datamanipulatie, door het commando uit te voeren: pip install requests pandas.
Jira API Token Genereren: Log in op uw Jira-instantie. Navigeer naar uw gebruikersprofielinstellingen, ga dan naar Beveiliging en selecteer 'Create and manage API tokens'. Creëer een nieuwe token en kopieer deze veilig. Deze token zal worden gebruikt in plaats van een wachtwoord voor scriptauthenticatie.
Het Python Script Configureren: Kopieer het geleverde Python-script naar een bestand, bijvoorbeeld, extract_jira_log.py. Open het bestand en update de configuratiesectie bovenaan met uw Jira site URL, uw e-mailadres en de zojuist gegenereerde API token.
De JQL Query Definiëren: Wijzig de JQL_QUERY-variabele in het script. Deze query definieert de scope van issues die moeten worden geëxtraheerd. Een goed startpunt is om te filteren op project, issue type en een specifiek datumbereik, bijvoorbeeld: project = "MyProject" AND issuetype in (Story, Bug, Task) AND updated >= -180d.
De Status Mapping Aanpassen: Bekijk de STATUS_MAPPING-dictionary in het script. Deze mapping is cruciaal omdat het de specifieke Jira workflow statussen van uw organisatie vertaalt naar de gestandaardiseerde activities voor process mining. U moet de keys, dit zijn de Jira statusnamen, updaten om exact overeen te komen met uw workflow.
Het Script Uitvoeren: Voer het script uit vanuit uw terminal met het commando: python extract_jira_log.py. Het script zal verbinding maken met de Jira API, de issue data ophalen en de changelogs verwerken.
API Paginatie Verwerken: Het script handelt paginatie automatisch af door issues op te halen in batches van 50. Het blijft verzoeken doen totdat alle issues die overeenkomen met de JQL query zijn opgehaald.
Issue Changelogs Verwerken: Voor elke issue haalt het script de gehele historie op. Het identificeert de creation event en itereert vervolgens door alle statuswijzigingen, waarbij een nieuwe rij in het event log wordt gecreëerd voor elke relevante transitie gebaseerd op uw STATUS_MAPPING.
Het Event Log Bestand Genereren: Zodra alle issues zijn verwerkt, compileert het script de events in een pandas DataFrame, voegt het vereiste metadata columns zoals SourceSystem en LastDataUpdate toe, en slaat het de uiteindelijke event log op als een CSV-bestand genaamd jira_event_log.csv in dezelfde map.

Configuratie

JIRA_URL: De basis-URL voor uw Jira-instantie, bijvoorbeeld, https://your-company.atlassian.net.
JIRA_EMAIL: Het e-mailadres van het gebruikersaccount dat zal worden gebruikt voor authenticatie.
JIRA_API_TOKEN: De API token gegenereerd vanuit de beveiligingsinstellingen van de Jira-gebruiker voor scriptauthenticatie.
JQL_QUERY: De Jira Query Language string die filtert welke issues worden geëxtraheerd. Het wordt sterk aanbevolen te filteren op een datumbereik, zoals de laatste 6-12 maanden, om het datavolume te beheren. U dient ook te filteren op project en de relevante issue types (bijv. Story, Bug, Task) om ervoor te zorgen dat u het juiste proces analyseert.
STATUS_MAPPING: Een Python dictionary die uw specifieke Jira workflow statusnamen toewijst aan de vereiste generic activity names. Dit is de belangrijkste configuratie om de nauwkeurigheid van het procesmodel te garanderen. U moet dit aanpassen om overeen te komen met de workflow van uw project.
Vereisten: Het script vereist een Jira-gebruikersaccount met leesrechten voor de projecten en issues die worden geëxtraheerd. De gebruiker moet machtigingen hebben om de REST API te gebruiken.

a Voorbeeldquery python

import requests
import pandas as pd
from requests.auth import HTTPBasicAuth
from datetime import datetime, timezone
import json

class=class="hl-string">"hl-comment"># --- CONFIGURATION SECTION ---
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://[your-company].atlassian.net"
JIRA_EMAIL = class="hl-string">"[your-email@example.com]"
JIRA_API_TOKEN = class="hl-string">"[your-jira-api-token]"

class=class="hl-string">"hl-comment"># JQL query to select the issues for extraction
class=class="hl-string">"hl-comment"># Best practice: Filter by project, issue type, and a date range
JQL_QUERY = class="hl-string">'project = "PROJ" AND issuetype in (Story, Bug, Task) AND updated >= -180d'

class=class="hl-string">"hl-comment"># --- STATUS MAPPING ---
class=class="hl-string">"hl-comment"># CRITICAL: Customize this mapping to match your Jira workflow statuses.
class=class="hl-string">"hl-comment"># The key is the Jira status name (case-sensitive) and the value is the desired Activity name.
STATUS_MAPPING = {
    class=class="hl-string">"hl-comment"># Example Mappings - Adjust to your workflow
    class="hl-string">'To Do': class="hl-string">'Item Ready for Development',
    class="hl-string">'In Progress': class="hl-string">'Development Started',
    class="hl-string">'In Review': class="hl-string">'Development Completed',
    class="hl-string">'Code Review': class="hl-string">'Code Review Performed', class=class="hl-string">"hl-comment"># Often combined with class="hl-string">'In Review' -> class="hl-string">'In QA' transition
    class="hl-string">'In QA': class="hl-string">'QA Testing Started',
    class="hl-string">'QA In Progress': class="hl-string">'QA Testing Started',
    class="hl-string">'Done from QA to In Progress': class="hl-string">'QA Testing Failed', class=class="hl-string">"hl-comment"># Special case for backward transitions
    class="hl-string">'UAT': class="hl-string">'UAT Started',
    class="hl-string">'Ready for Release': class="hl-string">'Prepared For Release',
    class="hl-string">'Done': class="hl-string">'Deployed To Production', class=class="hl-string">"hl-comment"># Often corresponds to final class="hl-string">'Done' state
    class="hl-string">'Released': class="hl-string">'Deployed To Production',
    class="hl-string">'Closed': class="hl-string">'Development Item Closed',
    class="hl-string">'Canceled': class="hl-string">'Development Item Canceled',
    class="hl-string">'Won\'t Doclass="hl-string">': 'Development Item Canceled',
    class=class="hl-string">"hl-comment"># Transitions to specific activities
    class="hl-string">'transition_In Review_to_In QA': class="hl-string">'Code Review Performed',
    class="hl-string">'transition_In QA_to_Ready for Release': class="hl-string">'QA Testing Completed',
    class="hl-string">'transition_UAT_to_Ready for Release': class="hl-string">'UAT Approved',
}

def get_team_from_issue(issue_fields):
    class=class="hl-string">"hl-comment"># Placeholder function to extract Team Name.
    class=class="hl-string">"hl-comment"># Customize this based on how team information is stored in your Jira.
    class=class="hl-string">"hl-comment"># Common sources are Components, Labels, or a custom field.
    if class="hl-string">'components' in issue_fields and issue_fields[class="hl-string">'components']:
        return issue_fields[class="hl-string">'components'][0][class="hl-string">'name']
    return None

def extract_jira_event_log():
    class="hl-string">"""Extracts an event log from Jira based on a JQL query."""
    auth = HTTPBasicAuth(JIRA_EMAIL, JIRA_API_TOKEN)
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json"
    }
    search_url = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"

    event_log = []
    start_at = 0
    max_results = 50
    total_issues = 1 class=class="hl-string">"hl-comment"># Initialize to enter loop

    while start_at < total_issues:
        params = {
            class="hl-string">'jql': JQL_QUERY,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        response = requests.get(search_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if the request fails
        data = response.json()

        total_issues = data[class="hl-string">'total']
        issues = data[class="hl-string">'issues']

        last_data_update = datetime.now(timezone.utc).isoformat()

        for issue in issues:
            issue_key = issue[class="hl-string">'key']
            fields = issue[class="hl-string">'fields']
            
            class=class="hl-string">"hl-comment"># Common attributes for all events of this issue
            common_attrs = {
                class="hl-string">'DevelopmentItem': issue_key,
                class="hl-string">'ItemType': fields.get(class="hl-string">'issuetype', {}).get(class="hl-string">'name'),
                class="hl-string">'ProjectName': fields.get(class="hl-string">'project', {}).get(class="hl-string">'name'),
                class="hl-string">'SourceSystem': class="hl-string">'Jira Software'
            }

            class=class="hl-string">"hl-comment"># 1. Development Item Created event
            created_time = pd.to_datetime(fields[class="hl-string">'created']).isoformat()
            event_log.append({
                **common_attrs,
                class="hl-string">'Activity': class="hl-string">'Development Item Created',
                class="hl-string">'EventTime': created_time,
                class="hl-string">'Assignee': fields.get(class="hl-string">'creator', {}).get(class="hl-string">'displayName'),
                class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                class="hl-string">'ItemStatus': class="hl-string">'Created',
                class="hl-string">'TeamName': get_team_from_issue(fields),
                class="hl-string">'LastDataUpdate': last_data_update
            })

            class=class="hl-string">"hl-comment"># Process changelog for status transitions
            if class="hl-string">'changelog' in issue and issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                for history in issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                    event_time = pd.to_datetime(history[class="hl-string">'created']).isoformat()
                    author = history.get(class="hl-string">'author', {}).get(class="hl-string">'displayName')

                    for item in history[class="hl-string">'items']:
                        if item[class="hl-string">'field'] == class="hl-string">'status':
                            from_status = item[class="hl-string">'fromString']
                            to_status = item[class="hl-string">'toString']
                            activity = None

                            class=class="hl-string">"hl-comment"># Handle specific transitions first
                            transition_key = fclass="hl-string">"transition_{from_status.replace(' ', '')}_to_{to_status.replace(' ', '')}"
                            if transition_key in STATUS_MAPPING:
                                activity = STATUS_MAPPING[transition_key]
                            class=class="hl-string">"hl-comment"># Handle backward transitions (rework)
                            elif to_status == class="hl-string">'In Progress' and from_status in [class="hl-string">'In QA', class="hl-string">'QA In Progress', class="hl-string">'In Review']:
                                activity = class="hl-string">'QA Testing Failed'
                            class=class="hl-string">"hl-comment"># Handle general status changes
                            elif to_status in STATUS_MAPPING:
                                activity = STATUS_MAPPING[to_status]
                            
                            if activity:
                                event_log.append({
                                    **common_attrs,
                                    class="hl-string">'Activity': activity,
                                    class="hl-string">'EventTime': event_time,
                                    class="hl-string">'Assignee': author, class=class="hl-string">"hl-comment"># Person who made the change
                                    class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                                    class="hl-string">'ItemStatus': to_status,
                                    class="hl-string">'TeamName': get_team_from_issue(fields),
                                    class="hl-string">'LastDataUpdate': last_data_update
                                })
        
        start_at += len(issues)
        print(fclass="hl-string">"Processed {start_at} of {total_issues} issues...")

    if not event_log:
        print(class="hl-string">"No events were generated. Check your JQL query and STATUS_MAPPING.")
        return

    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Ensure required columns are present
    required_cols = [class="hl-string">'DevelopmentItem', class="hl-string">'Activity', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate']
    recommended_cols = [class="hl-string">'Assignee', class="hl-string">'ItemType', class="hl-string">'ItemPriority', class="hl-string">'ItemStatus', class="hl-string">'ProjectName', class="hl-string">'TeamName']
    all_cols = required_cols + [col for col in recommended_cols if col in df.columns]
    df = df[all_cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    df.to_csv(class="hl-string">'jira_event_log.csv', index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to jira_event_log.csv")

if __name__ == class="hl-string">"__main__":
    extract_jira_event_log()

Stappen

Log in bij uw Jira Software-instantie.
Selecteer in de hoofdnavigatiebalk Issues en klik vervolgens op Search for issues. Dit opent de Issue Navigator.
Schakel op de zoekpagina over van de standaard Basic zoekoptie naar Advanced search om het gebruik van Jira Query Language (JQL) mogelijk te maken.
Voer in de JQL-querybalk de geleverde JQL-query in. Vervang de placeholderwaarden voor de project key en het datumbereik om aan uw specifieke vereisten te voldoen.
Voer de query uit door op het zoekpictogram te klikken of op Enter te drukken. Dit toont een lijst van alle ontwikkelingsobjecten die aan uw criteria voldoen.
Klik in de rechterbovenhoek van de zoekresultatenpagina op het Export-pictogram (dit kan eruitzien als een deelicoon of expliciet gelabeld zijn) en selecteer de XML-optie. Gebruik geen CSV, aangezien het XML-formaat de complete, gestructureerde changelog historie bevat die nodig is voor event log creatie.
Sla het gedownloade XML-bestand op uw lokale machine op. Dit bestand bevat één record voor elke Jira-issue, maar omvat alle historische wijzigingen die erin genest zijn.
Belangrijke Transformatie Stap: Het geëxporteerde XML-bestand is geen vlak event log. U moet een extern script of een ETL tool gebruiken om dit bestand te parsen. Het script moet door elke <item>-tag (die een Jira issue vertegenwoordigt) in de XML itereren.
Voor elke issue moet het script eerst een rij genereren voor de Development Item Created activity met behulp van de timestamp van het created veld.
Vervolgens moet het script de <changelog> data binnen elke issue parsen. Voor elke <changeitem> die een statusovergang vertegenwoordigt, genereert u een nieuwe rij in uw uitvoerbestand. Map de Jira statusovergang (bijv. van 'In Progress' naar 'In Review') naar de overeenkomstige business activity (bijv. 'Development Completed') en gebruik de timestamp van de overgang voor de EventTime.
Het script moet alle vereiste en aanbevolen attributes voor elke rij vullen, waarbij data zoals issue key, issue type, assignee, en project uit de XML-structuur worden geëxtraheerd.
Na het verwerken van alle issues en hun histories, slaat u de getransformeerde data op als een CSV-bestand met headers die overeenkomen met de gespecificeerde attributes, klaar voor upload naar de process mining tool.

Configuratie

JQL-queryfilters: De JQL-query is het primaire hulpmiddel voor het selecteren van data. Belangrijke filters zijn project om specifieke ontwikkelprojecten te targeten, issuetype om alleen relevante items zoals Story, Bug, of Task op te nemen, en created om het tijdsvenster voor de analyse te definiëren.
Datumbereik: Voor initiële analyse wordt aanbevolen data te extraheren voor een periode van 3 tot 6 maanden. Dit biedt voldoende data voor zinvolle patronen terwijl de exportbestandsgrootte beheersbaar blijft. Geef het bereik op met behulp van created >= 'YYYY-MM-DD' en created <= 'YYYY-MM-DD' in uw JQL.
Issue Types: Wees specifiek over de issuetype waarden. Vaak wilt u Story, Bug, Task, en Spike opnemen, maar container issues zoals Epic of granulaire zoals Sub-task uitsluiten als ze niet het primaire case vertegenwoordigen.
Exportformaat: U moet XML selecteren als exportformaat. De standaard CSV-export bevat niet betrouwbaar de gestructureerde changelog data die nodig is om de reeks activities te reconstrueren.
Gebruikersmachtigingen: De gebruiker die de export uitvoert, moet 'Browse Projects'-machtigingen hebben voor de Jira-projecten die zijn gespecificeerd in de JQL-query.

a Voorbeeldquery config

project = "[Your Project Key]" AND issuetype in (Story, Bug, Task) AND created >= "[Start Date in YYYY-MM-DD format]" AND created <= "[End Date in YYYY-MM-DD format]" ORDER BY created DESC

Uw Software Development Lifecycle Data Template

Uw Software Development Lifecycle Data Template

Software Development Lifecycle attributes

Software Development Lifecycle Activiteiten

Extractie Guides

Jira JQL Query met ingebouwde CSV- of XML-export

Stappen

Configuratie

a Voorbeeldquery config

Directe Jira Database Query via SQL (`Self-Hosted`)

Stappen

Configuratie

a Voorbeeldquery sql

Python Script met de officiële Jira REST API

Stappen

Configuratie

a Voorbeeldquery python

Realtime Event Streaming via Automation Webhooks

Stappen

Configuratie

a Voorbeeldquery config

Klaar om te starten?

Optimaliseer uw SDLC in Jira Software, start vandaag nog!

Uw Software Development Lifecycle Data Template

Uw Software Development Lifecycle Data Template

Software Development Lifecycle attributes

Software Development Lifecycle Activiteiten

Extractie Guides

Jira JQL Query met ingebouwde CSV- of XML-export

Stappen

Configuratie

a Voorbeeldquery config

Directe Jira Database Query via SQL (`Self-Hosted`)

Stappen

Configuratie

a Voorbeeldquery sql

Python Script met de officiële Jira REST API

Stappen

Configuratie

a Voorbeeldquery python

Realtime Event Streaming via Automation Webhooks

Stappen

Configuratie

a Voorbeeldquery config

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Optimaliseer uw SDLC in Jira Software, start vandaag nog!