Uw Software Development Lifecycle Data Template

Het Development Item dient als de primaire case identifier, en vertegenwoordigt een afzonderlijke eenheid van werk die wordt gevolgd. Het koppelt alle activiteiten, van initiële conceptie en planning tot ontwikkeling, testen en deployment voor dat specifieke item.

In process mining analyse is dit attribute fundamenteel voor het reconstrueren van de end-to-end reis van elk werkitem. Het maakt de visualisatie van procesflows, berekening van totale cyclustijden en identificatie van procesvarianten voor individuele features of bug fixes mogelijk. Elk event in de log moet gekoppeld zijn aan een Development Item om een coherente proceskaart op te bouwen.

Dit is de kernidentifier die alle gerelateerde ontwikkelingsactiviteiten verbindt in één procesinstantie, waardoor het mogelijk wordt de complete lifecycle van elk werkitem te analyseren.

Deze identifier is doorgaans de primaire sleutel uit tabellen die stories, bugs of tasks beheren, zoals de 'rm_story', 'rm_bug' of 'task' tabellen in ServiceNow.

Dit attribute registreert de naam van elke mijlpaal of taak die binnen de software development lifecycle is voltooid. Deze activiteiten vormen de sequentiële stappen van het proces, van creatie tot deployment.

Het analyseren van de sequentie en frequentie van deze activiteiten is de primaire functie van process mining. Het maakt de constructie van de proceskaart mogelijk, helpt knelpunten tussen stappen te identificeren en belicht niet-compliant of inefficiënte procesvarianten. De gedefinieerde set activiteiten omvat belangrijke fasen zoals design, development, testing en deployment.

Het definieert de stappen in de proceskaart, wat analyse van de processtroom, identificatie van knelpunten en ontdekking van afwijkingen van de standaard SDLC mogelijk maakt.

Dit wordt doorgaans afgeleid door statuswijzigingen, event records of audit trail entries te mappen aan een gestandaardiseerde lijst van activiteitsnamen. Bijvoorbeeld, een 'state' veld dat verandert naar 'In Progress' kan mappen aan 'Development Started'.

Dit attribute biedt de datum en tijd waarop elke activiteit in de ontwikkelingslifecycle is vastgelegd. Het is essentieel voor chronologische ordening van events en voor alle tijdgerelateerde analyse.

In process mining wordt de starttijd gebruikt om duren tussen activiteiten te berekenen, wachttijden te identificeren en de totale cyclustijd van het proces te meten. Het is een kritiek component voor dashboards die prestaties analyseren, zoals de SDLC End-to-End Cycle Time Analysis, en voor het berekenen van key performance indicators zoals Code Review Lead Time.

Deze timestamp is essentieel voor het correct ordenen van events en het berekenen van alle performance metrics, inclusief cyclustijden, duren en wachttijden.

Doorgaans te vinden in systeemgegenereerde timestamp velden zoals 'sys_updated_on' of 'sys_created_on' uit de audit trail of task tabellen.

Dit attribute specificeert het oorspronkelijke systeem voor de event data. Voor dit proces zal het consistent 'ServiceNow DevOps' zijn.

Hoewel het statisch kan lijken, is het expliciet opnemen van het bronsysteem cruciaal voor data governance en in omgevingen waar data mogelijk wordt samengevoegd uit meerdere systemen, zoals Jira of Azure DevOps. Het zorgt voor duidelijkheid over data herkomst en helpt bij het diagnosticeren van data quality of extractieproblemen.

Waarborgt data traceability en is essentieel voor het handhaven van data integrity, vooral bij het integreren van data uit meerdere development tools.

Dit is een statische waarde die moet worden toegevoegd tijdens het data-extractie- en transformatieproces.

Dit attribute registreert wanneer de dataset voor het laatst is geëxtraheerd of bijgewerkt vanuit ServiceNow DevOps. Het is van toepassing op de gehele dataset in plaats van individuele events.

Deze timestamp is van vitaal belang voor het begrijpen van de versheid van de analyse. Het informeert gebruikers hoe actueel de procesinzichten zijn en helpt bij het plannen van data refreshes. Het weergeven van deze informatie op dashboards biedt context aan alle metrics en visualisaties, en zorgt ervoor dat beslissingen worden genomen op basis van tijdige data.

Biedt cruciale context over de actualiteit van de data, zodat gebruikers begrijpen hoe up-to-date de procesanalyse is.

Deze timestamp wordt gegenereerd en toegevoegd tijdens het data-extractieproces, en registreert wanneer de extractie is uitgevoerd.

Dit attribute is een berekende metric die de end-to-end duur voor een enkel ontwikkelitem vertegenwoordigt. Het wordt berekend door het verschil te vinden tussen de timestamp van de allereerste activiteit en de allerlaatste activiteit voor elke case.

Dit is een primaire key performance indicator voor het gehele SDLC proces, die direct de 'Average SDLC Cycle Time' KPI ondersteunt. Het biedt een high-level maatstaf voor procesvelocity en efficiëntie. Het analyseren van deze metric over tijd en over verschillende dimensies, zoals prioriteit of team, helpt de impact van procesverbeteringsinitiatieven te volgen.

Vertegenwoordigt de totale end-to-end duur voor een werkitem, een belangrijke metric voor het meten van de algehele procesefficiëntie en velocity.

Dit is geen veld in het bronsysteem. Het wordt berekend in de process mining tool door de minimale StartTime af te trekken van de maximale StartTime voor elke CaseId.

Dit attribute weerspiegelt de officiële status van het ontwikkelitem binnen ServiceNow. Hoewel activiteiten afgeleide processtappen zijn, vertegenwoordigt de state de formele fase in de workflow van het systeem.

State is vaak de bron waaruit activiteiten worden afgeleid. Het kan worden gebruikt voor data validatie en voor het creëren van eenvoudigere, high-level weergaven van het proces. Het analyseren van de tijd die in elke state wordt doorgebracht, kan bijvoorbeeld een ander beeld geven van knelpunten dan het analyseren van de tijd tussen activiteiten. Het is ook nuttig voor het identificeren van items die vastzitten of zijn opgelost.

Biedt de officiële systeemstatus van een werkitem, die vaak de bron is voor het afleiden van activiteiten en kan worden gebruikt voor validatie en statusanalyse op hoog niveau.

Dit is een standaardveld, meestal 'state' of 'stage' genaamd, op taakgerelateerde tabellen in ServiceNow.

Dit attribute onderscheidt verschillende soorten werk die door het SDLC proces stromen. Zo kan het proces voor het oplossen van een kritieke bug anders en sneller zijn dan het proces voor het ontwikkelen van een nieuwe feature.

Het analyseren van het proces op basis van werkitem type maakt een meer genuanceerd begrip van de prestaties mogelijk. Het helpt vragen te beantwoorden zoals: 'Hebben bugs een hoger herwerkpercentage dan nieuwe features?' of 'Is onze cyclustijd voor technische schuldvermindering acceptabel?'. Deze segmentatie biedt diepere inzichten dan een one-size-fits-all procesoverzicht.

Onderscheidt verschillende soorten werk, zoals features en bugs, die verschillende process paths, priorities en verwachte durations kunnen hebben.

Dit kan worden bepaald uit de brontabel van het record (bijv. 'rm_story' vs 'rm_bug') of uit een 'type' veld op een generieke task-tabel.

Dit is een afgeleid attribute dat activiteiten identificeert die plaatsvinden nadat een proces is teruggekeerd naar een eerdere fase. Bijvoorbeeld, als een 'Development Started' activiteit plaatsvindt na een 'QA Testing Completed' activiteit voor hetzelfde item, wordt het gemarkeerd als herwerk.

Deze flag is essentieel voor het kwantificeren en visualiseren van herwerk. Het ondersteunt direct het 'Rework and Rejection Flow Analysis' dashboard en wordt gebruikt om de 'Rework Rate after Testing' KPI te berekenen. Door deze events te markeren, kunnen analisten eenvoudig filteren op en de frequentie, oorzaken en impact van herwerk op de totale cyclustijd analyseren.

Deze flag maakt het eenvoudig om herwerk te kwantificeren en te analyseren, en helpt bij het meten van proceskwaliteit en het identificeren van de hoofdoorzaken van herhaald werk.

Dit attribute wordt berekend binnen de process mining tool door de sequentie van activiteiten voor elke case te analyseren om backward movements in de procesflow te detecteren.

Dit attribute categoriseert het ontwikkelwerk op basis van het deel van het systeem dat het beïnvloedt. Dit kan een specifieke microservice, een UI component of een backend applicatie zijn.

Het segmenteren van het proces per module of component is cruciaal voor het identificeren van gelokaliseerde knelpunten. Het 'Component-Specific Bottleneck Insights' dashboard en de 'Avg Stage Duration by Component' KPI vertrouwen op dit attribute om vast te stellen of bepaalde delen van de codebase consistent geassocieerd worden met langere ontwikkelcycli, hogere herwerkpercentages of frequentere deployment failures. Dit helpt om verbeteringsinspanningen te richten waar ze het meest nodig zijn.

Maakt analysis mogelijk die gesegmenteerd kan worden per application of component, en helpt om bottlenecks of kwaliteitsproblemen te isoleren die specifiek zijn voor bepaalde delen van het systeem.

Dit is vaak een custom veld of een referentie naar de Configuration Management Database (CMDB), die het werkitem koppelt aan een 'cmdb_ci' record. Raadpleeg de ServiceNow DevOps documentatie.

Dit attribute categoriseert ontwikkelitems op basis van hun zakelijke urgentie. Prioriteitsniveaus helpen teams zich te richten op de meest kritieke taken en worden vaak gebruikt om SLA's en stakeholder-verwachtingen te beheren.

In process mining is prioriteit een belangrijke dimensie voor vergelijkende analyse. Het maakt het mogelijk om de proceskaart te filteren om te zien of high-priority items een sneller of ander pad volgen. Het is essentieel voor het 'High-Priority Feature Delivery Time' dashboard en KPI, en helpt te valideren of kritieke items daadwerkelijk worden versneld.

Maakt het filteren en vergelijken van processes voor verschillende priority levels mogelijk, en helpt te verifiëren of high-priority items sneller en efficiënter worden verwerkt.

Dit is een standaardveld, vaak 'priority' genaamd, op taakgerelateerde tabellen in ServiceNow.

Dit attribute identificeert de persoon die verantwoordelijk is voor het uitvoeren van een specifieke taak of activiteit. Het is dynamisch en kan veranderen naarmate het ontwikkelitem tussen verschillende fasen en teams beweegt.

Dit attribute is cruciaal voor het analyseren van resource-allocatie, workload en handoffs. Het ondersteunt direct het 'Developer Workload and Handoffs' dashboard en de 'Activity Volume per Developer' KPI. Door veranderingen in dit veld te volgen, is het mogelijk handoff-tijden te meten en collaboration knelpunten te identificeren tussen developers of tussen development en QA teams.

Dit is essentieel voor resource-gebaseerde analyse, inclusief workload distributie, handoff efficiëntie en het identificeren van teamspecifieke prestatiepatronen.

Deze informatie wordt doorgaans opgeslagen in het veld 'assigned_to' op taakgerelateerde tabellen in ServiceNow.

Dit attribute identificeert het team dat aan een werkitem is toegewezen, zoals 'Frontend Developers', 'Backend Services' of 'QA Team'. Naarmate een werkitem vordert, wordt het vaak overgedragen tussen verschillende assignment groups.

Het volgen van de assignment group is essentieel voor het begrijpen van cross-functionele collaboration en handoffs. Het helpt systemische vertragingen te identificeren die optreden wanneer werk van het ene team naar het andere verschuift. Dit attribute ondersteunt de analyse van team-level prestaties, workload en het identificeren welke teams knelpunten zijn in de algehele flow.

Volgt welk team verantwoordelijk is voor het werk, wat analyse van teamprestaties, workload balancing en de efficiëntie van handoffs tussen teams mogelijk maakt.

Deze informatie wordt opgeslagen in het veld 'assignment_group', wat een standaardveld is op taakgerelateerde tabellen in ServiceNow.

Dit attribute biedt een directe link van een ontwikkelitem naar de specifieke codewijziging in de source code repository, zoals Git. Het wordt vastgelegd wanneer een 'Code Committed' activiteit plaatsvindt.

In process mining verrijkt de Commit ID de analyse door procesdata te verbinden met engineering data. Het stelt analisten in staat een problematische deployment terug te leiden naar de exacte codewijziging of code complexity metrics te correleren met ontwikkelingscyclustijden. Dit biedt een veel diepere, meer technische laag van root cause analyse.

Koppelt de procesgebeurtenis aan een specifieke codewijziging, waardoor diepgaandere oorzaakanalyse mogelijk wordt door procesmetrics te correleren met code-niveau details.

Dit wordt vastgelegd door ServiceNow DevOps integraties met source code management systemen zoals Git of SVN. De data bevindt zich in gerelateerde tabellen die zijn gekoppeld aan het ontwikkelitem.

Dit attribute registreert het resultaat van een deployment naar een specifieke omgeving. Het is een cruciaal stuk informatie voor het begrijpen van de betrouwbaarheid en stabiliteit van het releaseproces.

Dit attribute is essentieel voor het 'Deployment Success and Failure Trends' dashboard en de 'Deployment Failure Rate' KPI. Door de frequentie en trends van deployment failures te analyseren, kunnen organisaties onderliggende problemen in hun testing, infrastructuur of releasecoördinatie identificeren. Het helpt de inspanningen te richten op het verbeteren van de kwaliteit en betrouwbaarheid van softwarelevering.

Meet direct het succes van deployment activities, wat cruciaal is voor het berekenen van de deployment failure rate en het analyseren van releasestabiliteit.

Deze status wordt doorgaans vastgelegd in deployment tracking tasks of CI/CD pipeline execution records die zijn geïntegreerd met ServiceNow DevOps.

Dit attribute biedt de datum en tijd waarop elke activiteit in de ontwikkelingslifecycle is voltooid. Het is bijzonder nuttig voor activiteiten die een meetbare duur hebben, zoals 'Code Review Performed' of 'QA Testing'.

In process mining maakt het hebben van zowel een start- als een eindtijd een precieze berekening van activiteitverwerkingstijden mogelijk, waardoor deze worden onderscheiden van de wachttijd tussen activiteiten. Dit helpt om vast te stellen of vertragingen te wijten zijn aan lange taken of lange wachttijden op resources. Voor events die als instantane worden beschouwd, zoals 'Build Triggered', kan de End Time hetzelfde zijn als de Start Time.

Maakt de precieze berekening van activity processing time mogelijk, wat helpt onderscheid te maken tussen tijd besteed aan werken en tijd besteed aan wachten.

Dit moet mogelijk worden afgeleid. Het kan de timestamp zijn van de starttijd van de volgende activiteit, of het kan afkomstig zijn van een apart 'end date' veld indien beschikbaar in het bronsysteem.

Dit attribute koppelt een ontwikkelitem aan een specifieke, geplande release, zoals 'Versie 2.3' of 'Q4 2023 Release'. Het is een sleutelelement voor projectmanagement en release planning.

Voor process mining is dit attribute cruciaal voor het 'Release Plan Adherence Monitoring' dashboard. Door de daadwerkelijke voltooiingsdata te vergelijken met geplande releasedata, kunnen teams de schema-adherentie meten, items identificeren die het risico lopen een release te missen, en de oorzaken van releasevertragingen analyseren. Het biedt een directe link tussen het low-level ontwikkelproces en high-level business doelstellingen.

Verbindt development work met specifieke releases, waardoor analysis van schedule adherence en de impact van processvertragingen op release timelines mogelijk wordt.

Deze informatie wordt doorgaans opgeslagen in een 'release' of 'planned_release' veld, vaak verwijzend naar een release management tabel in ServiceNow. Raadpleeg de ServiceNow DevOps documentatie.

Wanneer een item faalt in QA of UAT, legt dit attribute de reden voor de failure vast. Dit kan een specifieke bug categorie zijn, een misverstand over requirements, of een omgevingsprobleem.

Deze informatie biedt kritieke context voor het 'Rework and Rejection Flow Analysis' dashboard. In plaats van alleen te weten dat herwerk plaatsvond, kunnen analisten begrijpen waarom het gebeurde. Dit maakt gerichte verbeteringen mogelijk, zoals betere requirements definitie, verbeterde unit testing, of stabielere testomgevingen, om het algehele herwerkpercentage te verminderen.

Biedt kwalitatief inzicht in waarom herwerk plaatsvindt, waardoor gerichte procesverbeteringen mogelijk zijn om de kwaliteit te verhogen en herwerklussen te verminderen.

Dit kan worden vastgelegd in een 'close_notes' veld wanneer een test mislukt, of in een speciaal 'rework_reason' custom veld. Raadpleeg de ServiceNow DevOps documentatie.