Your Software Development Lifecycle Data Template

This attribute records the name of each milestone or task completed within the software development lifecycle. These activities form the sequential steps of the process, from creation to deployment.

Analyzing the sequence and frequency of these activities is the primary function of process mining. It enables the construction of the process map, helps identify bottlenecks between steps, and highlights non-compliant or inefficient process variations. The defined set of activities includes key stages like design, development, testing, and deployment.

It defines the steps in the process map, allowing for the analysis of process flow, identification of bottlenecks, and discovery of deviations from the standard SDLC.

This is typically derived by mapping status changes, event records, or audit trail entries to a standardized list of activity names. For example, a 'state' field changing to 'In Progress' could map to 'Development Started'.

The Development Item serves as the primary case identifier, representing a distinct unit of work being tracked. It links all activities, from initial conception and planning through development, testing, and deployment for that specific item.

In process mining analysis, this attribute is fundamental for reconstructing the end-to-end journey of each work item. It allows for the visualization of process flows, calculation of total cycle times, and identification of process variants for individual features or bug fixes. Every event in the log must be associated with a Development Item to build a coherent process map.

This is the core identifier that connects all related development activities into a single process instance, making it possible to analyze the complete lifecycle of each work item.

This identifier is typically the primary key from tables managing stories, bugs, or tasks, such as the 'rm_story', 'rm_bug', or 'task' tables in ServiceNow.

This attribute provides the date and time for when each activity in the development lifecycle was recorded. It is essential for chronological ordering of events and for all time-based analysis.

In process mining, the start time is used to calculate durations between activities, identify waiting times, and measure the overall cycle time of the process. It is a critical component for dashboards analyzing performance, such as the SDLC End-to-End Cycle Time Analysis, and for calculating key performance indicators like Code Review Lead Time.

This timestamp is essential for ordering events correctly and calculating all performance metrics, including cycle times, durations, and waiting times.

Typically found in system-generated timestamp fields like 'sys_updated_on' or 'sys_created_on' from the audit trail or task tables.

This attribute records when the dataset was last extracted or updated from ServiceNow DevOps. It applies to the entire dataset rather than individual events.

This timestamp is vital for understanding the freshness of the analysis. It informs users how current the process insights are and helps in scheduling data refreshes. Displaying this information on dashboards provides context to all metrics and visualizations, ensuring that decisions are made based on timely data.

Provides crucial context about the timeliness of the data, ensuring users understand how up-to-date the process analysis is.

This timestamp is generated and added during the data extraction process, recording when the extraction was executed.

This attribute specifies the originating system for the event data. For this process, it will consistently be 'ServiceNow DevOps'.

While it may seem static, explicitly including the source system is crucial for data governance and in environments where data might be merged from multiple systems, such as Jira or Azure DevOps. It ensures clarity on data provenance and helps in diagnosing data quality or extraction issues.

Ensures data traceability and is essential for maintaining data integrity, especially when integrating data from multiple development tools.

This is a static value that should be added during the data extraction and transformation process.

This attribute identifies the individual responsible for executing a specific task or activity. It is dynamic and can change as the development item moves between different stages and teams.

This attribute is critical for analyzing resource allocation, workload, and handoffs. It directly supports the 'Developer Workload and Handoffs' dashboard and the 'Activity Volume per Developer' KPI. By tracking changes in this field, it's possible to measure handoff times and identify collaboration bottlenecks between developers or between development and QA teams.

This is essential for resource-based analysis, including workload distribution, handoff efficiency, and identifying team-specific performance patterns.

This information is typically stored in the 'assigned_to' field on task-related tables in ServiceNow.

This attribute identifies the team assigned to a work item, such as 'Frontend Developers', 'Backend Services', or 'QA Team'. As a work item progresses, it is often handed off between different assignment groups.

Tracking the assignment group is essential for understanding cross-functional collaboration and handoffs. It helps identify systemic delays that occur when work moves from one team to another. This attribute supports analysis of team-level performance, workload, and identifying which teams are bottlenecks in the overall flow.

Tracks which team is responsible for the work, enabling analysis of team performance, workload balancing, and the efficiency of handoffs between teams.

This information is stored in the 'assignment_group' field, which is a standard field on task-related tables in ServiceNow.

This attribute is a calculated metric representing the end-to-end duration for a single development item. It is computed by finding the difference between the timestamp of the very first activity and the very last activity for each case.

This is a primary key performance indicator for the entire SDLC process, directly supporting the 'Average SDLC Cycle Time' KPI. It provides a high-level measure of process velocity and efficiency. Analyzing this metric over time and across different dimensions, like priority or team, helps track the impact of process improvement initiatives.

Represents the total end-to-end duration for a work item, a key metric for measuring overall process efficiency and velocity.

This is not a field in the source system. It is calculated in the process mining tool by subtracting the minimum StartTime from the maximum StartTime for each CaseId.

This attribute reflects the official status of the development item within ServiceNow. While activities are derived process steps, the state represents the formal stage in the system's workflow.

State is often the source from which activities are derived. It can be used for data validation and for creating simpler, high-level views of the process. For example, analyzing the time spent in each state can provide a different view of bottlenecks compared to analyzing time between activities. It is also useful for identifying items that are stalled or have been resolved.

Provides the official system status of a work item, which is often the source for deriving activities and can be used for validation and high-level status analysis.

This is a standard field, usually named 'state' or 'stage', on task-related tables in ServiceNow.

This attribute distinguishes between different kinds of work flowing through the SDLC process. For example, the process for fixing a critical bug might be different and faster than the process for developing a new feature.

Analyzing the process based on work item type allows for a more nuanced understanding of performance. It helps answer questions like: 'Do bugs have a higher rework rate than new features?' or 'Is our cycle time for technical debt reduction acceptable?'. This segmentation provides deeper insights than a one-size-fits-all process view.

Distinguishes between different types of work, like features and bugs, which may have different process paths, priorities, and expected durations.

This can be determined from the source table of the record (e.g., 'rm_story' vs 'rm_bug') or from a 'type' field on a generic task table.

This is a derived attribute that identifies activities occurring after a process has looped back to an earlier stage. For instance, if a 'Development Started' activity occurs after a 'QA Testing Completed' activity for the same item, it is flagged as rework.

This flag is essential for quantifying and visualizing rework. It directly supports the 'Rework and Rejection Flow Analysis' dashboard and is used to calculate the 'Rework Rate after Testing' KPI. By flagging these events, analysts can easily filter for and analyze the frequency, causes, and impact of rework on the overall cycle time.

This flag makes it easy to quantify and analyze rework, helping to measure process quality and identify the root causes of repeated work.

This attribute is calculated within the process mining tool by analyzing the sequence of activities for each case to detect backward movements in the process flow.

This attribute categorizes the development work by the part of the system it impacts. This could be a specific microservice, a UI component, or a backend application.

Segmenting the process by module or component is crucial for identifying localized bottlenecks. The 'Component-Specific Bottleneck Insights' dashboard and the 'Avg Stage Duration by Component' KPI rely on this attribute to pinpoint if certain parts of the codebase are consistently associated with longer development cycles, higher rework rates, or more frequent deployment failures. This helps focus improvement efforts where they are most needed.

Enables analysis to be segmented by application or component, helping to isolate bottlenecks or quality issues specific to certain parts of the system.

This is often a custom field or a reference to the Configuration Management Database (CMDB), linking the work item to a 'cmdb_ci' record. Consult ServiceNow DevOps documentation.

This attribute categorizes development items based on their business urgency. Priority levels help teams focus on the most critical tasks and are often used to manage SLAs and stakeholder expectations.

In process mining, priority is a key dimension for comparative analysis. It allows for filtering the process map to see if high-priority items follow a faster or different path. It is essential for the 'High-Priority Feature Delivery Time' dashboard and KPI, helping to validate whether critical items are truly being expedited.

Allows for filtering and comparing processes for different priority levels, helping to verify if high-priority items are processed faster and more efficiently.

This is a standard field, often named 'priority', on task-related tables in ServiceNow.

This attribute provides a direct link from a development item to the specific code change in the source code repository, like Git. It is captured when a 'Code Committed' activity occurs.

In process mining, the Commit ID enriches the analysis by connecting process data with engineering data. It allows analysts to trace a problematic deployment back to the exact code change or to correlate code complexity metrics with development cycle times. This provides a much deeper, more technical layer of root cause analysis.

Links the process event to a specific code change, enabling deeper root cause analysis by correlating process metrics with code-level details.

This is captured by ServiceNow DevOps integrations with source code management systems like Git or SVN. The data resides in related tables linked to the development item.

This attribute records the result of a deployment to a specific environment. It is a critical piece of information for understanding the reliability and stability of the release process.

This attribute is essential for the 'Deployment Success and Failure Trends' dashboard and the 'Deployment Failure Rate' KPI. By analyzing the frequency and trends of deployment failures, organizations can identify underlying issues in their testing, infrastructure, or release coordination. It helps focus efforts on improving the quality and reliability of software delivery.

Directly measures the success of deployment activities, which is critical for calculating the deployment failure rate and analyzing release stability.

This status is typically recorded in deployment tracking tasks or CI/CD pipeline execution records integrated with ServiceNow DevOps.

This attribute provides the date and time for when each activity in the development lifecycle was completed. It is particularly useful for activities that have a measurable duration, such as 'Code Review Performed' or 'QA Testing'.

In process mining, having both a start and end time allows for precise calculation of activity processing times, distinguishing them from the waiting time between activities. This helps pinpoint whether delays are due to long tasks or long waits for resources. For events that are considered instantaneous, such as 'Build Triggered', the End Time can be the same as the Start Time.

Enables the precise calculation of activity processing time, which helps differentiate between time spent working versus time spent waiting.

This may need to be derived. It could be the timestamp of the next activity's start time, or it could be sourced from a separate 'end date' field if available in the source system.

This attribute links a development item to a specific, planned release, such as 'Version 2.3' or 'Q4 2023 Release'. It is a key element for project management and release planning.

For process mining, this attribute is crucial for the 'Release Plan Adherence Monitoring' dashboard. By comparing the actual completion dates against planned release dates, teams can measure schedule adherence, identify items at risk of missing a release, and analyze the causes of release delays. It provides a direct link between the low-level development process and high-level business objectives.

Connects development work to specific releases, enabling analysis of schedule adherence and the impact of process delays on release timelines.

This information is typically stored in a 'release' or 'planned_release' field, often referencing a release management table in ServiceNow. Consult ServiceNow DevOps documentation.

When an item fails QA or UAT, this attribute captures the reason for the failure. This could be a specific bug category, a misunderstanding of requirements, or an environmental issue.

This information provides critical context for the 'Rework and Rejection Flow Analysis' dashboard. Instead of just knowing that rework occurred, analysts can understand why it occurred. This allows for targeted improvements, such as better requirements definition, enhanced unit testing, or more stable test environments, to reduce the overall rework rate.

Provides qualitative insight into why rework occurs, enabling targeted process improvements to enhance quality and reduce rework loops.

This may be captured in a 'close_notes' field when a test fails, or in a dedicated 'rework_reason' custom field. Consult ServiceNow DevOps documentation.