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

Event Start Time表示某项活动开始的确切日期和时间。它提供单个案例中所有事件的时间顺序，对于准确重建流程至关重要。

时间戳是所有基于时间的流程挖掘分析的基础。它们用于计算活动之间的周期时间、等待时间和处理时间等关键绩效指标。分析时间戳有助于定位瓶颈、衡量流程效率并了解开发生命周期各阶段的持续时间。例如，“Code Submitted for Review”与“Code Review Completed”之间的时长可以揭示评审流程中的延迟。

该时间戳对于正确排列事件以及计算周期时间和瓶颈等所有基于时间的指标至关重要。

可在记录开发工作项目变更的事件日志、审计轨迹或历史表中找到。

Development Item ID是唯一标识软件开发生命周期中每个案例实例的主键。每个ID代表一项独立工作，例如用户故事、Task或缺陷修复，从创建到最终解决或部署。

在流程挖掘分析中，该属性对于重建每个工作项的端到端历程至关重要。它可以将“Development Started”、“Code Review Completed”和“Deployed to Production”等所有相关活动关联起来，形成连贯的流程。分析单个开发项的生命周期，有助于识别与特定工作相关的差异、延迟和返工循环。

这是跟踪每个开发工作项目完整生命周期所需的基础案例标识符。

通常位于软件开发管理系统的主要工作项目表或问题跟踪表中。

活动名称描述开发流程中的具体步骤或状态变更。这些活动构成流程图中的节点，代表“Item Approved for Development”“Code Submitted for Review”或“QA Testing Completed”等关键里程碑。

该属性对于可视化流程和了解事件顺序至关重要。通过分析不同活动，团队可以识别最常见的路径、发现流程偏差，并衡量各阶段耗时。它也是瓶颈分析、返工检测以及与目标流程模型进行一致性检查的基础。

它定义了流程中的步骤，使开发工作流能够被可视化和分析。

通常来源于与开发工作项目相关的状态变更日志、事件流或审计历史表。

最后数据更新时间属性记录数据最近一次从源系统提取或更新的日期和时间，清晰反映数据的新鲜度和相关性。

该信息对于确保分析和仪表板基于最新信息至关重要。相关方可以一眼了解流程视图的更新程度，从而增强对分析洞察的信心。它也是管理数据管道和安排数据刷新的关键元数据。

反映数据的新鲜度，确保分析及时且与决策相关。

通常由数据提取、转换和加载（ETL）管道生成并存储。

源系统属性用于标识记录开发生命周期数据的源应用或平台。在使用多个开发工具的环境中，这一点尤其有用，例如使用Jira进行问题跟踪、使用GitLab进行源代码管理。

在分析中，指定源系统有助于验证数据并提供流程数据的背景信息。它支持比较不同系统管理的流程，并确保正确解读数据，因为不同系统的字段名称和流程约定可能有所不同。您还可以使用它将分析筛选为特定工具的数据集。

提供数据来源背景，对于数据验证以及涉及多个集成系统的分析至关重要。

通常是在数据提取过程中添加的静态值，用于标识记录来源。

事件结束时间标记活动的结束。许多流程步骤以瞬时事件记录，开始和结束时间相同；但部分活动具有可衡量的持续时间。例如，“Code Review”活动可能有不同的开始和结束时间。

该属性对于计算特定任务的主动处理时间至关重要，可将其与空闲或等待时间区分开来。通过比较事件开始时间和事件结束时间之间的时长，分析人员可以衡量增值活动投入的工作量，从而更细致地分析资源利用率，并识别消耗最多主动工作时间的任务。

支持计算单项活动的主动处理时间，将其与等待时间区分开来，更清晰地反映工作投入。

可在事件日志中找到，也可以使用同一工作项目序列中下一项活动的时间戳推导。

该属性用于标识负责完成当前步骤或整个工作项目的个人或团队。负责人可能在生命周期中多次变更，反映开发人员、QA测试人员和评审人员等不同角色之间的交接。

分析分配给属性是了解团队工作负载、交接效率和协作模式的关键。它支持筛选流程图，查看特定人员或团队的工作，并帮助识别与资源相关的瓶颈。基于负责人之间交接的社交网络分析，还可以揭示沟通缺口或过于复杂的协作结构。

支持分析资源工作负载、交接频率和协作模式，帮助优化团队效率。

可在工作项目或问题记录中找到，通常记录在项目历史或审计日志中。

该属性用于标识负责交付开发项目的具体团队、敏捷小组或群组。在大型组织中，工作通常由多个专业团队分担，例如“Frontend”“Backend”“Mobile”或“Platform”。

按团队名称分析可以比较团队绩效并分享最佳实践。它有助于回答“哪个团队的周期时间最短？”或“某个团队是否比其他团队经历更多返工？”等问题。这类分析可以发现工作流、技能组合或资源可用性方面的差异，以及这些差异对整体交付绩效的影响，为有针对性的流程改进提供机会。

支持不同团队之间的绩效基准比较，帮助识别最佳实践和改进方向。

通常与分配的用户关联，或作为项目或工作项目记录中的直接字段。

优先级属性表示工作项目的业务或技术紧迫性，通常设置为“High”“Medium”或“Low”等值，帮助团队决定下一步处理什么工作。

在流程挖掘中，优先级是重要的分析维度。团队可以据此检查高优先级项目是否确实比低优先级项目处理得更快。比较不同优先级的周期时间，可以揭示流程是否遵循业务优先级。如果高优先级项目经常延迟，可能表明规划、资源分配或工作流设计存在问题。

帮助验证高优先级工作是否能更快通过流程，并识别对关键项目影响更大的瓶颈。

大多数开发管理系统的工作项目或问题记录中都有此标准字段。

开发项目状态表示工作项目在特定时间点所处的状态。活动名称记录状态变更这一事件，而该属性记录状态本身。它可用于分析事件发生时工作的状态。

该属性通常用于生成活动名称，但也能提供额外背景。例如，分析状态字段可以衡量项目在“Blocked”或“Waiting for Review”等特定状态中停留的时长。了解非生产性状态的耗时，对于识别系统性延迟和提升流程效率至关重要。

支持分析项目在不同状态中的耗时，帮助识别延迟以及“Blocked”等非增值状态所占用的时间。

可作为工作项目或问题记录中的主要字段使用，并记录在其历史日志中。

该属性用于对所执行工作的性质进行分类。不同类型的工作项目通常遵循不同的流程路径，并有不同的绩效预期。例如，Bug可能需要快速热修复流程，而Feature则遵循标准的开发和测试周期。

利用该属性，分析人员可以比较不同工作类型的流程和绩效，从而回答“我们的缺陷修复流程是否比功能开发流程更快？”或“技术债务项目是否经历更多返工？”等问题。它是按维度细分数据、获取更具体且可执行洞察的基础。

支持比较不同工作类别的流程和绩效，揭示特定开发类型中的低效环节。

大多数开发管理系统的工作项目或问题记录中都有此标准字段。

项目名称通过归类属于特定产品、计划或代码库的工作项目，为分析提供背景。不同项目的开发实践和周期时间可能存在显著差异，例如遗留系统与全新应用之间的差异。

该属性支持在组织不同部分之间进行高层级汇总和开发流程比较。管理人员可以按项目筛选分析，评估每项开发工作的健康度和效率。它对于理解流程绩效与项目具体背景及技术环境之间的关系也至关重要。

支持按产品或计划细分流程分析，揭示与项目背景相关的绩效差异。

通常是工作项目或问题记录中的标准字段，也可以是Git等系统中的代码库名称。

创建者属性用于标识发起工作项目的人员。创建者可能是创建用户故事的产品经理、记录缺陷的QA测试人员，或报告客户问题的客服人员。

分析工作项目的创建者可以了解工作来源。例如，最终用户报告的大量缺陷可能表明近期发布版本存在质量问题。还可以将创建者与后续返工或延迟关联起来，分析初始需求的清晰度和质量。

帮助识别工作的发起者，从而分析需求、缺陷或功能请求的来源。

通常是工作项目初始创建记录中的“Reporter”或“Author”等标准字段。

严重性不同于优先级：严重性衡量问题的技术影响，而优先级衡量修复问题的紧迫性。例如，很少访问的页面中的拼写错误可能具有低严重性和低优先级，而严重的数据损坏问题则可能具有高严重性和高优先级。

该属性对于质量分析至关重要，尤其适用于缺陷修复流程分析。它帮助团队评估是否优先处理最严重的问题。通过分析不同严重性级别的周期时间，组织可以确保快速解决关键系统问题，尽量降低对客户的影响。

支持根据问题的技术影响分析团队的处理效果，确保及时解决关键问题。

开发管理系统中的标准字段，尤其适用于类型为“Bug”或“Incident”的工作项目。

计划发布版本属性将开发项目关联到特定的交付计划或版本。它通常用于发布规划，将功能和修复项批量安排到同一协调发布中。

按计划发布版本分析有助于评估发布流程的可预测性和可靠性。通过比较计划发布版本与实际部署日期，可以跟踪按时交付率。此外，它还有助于管理范围并了解计划在特定版本中交付的工作流，突出可能影响交付时间线的风险或延迟。

将开发工作与交付计划关联，支持分析按时交付率和发布可预测性。

敏捷规划和开发工具中的标准字段，例如“Fix Version”“Target Release”或“Iteration Path”。

返工指标是一个派生的布尔或分类属性，用于标记属于返工周期的事件。通常在流程向后回退时识别，例如从“QA Testing”退回“Development in Progress”，或发生“Rework Identified in QA”等特定返工活动时识别。

该属性对于质量和效率分析非常有价值。它支持直接计算返工率，并突出产生返工最多的流程环节。通过筛选返工活动，团队可以开展根因分析，了解质量问题为何未能更早发现。减少返工是提升开发速度和产品质量的重要杠杆。

直接量化返工，使团队能够衡量返工频率、分析原因，并跟踪质量随时间的改善情况。

通常在数据转换过程中，通过识别流程中的回退循环或特定的失败相关活动名称来推导。