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

L’élément de développement sert d’identifiant de cas principal et représente une unité de travail distincte suivie dans le processus. Il relie toutes les activités associées à cet élément, de sa conception initiale et sa planification jusqu’au développement, aux tests et au déploiement.

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 de visualiser les flux du processus, de calculer les temps de cycle totaux et de repérer les variantes du processus propres à chaque fonctionnalité ou correction de bug. Chaque événement du journal doit être associé à un élément de développement pour établir une cartographie cohérente du processus.

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

Il s’agit généralement de la clé primaire des tables qui gèrent les stories, les bugs ou les tâches, comme les tables « rm_story », « rm_bug » ou « task » dans ServiceNow.

Cet attribut indique la date et l’heure d’enregistrement de chaque activité du cycle de développement. Il est indispensable pour classer les événements par ordre chronologique et effectuer toutes les analyses temporelles.

Dans le Process Mining, l’heure de début sert à calculer les durées entre les activités, à repérer les temps d’attente et à mesurer le temps de cycle global du processus. Elle est essentielle aux Dashboards qui analysent les performances, comme l’analyse du temps de cycle de bout en bout du SDLC, et au calcul d’indicateurs clés tels que le délai de revue du code.

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

Généralement présent dans les champs d’horodatage générés par le système, comme « sys_updated_on » ou « sys_created_on », dans la piste d’audit ou les tables de tâches.

Cet attribut indique le nom de chaque étape importante ou tâche accomplie au cours du cycle de développement logiciel. Ces activités constituent les étapes successives du processus, de la création au déploiement.

L’analyse de leur séquence et de leur fréquence est au cœur du Process Mining. Elle permet de cartographier le processus, de repérer les goulots d’étranglement entre les étapes et de mettre en évidence les écarts par rapport au processus SDLC standard ou les variantes inefficaces. La liste des activités définies comprend les principales étapes de conception, de développement, de test et de déploiement.

Il définit les étapes de la cartographie du processus et permet d’analyser son déroulement, de repérer les goulots d’étranglement et de détecter les écarts par rapport au SDLC standard.

Cet attribut 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 passage du champ « state » à « 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 à chaque événement.

Cet horodatage est essentiel pour connaître l’actualité de l’analyse. Il indique aux utilisateurs à quel point les résultats sur le processus sont récents et aide à planifier l’actualisation des données. Son affichage dans les Dashboards donne du contexte à tous les indicateurs et visualisations, afin que les décisions reposent sur des données à jour.

Il indique si les données sont récentes et permet aux utilisateurs de savoir à quel point l’analyse du processus est à jour.

Cet horodatage est généré et ajouté lors de l’extraction des données. Il indique le moment où l’extraction a été effectuée.

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

Même si cette valeur peut sembler fixe, préciser le système source est essentiel à la gouvernance des données et dans les environnements où des données issues de plusieurs systèmes, comme Jira ou Azure DevOps, peuvent être regroupées. Cela clarifie la provenance 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 à préserver 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 à ajouter lors de l’extraction et de la transformation des données.

Cet attribut identifie la personne chargée d’exécuter une tâche ou une activité précise. Sa valeur peut changer au fil des étapes et des équipes traversées par l’élément de développement.

Cet attribut est essentiel pour analyser l’affectation des ressources, la charge de travail et les transferts entre personnes ou équipes. Il alimente directement le Dashboard « Developer Workload and Handoffs » et l’indicateur « Activity Volume per Developer ». Le suivi de ses changements permet de mesurer les délais de transfert et de repérer les difficultés de collaboration entre développeurs ou entre les équipes de développement et d’assurance qualité.

Cet attribut est indispensable aux analyses liées aux ressources, notamment à la répartition de la charge de travail, à l’efficacité des transferts et au repérage des tendances de performance propres à chaque équipe.

Cette information est généralement stockée dans le champ « assigned_to » des tables de tâches de ServiceNow.

Cet attribut indique l’état officiel de l’élément de développement dans ServiceNow. Les activités correspondent aux étapes du processus déduites des données, tandis que l’état représente l’étape formelle enregistrée dans le 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 simplifiées du processus, à un niveau général. Par exemple, l’analyse du temps passé dans chaque état offre un autre éclairage sur les goulots d’étranglement que l’analyse du temps écoulé entre les activités. Elle permet également de repérer les éléments bloqués ou résolus.

Indique l’état officiel d’un élément de travail dans le système. Il sert souvent de source pour déduire les activités et peut être utilisé pour valider les données et analyser les états à un niveau général.

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 indique l’équipe à laquelle un élément de travail est affecté, par exemple « Développeurs frontend », « Services backend » ou « Équipe d’assurance qualité ». Au fil de son avancement, l’élément de travail passe souvent d’un groupe d’affectation à un autre.

Le suivi du groupe d’affectation est essentiel pour comprendre la collaboration entre équipes et les transferts de travail. Il aide à repérer les retards systémiques qui surviennent lorsqu’un travail passe d’une équipe à une autre. Cet attribut permet d’analyser les performances et la charge de travail de chaque équipe, ainsi que de déterminer lesquelles créent des goulots d’étranglement dans le flux global.

Indique quelle équipe est responsable du travail et permet d’analyser les performances et la charge de travail des équipes, ainsi que l’efficacité des transferts entre elles.

Cette information est enregistrée dans le champ « assignment_group », un champ standard des tables liées aux tâches dans ServiceNow.

Cet attribut classe le travail de développement selon la partie du système concernée. Il peut s’agir d’un microservice, 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 « Component-Specific Bottleneck Insights » et l’indicateur « Avg Stage Duration by Component » s’appuient sur cet attribut pour déterminer si certaines parties du 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 le plus nécessaires.

Permet de segmenter l’analyse par application ou composant afin de repérer les goulots d’étranglement et 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 base de données de gestion des configurations (CMDB), qui relie l’élément de travail à un enregistrement « cmdb_ci ». Consultez la documentation 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é est un axe essentiel de comparaison. Elle permet de filtrer la cartographie du processus pour vérifier si les éléments prioritaires suivent un parcours plus rapide ou différent. Elle est indispensable au Dashboard et à l’indicateur « High-Priority Feature Delivery Time », qui permettent de vérifier si les éléments essentiels sont réellement traités plus rapidement.

Permet de filtrer et de comparer les processus selon leur niveau de priorité, afin de vérifier si les éléments 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.

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

Cet indicateur est essentiel pour quantifier et visualiser les reprises. Il contribue directement au Dashboard « Rework and Rejection Flow Analysis » et sert à calculer l’indicateur « Rework Rate after Testing ». Les analystes peuvent ainsi filtrer facilement ces événements et étudier leur fréquence, leurs causes et leur incidence sur le temps de cycle global.

Cet indicateur facilite la mesure et l’analyse des reprises. Il aide à évaluer la qualité du processus et à repérer les causes profondes du travail répété.

Cet attribut est calculé dans l’outil de Process Mining, qui analyse la séquence des activités de chaque cas pour repérer 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 élément de développement. Pour chaque cas, il est obtenu en calculant l’écart entre l’horodatage de la première activité et celui de la dernière.

Il s’agit d’un indicateur clé de performance pour l’ensemble du processus SDLC, qui contribue directement à l’indicateur « Average SDLC Cycle Time ». Il donne une mesure générale de la vitesse et de l’efficacité du processus. Son analyse dans le temps et selon différents critères, comme la priorité ou l’équipe, permet de suivre les effets des initiatives d’amélioration.

Représente la durée totale de bout en bout d’un élément de travail. C’est un indicateur clé de l’efficacité et de la vitesse globales du processus.

Ce champ n’existe pas dans le 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 traitement d’un bogue critique peut suivre un parcours différent et plus rapide que le développement d’une nouvelle fonctionnalité.

L’analyse par type d’élément de travail permet de mieux comprendre les performances. Elle aide à répondre à des questions telles que : « Les bogues entraînent-ils davantage de reprises que les nouvelles fonctionnalités ? » ou « Notre temps de cycle pour réduire la dette technique est-il acceptable ? ». Cette segmentation apporte un éclairage plus précis qu’une vue unique du processus, appliquée à tous les types de travail.

Distingue les différents types de travail, comme les fonctionnalités et les bogues, qui peuvent suivre des parcours, avoir des priorités et présenter des durées prévues différentes.

Cette information peut être déterminée à 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 enregistre le résultat d’un déploiement dans un environnement donné. Il est essentiel pour comprendre la fiabilité et la stabilité du processus de livraison.

Cet attribut est indispensable au Dashboard « Deployment Success and Failure Trends » et à l’indicateur « Deployment Failure Rate ». En analysant la fréquence et l’évolution des échecs de déploiement, les organisations peuvent repérer les problèmes sous-jacents liés aux tests, à l’infrastructure ou à la coordination des livraisons. Elles peuvent ainsi concentrer leurs efforts sur l’amélioration de la qualité et de la fiabilité de la livraison logicielle.

Mesure directement la réussite des activités de déploiement. Cette mesure est essentielle pour calculer le taux d’échec des déploiements et analyser la stabilité des livraisons.

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

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

Dans le Process Mining, disposer des heures de début et de fin permet de calculer précisément la durée de traitement des activités et de la distinguer du temps d’attente entre les activités. Vous pouvez ainsi 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.

Permet de calculer précisément la durée de traitement d’une activité et de distinguer le temps consacré au travail du temps passé en attente.

Cette valeur peut devoir être calculée. Elle peut correspondre à l’heure de début de l’activité suivante ou provenir d’un champ distinct « end date », s’il existe dans le système source.

Cet attribut relie directement un élément de développement à la modification de code correspondante dans le dépôt de code source, par exemple Git. Il est enregistré lorsqu’une activité « Code Committed » a lieu.

En Process Mining, l’ID de commit enrichit l’analyse en reliant les données de processus aux données d’ingénierie. Les analystes peuvent ainsi remonter d’un déploiement problématique à la modification de code précise, ou mettre en relation les mesures de complexité du code et les temps de cycle de développement. Cela apporte un niveau d’analyse des causes profondes plus détaillé et plus technique.

Relie l’événement du processus à une modification de code précise. Vous pouvez ainsi approfondir l’analyse des causes profondes en mettant en relation les indicateurs du processus et les détails du code.

Cette information est recueillie grâce aux intégrations ServiceNow DevOps avec des systèmes de gestion du code source comme Git ou SVN. Les données se trouvent dans des tables associées à l’élément de développement.

Lorsqu’un élément échoue aux tests d’assurance qualité ou aux tests d’acceptation utilisateur (UAT), cet attribut en indique la raison. Il peut s’agir d’un type de bogue précis, d’une mauvaise compréhension des exigences ou d’un problème d’environnement.

Cette information apporte un contexte essentiel au Dashboard « Rework and Rejection Flow Analysis ». Au-delà du simple constat de reprises, les analystes peuvent en comprendre les causes. Ils peuvent alors cibler les améliorations, par exemple en précisant les exigences, en renforçant les tests unitaires ou en stabilisant les environnements de test, afin de réduire le taux global de reprises.

Précise les raisons des reprises et permet de cibler les améliorations du processus pour renforcer la qualité et réduire les boucles de reprise.

Cette information peut être enregistrée dans le champ « close_notes » en cas d’échec d’un test, ou dans un champ personnalisé « rework_reason ». Consultez la documentation ServiceNow DevOps.

Cet attribut associe un élément de développement à une livraison prévue précise, par exemple « Version 2.3 » ou « Livraison du T4 2023 ». Il joue un rôle important dans la gestion de projet et la planification des livraisons.

En Process Mining, cet attribut est essentiel au Dashboard « Release Plan Adherence Monitoring ». En comparant les dates réelles d’achèvement aux dates de livraison prévues, les équipes peuvent mesurer le respect du calendrier, repérer les éléments susceptibles de manquer une livraison et analyser les causes des retards. Il établit un lien direct entre le processus de développement au quotidien et les objectifs généraux de l’entreprise.

Relie le travail de développement à des livraisons précises afin d’analyser le respect du calendrier et l’incidence des retards du processus sur les échéances de livraison.

Cette information est généralement enregistrée dans un champ « release » ou « planned_release », qui fait souvent référence à une table de gestion des livraisons dans ServiceNow. Consultez la documentation ServiceNow DevOps.