Plantilla de Datos para el Ciclo de Vida de Desarrollo de Software

El Elemento de Desarrollo sirve como el identificador de caso principal, representando una unidad de trabajo distinta que se está rastreando. Vincula todas las actividades, desde la concepción inicial y la planificación hasta el desarrollo, las pruebas y el despliegue para ese elemento específico.

En el análisis de Process Mining, este atributo es fundamental para reconstruir el recorrido completo de cada elemento de trabajo. Permite la visualización de flujos de proceso, el cálculo de los tiempos de ciclo totales y la identificación de variantes de proceso para características individuales o correcciones de errores. Cada evento en el registro debe estar asociado con un Elemento de Desarrollo para construir un mapa de proceso coherente.

Este es el identificador central que conecta todas las actividades de desarrollo relacionadas en una única instancia de proceso, haciendo posible analizar el ciclo de vida completo de cada elemento de trabajo.

Este identificador es típicamente la clave primaria de las tablas que gestionan stories, bugs o tareas, como las tablas 'rm_story', 'rm_bug' o 'task' en ServiceNow.

Este atributo proporciona la fecha y hora en que se registró cada actividad en el ciclo de vida de desarrollo. Es esencial para el orden cronológico de los eventos y para todo análisis basado en el tiempo.

En el Process Mining, la hora de inicio se utiliza para calcular las duraciones entre actividades, identificar los tiempos de espera y medir el tiempo de ciclo general del proceso. Es un componente crítico para los dashboards que analizan el rendimiento, como el 'SDLC End-to-End Cycle Time Analysis', y para calcular indicadores clave de rendimiento como el 'Code Review Lead Time'.

Esta marca de tiempo es esencial para ordenar los eventos correctamente y calcular todas las métricas de rendimiento, incluyendo tiempos de ciclo, duraciones y tiempos de espera.

Normalmente se encuentra en campos de marca de tiempo generados por el sistema como 'sys_updated_on' o 'sys_created_on' de la pista de auditoría o tablas de tareas.

Este atributo registra el nombre de cada hito o tarea completada dentro del ciclo de vida de desarrollo de software. Estas actividades forman los pasos secuenciales del proceso, desde la creación hasta el despliegue.

Analizar la secuencia y frecuencia de estas actividades es la función principal del Process Mining. Permite la construcción del mapa de proceso, ayuda a identificar cuellos de botella entre pasos y destaca variaciones de proceso no conformes o ineficientes. El conjunto definido de actividades incluye etapas clave como diseño, desarrollo, pruebas y despliegue.

Define los pasos en el mapa de procesos, permitiendo el análisis del flujo del proceso, la identificación de cuellos de botella y el descubrimiento de desviaciones del SDLC estándar.

Esto se deriva típicamente mapeando cambios de estado, registros de eventos o entradas de auditoría a una lista estandarizada de nombres de actividad. Por ejemplo, un campo 'state' cambiando a 'In Progress' podría mapearse a 'Development Started'.

Este atributo especifica el sistema de origen para los datos de eventos. Para este proceso, será consistentemente 'ServiceNow DevOps'.

Aunque pueda parecer estático, incluir explícitamente el sistema de origen es crucial para la gobernanza de datos y en entornos donde los datos podrían fusionarse de múltiples sistemas, como Jira o Azure DevOps. Garantiza claridad sobre la procedencia de los datos y ayuda a diagnosticar problemas de calidad o extracción de datos.

Garantiza la trazabilidad de los datos y es esencial para mantener la integridad de los datos, especialmente al integrar datos de múltiples herramientas de desarrollo.

Este es un valor estático que debe agregarse durante el proceso de extracción y transformación de data.

Este atributo registra cuándo se extrajo o actualizó por última vez el conjunto de datos de ServiceNow DevOps. Se aplica a todo el conjunto de datos en lugar de a eventos individuales.

Esta marca de tiempo es vital para comprender la actualidad del análisis. Informa a los usuarios sobre cuán actuales son las percepciones del proceso y ayuda a programar las actualizaciones de datos. Mostrar esta información en los dashboards proporciona contexto a todas las métricas y visualizaciones, asegurando que las decisiones se to tomen basándose en datos oportunos.

Proporciona un contexto crucial sobre la puntualidad de los datos, asegurando que los usuarios comprendan cuán actualizada está el análisis del proceso.

Esta marca de tiempo se genera y añade durante el proceso de extracción de datos, registrando cuándo se ejecutó la extracción.

Este es un atributo derivado que identifica actividades que ocurren después de que un proceso ha regresado a una etapa anterior. Por ejemplo, si una actividad de 'Development Started' ocurre después de una actividad de 'QA Testing Completed' para el mismo elemento, se marca como retrabajo.

Esta bandera es esencial para cuantificar y visualizar el retrabajo. Apoya directamente el dashboard 'Rework and Rejection Flow Analysis' y se utiliza para calcular el KPI 'Rework Rate after Testing'. Al marcar estos eventos, los analistas pueden filtrar y analizar fácilmente la frecuencia, las causas y el impacto del retrabajo en el tiempo de ciclo general.

Esta bandera facilita cuantificar y analizar el retrabajo, ayudando a medir la calidad del proceso e identificar las causas raíz del trabajo repetido.

Este atributo se calcula dentro de la herramienta de Process Mining analizando la secuencia de actividades para cada caso para detectar movimientos hacia atrás en el flujo del proceso.

Este atributo identifica al individuo responsable de ejecutar una tarea o actividad específica. Es dinámico y puede cambiar a medida que el elemento de desarrollo se mueve entre diferentes etapas y equipos.

Este atributo es crítico para analizar la asignación de recursos, la carga de trabajo y los traspasos. Apoya directamente el dashboard 'Developer Workload and Handoffs' y el KPI 'Activity Volume per Developer'. Al rastrear los cambios en este campo, es posible medir los tiempos de traspaso e identificar cuellos de botella de colaboración entre desarrolladores o entre equipos de desarrollo y QA.

Esto es esencial para el análisis basado en recursos, incluyendo la distribución de la carga de trabajo, la eficiencia de los traspasos y la identificación de patrones de rendimiento específicos del equipo.

Esta información se almacena típicamente en el campo 'assigned_to' en las tablas relacionadas con tareas en ServiceNow.

Este atributo refleja el estado oficial del elemento de desarrollo dentro de ServiceNow. Si bien las actividades son pasos de proceso derivados, el 'state' representa la etapa formal en el flujo de trabajo del sistema.

El 'state' es a menudo la fuente de la que se derivan las actividades. Puede utilizarse para la validación de datos y para crear vistas más simples y de alto nivel del proceso. Por ejemplo, analizar el tiempo dedicado a cada 'state' puede proporcionar una visión diferente de los cuellos de botella en comparación con el análisis del tiempo entre actividades. También es útil para identificar elementos que están estancados o se han resuelto.

Proporciona el estado oficial del sistema de un elemento de trabajo, que a menudo es la fuente para derivar actividades y puede usarse para validación y análisis de estado de alto nivel.

Este es un campo estándar, generalmente llamado 'state' o 'stage', en las tablas relacionadas con tareas en ServiceNow.

Este atributo identifica al equipo asignado a un elemento de trabajo, como 'Frontend Developers', 'Backend Services' o 'QA Team'. A medida que un elemento de trabajo progresa, a menudo se traspasa entre diferentes grupos de asignación.

El seguimiento del grupo de asignación es esencial para comprender la colaboración interfuncional y los traspasos. Ayuda a identificar retrasos sistémicos que ocurren cuando el trabajo se mueve de un equipo a otro. Este atributo respalda el análisis del rendimiento a nivel de equipo, la carga de trabajo y la identificación de qué equipos son cuellos de botella en el flujo general.

Rastrea qué equipo es responsable del trabajo, permitiendo el análisis del rendimiento del equipo, el equilibrio de la carga de trabajo y la eficiencia de los traspasos entre equipos.

Esta información se almacena en el campo 'assignment_group', que es un campo estándar en las tablas relacionadas con tareas en ServiceNow.

Este atributo categoriza el trabajo de desarrollo por la parte del sistema que impacta. Esto podría ser un microservicio específico, un componente de UI o una aplicación de backend.

Segmentar el proceso por módulo o componente es crucial para identificar cuellos de botella localizados. El dashboard 'Component-Specific Bottleneck Insights' y el KPI 'Avg Stage Duration by Component' dependen de este atributo para determinar si ciertas partes del código base están consistentemente asociadas con ciclos de desarrollo más largos, tasas de retrabajo más altas o fallos de despliegue más frecuentes. Esto ayuda a enfocar los esfuerzos de mejora donde más se necesitan.

Permite segmentar el análisis por aplicación o componente, lo que ayuda a aislar cuellos de botella o problemas de calidad específicos de ciertas partes del sistema.

Este es a menudo un campo personalizado o una referencia a la Base de Datos de Gestión de Configuración (CMDB), que vincula el elemento de trabajo a un registro 'cmdb_ci'. Consulte la documentación de ServiceNow DevOps.

Este atributo categoriza los elementos de desarrollo en función de su urgencia de negocio. Los niveles de prioridad ayudan a los equipos a centrarse en las tareas más críticas y a menudo se utilizan para gestionar los SLAs y las expectativas de los stakeholders.

En el Process Mining, la prioridad es una dimensión clave para el análisis comparativo. Permite filtrar el mapa de proceso para ver si los elementos de alta prioridad siguen un camino más rápido o diferente. Es esencial para el dashboard y KPI de 'High-Priority Feature Delivery Time', ayudando a validar si los elementos críticos están siendo realmente agilizados.

Permite filtrar y comparar procesos para diferentes niveles de prioridad, ayudando a verificar si los elementos de alta prioridad se procesan de manera más rápida y eficiente.

Este es un campo estándar, a menudo llamado 'priority', en las tablas relacionadas con tareas en ServiceNow.

Este atributo es una métrica calculada que representa la duración de extremo a extremo de un solo elemento de desarrollo. Se calcula encontrando la diferencia entre la marca de tiempo de la primera actividad y la última actividad para cada caso.

Este es un indicador clave de rendimiento principal para todo el proceso SDLC, apoyando directamente el KPI 'Average SDLC Cycle Time'. Proporciona una medida de alto nivel de la velocidad y eficiencia del proceso. Analizar esta métrica a lo largo del tiempo y a través de diferentes dimensiones, como la prioridad o el equipo, ayuda a rastrear el impacto de las iniciativas de mejora de procesos.

Representa la duración total de extremo a extremo de un elemento de trabajo, una métrica clave para medir la eficiencia y velocidad general del proceso.

Este no es un campo en el sistema de origen. Se calcula en la herramienta de Process Mining restando el StartTime mínimo del StartTime máximo para cada CaseId.

Este atributo distingue entre diferentes tipos de trabajo que fluyen a través del proceso SDLC. Por ejemplo, el proceso para corregir un 'bug' crítico podría ser diferente y más rápido que el proceso para desarrollar una nueva característica.

Analizar el proceso basado en el tipo de elemento de trabajo permite una comprensión más matizada del rendimiento. Ayuda a responder preguntas como: '¿Los bugs tienen una tasa de retrabajo más alta que las nuevas características?' o '¿Es aceptable nuestro tiempo de ciclo para la reducción de la deuda técnica?'. Esta segmentación proporciona percepciones más profundas que una vista de proceso única para todos.

Distingue entre diferentes tipos de trabajo, como funcionalidades y errores, que pueden tener diferentes rutas de proceso, prioridades y duraciones esperadas.

Esto se puede determinar a partir de la tabla de origen del registro (ej., 'rm_story' vs 'rm_bug') o de un campo 'type' en una tabla de tareas genérica.

Este atributo registra el resultado de un despliegue a un entorno específico. Es una pieza de información crítica para comprender la fiabilidad y estabilidad del proceso de lanzamiento.

Este atributo es esencial para el dashboard 'Deployment Success and Failure Trends' y el KPI 'Deployment Failure Rate'. Al analizar la frecuencia y las tendencias de los fallos de despliegue, las organizaciones pueden identificar problemas subyacentes en sus pruebas, infraestructura o coordinación de lanzamientos. Ayuda a enfocar los esfuerzos en mejorar la calidad y fiabilidad de la entrega de software.

Mide directamente el éxito de las actividades de despliegue, lo cual es crítico para calcular la tasa de fallo de despliegue y analizar la estabilidad del lanzamiento.

Este estado se registra típicamente en tareas de seguimiento de despliegue o registros de ejecución de pipeline de CI/CD integrados con ServiceNow DevOps.

Este atributo proporciona la fecha y hora en que se completó cada actividad en el ciclo de vida de desarrollo. Es particularmente útil para actividades que tienen una duración medible, como 'Code Review Performed' o 'QA Testing'.

En el Process Mining, tener tanto un tiempo de inicio como un tiempo de finalización permite un cálculo preciso de los tiempos de procesamiento de la actividad, distinguiéndolos del tiempo de espera entre actividades. Esto ayuda a determinar si los retrasos se deben a tareas largas o a largas esperas de recursos. Para eventos que se consideran instantáneos, como 'Build Triggered', el End Time puede ser el mismo que el Start Time.

Permite el cálculo preciso del tiempo de procesamiento de la actividad, lo que ayuda a diferenciar entre el tiempo dedicado a trabajar y el tiempo dedicado a esperar.

Esto podría necesitar ser derivado. Podría ser la marca de tiempo de la hora de inicio de la siguiente actividad, o podría obtenerse de un campo de 'end date' separado si está disponible en el sistema de origen.

Este atributo proporciona un vínculo directo desde un elemento de desarrollo al cambio de código específico en el repositorio de código fuente, como Git. Se captura cuando ocurre una actividad de 'Code Committed'.

En el Process Mining, el Commit ID enriquece el análisis al conectar los datos del proceso con los datos de ingeniería. Permite a los analistas rastrear un despliegue problemático hasta el cambio de código exacto o correlacionar las métricas de complejidad del código con los tiempos del ciclo de desarrollo. Esto proporciona una capa de análisis de causa raíz mucho más profunda y técnica.

Vincula el evento del proceso a un cambio de código específico, permitiendo un análisis de causa raíz más profundo al correlacionar métricas de proceso con detalles a nivel de código.

Esto es capturado por las integraciones de ServiceNow DevOps con sistemas de gestión de código fuente como Git o SVN. Los datos residen en tablas relacionadas vinculadas al elemento de desarrollo.

Cuando un elemento falla en QA o UAT, este atributo captura la razón del fallo. Esto podría ser una categoría de 'bug' específica, un malentendido de los requisitos o un problema ambiental.

Esta información proporciona un contexto crítico para el dashboard 'Rework and Rejection Flow Analysis'. En lugar de solo saber que ocurrió el retrabajo, los analistas pueden entender por qué ocurrió. Esto permite mejoras dirigidas, como una mejor definición de requisitos, pruebas unitarias mejoradas o entornos de prueba más estables, para reducir la tasa general de retrabajo.

Proporciona una visión cualitativa de por qué ocurre el retrabajo, permitiendo mejoras de proceso dirigidas para aumentar la calidad y reducir los bucles de retrabajo.

Esto puede capturarse en un campo 'close_notes' cuando una prueba falla, o en un campo personalizado dedicado 'rework_reason'. Consulte la documentación de ServiceNow DevOps.

Este atributo vincula un elemento de desarrollo a un lanzamiento planificado específico, como 'Version 2.3' o 'Q4 2023 Release'. Es un elemento clave para la gestión de proyectos y la planificación de lanzamientos.

Para el Process Mining, este atributo es crucial para el dashboard 'Release Plan Adherence Monitoring'. Al comparar las fechas de finalización reales con las fechas de lanzamiento planificadas, los equipos pueden medir el cumplimiento del cronograma, identificar elementos en riesgo de no alcanzar un lanzamiento y analizar las causas de los retrasos en los lanzamientos. Proporciona un vínculo directo entre el proceso de desarrollo de bajo nivel y los objetivos de negocio de alto nivel.

Conecta el trabajo de desarrollo con versiones específicas, lo que permite analizar la adhesión al cronograma y el impacto de los retrasos del proceso en los plazos de lanzamiento.

Esta información se almacena típicamente en un campo 'release' o 'planned_release', a menudo haciendo referencia a una tabla de gestión de lanzamientos en ServiceNow. Consulte la documentación de ServiceNow DevOps.