Implémentation de l’analyse des applications

Cette valeur dépend presque entièrement du projet spécifique et du soin apporté au choix des indicateurs ayant le plus d’impact et aux réponses qu’ils déclencheront. Néanmoins, il est possible de se focaliser sur les rouages de l’implémentation, sans perdre de vue l’objectif visant à réduire au minimum la complexité et à gérer le risque du projet. Lorsque le « coût de la connaissance » devient suffisamment simple, fiable et bon marché, l’analyse des applications évolue naturellement du statut de bien luxueux à celui de bien de consommation courante dans le processus de développement.

Implémentation de l’analyse des applications

Les étapes d’instrumentation d’application suivantes ne prennent généralement pas plus d’une heure ou deux, et incluent la prise en charge de la surveillance des données de fonctionnalités et données personnalisées, les mécanismes d’abonnement et la sécurité des données. Toutefois, au vu des particularités autour de la notion de « valeur », je contourne soigneusement les aspects épineux de la prescription des éléments à collecter et de leur exploitation. Ces questions concernent les propriétaires de produits, les spécialistes de Scrum et les architectes.

Portée et planification

Vous devez mapper les objectifs et les exigences pour les données, ainsi qu’identifier les champs de données spécifiques et la quantité de code à écrire pour répondre à ces exigences. Vous trouverez les réponses à ces questions dans l’association des exigences pour les données et des technologies d’instrumentation et d’analyse sélectionnées. Le tableau 1 propose des exemples courants.

Vie privée, identité et sécurité

Selon les fonctionnalités de l’application, les données démographiques des utilisateurs et les exigences définies, identifiez les politiques de respect de la vie privée appropriées, les obligations de communication, les processus d’abonnement et les mécanismes de mise en application. De nouveau, il faut déterminer les activités de codage nécessaires pour répondre à ces exigences. Et, encore une fois, les réponses à ces questions résident dans la combinaison des exigences et des technologies d’instrumentation et d’analyse sélectionnées.

Instrumentation

Quelles technologies et quels modèles seront employés pour modifier une application afin de respecter les exigences énoncées ici ? Je vais restreindre cet aspect aux technologies d’instrumentation et d’analyse des applications présentes dans Visual Studio 2010 et/ou faisant partie intégrante du téléchargement des Windows Phone 7 Developer Tools (en d’autres termes, si vous avez Visual Studio ou si vous développez des applications Windows Phone, tous ces outils sont inclus).

En particulier, le reste des étapes d’implémentation exposées ici utilise Visual Studio 2010 Dotfuscator Software Services Community Edition ou Dotfuscator for Windows Phone et Runtime Intelligence Service for Windows Phone (fournis avec les Windows Phone 7 Developer Tools).

Avant de commencer, un modèle digne d’être mentionné est l’approche d’injection Dotfuscator de l’instrumentation. Au lieu de s’appuyer uniquement sur les modifications du code, Dotfuscator injecte l’instrumentation dans le code déjà compilé. Ce processus se déroule en deux parties. Premièrement, au moyen d’attributs personnalisés ou d’une ressource XML externe, vous spécifiez ce qui suit :

Identité organisationnelle propriétaire de l’application.
Identité de l’application (GUID, nom et numéro de version).
Paramètres d’abonnement, de sécurité et de respect de la vie privée pour communiquer et appliquer les options de confidentialité et, éventuellement, pour sécuriser le consentement d’abonnement d’un utilisateur.
Données d’exécution à collecter, notamment données de session, système, de fonctionnalités et personnalisées, reporting des exceptions et suivi de niveau fonction.
Point d’extrémité cible pour l’envoi des données d’exécution.
Options de configuration supplémentaires, incluant la mise en cache hors ligne, les transmissions SSL, le reporting des exceptions, etc.

Deuxièmement, Dotfuscator injecte le code nécessaire à l’implémentation de tous ces éléments dans les assemblys, évidemment après la compilation.

Cette technique est souvent efficace lorsque l’analyse doit être implémentée à l’intérieur d’applications existantes ou entre des composants et applications développés par plusieurs équipes. Elle est aussi utile pour des groupes d’utilisateurs ciblés qui n’obtiennent pas habituellement une build spéciale (par exemple, des utilisateurs internes ou d’autres segments d’utilisateurs bien définis), ou lorsqu’il n’existe pas d’accès facile au code source ou aux développeurs du code.

Le recours à l’injection pour l’instrumentation aboutit au workflow d’implémentation de l’analyse des applications illustré sur la figure 1 (voir Club Abonnés).

Une fois la configuration terminée, Dotfuscator consomme les assemblys/fichiers XAP et injecte la logique d’instrumentation appropriée. A ce stade, une application peut, en option, faire l’objet d’une obfuscation, être signée et être packagée avec un package d’installation.

La figure 2 (voir Club Abonnés) illustre les trois prochaines étapes du workflow d’analyse des applications, à savoir :

?   Ingestion des données d’exécution au niveau d’un point d’extrémité.
?   Agrégation, analyse et publication des possibilités d’un point d’extrémité autonome.
?   Potentiel d’analyse supplémentaire provenant de l’intégration des éléments décisionnels d’exécution (runtime intelligence) avec les systèmes liés, notamment Visual Studio, Dynamics CRM et Operations Manager.

Les données d’exécution d’application sont acheminées vers un point d’extrémité, où elles sont ingérées, gérées et publiées auprès de personnes. Elles sont également exposées via une API RESTful afin de faciliter la consommation des données par d’autres systèmes, notamment des systèmes de gestion du cycle de vie des applications (ALM), de gestion de la relation client (CRM) et de gestion des opérations informatiques.