Uw Softwareontwikkelingscyclus datatemplate

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

Dit attribuut is belangrijk voor het visualiseren van de processtroom en het begrijpen van de reeks gebeurtenissen. Door de verschillende activiteiten te analyseren, kunnen teams de meest voorkomende paden vinden, procesafwijkingen bekijken en de tijd meten die in verschillende fasen wordt doorgebracht. Het vormt de basis voor knelpuntanalyse, reworkdetectie 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, gebeurtenis streams of audit history tables die geassocieerd zijn met ontwikkelingswerkitems.

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

In process mining-analyse is deze attribuut belangrijk voor het reconstrueren van de volledige procesgang 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 processtroom. Het analyseren van de levenscyclus van individuele ontwikkelingsitems helpt bij het vinden van variaties, vertragingen en rework-lussen die geassocieerd zijn met specifieke stukken werk.

Dit is de fundamentele case kenmerk 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 softwaresysteem voor development management.

De Starttijd event markeert de exacte datum en tijd waarop een activiteit begon. Het biedt de chronologische volgorde voor alle gebeurtenissen binnen een enkele case, wat belangrijk is voor het nauwkeurig reconstrueren van de processtroom.

Timestamps zijn de basis van alle tijdgebonden process mining-analyse. Ze worden gebruikt om key prestaties indicators zoals doorlooptijden, wachttijden en verwerkingstijden tussen activiteiten te berekenen. Het analyseren van tijdstempels helpt knelpunten te precies aanwijzen, 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 zichtbaar maken.

Deze timestamp is belangrijk voor het correct ordenen van gebeurtenissen en het berekenen van alle tijdsgebaseerde meetwaarden, 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 data over de ontwikkelcyclus 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 belangrijk 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 het records te vinden.

De Last Data Update attribuut registreert de datum en tijd waarop de data het meest recent is opgehaald of bijgewerkt uit het bronsysteem. Dit geeft een duidelijke indicatie van de relevantie en relevantie van de data.

Deze Informatie is belangrijk 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 datapijplijns en het plannen van data refreshes.

Geeft de relevantie 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) pijplijn.

De Event End Time markeert de conclusie van een activiteit. Hoewel veel processtappen worden vastgelegd als instantane gebeurtenissen 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.

Dit attribuut is belangrijk voor het berekenen van de actieve verwerkingstijd van specifieke taken, en onderscheidt deze van idle of wachttijd. Door de duur tussen Starttijd event en Event End Time te vergelijken, kunnen analysesten de inspanning meten die is besteed aan waardetoevoegende activiteiten. Dit maakt een fijnmazigere analyse van gebruik van brons mogelijk en helpt te vinden 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 waardevolle factor 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 zichtbaar maken of het proces de bedrijfsprioriteiten respecteert. Als items met hoge prioriteit regelmatig vertraging oplopen, kan dit duiden op problemen in de planning, bron-allocatie 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 greenveld-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 belangrijk 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 activiteitsnaam de gebeurtenis van statuswijziging vastlegt, legt deze attribuut de status zelf vast. Dit kan nuttig zijn voor het analyseren van de status van werk op het moment dat een gebeurtenis plaatsvond.

Dit attribuut wordt vaak gebruikt om de activiteitsnaam 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 belangrijk voor het vinden 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 vinden 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 herstelwerk dan andere?'. Deze analyse kan verschillen in workflows, vaardigheden of bronbeschikbaarheid blootleggen die de algehele leveringsprestaties beïnvloeden, wat kansen biedt voor gerichte procesverbeteringen.

Maakt prestatiebenchmarking tussen verschillende teams mogelijk, wat helpt bij het vinden 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 belangrijk 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 vinden van bronnenpecifieke knelpunten. Sociale netwerkanalyse op basis van overdrachten tussen toegewezenen kan communicatiekloven of overdreven complexe samenwerkingsstructuren blootleggen.

Het maakt analyse mogelijk van bron 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 auditlog 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 analysesten 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 herstelwerk?'. Het is een belangrijke basis 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.

Dit attribuut is belangrijk 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 gebeurtenissen 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 herstelwerk genereren. Door te filteren op herstelactiviteiten kunnen teams een oorzaakanalyse uitvoeren om te begrijpen waarom kwaliteitsproblemen niet eerder worden opgemerkt. Het verminderen van herstelwerk is een belangrijke hefboom voor het verbeteren van zowel de ontwikkelingssnelheid als de productkwaliteit.

Kwantificeert rework 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 vinden.

De Creator attribuut 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 rework of vertragingen.

Helpt bij het vinden 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.