Votre modèle de données pour le cycle de vie du développement logiciel

L'Heure de début de l'événement marque la date et l'heure exactes du début d'une activité. Elle fournit l'ordre chronologique de tous les événements au sein d'un même cas, ce qui est indispensable pour reconstituer le flux de processus.

Les horodatages sont le fondement de toute analyse Process Mining basée sur le temps. Ils sont utilisés pour calculer des indicateurs clés de performance tels que les temps de cycle, les temps d'attente et les temps de traitement entre les activités. L'analyse des horodatages aide à identifier les points de blocage, à mesurer l'efficacité des processus et à comprendre la durée des différentes étapes du cycle de vie du développement. Par exemple, le temps entre 'Code soumis à la révision' et 'Revue de code terminée' peut révéler des retards dans le processus de revue.

Cet horodatage est indispensable pour ordonner correctement les événements et calculer toutes les métriques temporelles, telles que le temps de cycle et les points de blocage.

Disponible dans les journaux d'événements, les pistes d'audit ou les tables d'historique qui enregistrent les modifications apportées aux éléments de travail de développement.

L'ID de l'élément de développement est la clé primaire qui identifie de manière unique chaque instance de cas tout au long du cycle de vie du développement logiciel. Chaque ID représente un élément de travail distinct, comme une user story, une tâche ou une correction de bug, de sa création à sa résolution finale ou son déploiement.

Dans l'analyse Process Mining, cet attribut est indispensable pour reconstruire le parcours complet de chaque élément de travail. Il permet à l'outil de lier toutes les activités connexes, telles que 'Développement commencé', 'Revue de code terminée' et 'Déployé en production', en un flux de processus cohérent. L'analyse du cycle de vie des éléments de développement individuels aide à identifier les variations, les retards et les boucles de reprise associées à des éléments de travail spécifiques.

C'est l'identifiant de cas clé requis pour tracer le cycle de vie complet de chaque élément de travail de développement du début à la fin.

Généralement disponible dans les tables principales d'éléments de travail ou de suivi des problèmes d'un système de gestion du développement logiciel.

Le Nom d'Activité décrit une étape spécifique ou un changement de statut dans le processus de développement. Ces activités forment les nœuds de la cartographie de processus, représentant des jalons clés comme 'Élément approuvé pour le développement', 'Code soumis à la révision' ou 'Tests QA terminés'.

Cet attribut est impératif pour visualiser le flux de processus et comprendre la séquence des événements. En analysant les différentes activités, les équipes peuvent identifier les chemins les plus courants, découvrir les écarts de processus et mesurer le temps passé à différentes étapes. Il sert de base à l'analyse des points de blocage, de la détection du reprises et de la vérification de la conformité par rapport à un modèle de processus cible.

Il définit les étapes du processus, pour visualiser et l'analyse du workflow de développement.

Souvent dérivé des journaux de changement de statut, des flux d'événements ou des tables d'historique d'audit associés aux éléments de travail de développement.

L'attribut Dernière mise à jour des données enregistre la date et l'heure de la dernière extraction ou mise à jour des données depuis le système source. Cela fournit une indication claire de la l'actualité et de la pertinence des données.

Cette information est fondamentale pour garantir que les analyses et les tableau de bords sont basés sur des informations actuelles. Les parties prenantes peuvent voir en un coup d'œil à quel point la vue du processus est à jour, ce qui renforce la confiance dans les informations dérivées. C'est une métadonnée clé pour gérer les pipelines de données et planifier les actualisations de données.

Indique la la réactualisation des données, garantissant que l'analyse est opportune et pertinente pour la prise de décision.

Cette valeur est généralement générée et stockée par le pipeline d'extraction, de transformation et de chargement (ETL) des données.

L'attribut Système Source identifie l'application ou la plateforme d'origine où les données du cycle de vie du développement ont été enregistrées. Ceci est particulièrement utile dans les environnements où plusieurs outils de développement sont utilisés, par exemple, Jira pour le suivi des problèmes et GitLab pour la gestion du code source.

En analyse, spécifier le système source aide à la validation des données et fournit un contexte pour les données de processus. Cela permet une analyse comparative entre les processus gérés dans différents systèmes et assure une interprétation correcte des données, car les noms de champs et les conventions de processus peuvent varier d'un système à l'autre. Il peut également être utilisé pour filtrer l'analyse sur l'ensemble de données d'un outil spécifique.

Fournit le contexte sur l'origine des données, ce qui est impératif pour la validation des données et pour les analyses impliquant plusieurs systèmes intégrés.

Il s'agit généralement d'une valeur statique ajoutée lors du processus d'extraction de données pour identifier l'origine des enregistrements.

Cet attribut identifie l'individu ou le groupe responsable de l'achèvement de l'étape actuelle ou de l'élément de travail global. L'assigné peut changer plusieurs fois tout au long du cycle de vie, reflétant les transferts entre différents rôles comme les développeurs, les testeurs QA et les relecteurs.

L'analyse de l'attribut 'Assigné à' est indispensablele pour comprendre la charge de travail de l'équipe, l'efficacité des transferts et les schémas de collaboration. Elle permet de filtrer la carte de processus pour visualiser le travail d'une personne ou d'une équipe spécifique, aidant ainsi à identifier les points de blocage liés aux ressources. L'analyse des réseaux sociaux basée sur les transferts entre assignés peut révéler des lacunes de communication ou des structures de collaboration trop complexes.

Il permet l'analyse de la charge de travail des ressources, de la fréquence des transferts et des schémas de collaboration, aidant à optimiser l'efficacité de l'équipe.

Trouvé dans l'enregistrement de l'élément de travail ou du problème, souvent suivi dans l'historique ou le journal d'audit de l'élément.

L'Heure de Fin de l'Événement marque la conclusion d'une activité. Alors que de nombreuses étapes de processus sont enregistrées comme des événements instantanés où les heures de début et de fin sont identiques, certaines activités ont une durée mesurable. Par exemple, une activité de 'Revue de code' peut avoir une heure de début et de fin distinctes.

Cet attribut est indispensable pour calculer le temps de traitement actif de tâches spécifiques, le distinguant du temps d'inactivité ou d'attente. En comparant la durée entre l'Heure de début de l'événement et l'Heure de Fin de l'Événement, les analystes peuvent mesurer l'effort consacré aux activités à valeur ajoutée. Cela permet une analyse plus granulairesre de l'utilisation des ressources et aide à identifier les tâches qui prennent le plus de temps de travail actif.

Permet le calcul du temps de traitement actif pour les activités individuelles, le séparant du temps d'attente et offrant une vue plus claire de l'effort.

Peut être trouvé dans les journaux d'événements ou dérivé en prenant l'horodatage de l'activité suivante dans la séquence pour le même élément de travail.

Cet attribut identifie l'équipe, la squad ou le groupe spécifique responsable de la livraison de l'élément de développement. Dans les grandes organisations, le travail est souvent réparti entre plusieurs équipes spécialisées comme 'Frontend', 'Backend', 'Mobile' ou 'Plateforme'.

L'analyse par Nom d'Équipe permet la comparaison des performances et le partage des meilleures pratiques entre les équipes. Elle aide à répondre à des questions comme 'Quelle équipe a le temps de cycle le plus court ?' ou 'Une équipe connaît-elle plus de reprises que d'autres ?'. Cette analyse peut révéler des différences dans les workflows, les compétences ou la disponibilité des ressources qui impactent la performance globale de livraison, offrant des opportunités d'améliorations ciblées des processus.

Permet l'analyse comparative des performances entre différentes équipes, aidant à identifier les meilleures pratiques et les domaines d'amélioration.

Souvent associé à l'utilisateur assigné ou comme un champ direct sur l'enregistrement du projet ou de l'élément de travail.

L'attribut Nom du Projet fournit un contexte en regroupant les éléments de travail appartenant à un produit, une initiative ou une base de code spécifique. Les pratiques de développement et les temps de cycle peuvent varier considérablement entre les projets, par exemple, un système hérité versus une nouvelle application 'greenfield'.

Cet attribut permet une agrégation et une comparaison de haut niveau des processus de développement à travers les différentes parties de l'organisation. En filtrant l'analyse par projet, les managers peuvent évaluer la santé et l'efficacité de chaque effort de développement. Il est également essentiel pour comprendre comment la performance des processus est liée au contexte spécifique et à l'environnement technique d'un projet.

Permet de segmenter l'analyse des processus par produit ou initiative, révélant les différences de performance liées au contexte du projet.

Un champ standard sur l'enregistrement de l'élément de travail ou du problème, ou le nom du dépôt dans des systèmes comme Git.

L'attribut Priorité indique l'urgence métier ou technique d'un élément de travail. Il est généralement défini sur des valeurs comme 'Élevée', 'Moyenne' ou 'Faible' et aide les équipes à décider sur quoi travailler ensuite.

Dans le Process Mining, la priorité est une dimension d'analyse puissante. Elle permet aux équipes de vérifier si les éléments à haute priorité sont réellement traités plus rapidement que ceux à faible priorité. La comparaison des temps de cycle entre les différents niveaux de priorité peut révéler si le processus respecte les priorités métier. Si les éléments à haute priorité sont fréquemment retardés, cela peut indiquer des problèmes de planification, d'allocation des ressources ou de conception du workflow.

Aide à vérifier si le travail de haute priorité progresse plus rapidement dans le processus et identifie les points de blocage qui affectent de manière disproportionnée les éléments critiques.

Un champ standard sur l'enregistrement de l'élément de travail ou du problème dans la plupart des systèmes de gestion du développement.

Le Statut de l'élément de développement représente l'état d'un élément de travail à un moment précis. Alors que le Nom d'Activité capture l'événement de changement de statut, cet attribut capture l'état lui-même. Ceci peut être utile pour analyser l'état du travail au moment où un événement s'est produit.

Cet attribut est souvent utilisé pour créer le Nom d'Activité mais peut fournir un contexte supplémentaire. Par exemple, l'analyse du champ de statut permet une analyse de la durée pendant laquelle les éléments restent dans un état particulier, tel que 'Bloqué' ou 'En attente de révision'. Comprendre le temps passé dans des états non productifs est impératif pour identifier les retards systémiques et améliorer l'efficacité du flux.

Il permet l'analyse du temps passé dans différents états, aidant à identifier les retards et le temps passé dans des statuts sans valeur ajoutée comme 'Bloqué'.

Disponible en tant que champ principal sur l'enregistrement de l'élément de travail ou du problème et est suivi dans son journal d'historique.

Cet attribut catégorise la nature du travail effectué. Différents types d'éléments de travail suivent souvent des chemins de processus distincts et ont des attentes de performance différentes. Par exemple, un 'Bug' peut nécessiter un processus de correctif rapide, tandis qu'une 'Fonctionnalité' suit un cycle de développement et de test standard.

En utilisant cet attribut, les analystes peuvent comparer les flux de processus et les performances pour différents types de travail. Cela aide à répondre à des questions comme 'Notre processus de correction de bugs est-il plus rapide que notre processus de développement de fonctionnalités ?' ou 'Les éléments de dette technique subissent-ils plus de reprises ?'. C'est une dimension clée pour segmenter les données afin d'obtenir des enseignements plus spécifiques et exploitables.

Permet de comparer les processus et les performances entre différentes catégories de travail, révélant les inefficacités spécifiques à certains types de développement.

Un champ standard sur l'enregistrement de l'élément de travail ou du problème dans la plupart des systèmes de gestion du développement.

L'attribut Créateur identifie la personne qui a initié l'élément de travail. Il peut s'agir d'un chef de produit créant une user story, d'un testeur QA enregistrant un bug, ou d'un agent du service client signalant un problème client.

L'analyse du créateur des éléments de travail peut fournir des informations sur les sources de travail. Par exemple, un volume élevé de bugs signalés par les utilisateurs finaux pourrait indiquer des problèmes de qualité dans les releases récentes. Il peut également être utilisé pour analyser la clarté et la qualité des exigences initiales en corrélant le créateur avec les reprises ou les retards en aval.

Aide à identifier les initiateurs du travail, qui peuvent être analysés pour comprendre les sources de demande, de bugs ou de demandes de fonctionnalités.

Un champ standard comme 'Reporter' ou 'Author' sur l'enregistrement de création initial d'un élément de travail.

L'Indicateur de Retravail est un attribut booléen ou catégoriel dérivé qui signale les événements faisant partie d'un cycle de reprises. Il est généralement identifié lorsque le flux de processus revient en arrière, par exemple, de 'Tests QA' à 'Développement en cours', ou lorsque des activités de reprises spécifiques comme 'Retravail identifié en QA' se produisent.

Cet attribut est extrêmement précieux pour l'analyse de la qualité et de l'efficacité. Il permet le calcul direct des taux de reprise et met en évidence les parties du processus qui génèrent le plus de reprises. En filtrant les activités de reprises, les équipes peuvent effectuer une analyse des causes profondes pour comprendre pourquoi les problèmes de qualité ne sont pas détectés plus tôt. La réduction du reprises est un levier clé pour améliorer à la fois la vitesse de développement et la qualité du produit.

Quantifie directement les reprises, permettant aux équipes de mesurer sa fréquence, d'analyser ses causes et de suivre les améliorations de qualité au fil du temps.

Généralement dérivé lors de la transformation des données en identifiant les boucles arrière dans le flux de processus ou les noms d'activités spécifiques liées aux échecs.

L'attribut Version Planifiée associe un élément de développement à un calendrier de livraison ou une version spécifique. Il est fréquemment utilisé dans la planification des releases pour regrouper des fonctionnalités et des correctifs en vue d'un déploiement coordonné.

L'analyse par Version Planifiée permet d'évaluer la prévisibilité et la fiabilité du processus de release. Elle offre la possibilité de suivre les taux de paiement à temps en comparant la version planifiée avec la date de déploiement réelle. En outre, elle aide à gérer la portée et à comprendre le flux de travail destiné à une release spécifique, mettant en évidence les risques ou retards potentiels qui pourraient affecter le calendrier de livraison.

Connecte le travail de développement aux calendriers de livraison, permettant l'analyse des taux de paiement à temps et de la prévisibilité des releases.

Un champ standard tel que 'Fix Version', 'Target Release' ou 'Iteration Path' dans les outils de planification et de développement agile.

La sévérité est distincte de la priorité : elle mesure l'impact technique d'un problème, tandis que la priorité mesure l'urgence de sa résolution. Par exemple, une faute de frappe sur une page rarement visitée pourrait avoir une faible sévérité et une faible priorité, alors qu'un problème critique de corruption de données aurait une sévérité élevée et une priorité élevée.

Cet attribut est impératif pour l'analyse de la qualité, en particulier lors de l'analyse des processus de correction de bugs. Il permet aux équipes d'évaluer si elles traitent efficacement les problèmes les plus graves en premier. En analysant le temps de cycle pour différents niveaux de sévérité, les organisations peuvent s'assurer que les problèmes système critiques sont résolus rapidement pour minimiser l'impact sur le client.

Permet d'analyser l'efficacité avec laquelle l'équipe résout les problèmes en fonction de leur impact technique, garantissant que les problèmes critiques sont résolus rapidement.

Un champ standard, particulièrement pour les éléments de travail de type 'Bug' ou 'Incident', dans les systèmes de gestion du développement.