Votre template de données pour le cycle de développement logiciel

Le Development Item sert d’identifiant principal du cas et représente une unité de travail distincte suivie dans le système. Il relie toutes les activités, de la conception et de la planification initiales au développement, aux tests et au déploiement de cet élément.

Dans une analyse de Process Mining, cet attribut est fondamental pour reconstituer le parcours complet de chaque élément de travail. Il permet de visualiser les flux de processus, de calculer les temps de cycle totaux et d’identifier les variantes de processus pour chaque fonctionnalité ou correction de bug. Chaque événement du journal doit être associé à un Development Item afin de construire une cartographie cohérente du processus.

Il s’agit de l’identifiant central qui relie toutes les activités de développement associées au sein d’une même instance de processus, ce qui permet d’analyser le cycle de vie complet de chaque élément de travail.

Cet identifiant correspond généralement à la clé primaire des tables qui gèrent les stories, les bugs ou les tâches, telles que les tables « rm_story », « rm_bug » ou « task » dans ServiceNow.

Cet attribut fournit la date et l’heure d’enregistrement de chaque activité du cycle de vie du développement. Il est indispensable pour classer les événements dans l’ordre chronologique et réaliser toutes les analyses fondées sur le temps.

Dans le Process Mining, l’heure de début sert à calculer les durées entre les activités, à identifier les temps d’attente et à mesurer le temps de cycle global du processus. Elle constitue un élément essentiel des Dashboards qui analysent la performance, comme « SDLC End-to-End Cycle Time Analysis », ainsi que du calcul d’indicateurs clés tels que « Code Review Lead Time ».

Cet horodatage est indispensable pour classer correctement les événements et calculer tous les indicateurs de performance, notamment les temps de cycle, les durées et les temps d’attente.

Il se trouve généralement dans des champs d’horodatage générés par le système, tels que « sys_updated_on » ou « sys_created_on », issus de la piste d’audit ou des tables de tâches.

Cet attribut enregistre le nom de chaque jalon ou tâche achevé dans le cycle de développement logiciel. Ces activités constituent les étapes successives du processus, de la création au déploiement.

L’analyse de la séquence et de la fréquence de ces activités est la fonction principale du Process Mining. Elle permet de construire la carte du processus, d’identifier les goulots d’étranglement entre les étapes et de mettre en évidence les variations non conformes ou inefficaces du processus. L’ensemble défini d’activités comprend des étapes clés telles que la conception, le développement, les tests et le déploiement.

Il définit les étapes de la carte du processus et permet d’analyser le déroulement du processus, d’identifier les goulots d’étranglement et de repérer les écarts par rapport au cycle de développement logiciel standard.

Il est généralement obtenu en associant les changements de statut, les enregistrements d’événements ou les entrées de la piste d’audit à une liste normalisée de noms d’activités. Par exemple, le changement d’un champ « state » vers « In Progress » peut être associé à « Development Started ».

Cet attribut indique la date de la dernière extraction ou mise à jour du jeu de données depuis ServiceNow DevOps. Il s’applique à l’ensemble du jeu de données, et non à des événements individuels.

Cet horodatage est essentiel pour évaluer l’actualité de l’analyse. Il indique aux utilisateurs dans quelle mesure les analyses du processus sont à jour et facilite la planification des actualisations de données. L’affichage de cette information dans les Dashboards fournit un contexte à tous les indicateurs et visualisations, afin que les décisions reposent sur des données récentes.

Il fournit un contexte important sur l’actualité des données et permet aux utilisateurs de comprendre dans quelle mesure l’analyse du processus est à jour.

Cet horodatage est généré et ajouté lors de l’extraction des données afin d’enregistrer le moment où celle-ci a été exécutée.

Cet attribut précise le système d’origine des données d’événements. Pour ce processus, sa valeur sera toujours « ServiceNow DevOps ».

Même s’il peut sembler statique, l’indication explicite du système source est essentielle à la gouvernance des données et aux environnements dans lesquels les données peuvent être fusionnées depuis plusieurs systèmes, tels que Jira ou Azure DevOps. Elle garantit la traçabilité de l’origine des données et facilite le diagnostic des problèmes de qualité ou d’extraction.

Il garantit la traçabilité des données et contribue au maintien de leur intégrité, en particulier lorsque des données provenant de plusieurs outils de développement sont intégrées.

Il s’agit d’une valeur statique qui doit être ajoutée lors de l’extraction et de la transformation des données.

Cet attribut identifie la personne responsable de l’exécution d’une tâche ou d’une activité précise. Il est dynamique et peut changer lorsque l’élément de développement passe d’une étape ou d’une équipe à une autre.

Cet attribut est essentiel pour analyser la répartition des ressources, la charge de travail et les transferts. Il alimente directement le Dashboard « Charge de travail et transferts entre développeurs » ainsi que le KPI « Volume d’activités par développeur ». Le suivi des changements de ce champ permet de mesurer les temps de transfert et d’identifier les goulots d’étranglement de la collaboration entre développeurs ou entre les équipes de développement et d’assurance qualité.

Il est indispensable aux analyses fondées sur les ressources, notamment la répartition de la charge de travail, l’efficacité des transferts et l’identification des tendances de performance propres à chaque équipe.

Ces informations sont généralement stockées dans le champ « assigned_to » des tables liées aux tâches dans ServiceNow.

Cet attribut indique le statut officiel de l’élément de développement dans ServiceNow. Alors que les activités correspondent aux étapes du processus, l’état représente l’étape formelle du flux de travail du système.

L’état est souvent la source à partir de laquelle les activités sont déduites. Il peut servir à valider les données et à créer des vues plus simples et de haut niveau du processus. Par exemple, l’analyse du temps passé dans chaque état peut donner une autre vision des goulots d’étranglement que l’analyse du temps écoulé entre les activités. Cet attribut est également utile pour repérer les éléments bloqués ou résolus.

Il fournit le statut officiel d’un élément de travail dans le système. Il sert souvent de source pour dériver les activités et peut être utilisé à des fins de validation et d’analyse globale des statuts.

Il s’agit d’un champ standard, généralement nommé « state » ou « stage », dans les tables liées aux tâches de ServiceNow.

Cet attribut identifie l’équipe affectée à un élément de travail, comme « Développeurs frontend », « Services backend » ou « Équipe d’assurance qualité ». À mesure que l’élément de travail progresse, il est souvent transféré entre différents groupes d’affectation.

Le suivi du groupe d’affectation est essentiel pour comprendre la collaboration entre les équipes et les transferts de responsabilité. Il permet d’identifier les retards systémiques qui surviennent lorsque le travail passe d’une équipe à une autre. Cet attribut facilite l’analyse des performances et de la charge de travail au niveau des équipes, ainsi que l’identification des équipes qui constituent des goulots d’étranglement dans le flux global.

Il indique quelle équipe est responsable du travail et permet d’analyser les performances des équipes, l’équilibre de la charge de travail et l’efficacité des transferts entre équipes.

Ces informations sont stockées dans le champ « assignment_group », un champ standard des tables liées aux tâches dans ServiceNow.

Cet attribut catégorise le travail de développement selon la partie du système concernée. Il peut s’agir d’un microservice précis, d’un composant d’interface utilisateur ou d’une application backend.

La segmentation du processus par module ou composant est essentielle pour repérer les goulots d’étranglement localisés. Le Dashboard « Analyses des goulots d’étranglement par composant » et le KPI « Durée moyenne des étapes par composant » s’appuient sur cet attribut pour déterminer si certaines parties de la base de code sont régulièrement associées à des cycles de développement plus longs, à davantage de reprises ou à des échecs de déploiement plus fréquents. Vous pouvez ainsi concentrer les efforts d’amélioration là où ils sont les plus nécessaires.

Permet de segmenter l’analyse par application ou par composant afin d’isoler les goulots d’étranglement ou les problèmes de qualité propres à certaines parties du système.

Il s’agit souvent d’un champ personnalisé ou d’une référence à la Configuration Management Database (CMDB), qui relie l’élément de travail à un enregistrement « cmdb_ci ». Consultez la documentation de ServiceNow DevOps.

Cet attribut classe les éléments de développement selon leur degré d’urgence métier. Les niveaux de priorité aident les équipes à se concentrer sur les tâches les plus importantes et servent souvent à gérer les SLA et les attentes des parties prenantes.

Dans le Process Mining, la priorité constitue une dimension essentielle de l’analyse comparative. Elle permet de filtrer la cartographie du processus afin de vérifier si les éléments hautement prioritaires suivent un parcours plus rapide ou différent. Elle est indispensable au Dashboard et au KPI « High-Priority Feature Delivery Time », qui permettent de vérifier si les éléments importants sont effectivement traités en priorité.

Elle permet de filtrer et de comparer les processus selon différents niveaux de priorité, afin de vérifier si les éléments hautement prioritaires sont traités plus rapidement et plus efficacement.

Il s’agit d’un champ standard, souvent nommé « priority », dans les tables liées aux tâches de ServiceNow.

Il s’agit d’un attribut dérivé qui identifie les activités survenant après le retour du processus à une étape antérieure. Par exemple, si une activité « Development Started » survient après une activité « QA Testing Completed » pour le même élément, elle est marquée comme une reprise.

Cet indicateur est essentiel pour quantifier et visualiser les reprises. Il alimente directement le Dashboard « Rework and Rejection Flow Analysis » et sert à calculer le KPI « Rework Rate after Testing ». En marquant ces événements, les analystes peuvent facilement filtrer et analyser la fréquence, les causes et l’impact des reprises sur le temps de cycle global.

Cet indicateur facilite la quantification et l’analyse des reprises, aide à mesurer la qualité du processus et permet d’identifier les causes profondes du travail répété.

Cet attribut est calculé dans l’outil de Process Mining en analysant la séquence des activités pour chaque cas afin de détecter les retours en arrière dans le flux du processus.

Cet attribut est un indicateur calculé qui représente la durée de bout en bout d’un Development Item. Il est calculé en déterminant la différence entre l’horodatage de la toute première activité et celui de la toute dernière activité pour chaque cas.

Il s’agit d’un indicateur clé de performance du processus SDLC dans son ensemble, qui alimente directement le KPI « Average SDLC Cycle Time ». Il fournit une mesure globale de la vitesse et de l’efficacité du processus. Son analyse au fil du temps et selon différentes dimensions, telles que la priorité ou l’équipe, permet de suivre les effets des initiatives d’amélioration du processus.

Il représente la durée totale de bout en bout d’un élément de travail et constitue un indicateur important de l’efficacité et de la vitesse globales du processus.

Il ne s’agit pas d’un champ du système source. Il est calculé dans l’outil de Process Mining en soustrayant le StartTime minimum du StartTime maximum pour chaque CaseId.

Cet attribut distingue les différents types de travail qui suivent le processus SDLC. Par exemple, le processus de correction d’un bug critique peut différer de celui du développement d’une nouvelle fonctionnalité et être plus rapide.

L’analyse du processus selon le type d’élément permet de mieux comprendre les performances. Elle aide à répondre à des questions telles que : « Les bugs présentent-ils un taux de reprise supérieur à celui des nouvelles fonctionnalités ? » ou « Le temps de cycle consacré à la réduction de la dette technique est-il acceptable ? » Cette segmentation fournit une vision plus précise qu’une vue unique du processus applicable à tous les cas.

Il distingue les différents types de travail, comme les fonctionnalités et les bugs, qui peuvent suivre des parcours, avoir des priorités et présenter des durées attendues différents.

Il peut être déterminé à partir de la table source de l’enregistrement, par exemple « rm_story » ou « rm_bug », ou d’un champ « type » dans une table de tâches générique.

Cet attribut fournit la date et l’heure d’achèvement de chaque activité du cycle de vie du développement. Il est particulièrement utile pour les activités dont la durée peut être mesurée, telles que « Code Review Performed » ou « QA Testing ».

Dans le Process Mining, la présence d’une heure de début et d’une heure de fin permet de calculer précisément le temps de traitement des activités et de le distinguer du temps d’attente entre les activités. Il devient ainsi possible de déterminer si les retards sont dus à des tâches longues ou à l’attente de ressources. Pour les événements considérés comme instantanés, tels que « Build Triggered », l’heure de fin peut être identique à l’heure de début.

Il permet de calculer précisément le temps de traitement d’une activité et de distinguer le temps consacré au travail du temps d’attente.

Cet attribut peut nécessiter une dérivation. Il peut correspondre à l’heure de début de l’activité suivante ou provenir d’un champ distinct « end date », s’il est disponible dans le système source.

Cet attribut établit un lien direct entre un Development Item et la modification précise du code dans le dépôt de code source, tel que Git. Il est enregistré lorsqu’une activité « Code Committed » se produit.

Dans le Process Mining, le Commit ID enrichit l’analyse en reliant les données du processus aux données d’ingénierie. Il permet de remonter d’un déploiement problématique jusqu’à la modification exacte du code ou de mettre en relation les indicateurs de complexité du code avec les temps de cycle du développement. Il apporte ainsi un niveau d’analyse des causes profondes plus détaillé et plus technique.

Il relie l’événement du processus à une modification précise du code et permet d’approfondir l’analyse des causes profondes en mettant en relation les indicateurs du processus avec les détails du code.

Il est capturé par les intégrations de ServiceNow DevOps avec des systèmes de gestion du code source tels que Git ou SVN. Les données se trouvent dans des tables associées au Development Item.

Lorsqu’un élément échoue aux tests QA ou UAT, cet attribut enregistre la raison de l’échec. Il peut s’agir d’une catégorie de bug précise, d’une mauvaise compréhension des exigences ou d’un problème d’environnement.

Ces informations fournissent un contexte essentiel au Dashboard « Rework and Rejection Flow Analysis ». Au lieu de constater simplement qu’une reprise a eu lieu, les analystes peuvent en comprendre la cause. Ils peuvent ainsi cibler les améliorations, par exemple en renforçant la définition des exigences, les tests unitaires ou la stabilité des environnements de test, afin de réduire le taux global de reprise.

Il fournit des informations qualitatives sur les causes des reprises et permet de cibler les améliorations du processus afin d’accroître la qualité et de réduire les boucles de reprise.

Il peut être enregistré dans un champ « close_notes » lorsqu’un test échoue ou dans un champ personnalisé dédié « rework_reason ». Consultez la documentation de ServiceNow DevOps.

Cet attribut enregistre le résultat d’un déploiement vers un environnement précis. Il fournit une information essentielle pour comprendre la fiabilité et la stabilité du processus de release.

Cet attribut est indispensable au Dashboard « Deployment Success and Failure Trends » et au KPI « Deployment Failure Rate ». L’analyse de la fréquence et des tendances des échecs de déploiement permet aux organisations d’identifier les problèmes sous-jacents liés aux tests, à l’infrastructure ou à la coordination des releases. Elle aide à concentrer les efforts sur l’amélioration de la qualité et de la fiabilité de la livraison logicielle.

Il mesure directement la réussite des activités de déploiement, ce qui est essentiel pour calculer le taux d’échec des déploiements et analyser la stabilité des releases.

Ce statut est généralement enregistré dans les tâches de suivi des déploiements ou dans les enregistrements d’exécution des pipelines CI/CD intégrés à ServiceNow DevOps.

Cet attribut relie un Development Item à une release planifiée précise, telle que « Version 2.3 » ou « Q4 2023 Release ». Il constitue un élément important de la gestion de projet et de la planification des releases.

Dans le Process Mining, cet attribut est essentiel au Dashboard « Release Plan Adherence Monitoring ». En comparant les dates d’achèvement réelles aux dates de release prévues, les équipes peuvent mesurer le respect du calendrier, identifier les éléments susceptibles de ne pas être livrés à temps et analyser les causes des retards de release. Il établit un lien direct entre le processus de développement détaillé et les objectifs métier globaux.

Il relie le travail de développement à des releases précises et permet d’analyser le respect du calendrier ainsi que l’impact des retards du processus sur les échéances de release.

Ces informations sont généralement stockées dans un champ « release » ou « planned_release », qui fait souvent référence à une table de gestion des releases dans ServiceNow. Consultez la documentation de ServiceNow DevOps.