Tableaux de bord, rapports et extractions

Le portail par défaut Runtime Intelligence Service fournit des tableaux de bord de synthèse et détaillés, afin de présenter l’utilisation relative de l’application par utilisateur, par application et version, par site et sur l’ensemble des fonctionnalités.

Des filtres permettent d’explorer facilement des comportements spécifiques d’instances d’applications et d’utilisateurs individuels. Les champs de données personnalisés peuvent refléter une multitude de choses, allant des termes de recherche les plus fréquents ou du temps moyen nécessaire pour répondre à un appel à un service distant, jusqu’à la fourniture de données d’exception, y compris les exceptions non gérées, gérées et utilisant le mot-clé throw.

Un reporting et des tableaux de bord performants peuvent raccourcir de manière spectaculaire les délais d’identification des dépendances. Une fonctionnalité commune peut être implémentée sur plusieurs applications (même avec du code différent), un utilisateur spécifique peut exécuter plusieurs applications, un logiciel peut être impacté outre mesure par une carte son particulière ou une version de CLR, un comportement d’application peut être lié à des données utilisateur, et certaines de ces variables ou toutes peuvent être la clé pour l’identification des causes premières derrière les rapports d’exceptions. Il n’y a pas de pénurie de variables.

Le tableau de bord de synthèse de la figure 3 présente le type d’éléments décisionnels d’exécution pouvant être générés dans Visual Studio au moyen de Dotfuscator Community Edition. Les données présentent les modèles d’utilisation du monde réel d’une application ALM CodePlex, Scrum Sprint Monitor.

Développée de manière indépendante et utilisant Dotfuscator Community Edition pour l’instrumentation, Scrum Sprint Monitor, selon la page de projet, « fournit à l’équipe Agile un statut automatique et toujours à jour du Sprint courant, tant au niveau individuel que de l’équipe. » La figure 3 et la figure 4 (voir Club Abonnés) présentent des éléments décisionnels d’exécution réels générés pour Scrum Sprint Monitor. L’accès à l’application, à son code source et à ses données d’exécution est ouvert via codeplex.com. Ces statistiques montrent les données d’application, de fonctionnalités et d’utilisation qui fournissent à l’équipe de développement des informations sur l’activité et les préférences des utilisateurs, autant de connaissances clés pour le propriétaire du produit sur toute la durée de vie de cette application.

L’application des données d’exécution peut être encore étendue en la combinant avec d’autres données pertinentes. Les données d’utilisation des fonctionnalités, par exemple, peuvent être exportées et intégrées avec des données de couverture du code, afin d’identifier visuellement des écarts potentiels entre les plans de tests et les modèles d’utilisation dans le monde réel. L’intégration de CodePlex citée dans la figure 3 et la figure 4 constitue un bon exemple.

Le site CodePlex utilise l’API RESTful afin d’extraire les données d’exécution pour les projets CodePlex au moyen des éléments décisionnels d’exécution et expose ces données à l’intérieur des portails de projets. Cette approche fournit à la communauté CodePlex un modèle cohérent pour les développeurs et utilisateurs sur tous les projets CodePlex.