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

L’heure de début de l’événement indique la date et l’heure exactes auxquelles une activité a commencé. Elle établit l’ordre chronologique de tous les événements d’un même cas, ce qui est indispensable pour reconstituer fidèlement le flux du processus.

Les horodatages sont à la base de toutes les analyses de Process Mining fondées sur le temps. Ils servent à calculer des indicateurs clés, comme les temps de cycle, les temps d’attente et les durées de traitement entre les activités. Leur analyse permet de repérer les goulots d’étranglement, de mesurer l’efficacité du processus et de comprendre la durée des différentes étapes du cycle de vie du développement. Par exemple, le délai entre « Code soumis à la revue » et « Revue de code terminée » peut révéler des retards dans le processus de revue.

Cet horodatage est indispensable pour remettre les événements dans le bon ordre et calculer tous les indicateurs temporels, comme le temps de cycle et les goulots d’étranglement.

Disponible dans les journaux d’événements, les pistes d’audit ou les tables d’historique qui consignent 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 correspond à un élément de travail distinct, comme un récit utilisateur, une tâche ou la correction d’un bogue, depuis sa création jusqu’à sa résolution ou son déploiement final.

Dans une analyse de Process Mining, cet attribut est indispensable pour reconstituer le parcours de bout en bout de chaque élément de travail. Il permet à l’outil de relier toutes les activités associées, comme « Développement commencé », « Revue de code terminée » et « Déployé en production », afin de former un flux de processus cohérent. L’analyse du cycle de vie de chaque élément de développement permet de repérer les variations, les retards et les boucles de reprise propres à certains éléments.

Il s’agit de l’identifiant de cas fondamental, nécessaire pour suivre le cycle de vie complet de chaque élément de travail de développement, du début à la fin.

On le trouve généralement dans les principales tables de suivi des éléments de travail ou des anomalies d’un système de gestion du développement logiciel.

Le nom de l’activité décrit une étape précise ou un changement de statut dans le processus de développement. Ces activités constituent les nœuds de la carte du processus et représentent des jalons clés, comme « Élément approuvé pour le développement », « Code soumis à la revue » ou « Tests d’assurance qualité terminés ».

Cet attribut est essentiel pour visualiser le flux du processus et comprendre l’ordre des événements. En analysant les différentes activités, les équipes peuvent repérer les parcours les plus fréquents, détecter les écarts du processus et mesurer le temps passé à chaque étape. Il sert de base à l’analyse des goulots d’étranglement, à la détection des reprises et à la vérification de la conformité à un modèle de processus cible.

Il définit les étapes du processus et permet de visualiser et d’analyser le flux de travail de développement.

Il est souvent tiré 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 de dernière mise à jour des données indique la date et l’heure de leur extraction ou actualisation la plus récente depuis le système source. Il renseigne clairement sur leur fraîcheur et leur pertinence.

Cette information est essentielle pour s’assurer que les analyses et les Dashboards reposent sur des données à jour. Les parties prenantes peuvent vérifier d’un coup d’œil la date de mise à jour de la vue du processus, ce qui renforce leur confiance dans les analyses obtenues. Il s’agit d’une métadonnée importante pour gérer les pipelines de données et planifier leur actualisation.

Indique si les données sont à jour, afin que l’analyse reste pertinente et disponible au bon moment 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 des données (ETL).

L’attribut du 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. Il est particulièrement utile lorsque plusieurs outils de développement sont utilisés, par exemple Jira pour le suivi des anomalies et GitLab pour la gestion du code source.

Dans une analyse, préciser le système source facilite la validation des données et apporte un contexte utile. Cela permet de comparer les processus gérés dans différents systèmes et de s’assurer que les données sont interprétées correctement, car les noms de champs et les conventions de processus peuvent varier d’un système à l’autre. Cet attribut peut également servir à limiter l’analyse aux données d’un outil donné.

Il précise l’origine des données, ce qui est essentiel pour les valider et mener des analyses portant sur plusieurs systèmes intégrés.

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

L’heure de fin de l’événement marque la fin d’une activité. De nombreuses étapes de processus sont enregistrées comme des événements instantanés, dont les heures de début et de fin sont identiques. Certaines activités ont toutefois une durée mesurable. Par exemple, une activité « Revue de code » peut avoir une heure de début et une heure de fin distinctes.

Cet attribut est essentiel pour calculer le temps de traitement actif de certaines tâches et le distinguer du temps d’inactivité ou d’attente. En comparant la durée entre l’heure de début et l’heure de fin de l’événement, les analystes peuvent mesurer le temps consacré aux activités qui créent de la valeur. Cette analyse détaillée de l’utilisation des ressources permet également de repérer les tâches qui mobilisent le plus de temps de travail actif.

Permet de calculer le temps de traitement actif de chaque activité, de le distinguer du temps d’attente et de mieux comprendre le temps de travail consacré.

Cette valeur figure dans les journaux d’événements ou peut être calculée à partir de l’horodatage de l’activité suivante dans la séquence pour le même élément de travail.

Cet attribut désigne l’équipe, la cellule ou le groupe chargé de livrer l’élément de développement. Dans les grandes organisations, le travail est souvent réparti entre plusieurs équipes spécialisées, par exemple « Frontend », « Backend », « Mobile » ou « Plateforme ».

L’analyse par nom d’équipe permet de comparer les performances et de partager les bonnes pratiques entre équipes. Elle aide à répondre à des questions telles que « Quelle équipe a le temps de cycle le plus court ? » ou « Une équipe connaît-elle davantage de reprises que les autres ? ». Cette analyse peut mettre en évidence des différences de flux de travail, de compétences ou de disponibilité des ressources qui influent sur les performances globales de livraison, et ainsi orienter les améliorations du processus.

Permet de comparer les performances des équipes, de repérer les bonnes pratiques et de déterminer les points à améliorer.

Souvent associé à l’utilisateur affecté ou indiqué directement dans le dossier du projet ou de l’élément de travail.

Le nom du projet permet de regrouper les éléments de travail associés à un produit, une initiative ou une base de code. Les pratiques de développement et les temps de cycle peuvent varier considérablement d’un projet à l’autre, par exemple entre un système ancien et une nouvelle application créée de zéro.

Cet attribut permet d’agréger les données à un niveau global et de comparer les processus de développement dans différentes parties de l’organisation. En filtrant l’analyse par projet, les responsables peuvent évaluer l’état et l’efficacité de chaque initiative de développement. Cet attribut est également essentiel pour comprendre le lien entre les performances du processus et le contexte propre au projet, notamment son environnement technique.

Permet de segmenter l’analyse des processus par produit ou initiative et de repérer les écarts de performance liés au contexte du projet.

Champ standard de l’élément de travail ou du dossier de l’incident, ou nom du dépôt dans des systèmes comme Git.

Cet attribut désigne la personne ou le groupe chargé de réaliser l’étape en cours ou l’ensemble de l’élément de travail. La personne affectée peut changer plusieurs fois au cours du cycle de vie, au gré des transferts entre différents rôles, par exemple entre développeurs, testeurs QA et réviseurs.

L’analyse de l’attribut « Personne affectée » permet de comprendre la charge de travail des équipes, l’efficacité des transferts et les modes de collaboration. Elle permet de filtrer la cartographie du processus pour examiner le travail d’une personne ou d’une équipe et repérer les goulots d’étranglement liés aux ressources. L’analyse des réseaux sociaux fondée sur les transferts entre personnes affectées peut révéler des lacunes de communication ou des structures de collaboration trop complexes.

Permet d’analyser la charge de travail des ressources, la fréquence des transferts et les modes de collaboration, afin d’améliorer l’efficacité de l’équipe.

Cette information figure dans l’élément de travail ou le dossier de l’incident, souvent dans l’historique de l’élément ou le journal d’audit.

L’attribut de priorité indique le degré d’urgence métier ou technique d’un élément de travail. Il prend généralement des valeurs telles que « Élevée », « Moyenne » ou « Faible » et aide les équipes à déterminer le travail à traiter en priorité.

Dans le Process Mining, la priorité constitue une dimension d’analyse utile. Les équipes peuvent vérifier si les éléments prioritaires sont effectivement traités plus rapidement que les éléments de faible priorité. La comparaison des temps de cycle selon les niveaux de priorité permet de vérifier si le processus respecte les priorités métier. Si les éléments prioritaires subissent souvent des retards, cela peut révéler des problèmes de planification, d’affectation des ressources ou de conception du flux de travail.

Permet de vérifier si les travaux prioritaires avancent plus vite dans le processus et de repérer les goulots d’étranglement qui touchent particulièrement les éléments critiques.

Champ standard de l’élément de travail ou du dossier de l’incident dans la plupart des systèmes de gestion du développement.

Le statut de l’élément de développement indique l’état d’un élément de travail à un moment donné. Alors que le nom de l’activité décrit l’événement de changement de statut, cet attribut indique l’état lui-même. Il peut donc servir à analyser l’état du travail au moment où un événement s’est produit.

Cet attribut sert souvent à créer le nom de l’activité, mais il apporte aussi des informations complémentaires. Par exemple, l’analyse du champ de statut permet de mesurer le temps passé dans un état donné, comme « Bloqué » ou « En attente de revue ». Comprendre le temps passé dans des états improductifs est essentiel pour repérer les retards systémiques et améliorer l’efficacité du flux.

Permet d’analyser le temps passé dans les différents états et de repérer les retards ainsi que le temps passé dans des statuts sans création de valeur, comme « Bloqué ».

Disponible comme champ principal de l’élément de travail ou du dossier de l’incident, et consigné dans son historique.

Cet attribut catégorise la nature du travail effectué. Les différents types d’éléments de travail suivent souvent des parcours de processus distincts et répondent à des attentes différentes en matière de performance. Par exemple, un bug peut nécessiter un correctif urgent, tandis qu’une fonctionnalité suit un cycle standard de développement et de test.

Cet attribut permet aux analystes de comparer les flux de processus et les performances selon le type de travail. Il aide à répondre à des questions telles que « Le processus de correction des bugs est-il plus rapide que celui de développement des fonctionnalités ? » ou « Les éléments liés à la dette technique font-ils l’objet de davantage de reprises ? ». Il s’agit d’une dimension fondamentale pour segmenter les données et obtenir des analyses plus précises et concrètes.

Permet de comparer les processus et les performances selon les catégories de travail et de repérer les inefficacités propres à certains types de développement.

Champ standard de l’élément de travail ou du dossier de l’incident dans la plupart des systèmes de gestion du développement.

L’attribut « Créateur » désigne la personne à l’origine de l’élément de travail. Il peut s’agir d’un responsable produit qui crée un récit utilisateur, d’un testeur QA qui signale un bug ou d’un agent du service client qui rapporte un problème rencontré par un client.

L’analyse des créateurs des éléments de travail permet de comprendre l’origine des demandes. Par exemple, un grand nombre de bugs signalés par les utilisateurs finaux peut indiquer des problèmes de qualité dans les versions récentes. La mise en relation du créateur avec les reprises ou les retards ultérieurs permet aussi d’évaluer la clarté et la qualité des exigences initiales.

Permet d’identifier les personnes à l’origine du travail et d’analyser les sources de la demande, des bugs ou des demandes de fonctionnalités.

Champ standard, tel que « Déclarant » ou « Auteur », dans l’enregistrement initial de création d’un élément de travail.

La gravité et la priorité sont deux notions distinctes : la gravité mesure l’incidence technique d’un problème, tandis que la priorité indique l’urgence de sa correction. Par exemple, une faute de frappe sur une page rarement consultée peut être de faible gravité et de faible priorité, tandis qu’un problème critique de corruption des données sera de gravité et de priorité élevées.

Cet attribut est essentiel à l’analyse de la qualité, notamment pour étudier les processus de correction des bugs. Il permet aux équipes de vérifier si elles traitent efficacement les problèmes les plus graves en premier. L’analyse du temps de cycle selon le niveau de gravité aide les organisations à s’assurer que les problèmes critiques du système sont résolus rapidement afin de limiter leurs conséquences pour les clients.

Permet d’analyser la capacité de l’équipe à traiter les problèmes selon leur incidence technique et de vérifier que les problèmes critiques sont résolus rapidement.

Champ standard des systèmes de gestion du développement, en particulier pour les éléments de travail de type « Bug » ou « Incident ».

L’indicateur de reprise est un attribut booléen ou catégoriel dérivé qui signale les événements faisant partie d’un cycle de reprise. Il est généralement défini lorsque le flux de processus revient en arrière, par exemple de « Test QA » à « Développement en cours », ou lorsque des activités précises, comme « Reprise signalée lors du contrôle QA », se produisent.

Cet attribut est très utile pour analyser la qualité et l’efficacité. Il permet de calculer directement le taux de reprises et de repérer les étapes du processus qui en génèrent le plus. En filtrant les activités de reprise, les équipes peuvent rechercher les causes profondes des problèmes de qualité qui n’ont pas été détectés plus tôt. La réduction des reprises est un levier important pour accélérer le développement et améliorer la qualité du produit.

Quantifie directement les reprises, ce qui permet aux équipes d’en mesurer la fréquence, d’en analyser les causes et de suivre l’évolution de la qualité.

Généralement calculé lors de la transformation des données, en repérant les retours en arrière dans le flux de processus ou les noms d’activités associés à des échecs.

L’attribut « Version prévue » associe un élément de développement à un calendrier de livraison ou à une version précise. Il sert souvent à regrouper des fonctionnalités et des correctifs en vue d’un déploiement coordonné.

L’analyse par version prévue aide à évaluer la prévisibilité et la fiabilité du processus de livraison. Elle permet de suivre le taux de livraisons dans les délais en comparant la version prévue à la date réelle de déploiement. Elle aide également à gérer le périmètre et à comprendre le flux de travail destiné à une version donnée, tout en mettant en évidence les risques et les retards susceptibles de compromettre le calendrier de livraison.

Relie le travail de développement aux calendriers de livraison et permet d’analyser le taux de livraisons dans les délais ainsi que la prévisibilité des versions.

Champ standard, tel que « Version de correction », « Version cible » ou « Chemin d’itération », dans les outils de planification agile et de développement.