您的软件开发生命周期数据模板

ServiceNow DevOps
您的软件开发生命周期数据模板

您的软件开发生命周期数据模板

此模板全面介绍了优化软件开发生命周期所需的数据收集方法,包括应收集的关键属性、应跟踪的主要活动,以及从ServiceNow DevOps提取这些数据的实用指南。您可以借助此资源构建可靠的事件日志,开展深入的流程分析。
  • 建议收集的属性
  • 需要跟踪的关键活动
  • ServiceNow DevOps数据提取指南
刚接触事件日志?了解 如何创建流程挖掘事件日志.

软件开发生命周期属性

为全面分析软件开发生命周期,建议在事件日志中纳入以下数据字段。
5 必填 8 建议填写 5 选填
名称 说明
开发项
DevelopmentItem
用于标识单个工作单元的唯一标识符,例如在开发生命周期中推进的功能、缺陷或任务。
说明

开发项是主要案例标识,代表正在跟踪的独立工作单元。它将该项从初始构想到规划、开发、测试和部署的所有活动关联起来。

在流程挖掘分析中,此属性是重建每个工作项端到端历程的基础。它有助于可视化流程路径、计算总周期时间,并识别各项功能或缺陷修复的流程变体。日志中的每个事件都必须关联到一个开发项,才能构建连贯的流程图。

重要性

这是将所有相关开发活动关联到同一流程实例的核心标识符,因此可以分析每个工作项的完整生命周期。

获取途径

此标识符通常是管理用户故事、缺陷或任务的表中的主键,例如ServiceNow中的“rm_story”“rm_bug”或“task”表。

示例
STRY0010015BUG0034092TASK0050118
开始时间
EventTime
表示特定活动或事件发生时间的准确时间戳。
说明

此属性记录开发生命周期中每项活动的日期和时间,是按时间顺序排列事件及开展所有时间分析的基础。

在流程挖掘中,开始时间用于计算活动间隔、识别等待时间和衡量流程总周期时间。它是分析绩效的仪表板(如SDLC端到端周期时间分析)以及计算代码审查交付周期等关键绩效指标的重要依据。

重要性

此时间戳对于正确排列事件,以及计算周期时间、持续时间和等待时间等绩效指标至关重要。

获取途径

通常可在审计跟踪或任务表的系统生成时间戳字段中找到,例如“sys_updated_on”或“sys_created_on”。

示例
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:15:00Z
活动名称
ActivityName
发生的具体开发生命周期事件名称,例如“开发开始”或“完成代码审查”。
说明

此属性记录软件开发生命周期中完成的各个里程碑或任务名称。这些活动构成流程的连续步骤,从创建到部署。

分析活动的顺序和频率是流程挖掘的主要用途。通过分析,您可以构建流程图、发现步骤之间的瓶颈,并找出不符合规范或效率低下的流程变体。活动列表涵盖设计、开发、测试和部署等关键阶段。

重要性

此属性定义流程图中的步骤,支持分析流程路径、发现瓶颈,并找出偏离标准SDLC的情况。

获取途径

通常通过将状态变更、事件记录或审计跟踪条目映射到标准化活动名称列表来确定。例如,“状态”字段变为“进行中”时,可映射为“开发开始”。

示例
开发开始提交代码QA测试完成已部署到生产环境
数据上次更新时间
LastDataUpdate
表示事件日志数据上次从源系统刷新的时间戳。
说明

此属性记录数据集上次从ServiceNow DevOps提取或更新的时间,适用于整个数据集,而非单个事件。

此时间戳对于了解分析数据的新鲜度至关重要。它能让用户了解流程洞察的时效性,并帮助安排数据刷新。在仪表板上显示此信息,可为所有指标和可视化内容提供背景,确保决策依据及时的数据。

重要性

为了解数据的时效性提供重要背景,帮助用户判断流程分析所用数据是否为最新。

获取途径

此时间戳在数据提取过程中生成并添加,用于记录提取执行时间。

示例
2023-11-15T08:00:00Z
源系统
SourceSystem
标识数据的提取来源,本例中的源系统为ServiceNow DevOps。
说明

此属性指定事件数据的来源系统。对于此流程,该值始终为“ServiceNow DevOps”。

虽然该值看似固定,但明确记录源系统对于数据治理至关重要;在合并来自Jira或Azure DevOps等多个系统的数据时尤其如此。它能清楚说明数据来源,并帮助排查数据质量或提取问题。

重要性

确保数据可追溯,并有助于维护数据完整性,尤其是在整合多个开发工具的数据时。

获取途径

这是一个固定值,应在数据提取和转换过程中添加。

示例
ServiceNow DevOps
优先级
DevelopmentItemPriority
分配给开发项的优先级,例如“高”“中”或“低”。
说明

此属性根据业务紧迫程度对开发项分类。优先级有助于团队聚焦最关键的任务,通常用于管理SLA和相关方预期。

在流程挖掘中,优先级是比较分析的重要维度。您可以按优先级筛选流程图,查看高优先级项目是否采用更快或不同的处理路径。它也是“高优先级功能交付时间”仪表板和KPI的重要依据,可用于验证关键项目是否确实得到加速处理。

重要性

支持按不同优先级筛选和比较流程,帮助确认高优先级项目是否得到更快、更高效的处理。

获取途径

这是ServiceNow中任务相关表的标准字段,通常名为“priority”。

示例
1 - 严重2 - 高3 - 中等4 - 低
分配组
AssignmentGroup
活动发生时负责该开发项的团队或小组。
说明

此属性用于标识工作项所属团队,例如“前端开发”“后端服务”或“QA团队”。工作项推进过程中,通常会在不同分配组之间交接。

跟踪分配组对于了解跨职能协作和工作交接至关重要。它有助于发现工作在团队间流转时出现的系统性延误,也支持分析团队绩效和工作量,并识别整体流程中的瓶颈团队。

重要性

跟踪负责工作的团队,以便分析团队绩效、平衡工作量,并评估团队间交接效率。

获取途径

此信息存储在“assignment_group”字段中,这是ServiceNow任务相关表的标准字段。

示例
平台工程移动应用团队质量保证DevOps
受分派开发人员
AssignedDeveloper
活动发生时,受分派到该开发项的开发人员或用户的姓名或ID。
说明

此属性标识负责执行特定任务或活动的人员。开发项在不同阶段和团队之间流转时,此属性可能发生变化。

此属性对于分析资源分配、工作负荷和交接情况至关重要,可直接支持“开发人员工作负荷与交接”仪表板和“每位开发人员的活动量”KPI。跟踪此字段的变化,可以衡量交接时间,并发现开发人员之间或开发与QA团队之间的协作瓶颈。

重要性

这是基于资源开展分析的必要信息,包括工作负荷分配、交接效率,以及识别团队特有的绩效模式。

获取途径

此信息通常存储在ServiceNow任务相关表的“assigned_to”字段中。

示例
David MillerAnna WilliamsJames Brown
受影响的模块/组件
ModuleComponentAffected
开发项涉及的具体软件模块、应用程序或组件。
说明

此属性按受影响的系统部分对开发工作进行分类,例如特定微服务、UI组件或后端应用程序。

按模块或组件细分流程,对于发现局部瓶颈至关重要。“按组件查看瓶颈分析”仪表板和“各组件平均阶段耗时”KPI会使用此属性,定位代码库中的哪些部分持续伴随较长的开发周期、较高的返工率或较频繁的部署失败。这有助于将改进工作集中在最需要的地方。

重要性

支持按应用程序或组件细分分析,帮助定位系统特定部分的瓶颈或质量问题。

获取途径

这通常是自定义字段,或指向配置管理数据库(CMDB)的引用字段,用于将工作项关联到“cmdb_ci”记录。请参阅ServiceNow DevOps文档。

示例
计费服务用户身份验证界面报表数据库API网关
开发项周期时间
DevelopmentItemCycleTime
从创建开发项到最终关闭或部署所经过的总时间。
说明

此属性是一个计算指标,表示单个开发项的端到端耗时。计算方法是针对每个案例,求首次活动与最后一次活动时间戳之间的差值。

这是衡量整个SDLC流程绩效的核心指标,也是“SDLC平均周期时间”KPI的直接依据。它从整体上衡量流程速度和效率。按时间以及优先级、团队等维度分析此指标,有助于跟踪流程改进举措的成效。

重要性

表示工作项的端到端总耗时,是衡量整体流程效率和速度的关键指标。

获取途径

源系统中没有此字段。流程挖掘工具会针对每个案例,用最大StartTime减去最小StartTime进行计算。

示例
15天4小时3天12小时32天8小时
开发项状态
DevelopmentItemState
事件发生时开发项的状态,例如“Open”(打开)、“In Progress”(进行中)或“Closed”(已关闭)。
说明

此属性反映开发项在ServiceNow中的正式状态。活动是从流程中提取的步骤,而状态表示该项在系统工作流中的正式阶段。

状态通常是提取活动的依据,可用于验证数据,也可用于创建更简洁的高层流程视图。例如,分析各状态的耗时,可以从不同于分析活动间耗时的角度发现瓶颈。状态也有助于识别停滞或已解决的事项。

重要性

提供工作项在系统中的正式状态,通常可作为提取活动的依据,也可用于数据验证和高层状态分析。

获取途径

这是ServiceNow中任务相关表的标准字段,通常名为“state”或“stage”。

示例
待处理进行中待测试已完成并关闭
开发项类型
DevelopmentItemType
工作项的分类,例如“功能”“缺陷”“技术债务”或“任务”。
说明

此属性用于区分SDLC流程中的不同工作类型。例如,修复严重缺陷的流程可能不同于开发新功能的流程,且速度可能更快。

按工作项类型分析流程,有助于更细致地了解绩效,并回答诸如“缺陷的返工率是否高于新功能?”或“技术债务的周期时间是否在可接受范围内?”等问题。与一概而论的流程视图相比,这种细分能带来更深入的洞察。

重要性

区分功能和缺陷等不同工作类型,因为它们可能采用不同的流程路径、优先级和预期耗时。

获取途径

可根据记录的源表(例如“rm_story”与“rm_bug”)确定,也可通过通用任务表中的“type”字段确定。

示例
功能缺陷Task技术调研
是否返工
IsRework
布尔标记。如果某项活动属于返工循环(例如测试后返回开发阶段),则值为true。
说明

这是一个派生属性,用于识别流程返回较早阶段后发生的活动。例如,同一事项在“QA测试完成”后又发生“开发已开始”活动,就会被标记为返工。

此标记对于量化和可视化返工至关重要,可直接用于“返工与驳回流程分析”仪表板,并用于计算“测试后返工率”KPI。标记这些事件后,分析人员可以轻松筛选并分析返工的频率、原因及其对整体周期时间的影响。

重要性

此标记便于量化和分析返工,帮助衡量流程质量并找出重复工作的根本原因。

获取途径

流程挖掘工具会分析每个案例的活动顺序,检测流程中的回退,从而计算此属性。

示例
truefalse
提交ID
CommitId
与开发工作相关联的源代码提交唯一标识符。
说明

此属性将开发项直接关联到Git等源代码仓库中的具体代码变更,并在发生“代码已提交”活动时记录。

在流程挖掘中,提交ID通过关联流程数据和工程数据,丰富分析内容。分析人员可以追溯问题部署对应的具体代码变更,也可以将代码复杂度指标与开发周期时间进行关联分析,从而深入开展技术层面的根因分析。

重要性

将流程事件关联到具体代码变更,以便结合流程指标和代码级详情深入分析根因。

获取途径

此信息由ServiceNow DevOps与Git或SVN等源代码管理系统的集成记录,并存储在与开发项关联的表中。

示例
a1b2c3d4e5f6f0e9d8c7b6a59a8b7c6d5e4f
结束时间
EventEndTime
表示活动完成时间的准确时间戳。对于瞬时事件,该值与开始时间相同。
说明

此属性记录开发生命周期中每项活动完成的日期和时间,尤其适用于“完成代码审查”或“QA测试”等可衡量耗时的活动。

在流程挖掘中,同时记录开始和结束时间,才能准确计算活动处理时间,并将其与活动间的等待时间区分开来。这有助于判断延误是由任务耗时过长,还是等待资源造成的。对于“触发构建”等瞬时事件,结束时间可以与开始时间相同。

重要性

支持准确计算活动处理时间,帮助区分实际工作耗时和等待耗时。

获取途径

此值可能需要推算,可以使用下一项活动的开始时间戳,也可以从源系统中单独的“结束日期”字段获取(如果有)。

示例
2023-10-26T18:05:00Z2023-10-28T11:20:15Z2023-11-02T10:00:00Z
计划发布版本
PlannedReleaseVersion
计划交付开发项的目标软件发布版本。
说明

此属性将开发项关联到特定的计划发布版本,例如“版本2.3”或“2023年第四季度发布”。它是项目管理和发布规划的重要组成部分。

在流程挖掘中,此属性对于“发布计划执行情况监控”仪表板至关重要。通过比较实际完成日期与计划发布日期,团队可以衡量计划执行情况、识别可能错过发布的事项,并分析发布延误的原因。它将底层开发流程与高层业务目标直接关联起来。

重要性

将开发工作关联到具体发布版本,以便分析计划执行情况,以及流程延误对发布时间安排的影响。

获取途径

此信息通常存储在“release”或“planned_release”字段中,且往往引用ServiceNow中的发布管理表。请参阅ServiceNow DevOps文档。

示例
v3.4.12024年第一季度发布Phoenix项目上线
返工原因
ReworkReason
对开发项测试后需要返工的原因进行分类或说明。
说明

当某个事项未通过QA或UAT时,此属性会记录失败原因,例如特定缺陷类别、需求理解有误或环境问题。

这些信息为“返工与驳回流程分析”仪表板提供重要背景。分析人员不仅能了解是否发生返工,还能查明返工原因,从而有针对性地改进,例如完善需求定义、加强单元测试或提高测试环境稳定性,以降低整体返工率。

重要性

提供返工原因的定性信息,帮助有针对性地改进流程、提升质量并减少反复返工。

获取途径

测试失败时,原因可能记录在“close_notes”字段中,也可能存储在专用的“rework_reason”自定义字段中。请参阅ServiceNow DevOps文档。

示例
需求理解有误回归缺陷性能测试未通过UI/UX问题
部署状态
DeploymentStatus
表示部署活动的结果,通常为“成功”或“失败”。
说明

此属性记录部署到特定环境的结果,是了解发布流程可靠性和稳定性的关键信息。

此属性是“部署成功与失败趋势”仪表板和“部署失败率”KPI的必要数据。通过分析部署失败的频率和趋势,组织可以发现测试、基础设施或发布协调方面的潜在问题,并据此改进软件交付的质量和可靠性。

重要性

直接衡量部署活动是否成功,是计算部署失败率和分析发布稳定性的关键数据。

获取途径

此状态通常记录在部署跟踪任务或与ServiceNow DevOps集成的CI/CD流水线执行记录中。

示例
成功失败已完成,但有警告
必填 建议填写 选填

软件开发生命周期活动

为准确发现和优化流程,建议在事件日志中记录以下关键步骤和里程碑。
7 建议填写 9 选填
活动 说明
QA测试完成
表示质量保证团队已完成该开发项的测试。通常根据开发项状态从测试阶段变为“待UAT”或“已完成”等状态推断。
重要性

此里程碑标志着一个重要质量关卡完成,是后续用户验收测试或发布准备等阶段的前提。

获取途径

根据状态从测试状态(如“QA中”)变为测试后的状态(如“待UAT”或“已解决”)的时间戳推断。

采集

根据状态从“测试中”变为后续状态的时间戳确定。

事件类型 inferred
UAT已批准
表示业务相关方在用户验收测试后正式批准了开发项。这是一个关键里程碑,可根据状态变更推断,例如从“UAT中”变为“待发布”或“已批准”。
重要性

这是开发项获准部署到生产环境前的最终业务审批,也是重要的质量与治理检查点。

获取途径

根据开发项记录中表示UAT成功完成的状态转换推断,并记录在该项的活动历史中。

采集

根据状态从“UAT”变为已批准或可发布状态推断。

事件类型 inferred
创建开发项
此活动表示在ServiceNow中创建了新的开发项,例如用户故事、缺陷或大型需求。通常在向相关表(如Story [rm_story]表)插入新记录时,会明确记录此事件。
重要性

这是SDLC流程的主要开始事件,可用于衡量端到端总周期时间,并跟踪初始需求的接收情况。

获取途径

在Story [rm_story]、Epic [rm_epic]或Defect [rm_defect]等开发相关表中创建记录时,相关信息会记录在sys_audit或sys_history_line表中。创建时间戳通常保存在记录本身。

采集

取自开发项记录的创建时间戳。

事件类型 explicit
完成代码审查
此活动表示已完成同行代码审查,通常与拉取请求或合并请求相关联。可通过DevOps集成明确捕获此事件,也可根据相关记录的状态变更推断。
重要性

这是关键的质量关卡。分析其耗时有助于发现审查流程中的瓶颈,而这也是SDLC延误的常见原因。

获取途径

可从ServiceNow Git集成中拉取请求记录的“已合并”或“已完成”事件获取,也可根据开发项状态变为“代码审查完成”推断。

采集

与工作项关联的拉取请求合并时记录。

事件类型 explicit
已部署到生产环境
此事件标志着部署已成功完成并进入生产环境。CI/CD工具报告流水线成功完成时,ServiceNow DevOps会明确捕获此事件。
重要性

这是SDLC流程的主要成功结束点,标志着价值流完成,也是计算总周期时间的关键依据。

获取途径

取自Pipeline Execution [sn_devops_pipeline_execution]记录或其关联的Stage Execution Run中的“completion_status”。结束时间的状态为“Success”时,即表示发生此事件。

采集

生产部署流水线成功完成时记录。

事件类型 explicit
开发开始
此活动表示开发人员开始为开发项编写代码或进行实现。通常根据开发项状态变为“进行中”“开发中”或“编码中”来推断。
重要性

这是一个重要里程碑,标志着创造价值的构建阶段开始。它对于衡量开发人员交付周期和代码审查周期至关重要。

获取途径

根据开发项记录(如Story [rm_story])中的“状态”字段更新为“进行中”或等效状态的时间戳推断。

采集

根据状态变为“进行中”或类似值的时间戳确定。

事件类型 inferred
部署失败
表示开发项未能成功部署到生产环境。CI/CD流水线报告失败时,ServiceNow DevOps会明确捕获此事件。
重要性

这是一个关键的失败结束点。分析其发生频率和原因,对于提升发布稳定性、降低部署失败率至关重要。

获取途径

取自Pipeline Execution [sn_devops_pipeline_execution]记录中的“completion_status”。结束时间的状态为“Failed”时,即表示发生此事件。

采集

生产部署流水线报告失败状态时记录。

事件类型 explicit
QA测试开始
标志着正式质量保证测试阶段开始。通常根据开发项状态变为“QA中”“测试中”或“待测试”等值推断。
重要性

此活动标志着工作从开发团队移交给QA团队,可用于衡量测试阶段耗时并发现测试能力方面的瓶颈。

获取途径

根据开发项记录(如Story或Defect)中的“状态”字段更新为QA专属状态的时间戳推断。

采集

根据状态变为“测试中”或等效状态的时间戳确定。

事件类型 inferred
UAT开始
表示用户验收测试开始,业务相关方将在此阶段验证功能。可根据状态变为“UAT”“UAT中”或“用户验收测试”推断此事件。
重要性

此阶段对于确保开发的功能满足业务需求至关重要。分析其耗时有助于发现用户参与度不足或需求不匹配等问题。

获取途径

根据开发项记录中的状态转换推断。客户的状态模型需包含单独的UAT状态。

采集

根据状态变为“UAT”推断。

事件类型 inferred
发现返工
表示测试期间发现问题,需要将开发项退回开发阶段。可通过观察流程中的回退来推断,例如状态从“QA中”变回“进行中”。
重要性

跟踪返工对于了解质量问题和流程低效至关重要。此活动频繁发生,说明开发过程或需求说明可能存在问题。

获取途径

通过分析sys_audit或sys_history_line表中“状态”字段的历史记录推断。从较后阶段的状态(如“测试中”)变为较早阶段的状态(如“进行中”),即表示发生返工。

采集

根据状态回退推断,例如“测试中”->“进行中”。

事件类型 inferred
已准备发布
此活动表示开发项已通过所有质量关卡,并纳入特定版本。可根据开发项关联到发布记录,或状态变为“待部署”推断。
重要性

此步骤表示开发项在技术和功能方面均已完成。在此状态停留的时间可能代表等待预定部署窗口的排队时间。

获取途径

根据“状态”字段变为“待发布”推断,也可跟踪开发项记录中的“发布”字段何时填入或更新。

采集

根据状态变更或与发布记录的关联推断。

事件类型 inferred
开发项已取消
表示开发项尚未完成便已终止。这是一种替代结束状态,通常根据该项状态设为“已取消”或“未完成关闭”推断。
重要性

跟踪取消情况有助于发现资源浪费,并了解范围变更或优先级调整的原因,也能更完整地呈现流程可能产生的结果。

获取途径

根据开发项记录中的“状态”字段更新为“已取消”等未完成的终止状态时的时间戳推断。

采集

根据状态变为“已取消”或等效终止状态推断。

事件类型 inferred
开始部署到生产环境
此活动标志着部署流水线开始向生产环境部署。生产阶段的CI/CD流水线开始执行时,ServiceNow DevOps会明确捕获此事件。
重要性

这标志着生命周期最后一个阶段的开始,该阶段往往最为关键。跟踪此活动有助于分析部署耗时并发现自动化机会。

获取途径

在Stage Execution Run [sn_devops_stage_execution]表中明确记录,并筛选与生产环境相关的阶段。

采集

取自Pipeline Execution中生产部署阶段的开始时间。

事件类型 explicit
提交代码
表示开发人员将代码提交到与开发项关联的版本控制系统代码库。ServiceNow DevOps会从Git或GitHub等集成SCM工具中明确捕获此类事件。
重要性

跟踪代码提交可细致呈现开发进度和活动频率,并帮助将具体代码变更与其所属开发项关联起来。

获取途径

此事件会明确记录在ServiceNow DevOps的Commits [sn_devops_commit]表中,该表由集成的源代码管理系统通过webhook填充。

采集

收到SCM工具发送的提交webhook时记录。

事件类型 explicit
触发构建
此事件表示CI/CD流水线构建开始,通常由代码提交触发。ServiceNow DevOps会将其记录为流水线执行,并关联到发起构建的开发项。
重要性

此活动连接开发与自动化测试或部署。分析代码提交到构建开始之间的时间,可以发现CI/CD流程中的延误。

获取途径

集成的CI/CD工具(如Jenkins、Azure DevOps)启动构建时,事件会明确记录在Pipeline Execution [sn_devops_pipeline_execution]表中。

采集

取自Pipeline Execution表中记录的开始时间。

事件类型 explicit
设计开始
表示正在为开发项制定技术设计或解决方案架构。通常根据开发项记录中的状态字段推断,例如状态变为“设计”或“方案设计”。
重要性

分析设计阶段的耗时,有助于在开发开始前发现需求转化和解决方案规划中的瓶颈。

获取途径

根据开发项记录(如Story [rm_story])中的状态转换推断。查找“状态”或自定义“阶段”字段变为设计相关值的记录。

采集

根据状态变为“设计”或类似状态推断。

事件类型 inferred
建议填写 选填

数据提取指南

如何从ServiceNow DevOps获取数据

准备好开始了吗?

立即着手改进您的软件开发生命周期。使用此数据模板发现隐性低效,推动持续改进。

立即优化您的软件开发生命周期

定位低效环节,将软件开发生命周期周期时间缩短30%或更多。

开始免费试用

无需信用卡,立即开始优化