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

L'élément de développement (Development Item) sert d'identifiant de dossier principal, représentant une unité de travail distincte suivie. Il relie toutes les activités, de la conception et planification initiales jusqu'au développement, test et déploiement pour cet élément spécifique.

Dans l'analyse par process mining, cet attribut est indispensable pour reconstituer le parcours complet de chaque élément de travail. Il facilite la visualisation des flux de processus, le calcul des temps de cycle totaux et l'identification des variantes de processus pour les fonctionnalités individuelles ou les corrections de bugs. Chaque événement du journal doit être associé à un élément de développement pour construire une carte de processus cohérente.

C'est l'identifiant principal qui connecte toutes les activités de développement connexes en une seule instance de processus, permettant d'analyser le cycle de vie complet de chaque élément de travail.

Cet identifiant est généralement la clé primaire des tables gérant 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 l'ordonnancement chronologique des événements et pour toutes les analyses temporelles.

En process mining, l'heure de début est utilisée pour calculer les durées entre les activités, identifier les temps d'attente et mesurer le temps de cycle global du processus. C'est un élément clé pour les dashboards analysant les performances, tels que l'analyse du temps de cycle complet du SDLC, et pour le calcul d'indicateurs de performance clés comme le Code Review Lead Time.

Cet horodatage est indispensable pour ordonner correctement les événements et calculer toutes les métriques de performance, y compris les temps de cycle, les durées et les temps d'attente.

Généralement disponible dans les champs d'horodatage générés par le système comme 'sys_updated_on' ou 'sys_created_on' des pistes d'audit ou des tables de tâches.

Cet attribut enregistre le nom de chaque jalon ou tâche achevée dans le cycle de vie du développement logiciel. Ces activités constituent les étapes séquentielles 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 la construction de la cartographie des processus, aide à identifier les points de blocage entre les étapes et met en évidence les variations de processus non conformes ou inefficaces. L'ensemble défini d'activités comprend des étapes clés comme la conception, le développement, les tests et le déploiement.

Il définit les étapes de la cartographie des processus, permettant l'analyse des flux, l'identification des points de blocage et la détection des écarts par rapport au cycle de vie de développement logiciel (SDLC) standard.

Ceci est généralement dérivé en mappant les changements de statut, les enregistrements d'événements ou les entrées de piste d'audit à une liste standardisée de noms d'activités. Par exemple, un champ 'state' passant à 'In Progress' pourrait correspondre à 'Development Started'.

Cet attribut enregistre la dernière date d'extraction ou de mise à jour du dataset depuis ServiceNow DevOps. Il s'applique à l'ensemble du dataset plutôt qu'aux événements individuels.

Cet horodatage est indispensable à comprendre la récence de l'analyse. Il informe les utilisateurs de l'actualité des analyses de processus et aide à planifier les rafraîchissements de données. L'affichage de cette information sur les dashboards contextualise toutes les métriques et visualisations, garantissant que les décisions sont prises sur la base de données actualisées.

Fournit un contexte essentiel sur la réactualisation des données, garantissant que les utilisateurs comprennent le degré de mise à jour de l'analyse des processus.

Cet horodatage est généré et ajouté pendant le processus d'extraction des données, enregistrant le moment où l'extraction a été exécutée.

Cet attribut spécifie le système d'origine pour les données d'événement. Pour ce processus, il sera toujours 'ServiceNow DevOps'.

Bien qu'il puisse sembler statique, l'inclusion explicite du système source est indispensablele pour la gouvernance des données et dans les environnements où les données pourraient être fusionnées à partir de plusieurs systèmes, tels que Jira ou Azure DevOps. Elle assure la clarté sur la provenance des données et aide à diagnostiquer les problèmes de qualité ou d'extraction des données.

Assure la traçabilité des données et est indispensable pour maintenir l'intégrité des données, en particulier lors de l'intégration de données provenant de plusieurs outils de développement.

Il s'agit d'une valeur statique qui doit être ajoutée pendant le processus d'extraction et de transformation des données.

Cet attribut identifie la personne responsable de l'exécution d'une tâche ou activité spécifique. Il est dynamique et peut changer à mesure que l'élément de développement se déplace entre les différentes étapes et équipes.

Cet attribut est impératif pour analyser l'allocation des ressources, la charge de travail et les transferts. Il prend directement en charge le tableau de bord « Charge de travail et transferts des développeurs » et le KPI 'Activity Volume per Developer'. En suivant les changements dans ce champ, il est possible de mesurer les temps de transfert et d'identifier les points de blocage de collaboration entre les développeurs ou entre les équipes de développement et d'assurance qualité.

Ceci est indispensable pour l'analyse basée sur les ressources, y compris la distribution de la charge de travail, l'efficacité des transferts et l'identification des modèles de performance spécifiques aux équipes.

Cette information est généralement stockée dans le champ 'assigned_to' sur les tables liées aux tâches dans ServiceNow.

Ceci est un attribut dérivé qui identifie les activités se produisant après qu'un processus a bouclé vers une étape antérieure. Par exemple, si une activité 'Development Started' se produit après une activité 'QA Testing Completed' pour le même élément, elle est signalée comme une reprise de travail.

Ce flag est indispensable pour quantifier et visualiser les reprises. Il supporte directement le tableau de bord 'Rework and Rejection Flow Analysis' et est utilisé pour calculer le KPI 'Rework Rate after Testing'. En signalant 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.

Ce flag facilite la quantification et l'analyse des reprises, aidant à mesurer la qualité des processus et à identifier les causes profondes des travaux répétés.

Cet attribut est calculé dans l'outil de process mining en analysant la séquence d'activités pour chaque cas afin de détecter les mouvements rétrogrades dans le flux de processus.

Cet attribut reflète le statut officiel de l'élément de développement dans ServiceNow. Alors que les activités sont des étapes de processus dérivées, l'état représente la phase formelle dans le workflow du système.

L'état est souvent la source à partir de laquelle les activités sont dérivées. Il peut être utilisé pour la validation des données et pour créer des vues plus simples et de haut niveau du processus. Par exemple, l'analyse du temps passé dans chaque état peut fournir une vue différente des points de blocage par rapport à l'analyse du temps entre les activités. Il est également utile pour identifier les éléments bloqués ou résolus.

Fournit le statut système officiel d'un élément de travail, qui est souvent la source pour dériver des activités et peut être utilisé pour la validation et l'analyse de statut de haut niveau.

Ceci est un champ standard, généralement nommé 'state' ou 'stage', sur les tables liées aux tâches dans ServiceNow.

Cet attribut identifie l'équipe assignée à un élément de travail, tel que 'Frontend Developers', 'Backend Services' ou 'QA Team'. À mesure qu'un élément de travail progresse, il est souvent transféré entre différents groupes d'affectation.

Le suivi du groupe d'affectation est indispensable pour comprendre la collaboration interfonctionnelle et les transferts. Il aide à identifier les retards systémiques qui se produisent lorsque le travail passe d'une équipe à une autre. Cet attribut prend en charge l'analyse des performances au niveau de l'équipe, de la charge de travail et l'identification des équipes qui sont des points de blocage dans le flux global.

Suit l'équipe responsable du travail, permettant l'analyse de la performance de l'équipe, l'équilibrage de la charge de travail et l'efficacité des transferts entre les équipes.

Cette information est stockée dans le champ 'assignment_group', qui est un champ standard sur les tables liées aux tâches dans ServiceNow.

Cet attribut catégorise le travail de développement par la partie du système qu'il impacte. Il peut s'agir d'un microservice spécifique, d'un composant d'interface utilisateur ou d'une application backend.

Segmenter le processus par module ou composant est impératif pour identifier les points de blocage localisés. Le tableau de bord 'Component-Specific Bottleneck Insights' et le KPI 'Avg Stage Duration by Component' s'appuient sur cet attribut pour déterminer si certaines parties du code sont systématiquement associées à des cycles de développement plus longs, à des taux de reprise plus élevés ou à des échecs de déploiement plus fréquents. Cela aide à concentrer les efforts d'amélioration là où ils sont le plus nécessaires.

Permet de segmenter l'analyse par application ou composant, aidant à isoler les points de blocage ou les problèmes de qualité spécifiques à certaines parties du système.

Ceci est souvent un champ personnalisé ou une référence à la base de données de gestion de configuration (CMDB), liant l'élément de travail à un enregistrement 'cmdb_ci'. Consultez la documentation de ServiceNow DevOps.

Cet attribut catégorise les éléments de développement en fonction de leur urgence métier. Les niveaux de priorité aident les équipes à se concentrer sur les tâches les plus critiques et sont souvent utilisés pour gérer les accords de niveau de service (SLA) et les attentes des parties prenantes.

En process mining, la priorité est une dimension clé pour l'analyse comparative. Elle permet de filtrer la carte de processus pour voir si les éléments à haute priorité suivent un chemin plus rapide ou différent. Elle est indispensablele pour le tableau de bord et le KPI 'High-Priority Feature Delivery Time', aidant à valider si les éléments critiques sont réellement traités en priorité.

Permet de filtrer et de comparer les processus pour différents niveaux de priorité, aidant à vérifier si les éléments à haute priorité sont traités plus rapidement et plus efficacement.

Ceci est un champ standard, souvent nommé 'priority', sur les tables liées aux tâches dans ServiceNow.

Cet attribut est une métrique calculée représentant la durée complet pour un seul élément de développement. Il est calculé en trouvant la différence entre l'horodatage de la toute première activité et de la toute dernière activité pour chaque cas.

C'est un indicateur de performance clé pour l'ensemble du processus SDLC, supportant directement le KPI 'Average SDLC Cycle Time'. Il fournit une mesure de haut niveau de la vélocité et de l'efficacité du processus. L'analyse de cette métrique au fil du temps et selon différentes dimensions, comme la priorité ou l'équipe, aide à suivre l'impact des initiatives d'amélioration des processus.

Représente la durée totale complet d'un élément de travail, une métrique clé pour mesurer l'efficacité et la vélocité globale des processus.

Ce n'est pas un champ 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 parcourent le processus SDLC. Par exemple, le processus de correction d'un bug critique pourrait être différent et plus rapide que celui de développement d'une nouvelle fonctionnalité.

L'analyse du processus basée sur le type d'élément de travail permet une compréhension plus précise des performances. Elle aide à répondre à des questions comme : « Les bugs ont-ils un taux de reprise plus élevé que les nouvelles fonctionnalités ? » ou « Notre temps de cycle pour la réduction de la dette technique est-il acceptable ? ». Cette segmentation fournit des insights plus approfondis qu'une vue de processus unique et standardisée.

Distingue les différents types de travail, comme les fonctionnalités et les bugs, qui peuvent avoir des chemins de processus, des priorités et des durées attendues différents.

Cela peut être déterminé à partir de la table source de l'enregistrement (par ex., 'rm_story' vs 'rm_bug') ou d'un champ 'type' sur une table de tâches générique.

Cet attribut fournit la date et l'heure de l'achèvement de chaque activité du cycle de vie du développement. Il est particulièrement utile pour les activités ayant une durée mesurable, telles que 'Code Review Performed' ou 'QA Testing'.

En process mining, disposer à la fois d'une heure de début et de fin permet un calcul précis des temps de traitement des activités, les distinguant du temps d'attente entre les activités. Cela aide à déterminer si les retards sont dus à des tâches longues ou à de longues attentes de ressources. Pour les événements considérés comme instantanés, comme 'Build Triggered', l'heure de fin peut être la même que l'heure de début.

Permet le calcul précis du temps de traitement des activités, ce qui aide à différencier le temps passé à travailler du temps passé à attendre.

Ceci peut nécessiter une dérivation. Il pourrait s'agir de l'horodatage de l'heure de début de l'activité suivante, ou il pourrait être obtenu à partir d'un champ 'end date' séparé s'il est disponibleble dans le système source.

Cet attribut fournit un lien direct entre un élément de développement et la modification de code spécifique dans le dépôt de code source, tel que Git. Il est capturé lorsqu'une activité 'Code Committed' se produit.

En process mining, l'ID de commit enrichit l'analyse en connectant les données de processus aux données d'ingénierie. Il permet aux analystes de retracer un déploiement problématique jusqu'au changement de code exact ou de corréler les métriques de complexité du code avec les temps de cycle de développement. Cela offre une couche d'analyse des causes profondes beaucoup plus approfondie et technique.

Relie l'événement de processus à un changement de code spécifique, permettant une analyse plus approfondie des causes profondes en corrélant les métriques de processus avec les détails au niveau du code.

Ceci est capturé par les intégrations ServiceNow DevOps avec les systèmes de gestion de code source comme Git ou SVN. Les données résident dans des tables liées à l'élément de développement.

Lorsqu'un élément échoue à l'AQ ou à l'UAT, cet attribut capture la raison de l'échec. Cela pourrait être une catégorie de bug spécifique, une mauvaise compréhension des exigences ou un problème d'environnement.

Cette information fournit un contexte critique pour le tableau de bord 'Rework and Rejection Flow Analysis'. Au lieu de simplement savoir qu'une reprise a eu lieu, les analystes peuvent comprendre pourquoi elle s'est produite. Cela permet des améliorations ciblées, telles qu'une meilleure définition des exigences, des tests unitaires améliorés ou des environnements de test plus stables, pour réduire le taux global de reprises.

Fournit des informations qualitatives sur les raisons des reprises de travail, permettant des améliorations ciblées des processus pour augmenter la qualité et réduire les boucles de reprises.

Ceci peut être capturé 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 spécifique. C'est une information cruciale pour comprendre la fiabilité et la stabilité du processus de publication.

Cet attribut est indispensable pour le tableau de bord 'Deployment Success and Failure Trends' et le KPI 'Deployment Failure Rate'. En analysant la fréquence et les tendances des échecs de déploiement, les organisations peuvent identifier les problèmes sous-jacents dans leurs tests, leur infrastructure ou leur coordination de publication. Il aide à concentrer les efforts sur l'amélioration de la qualité et de la fiabilité de la livraison logicielle.

Mesure directement le succès des activités de déploiement, ce qui est indispensable pour calculer le taux d'efficacité.x d'échec de déploiement et analyser la stabilité des publications.

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

Cet attribut relie un élément de développement à une publication planifiée spécifique, telle que 'Version 2.3' ou 'Q4 2023 Release'. Il est indispensable pour la gestion de projet et la planification des publications.

Pour le process mining, cet attribut est impératif pour le tableau de bord 'Release Plan Adherence Monitoring'. En comparant les dates d'achèvement réelles aux dates de publication prévues, les équipes peuvent mesurer l'adhérence au calendrier, identifier les éléments risquant de manquer une publication et analyser les causes des retards de publication. Il établit un lien direct entre le processus de développement de bas niveau et les objectifs commerciaux de haut niveau.

Relie le travail de développement à des publications spécifiques, permettant l'analyse du respect des délais et de l'impact des retards de processus sur les échéances de publication.

Cette information est généralement stockée dans un champ 'release' ou 'planned_release', faisant souvent référence à une table de gestion des publications dans ServiceNow. Consultez la documentation de ServiceNow DevOps.