Datatemplate voor de levenscyclus van softwareontwikkeling

De activiteitsnaam beschrijft een specifieke stap of statuswijziging in het ontwikkelproces. Deze activiteiten vormen de knooppunten op de proceskaart en staan voor belangrijke mijlpalen, zoals 'Ontwikkelitem goedgekeurd', 'Code ingediend voor review' of 'QA-test afgerond'.

Dit attribuut is nodig om het procesverloop zichtbaar te maken en de volgorde van events te begrijpen. Door de verschillende activiteiten te analyseren, kunnen teams de meest voorkomende routes vinden, procesafwijkingen ontdekken en meten hoeveel tijd verschillende fasen kosten. Dit vormt de basis voor bottleneckanalyse, het opsporen van herstelwerk en conformancechecks met een doelprocesmodel.

Dit attribuut bepaalt welke stappen het proces bevat en maakt het mogelijk de ontwikkelworkflow zichtbaar te maken en te analyseren.

Vaak af te leiden uit statuswijzigingslogs, eventstreams of auditgeschiedenistabellen van ontwikkelitems.

Het ID van het ontwikkelitem is de primaire sleutel waarmee elke case tijdens de softwareontwikkelingscyclus uniek wordt geïdentificeerd. Elk ID staat voor een afzonderlijk werkitem, zoals een user story, taak of bugfix, vanaf de aanmaak tot de uiteindelijke oplossing of implementatie.

Bij process mining is dit attribuut nodig om het volledige verloop van elk werkitem te reconstrueren. De tool kan hiermee alle bijbehorende activiteiten aan elkaar koppelen, zoals 'Ontwikkeling gestart', 'Codereview afgerond' en 'Geïmplementeerd in productie', tot één samenhangend procesverloop. Door de levenscyclus van afzonderlijke ontwikkelitems te analyseren, zie je variaties, vertragingen en herstelwerkloops bij specifieke werkitems.

Dit is het case-ID dat nodig is om de volledige levenscyclus van elk ontwikkelitem van begin tot eind te volgen.

Meestal te vinden in de hoofdtabellen voor werkitems of issuetracking van een softwareontwikkelbeheersysteem.

De starttijd van het event geeft de exacte datum en tijd aan waarop een activiteit begon. Hiermee bepaal je de chronologische volgorde van alle events binnen één case, wat nodig is om het procesverloop correct te reconstrueren.

Timestamps vormen de basis voor alle tijdsgebonden process mining-analyses. Je gebruikt ze om KPI’s te berekenen, zoals doorlooptijden, wachttijden en verwerkingstijden tussen activiteiten. Door timestamps te analyseren, kun je bottlenecks opsporen, de procesefficiëntie meten en zien hoelang verschillende fasen van de ontwikkelcyclus duren. De tijd tussen 'Code ingediend voor review' en 'Codereview afgerond' kan bijvoorbeeld vertragingen in het reviewproces aan het licht brengen.

Deze timestamp is nodig om events in de juiste volgorde te zetten en tijdsgebonden metrieken te berekenen, zoals doorlooptijden en bottlenecks.

Beschikbaar in event logs, auditsporen of geschiedenistabellen waarin wijzigingen aan ontwikkelitems worden vastgelegd.

Het attribuut Bronsysteem geeft aan in welke applicatie of op welk platform de gegevens over de ontwikkelcyclus zijn vastgelegd. Dit is vooral nuttig wanneer meerdere ontwikkeltools worden gebruikt, bijvoorbeeld Jira voor issuetracking en GitLab voor broncodebeheer.

In een analyse helpt het bronsysteem bij datavalidatie en geeft het context bij de procesdata. Je kunt processen uit verschillende systemen met elkaar vergelijken en de data correct interpreteren, omdat veldnamen en procesafspraken per systeem kunnen verschillen. Ook kun je de analyse beperken tot de data uit één specifieke tool.

Geeft context over de herkomst van de data. Dat is belangrijk voor datavalidatie en analyses waarin meerdere geïntegreerde systemen voorkomen.

Dit is meestal een vaste waarde die tijdens de data-extractie wordt toegevoegd om de herkomst van de records aan te geven.

Het attribuut Laatste data-update registreert de datum en tijd waarop de data voor het laatst uit het bronsysteem is opgehaald of bijgewerkt. Zo zie je hoe actueel en relevant de data is.

Deze informatie is nodig om analyses en dashboards op actuele gegevens te baseren. Stakeholders zien in één oogopslag hoe recent het procesoverzicht is. Dat geeft meer zekerheid over de inzichten. Ook zijn deze gegevens belangrijk voor het beheer van datapijplijnen en het plannen van data-updates.

Geeft aan hoe actueel de data is, zodat analyses op tijd beschikbaar zijn en relevant blijven voor besluitvorming.

Deze waarde wordt meestal gegenereerd en opgeslagen door de ETL-pijplijn (extractie, transformatie en laden).

De eindtijd van een gebeurtenis markeert het einde van een activiteit. Veel processtappen worden vastgelegd als gebeurtenissen zonder duur, waarbij de begin- en eindtijd gelijk zijn. Sommige activiteiten hebben wel een meetbare duur. Een activiteit als ‘Code review’ heeft bijvoorbeeld een aparte begin- en eindtijd.

Dit attribuut is nodig om de actieve verwerkingstijd van specifieke taken te berekenen en die te onderscheiden van stilstand- of wachttijd. Door de tijd tussen de begin- en eindtijd van een gebeurtenis te vergelijken, kunnen analisten meten hoeveel tijd aan activiteiten met toegevoegde waarde is besteed. Zo kunnen ze het gebruik van capaciteit gedetailleerder analyseren en zien welke taken de meeste actieve werktijd kosten.

Hiermee kun je de actieve verwerkingstijd per activiteit berekenen en onderscheiden van wachttijd. Zo krijg je een duidelijker beeld van de bestede inspanning.

Te vinden in event logs of af te leiden uit de timestamp van de volgende activiteit in de reeks voor hetzelfde werkitem.

Het attribuut ‘Prioriteit’ geeft aan hoe urgent een werkitem vanuit zakelijk of technisch oogpunt is. Meestal zijn de waarden ‘Hoog’, ‘Gemiddeld’ of ‘Laag’. Teams gebruiken deze informatie om te bepalen wat ze als volgende oppakken.

In process mining is prioriteit een nuttige dimensie voor analyse. Teams kunnen nagaan of items met een hoge prioriteit daadwerkelijk sneller worden verwerkt dan items met een lage prioriteit. Door de doorlooptijden per prioriteitsniveau te vergelijken, zie je of het proces rekening houdt met zakelijke prioriteiten. Als items met hoge prioriteit vaak vertraging oplopen, kan dat wijzen op problemen met de planning, de verdeling van capaciteit of de workflow.

Hiermee kun je nagaan of werk met hoge prioriteit sneller door het proces gaat en bottlenecks vinden die kritieke items onevenredig vaak raken.

Een standaardveld in het werkitem of de issue-registratie van de meeste systemen voor ontwikkelbeheer.

De projectnaam geeft context door werkitems te groeperen die bij een bepaald product, initiatief of codebestand horen. Ontwikkelwerkwijzen en doorlooptijden kunnen per project sterk verschillen, bijvoorbeeld tussen een verouderd systeem en een nieuwe applicatie.

Met dit attribuut kun je ontwikkelprocessen op hoofdlijnen samenvoegen en vergelijken tussen verschillende onderdelen van de organisatie. Door de analyse op project te filteren, kunnen managers de gezondheid en efficiëntie van elk ontwikkeltraject beoordelen. De projectnaam is ook belangrijk om te begrijpen hoe procesprestaties samenhangen met de specifieke context en technische omgeving van een project.

Hiermee kun je procesanalyses uitsplitsen naar product of initiatief en prestatieverschillen vinden die samenhangen met de projectcontext.

Een standaardveld in het werkitem of de issue-registratie, of de naam van de repository in systemen zoals Git.

De status van een ontwikkelitem geeft aan wat de toestand van een werkitem op een bepaald moment is. De activiteitsnaam legt vast dat de status is gewijzigd; dit attribuut legt de status zelf vast. Dat is handig om te analyseren wat de status van het werkitem was toen een gebeurtenis plaatsvond.

Dit attribuut wordt vaak gebruikt om de activiteitsnaam te bepalen, maar geeft ook extra context. Met het statusveld kun je bijvoorbeeld analyseren hoelang items in een bepaalde status blijven, zoals ‘Geblokkeerd’ of ‘Wacht op review’. Inzicht in de tijd die items in niet-productieve statussen doorbrengen, helpt structurele vertragingen te vinden en de doorstroming te verbeteren.

Hiermee kun je analyseren hoelang items in verschillende statussen blijven. Zo vind je vertragingen en zie je hoeveel tijd items doorbrengen in statussen zonder toegevoegde waarde, zoals ‘Geblokkeerd’.

Beschikbaar als standaardveld in het werkitem of de issue-registratie. De wijzigingen worden bijgehouden in de geschiedenis.

Dit attribuut geeft aan welk team, welke squad of welke groep verantwoordelijk is voor de oplevering van het ontwikkelitem. In grotere organisaties is het werk vaak verdeeld over gespecialiseerde teams, zoals Frontend, Backend, Mobile of Platform.

Met een analyse op teamnaam kun je prestaties vergelijken en goede werkwijzen tussen teams delen. Zo krijg je antwoord op vragen als: ‘Welk team heeft de kortste doorlooptijd?’ of ‘Heeft een team vaker herstelwerk dan andere teams?’ De analyse kan verschillen in workflows, vaardigheden of beschikbare capaciteit aan het licht brengen die de totale opleverprestaties beïnvloeden. Dat biedt aanknopingspunten om processen gericht te verbeteren.

Hiermee kun je prestaties van teams vergelijken, goede werkwijzen vinden en zien waar verbetering mogelijk is.

Vaak gekoppeld aan de toegewezen gebruiker of opgenomen als veld in de project- of werkitemregistratie.

Dit attribuut geeft aan welke persoon of groep verantwoordelijk is voor de huidige stap of het volledige werkitem. De toegewezen persoon kan tijdens de levenscyclus meerdere keren veranderen, bijvoorbeeld wanneer het werk wordt overgedragen tussen ontwikkelaars, QA-testers en reviewers.

Analyse van het attribuut ‘Toegewezen aan’ geeft inzicht in de werkdruk van teams, de efficiëntie van overdrachten en de samenwerking. Je kunt de proceskaart filteren op het werk van een specifieke persoon of een specifiek team en zo bottlenecks vinden die met bepaalde medewerkers of teams samenhangen. Een sociale netwerkanalyse van overdrachten tussen toegewezen personen kan communicatieproblemen of onnodig ingewikkelde samenwerkingsstructuren aan het licht brengen.

Hiermee kun je de werkdruk, het aantal overdrachten en samenwerkingspatronen analyseren, zodat je de efficiëntie van teams kunt verbeteren.

Te vinden in het werkitem of de issue-registratie, vaak in de geschiedenis of het auditspoor van het item.

Dit attribuut geeft aan wat voor werk er wordt uitgevoerd. Verschillende typen werkitems volgen vaak verschillende procesroutes en hebben andere verwachtingen voor de prestaties. Voor een Bug kan bijvoorbeeld een snelle hotfixprocedure gelden, terwijl een Functie een standaard ontwikkel- en testcyclus doorloopt.

Met dit attribuut kunnen analisten processtromen en prestaties voor verschillende soorten werk vergelijken. Zo kun je vragen beantwoorden als: ‘Verhelpen we bugs sneller dan we functies ontwikkelen?’ of ‘Leiden technische schuld-items vaker tot herstelwerk?’ Het is een belangrijke dimensie om de data op te splitsen en specifiekere inzichten te krijgen waar je iets mee kunt.

Hiermee kun je processen en prestaties voor verschillende werkcategorieën vergelijken en inefficiënties vinden die bij bepaalde soorten ontwikkelwerk horen.

Een standaardveld in het werkitem of de issue-registratie van de meeste systemen voor ontwikkelbeheer.

Het attribuut ‘Aangemaakt door’ geeft aan wie het werkitem heeft gestart. Dat kan een productmanager zijn die een User Story aanmaakt, een QA-tester die een bug registreert of een medewerker van de klantenservice die een klantprobleem meldt.

Analyse van de aanmaker van werkitems geeft inzicht in waar het werk vandaan komt. Veel bugs die door eindgebruikers worden gemeld, kunnen bijvoorbeeld wijzen op kwaliteitsproblemen in recente releases. Je kunt ook de duidelijkheid en kwaliteit van de oorspronkelijke vereisten analyseren door de aanmaker te vergelijken met later herstelwerk of vertragingen.

Hiermee zie je wie het werk heeft gestart. Analyse daarvan geeft inzicht in de bronnen van vraag, bugs en functieverzoeken.

Een standaardveld, zoals ‘Melder’ of ‘Auteur’, in de oorspronkelijke registratie van een werkitem.

Ernst is iets anders dan prioriteit. Ernst meet de technische impact van een probleem, terwijl prioriteit aangeeft hoe dringend het moet worden opgelost. Een typefout op een pagina die weinig wordt bezocht, kan bijvoorbeeld een lage ernst en lage prioriteit hebben. Een ernstig probleem met beschadigde data heeft juist een hoge ernst en hoge prioriteit.

Dit attribuut is belangrijk voor kwaliteitsanalyse, vooral bij het analyseren van bugfixprocessen. Teams kunnen ermee nagaan of ze de ernstigste problemen als eerste aanpakken. Door de doorlooptijd per ernstniveau te analyseren, kunnen organisaties ervoor zorgen dat kritieke systeemproblemen snel worden opgelost en de impact op klanten beperkt blijft.

Hiermee kun je analyseren hoe goed het team problemen aanpakt op basis van hun technische impact, zodat kritieke problemen snel worden opgelost.

Een standaardveld in systemen voor ontwikkelbeheer, vooral voor werkitems van het type ‘Bug’ of ‘Incident’.

Het attribuut ‘Geplande release’ koppelt een ontwikkelitem aan een specifieke opleverplanning of versie. Dit wordt vaak gebruikt bij releaseplanning om functies en fixes te bundelen voor een gezamenlijke uitrol.

Met een analyse op geplande release kun je de voorspelbaarheid en betrouwbaarheid van het releaseproces beoordelen. Je kunt bijhouden hoe vaak releases op tijd worden opgeleverd door de geplande release te vergelijken met de werkelijke uitroldatum. Ook helpt dit bij het beheren van de scope en het volgen van werk voor een specifieke release. Zo worden mogelijke risico’s of vertragingen zichtbaar die de planning kunnen beïnvloeden.

Koppelt ontwikkelwerk aan opleverplanningen, zodat je kunt analyseren hoe vaak werk op tijd wordt opgeleverd en hoe voorspelbaar releases zijn.

Een standaardveld, zoals ‘Fix Version’, ‘Target Release’ of ‘Iteration Path’, in agile plannings- en ontwikkeltools.

De indicator voor herstelwerk is een afgeleid booleaans of categorisch attribuut dat gebeurtenissen markeert als onderdeel van een herstelcyclus. Dit wordt meestal vastgesteld wanneer de processtroom teruggaat, bijvoorbeeld van ‘QA-testen’ naar ‘Ontwikkeling in uitvoering’, of wanneer specifieke herstelactiviteiten plaatsvinden, zoals ‘Herstelwerk vastgesteld bij QA’.

Dit attribuut is erg nuttig voor kwaliteits- en efficiëntieanalyses. Je kunt er herstelpercentages mee berekenen en ziet welke procesonderdelen het meeste herstelwerk opleveren. Door op herstelactiviteiten te filteren, kunnen teams met oorzaakanalyse onderzoeken waarom kwaliteitsproblemen niet eerder worden ontdekt. Minder herstelwerk leidt tot snellere ontwikkeling en betere productkwaliteit.

Hiermee kun je herstelwerk rechtstreeks meten, de oorzaken ervan analyseren en kwaliteitsverbeteringen in de tijd volgen.

Meestal afgeleid tijdens de datatransformatie door teruggaande lussen in de processtroom of specifieke activiteitsnamen die op fouten wijzen te herkennen.