Pour afficher l’article en anglais, activez la case d’option Anglais. Vous pouvez aussi afficher la version anglaise dans une fenêtre contextuelle en faisant glisser le pointeur de la souris sur le texte.
Traduction
Anglais

Analyse d'applications : ce que chaque développeur doit savoir

Sebastian Holst est chargé des stratégies produits/marchés chez PreEmptive Solutions et plus particulièrement de l'analyse des applications et de la sécurité. En plus de ses tâches de création de logiciels, Sebastian est membre actif d'organismes de normalisation dans l'industrie et l'informatique, tels que le W3C (World Wide Web Consortium), les comités MMA sur la confidentialité et l'analyse, il est également co-fondateur du Consortium de conformité. Sebastian tient également un blogspot Applications are people too, dans lequel il s'exprime sur les forces et les faiblesses des personnes, des programmes et de la culture. Pendant son temps libre, il développe des applications mobiles et collabore avec des étudiants pour les aider à en faire de même.

Juillet 2012

Sebastian Holst traite des objectifs et des avantages liés à l'analyse des applications.

Gestion du cycle de vie des applications, Visual Studio 2013, Team Foundation Server

Objectives

Requirements

Restrictions

Visual Studio 2012 and Application Analytics

Imaginez combien les développeurs seraient efficaces s'ils n'étaient pas obligés de deviner quelles fonctionnalités ont été utilisées et lesquelles peuvent être déconseillées ? Quel serait l'impact sur la satisfaction des utilisateurs si les données d'exception avec le contexte d'utilisation leur étaient remises avant qu'ils aient le temps de les réclamer ? Quel serait l'impact sur la qualité de vos logiciels si vos plans d'évaluation étaient alignés avec les véritables modèles d'utilisation et les préférences utilisateur dans l'environnement de production ? L'analyse des applications est la branche destinée à l'analyse, elle est conçue pour faire de ces scénarios une réalité ; pour répondre aux besoins des parties prenantes d'application en termes « d'intérêts égoïstes », par exemple : développement, test, directeurs de produit, opérations, etc.

Diagramme des cycles analytiques d'application

Figure 1 : l'analyse des applications améliore à la fois le développement et les opérations en fournissant un éclairage sur l'adoption d'application et le comportement d'utilisateur dans les plateformes de développement et d'opérations.

L'analyse des applications intègre les données d'utilisation de l'application, le logiciel d'analyse centré sur les applications et l'heuristique intégrée dans le développement et les opérations.

La diversité des solutions d'analyse est de nos jours pilotée par les clients. Par exemple, en analyse Web, le client vise surtout le marketing et la vente est le focus est donc sur les vues de page, les clics et les conversions. Les solutions d'analyse Web partagent ce qui suit :

  • Objectifs : monétisation des propriétés Web,

  • Spécifications : analyse des visiteurs, des impressions, des clics et des conversions et

  • Restrictions : respect des obligations en termes de confidentialité et de performances.

Dans le langage agile, l'analyse des applications englobe les solutions d'analyse où le client principal est une ou plusieurs « personas » de développement d'application qui partagent les mêmes objectifs, exigences et restrictions.

Les états du Manifeste agile : la « plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des logiciels à grande valeur ajoutée ». Dans ce contexte, le succès du développement peut uniquement être mesuré de façon précise là où les utilisateurs et leurs applications se retrouvent : « au point de rencontre ». L'analyse des applications fournit une preuve empirique de l'utilisation de l'application et du comportement de l'utilisateur final qui, lorsqu'il est correctement intégré dans un processus de développement fournit ce qui suit :

  • aperçu des besoins des utilisateurs ;

  • validation des priorités de développement ;

  • mesure des objectifs de la précision et de l'exhaustivité du plan de test.

Voici quelques exemples :

  • Le Programme d'amélioration de l'expérience utilisateur de Microsoft a été créé pour donner à tous les utilisateurs de Microsoft la possibilité de participer à la création et au développement de produits Microsoft. Ce programme collecte des informations sur la façon dont les programmes Microsoft sont utilisés en réalité.

Le Manifeste agile indique également « qu'un logiciel opérationnel est la principale mesure d'avancement ». La mission des opérations consiste à exploiter au mieux les applications actuelles, les futures itérations d'applications ne peuvent pas traiter immédiatement la stabilité, les performances, l'expérience de l'utilisateur, ou les problèmes de sécurité. L'analyse des applications, lorsqu'elle est correctement intégrée dans les opérations et la prise en charge, fournit ce qui suit :

  1. adoption d'application et mesures d'utilisation dans une infrastructure d'événements spécifique ;

  2. alertes d'incident de production à partir des exceptions d'application ;

  3. analyse de la productivité et adoption organisationnelle reliant les investissements d'application au ROI de l'entreprise.

Voici quelques exemples :

  • La solution PreEmptive Analytics Community Edition qui permet aux développeurs utilisant Microsoft Visual Studio 2012 Professional de créer leur propre programme d'amélioration du produit en permettant au développement et aux opérations d'identifier et de répondre rapidement aux exceptions d'application qui se produisent en production.

Étant donné ces objectifs, la valeur de l'analyse des applications est évidente, mais les détails peuvent la rendre difficile. La collecte, l'analyse et l'action sur les données de runtime de l'application soulèvent des défis uniques en termes de types de données à collecter et de métriques qui mesurent la réussite.

Les implémentations effectives d'analyse des applications doivent prendre en compte la diversité des applications actuelles et l'émergence des plateformes informatiques Cloud, mobiles et distribuées. Les spécifications d'analyse des applications suivantes montrent clairement pourquoi il ne faut jamais attendre des technologies d'analyse plus étroites qu'elles répondent entièrement aux objectifs de développement.

Les données de runtime qui proviennent d'une application sont généralement beaucoup plus complexes et hétérogènes que celles transmises à partir d'une page Web ou d'un portail.

Types de données

Télémétrie Runtime : diversité, sémantique et emplacement des données de runtime de l'application

Fonctionnalité

Une fonctionnalité de l'application n'est pas un clic. Une fonctionnalité peut couvrir une ou plusieurs méthodes, plusieurs composants intégrés, s'exécuter sur les surfaces de runtime et même être implémentée plusieurs fois dans différentes langues, par exemple Windows Presentation Foundation (WPF), Microsoft Silverlight et HTML5. La mesure de l'utilisation et des performances d'une étendue définie arbitrairement est requise pour surveiller des périphériques et des plateformes.

Données d'application

Une grande partie des applications actuelles est pilotée par les données et le comportement lui-même est encodé dans les données. En sachant quels modèles, flux de travail et autre contenu « moderne » sont traités peut s'avérer plus précieux que de savoir quel flux de travail ou moteur de rendu a traité ces données.

Session

Les informations de session peuvent être définies différemment dans un serveur d'applications, une session mobile, dans un navigateur ou être réparties dans tous les services précédents par un service basé sur le Cloud.

Événement

Les exceptions non gérées, les exceptions levées et interceptées, les performances inattendues ou un comportement utilisateur suspect peuvent tous constituer un « événement de production ».

Application

Les applications sont souvent composées de plusieurs composants : certains sur site et d'autres basés sur des services. Ces applications (et leurs composants) sont gérées à des cadences imprévisibles. Le calcul du flux de travail entre les applications distribuées et le rapprochement de cette activité dans le temps et entre les versions est une contrainte de l'analyse des applications.

Stack

Tandis que de nombreuses applications sont exécutées dans un bac à sable (sandbox), par exemple les applications mobiles, Windows Runtime, Microsoft Azure, de nombreuses autres disposent d'un accès complet au système d'exploitation et au système informatique sous-jacents. Le suivi de la résolution d'écran, des fabricants de puces et de la disponibilité du matériel est souvent essentiel pour comprendre l'expérience de l'utilisateur et le comportement de l'application.

Identité

L'identité d'un utilisateur peut être définie et suivie par ID de périphérique, adresse IP, informations d'identification de l'utilisateur, licence de logiciel etc. Les solutions d'analyse des applications doivent avoir la possibilité d'appliquer des stratégies de sécurité et de confidentialité au niveau du client et au niveau global. La garantie d'une gouvernance efficace des données précède l'analyse efficace des données de runtime résultantes.

Étant donnée la complexité, la diversité et la distribution des plateformes de production actuelles, il n'est plus possible de simuler une production. L'analyse des applications peut combler cet écart uniquement s'il existe une prise en charge complète des plateformes informatiques actuelles.

Catégories

Architectures et technologies de runtime : langues et plateformes existantes et émergentes

Architectures et surfaces

Les applications sont beaucoup plus qu'une simple couche de présentation et une séquence d'actions utilisateur. L'instrumentation doit couvrir le serveur client, les services Cloud (privés et publics), le servlet Web et les plateformes, les architectures et les surfaces mobiles.

Langues et runtimes

Les applications actuelles intègrent des composants managés, natifs et écrits en scripts notamment Microsoft .NET Framework, C++, Java et JavaScript.

Pour que l'analyse des applications ait un impact, des informations correctes doivent être fournies aux bons rôles, au bon moment et dans le bon contexte. Cela inclut l'intégration de la tâche d'instrumentation dans le processus de génération et de développement et le surfaçage d'analyse des applications dans les phases de développement, de tests, de déploiement et de gestion.

Organigramme affichant cinq phases en séquence

Figure 2 : cinq étapes fonctionnelles d'implémentation d'analyse des applications.

Phase de DevOps

Intégration d'IDE et de la gestion du cycle de vie des applications : rôle et scénarios pilotés par cas d'usage

1. Instrumentation

L'instrumentation est la logique dans une application qui crée les données d'exécution à analyser. Elle peut être codée par le biais d'une API (obligatoire pour les applications natives et écrites en scripts) ou après la compilation injectée dans les assemblys managés.

2. Génération et déploiement

Les applications peuvent être générées manuellement, dans le cadre d'un processus de génération continu et être automatisées pour prendre en charge des plateformes Cloud. La prise en charge des différents processus de fabrication et formats de charge utile est nécessaire pour garantir des déploiements efficaces et évolutifs.

3. Gestion des données de runtime

La gestion des données de runtime nécessite des contrôles d'échelle, de gouvernance et de sécurité. Les spécifications de gestion des données de runtime d'application sont considérablement déplacées dans les limites du secteur, du cas d'usage et juridictionnelles.

4. Publication de données de runtime

Les différentes parties prenantes nécessitent des présentations distinctes et une analyse. Les développeurs, les architectes, les propriétaires de produit et la branche d'activités de gestion apportent des points de vue et priorités aux mêmes données de runtime sous-jacentes. Les rapports, les tableaux de bord, l'exportation et l'accès par programmation sont tous généralement requis lorsque les cas d'usage étendent la planification de sprint, du support technique et de l'analyse des performances de l'entreprise.

5. Intégration

L'intégration de l'analyse des applications dans des plateformes de développement (par exemple, Visual Studio et TFS), des opérations (par exemple, directeur des opérations) et la gestion de la relation client (par exemple, Microsoft Dynamics par le biais de rapports) et la planification d'événements constituent les dernières étapes de la productivité de l'analyse des applications.

Le traitement ne peut pas être pire que la maladie. Pour l'analyse des applications, cela signifie que son inclusion dans le développement et les opérations ne peut pas engendrer plus de risques en termes de productivité, de performances, de sécurité ou d'expérience utilisateur. Étant donné les nombreuses formes et les nombreux rôles que les applications actuelles peuvent prendre, cette tâche est importante.

Gestion des risques

Restrictions : performances, stabilité, confidentialité, et complexité

Stabilité et performances

Collecte, mise en cache et transmission efficaces des données de runtime sur des périphériques sans pénalités en termes de performances (en cas de fonctionnement correct) sans impacter la stabilité de l'application ou de l'expérience de l'utilisateur si/quand un ou plusieurs aspects de la solution d'analyse échouent. Cela peut s'avérer particulièrement difficile quand il s'agit des dépendances particulières telles que l'autonomie des batteries, les plans de données, les caractéristiques de réseau…

Confidentialité et sécurité

Les applications de consommateurs, les applications interentreprises et les applications métier ont toutes leurs propres obligations en termes de sécurité et de protection des données. Ces obligations sont ensuite fragmentées par secteur et par juridiction. L'instrumentation, le transport et la gestion du contenu d'analyse des applications doivent pouvoir être extensibles et capables d'appliquer ces exigences au cas par cas.

Complexité

La complexité inclut le gaspillage et les risques et enfin la résistance à l'adoption. L'intégration dans les plateformes, les processus et les méthodologies existantes est une condition requise pour des implémentations effectives d'analyse des applications.

Visual Studio 2012 inclut PreEmptive Analytics pour TFS Community Edition (PA pour TFS CE), une solution d'analyse des applications qui surveille les exceptions et crée ou met à jour des éléments de travail à l'intérieur de Team Foundation Server (TFS) en fonction des seuils définis par l'utilisateur.

PA pour TFS CE est conçu pour suivre les exceptions non gérées dans les applications exécutant les environnements d'exécution .NET Framework et Java. Prise en charge des cinq étapes d'analyse des applications comme suit :

Phase de DevOps

PreEmptive Analytics pour TFS Community Edition

1. Instrumentation

L'instrumentation est effectuée avec Dotfuscator Community Edition. L'analyse d'exception non gérée avec les options de commentaires utilisateurs et de choix est prise en charge par les applications .NET Framework, Silverlight, Microsoft Windows Phone et XNA. Une API pour les applications Java est également disponible en téléchargement gratuit et inclut la prise en charge d'Android. La prise en charge de code natif, de JavaScript et de Java est fournie par PreEmptive Solutions.

2. Génération et déploiement

Dotfuscator Community Edition est interactif. L'interface de ligne de commande et la prise en charge de Msbuild est disponible avec Dotfuscator Professional à partir de PreEmptive Solutions.

3. Gestion des données de runtime

Un collecteur de données côté serveur est inclus avec Visual Studio Team Foundation Server 2012. Le point de terminaison de collecteur est référencé par le biais d'une URL incorporée dans l'application et surveillée dans le cadre de la phase d'instrumentation ci-dessus. Le collecteur peut se trouver près du serveur TFS, sur un serveur complètement différent, et même dans Microsoft Azure.

4. Publication de données de runtime

Un service d'agrégation est également inclus avec TFS dans Visual Studio 2012 et interroge le point de terminaison du collecteur. Lorsque des seuils définis par l'utilisateur sont atteints, l'agrégation crée (ou met à jour) un élément de travail Incident de production à l'intérieur de TFS dans Visual Studio 2012.

5. Intégration

Dans Visual Studio 2012, les éléments de travail de TFS créés par PA pour TFS CE sont suivis, attribués, classés par ordre de priorité et signalés comme tout autre type d'élément de travail de première classe.

Capture d'écran de l'emplacement du menu Outils

Figure 3 : recherche de PreEmptive Analytics dans Visual Studio 2012 désactivée du menu outils

Capture d'écran affichant Dotfuscator CE

Figure 4 : instrumentation. Dans Dotfuscator CE, l'ajout de l'attribut d'installation identifie le point de terminaison du collecteur pour les données de runtime. Le point de terminaison peut être sur site près d'un serveur TFS ou hébergé sur Microsoft Azure à distance.

Capture d'écran de Visual Studio affichant l'intégration

Figure 5 : intégration de Visual Studio 2012. Les éléments de travail de type Incident de production sont signalés dans Visual Studio automatiquement lorsque des seuils de volume sont atteints. Dans cette requête « Tous les éléments », vous pouvez afficher le type d'exception, le nombre d'exceptions de ce type qui ont été détectées et sur combien d'ordinateurs. Vous pouvez obtenir plus de détails sur cet élément de travail ci-dessous, y compris une trace de la pile ainsi que l'affectation de l'élément de travail, la hiérarchisation et la classification.

Capture d'écran d'un exemple de graphique synthèse

Figure 6 : rapports. Un exemple des graphiques de résumé inclus avec PA pour TFS CE indique l'état de tous les sinistres ouverts.

Outre les options améliorées d'intégration et d'instrumentation de TFS, l'édition Professional de PreEmptive Analytics inclut des analyses de fonctionnalités, de session et d'utilisateurs conçues pour évaluer les tendances, les modèles d'utilisation et des préférences de l'utilisateur durant toute la durée de vie d'une application de production.

Cas d'usage

Community Edition

Professional

Suivi des exceptions non gérées sur .NET Framework et les applications Java

Oui

Oui

Création et mise à jour automatiques des éléments de travail TFS dans Visual Studio 2012

Oui

Oui

Fourniture d'options de commentaires utilisateurs et de choix au moment de l'exécution

Oui

Oui

Prise en charge de Visual Studio 2010

Oui

Suivi des exceptions interceptées et levées

Oui

Prise en charge des données personnalisées, d'une règle extensible et des définitions d'élément de travail

Oui

Prise en charge de la surveillance d'application native et JavaScript

Oui

Fonctionnalité de mesure et utilisation de session

Oui

  • Le développement a des contraintes uniques auxquelles le Web, BI ou d'autres solutions d'analyse non centrées sur le développement ne peuvent répondre.

  • L'analyse des applications offre des fonctions spécifiques conçues pour répondre aux besoins en termes de développement et d'opération.

  • Visual Studio 2012 offre une analyse des applications intégrée « prête à l'emploi » avec des possibilités d'étendre ces fonctions par le bais d'intégration et d'options de partenaire.

Vous pouvez consulter ces sites pour en savoir plus :

  1. http://www.preemptive.com/pa

  2. http://www.microsoft.com/visualstudio/11/en-us/products/alm

  3. http://blogs.msdn.com/b/bharry/archive/2012/04/11/preemptive-analytics-in-visual-studio-and-tfs-11.aspx

Afficher: