Uw Software Development Lifecycle Data Template

De Activity Name beschrijft een specifieke stap of statuswijziging in het ontwikkelingsproces. Deze activiteiten vormen de knooppunten in de procesmap en vertegenwoordigen belangrijke mijlpalen zoals 'Item Approved for Development', 'Code Submitted for Review' of 'QA Testing Completed'.

Deze attribute is cruciaal voor het visualiseren van de procesflow en het begrijpen van de reeks events. Door de verschillende activiteiten te analyseren, kunnen teams de meest voorkomende paden identificeren, procesafwijkingen ontdekken en de tijd meten die in verschillende fasen wordt doorgebracht. Het vormt de basis voor knelpuntanalyse, herwerkdetectie en conformance checking tegen een target procesmodel.

Het definieert de stappen in het proces, wat de visualisatie en analyse van de ontwikkelworkflow mogelijk maakt.

Vaak afgeleid van status change logs, event streams of audit history tables die geassocieerd zijn met ontwikkelingswerkitems.

De Development Item ID is de primary key die elke case-instance uniek identificeert gedurende de softwareontwikkelingslevenscyclus. Elke ID vertegenwoordigt een afzonderlijk stuk werk, zoals een user story, task of bug fix, van de aanmaak tot de uiteindelijke oplossing of deployment.

In process mining analyse is deze attribute essentieel voor het reconstrueren van de end-to-end reis van elk werkitem. Het stelt de tool in staat om alle gerelateerde activiteiten, zoals 'Development Started', 'Code Review Completed' en 'Deployed to Production', te koppelen tot een coherente procesflow. Het analyseren van de levenscyclus van individuele ontwikkelingsitems helpt bij het identificeren van variaties, vertragingen en herwerk-lussen die geassocieerd zijn met specifieke stukken werk.

Dit is de fundamentele case identifier vereist om de volledige levenscyclus van elk ontwikkelingswerkitem van begin tot eind te traceren.

Doorgaans te vinden in de hoofdtabellen voor werkitems of issue tracking van een softwareontwikkelingsmanagementsysteem.

De Event Start Time markeert de exacte datum en tijd waarop een activiteit begon. Het biedt de chronologische volgorde voor alle events binnen een enkele case, wat essentieel is voor het nauwkeurig reconstrueren van de procesflow.

Timestamps zijn de basis van alle tijdgebaseerde process mining analyse. Ze worden gebruikt om key performance indicators zoals doorlooptijden, wachttijden en verwerkingstijden tussen activiteiten te berekenen. Het analyseren van timestamps helpt knelpunten te pinpointen, procesefficiëntie te meten en de duur van verschillende fasen in de ontwikkelingslevenscyclus te begrijpen. Bijvoorbeeld, de tijd tussen 'Code Submitted for Review' en 'Code Review Completed' kan vertragingen in het reviewproces onthullen.

Deze timestamp is essentieel voor het correct ordenen van events en het berekenen van alle tijdsgebaseerde metrics, zoals doorlooptijd en knelpunten.

Beschikbaar in event logs, audit trails of history tables die wijzigingen aan ontwikkelingswerkitems vastleggen.

Het attribuut 'Bronssysteem' identificeert de herkomst van de applicatie of het platform waar de ontwikkellevenscyclusdata werd vastgelegd. Dit is vooral nuttig in omgevingen waar meerdere ontwikkelingstools worden gebruikt, zoals Jira voor issue tracking en GitLab voor sourcecodemanagement.

Bij analyse helpt het specificeren van het bronssysteem bij datavalidatie en biedt het context voor de procesdata. Het maakt vergelijkende analyse mogelijk tussen processen die in verschillende systemen worden beheerd en zorgt ervoor dat de data-interpretatie correct is, aangezien veldnamen en procesconventies tussen systemen kunnen variëren. Het kan ook worden gebruikt om de analyse te filteren op de dataset van een specifieke tool.

Biedt context over de herkomst van de data, wat cruciaal is voor data-validatie en voor analyses die meerdere geïntegreerde systemen omvatten.

Dit is doorgaans een statische waarde toegevoegd tijdens het data-extractieproces om de herkomst van de records te identificeren.

De Last Data Update attribute registreert de datum en tijd waarop de data het meest recent is geëxtraheerd of bijgewerkt uit het bronsysteem. Dit geeft een duidelijke indicatie van de actualiteit en relevantie van de data.

Deze informatie is van vitaal belang om ervoor te zorgen dat analyses en dashboards gebaseerd zijn op actuele informatie. Stakeholders kunnen in één oogopslag zien hoe up-to-date de procesweergave is, wat het vertrouwen in de afgeleide inzichten vergroot. Het is een belangrijk stuk metadata voor het beheren van data pipelines en het plannen van data refreshes.

Geeft de actualiteit van de data aan, en zorgt ervoor dat analyse tijdig en relevant is voor besluitvorming.

Deze waarde wordt doorgaans gegenereerd en opgeslagen door de data-extractie, -transformatie en -lading (ETL) pipeline.

De Event End Time markeert de conclusie van een activiteit. Hoewel veel processtappen worden vastgelegd als instantane events waarbij de start- en eindtijden identiek zijn, hebben sommige activiteiten een meetbare duur. Bijvoorbeeld, een 'Code Review' activiteit kan een duidelijke start- en eindtijd hebben.

Deze attribute is essentieel voor het berekenen van de actieve verwerkingstijd van specifieke taken, en onderscheidt deze van idle of wachttijd. Door de duur tussen Event Start Time en Event End Time te vergelijken, kunnen analisten de inspanning meten die is besteed aan waardetoevoegende activiteiten. Dit maakt een meer granulaire analyse van resource-benutting mogelijk en helpt te identificeren welke taken de meeste actieve werktijd consumeren.

Maakt de berekening van actieve verwerkingstijd voor individuele activiteiten mogelijk, scheidt deze van wachttijd en biedt een duidelijker beeld van de inspanning.

Kan worden gevonden in event logs of worden afgeleid door de timestamp van de volgende activiteit in de reeks voor hetzelfde werkitem te nemen.

Het attribuut 'Prioriteit' geeft de zakelijke of technische urgentie van een werkitem aan. Dit wordt meestal ingesteld op waarden zoals 'Hoog', 'Gemiddeld' of 'Laag' en helpt teams te bepalen waaraan ze vervolgens moeten werken.

Binnen process mining is prioriteit een krachtige dimensie voor analyse. Het stelt teams in staat om te controleren of items met hoge prioriteit daadwerkelijk sneller worden verwerkt dan items met lage prioriteit. Het vergelijken van de doorlooptijden over verschillende prioriteitsniveaus kan onthullen of het proces de bedrijfsprioriteiten respecteert. Als items met hoge prioriteit regelmatig vertraging oplopen, kan dit duiden op problemen in de planning, resourceallocatie of het workflowontwerp.

Helpt te verifiëren of werk met hoge prioriteit sneller door het proces beweegt en identificeert knelpunten die kritieke items onevenredig beïnvloeden.

Een standaardveld op de werkitem- of issue-record in de meeste ontwikkelingsmanagementsystemen.

De 'Projectnaam' biedt context door werkitems te groeperen die behoren tot een specifiek product, initiatief of codebasis. Ontwikkelpraktijken en doorlooptijden kunnen aanzienlijk verschillen tussen projecten, bijvoorbeeld een legacy-systeem versus een nieuwe greenfield-applicatie.

Dit attribuut maakt een aggregatie en vergelijking op hoog niveau van ontwikkelprocessen binnen verschillende onderdelen van de organisatie mogelijk. Door de analyse per project te filteren, kunnen managers de status en efficiëntie van elke ontwikkelingsinspanning beoordelen. Het is ook essentieel om te begrijpen hoe procesprestaties zich verhouden tot de specifieke context en technische omgeving van een project.

Maakt procesanalyse mogelijk gesegmenteerd per product of initiatief, en onthult prestatieverschillen gerelateerd aan de projectcontext.

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

De Development Item Status vertegenwoordigt de status van een werkitem op een specifiek moment. Terwijl de Activity Name de event van statuswijziging vastlegt, legt deze attribute de status zelf vast. Dit kan nuttig zijn voor het analyseren van de status van werk op het moment dat een event plaatsvond.

Deze attribute wordt vaak gebruikt om de Activity Name te creëren, maar kan aanvullende context bieden. Bijvoorbeeld, het analyseren van het statusveld maakt een duur-analyse mogelijk van hoe lang items in een bepaalde status doorbrengen, zoals 'Blocked' of 'Waiting for Review'. Het begrijpen van de tijd besteed in niet-productieve statussen is cruciaal voor het identificeren van systemische vertragingen en het verbeteren van de flow-efficiëntie.

Het maakt analyse mogelijk van de tijd besteed in verschillende statussen, wat helpt bij het identificeren van vertragingen en tijd besteed in niet-waardetoevoegende statussen zoals 'Blocked'.

Beschikbaar als primair veld op de werkitem- of issue-record en wordt bijgehouden in de history log.

Dit attribuut identificeert het specifieke team, de squad of groep die verantwoordelijk is voor het opleveren van het ontwikkelitem. In grotere organisaties wordt werk vaak verdeeld over meerdere gespecialiseerde teams zoals 'Frontend', 'Backend', 'Mobile' of 'Platform'.

Analyseren op basis van 'Teamnaam' maakt prestatievergelijking en het delen van best practices tussen teams mogelijk. Het helpt vragen te beantwoorden zoals 'Welk team heeft de kortste doorlooptijd?' of 'Ervaart één team meer rework dan andere?'. Deze analyse kan verschillen in workflows, vaardigheden of resourcebeschikbaarheid blootleggen die de algehele leveringsprestaties beïnvloeden, wat kansen biedt voor gerichte procesverbeteringen.

Maakt prestatiebenchmarking tussen verschillende teams mogelijk, wat helpt bij het identificeren van best practices en gebieden voor verbetering.

Vaak geassocieerd met de toegewezen gebruiker of als een direct veld op de project- of werkitem-record.

Dit attribuut identificeert de persoon of groep die verantwoordelijk is voor het voltooien van de huidige stap of het gehele werkitem. De toegewezene kan meerdere keren wisselen gedurende de levenscyclus, wat de overdrachten tussen verschillende rollen zoals ontwikkelaars, QA-testers en reviewers weerspiegelt.

Het analyseren van het 'Toegewezen Aan' attribuut is cruciaal voor het begrijpen van de werkdruk van teams, de efficiëntie van overdrachten en samenwerkingspatronen. Het maakt het mogelijk om de proceskaart te filteren om het werk van een specifieke persoon of team te zien, wat helpt bij het identificeren van resourcespecifieke knelpunten. Sociale netwerkanalyse op basis van overdrachten tussen toegewezenen kan communicatiekloven of overdreven complexe samenwerkingsstructuren blootleggen.

Het maakt analyse mogelijk van resource workload, overdrachtsfrequentie en samenwerkingspatronen, wat helpt bij het optimaliseren van team-efficiëntie.

Gevonden in de werkitem- of issue-record, vaak bijgehouden in de history of audit log van het item.

Dit attribuut categoriseert de aard van het uitgevoerde werk. Verschillende soorten werkitems volgen vaak verschillende procespaden en hebben uiteenlopende prestatieverwachtingen. Een 'Bug' vereist bijvoorbeeld mogelijk een snel hotfix-proces, terwijl een 'Feature' een standaard ontwikkelings- en testcyclus volgt.

Met behulp van dit attribuut kunnen analisten de processtromen en prestaties voor verschillende soorten werk vergelijken. Dit helpt vragen te beantwoorden zoals 'Is ons bug-fixing proces sneller dan ons feature ontwikkelproces?' of 'Ervaren technical debt items meer rework?'. Het is een fundamentele dimensie voor het segmenteren van de data om specifiekere en bruikbaardere inzichten te verkrijgen.

Maakt het mogelijk processen en prestaties te vergelijken tussen verschillende werkcategorieën, en onthult inefficiënties die specifiek zijn voor bepaalde soorten ontwikkeling.

Een standaardveld op de werkitem- of issue-record in de meeste ontwikkelingsmanagementsystemen.

Severity is onderscheidend van prioriteit; het meet de technische impact van een issue, terwijl prioriteit de urgentie van het oplossen ervan meet. Zo kan een typfout op een zelden bezochte pagina een lage severity en lage prioriteit hebben, terwijl een kritiek data-corruptie-issue een hoge severity en hoge prioriteit zou hebben.

Deze attribute is cruciaal voor kwaliteitsanalyse, vooral bij het analyseren van bug-fixing processen. Het stelt teams in staat om te beoordelen of ze de meest ernstige issues effectief eerst aanpakken. Door de doorlooptijd voor verschillende severity levels te analyseren, kunnen organisaties ervoor zorgen dat kritieke systeemproblemen snel worden opgelost om de klantimpact te minimaliseren.

Maakt analyse mogelijk van hoe effectief het team problemen aanpakt op basis van hun technische impact, en zorgt ervoor dat kritieke problemen snel worden opgelost.

Een standaardveld, met name voor werkitems van het type 'Bug' of 'Incident', in ontwikkelingsmanagementsystemen.

Het attribuut 'Geplande Release' koppelt een ontwikkelitem aan een specifiek leveringsschema of een versie. Dit wordt vaak gebruikt bij releaseplanning om features en fixes te bundelen voor een gecoördineerde implementatie.

Analyseren op basis van 'Geplande Release' helpt bij het beoordelen van de voorspelbaarheid en betrouwbaarheid van het releaseproces. Het maakt het mogelijk om de punctualiteit van leveringen te volgen door de geplande release te vergelijken met de daadwerkelijke implementatiedatum. Bovendien helpt het bij het beheren van de scope en het begrijpen van de workflow die bestemd is voor een specifieke release, waarbij potentiële risico's of vertragingen die de leveringstermijn kunnen beïnvloeden, worden benadrukt.

Verbindt ontwikkelwerk met leveringsschema's, wat analyse van on-time leveringspercentages en release-voorspelbaarheid mogelijk maakt.

Een standaardveld zoals 'Fix Version', 'Target Release' of 'Iteration Path' in agile planning- en ontwikkeltools.

De 'Rework Indicator' is een afgeleid booleaans of categorisch attribuut dat events markeert als onderdeel van een herstelcyclus. Dit wordt doorgaans geïdentificeerd wanneer de processtroom achterwaarts beweegt, bijvoorbeeld van 'QA Testing' terug naar 'Development in Progress', of wanneer specifieke herstelactiviteiten zoals 'Rework Identified in QA' plaatsvinden.

Dit attribuut is uiterst waardevol voor kwaliteits- en efficiëntieanalyse. Het maakt de directe berekening van herstelpercentages mogelijk en belicht de delen van het proces die de meeste rework genereren. Door te filteren op herstelactiviteiten kunnen teams een oorzaakanalyse uitvoeren om te begrijpen waarom kwaliteitsproblemen niet eerder worden opgemerkt. Het verminderen van rework is een belangrijke hefboom voor het verbeteren van zowel de ontwikkelingssnelheid als de productkwaliteit.

Kwantificeert herwerk direct, waardoor teams de frequentie, oorzaken en kwaliteitsverbeteringen over tijd kunnen meten en analyseren.

Doorgaans afgeleid tijdens datatransformatie door achterwaartse lussen in de processtroom of specifieke foutgerelateerde activiteitsnamen te identificeren.

De Creator attribute identificeert de persoon die het werkitem heeft geïnitieerd. Dit kan een productmanager zijn die een user story aanmaakt, een QA-tester die een bug logt, of een klantenservice-agent die een klantissue rapporteert.

Het analyseren van de creator van werkitems kan inzichten bieden in de bronnen van werk. Bijvoorbeeld, een hoog volume aan bugs gerapporteerd door eindgebruikers kan wijzen op kwaliteitsproblemen in recente releases. Het kan ook worden gebruikt om de duidelijkheid en kwaliteit van initiële vereisten te analyseren door de creator te correleren met downstream herwerk of vertragingen.

Helpt bij het identificeren van de initiators van werk, die kunnen worden geanalyseerd om bronnen van vraag, bugs of feature requests te begrijpen.

Een standaardveld zoals 'Reporter' of 'Author' op de initiële aanmaakrecord van een werkitem.