Microsoft Office : Calculez la compatibilité Office
Lorsque vous planifiez une mise à jour d'Office, un calcul simple peut vous aider à déterminer les tests de compatibilité que vous devez effectuer.
Chris Jackson
« Les faits sont choses tenaces ; et quelles que soient nos souhaits, nos inclinations ou les préceptes de notre passion, ils ne peuvent changer l'état des faits et des éléments de preuve. » — John Adams
Si vous avez décidé de déployer une nouvelle version d'Office tout au long de votre organisation. Combien de temps est-ce que vous devez attendre à prendre entre la signature sur la ligne pointillée et lorsque vos utilisateurs sont productifs dans leurs tâches quotidiennes ? Pour l'organisation moyenne, qui peut être n'importe où entre 12 et 18 mois.
Une grande partie de ce retard est dû à des efforts de gestion des risques. Vous devez vous assurer que vous ne perturbent l'entreprise avec vos efforts de déploiement. Qui peut sembler frustrant, vous ne peut pas renoncer complètement la gestion des risques. Comment pour concilier ces objectifs contradictoires ?
L'approche classique est de résoudre ces problèmes grâce à la technologie. Vous utilisez les outils pour recueillir des données, comme si l'existence de données doit d'une certaine façon accélérer votre processus. Ajoutant encore plus de données n'atténue pas l'expérience émotionnelle naturel de peur. Il y aura peur que votre mise à niveau entraîne un échec de mission-critiques de l'entreprise. Vous pouvez appliquer l'équation suivante : Le coût de l'échec peut être égal l'infini.
Vous devez également composer avec la peur du changement et de l'insistance que rien ne peut être brisé. Vous pouvez choisir de conserver une copie virtuelle de la version héritage de bureau disponible. Si vous rencontrez un problème avec un document ou une application, vous pouvez directement l'utilisateur immédiatement tirer parti de ce filet de sécurité et obtenir productif une fois de plus. Vous pourrait aussi remettre en état l'application afin de retourner aussi rapidement que possible sur l'environnement mis à niveau.
Trop d'épingler leurs espoirs sur l'infaillibilité du processus, un outil ou de partenaire sans s'arrêter pour réfléchir à ce que toutes ces décisions moyenne. Ils tentent à tout prix éviter l'échec. Une fois que vous avez réduit le coût de l'échec de « catastrophique » à « raisonnable et prudente », vous devez explorer certains des mathématiques derrière ces décisions. Cela vous aidera à prendre de meilleures décisions et d'évaluer les réclamations d'autres le font.
Vous devez tester vos applications pour la compatibilité lorsque le coût de l'échec, multiplié par la probabilité de rupture est plus grand que le coût de la mise à l'essai.
Comme avec toute formule généralisée, cela nécessite une interprétation. Test de compatibilité n'est pas d'être considéré comme un luxe, ni compatibilité applicative teste une taxe. Considérer comme un investissement dans la gestion des risques.
Ce que cela signifie pour le reste de vos documents et vos applications — ceux qui vous n'a pas d'essai ? Cela ne signifie pas que vous devez les ignorer. Vous avez tout simplement choisi de ne pas investir dans un essai proactive. Au lieu de cela, vous investissez dans des tests réactifs. Vous fixer lorsqu'un utilisateur signale ils ont cassé (et vous rend très facile pour les utilisateurs de le faire).
Imaginez que vous avez un document qui est en effet important, mais ne cause une perturbation excessive d'entreprise en cas de panne. L'utilisateur va appeler le service d'assistance et avec votre app-compatibilité réactif soutien, vous pouvez résoudre le problème dans une moyenne de 30 minutes. Cette époque sera moindre si elle est essentielle et vous devez utiliser la virtualisation et obtenir immédiatement productif une fois de plus.
En supposant que vous êtes suivi échec de documents, vous découvrez que vous avez un taux d'échec de 5 % pour les documents Office dans cette migration en particulier. En supposant que les temps de l'utilisateur est une valeur de 250 $ l'heure, cet échec vous coûtera $125 fois 5 p. 100, ou 6,25 $. Si le coût amorti de votre processus d'essai proactive dépasse $6,25, même par seulement un penny, vous ne devrait pas déranger proactivement analyse le document à tous les.
Tout d'abord l'inventaire ?
Le flux du processus de « inventaire, rationaliser, tester et corriger » est omniprésente et enracinée. Les entreprises passent par toutes sortes de contorsions chassant un inventaire précis. Le calcul indique vraiment que cela vaut la peine ?
La réponse dépend bien sûr, sur les entrées que vous apportez à l'équation. Il convient de faire le calcul, mais, afin de déterminer comment vous devez effectuer la découverte d'applications. Vous devez prendre un inventaire complet lorsque le nombre de documents multiplié par la moyenne de taux multiplié par le temps de déterminer la criticité est inférieure aux vitesse high times temps liste des documents.
La première variable est documents combien vous générez habituellement. Ce nombre a un grand écart type selon la nature de votre entreprise. Vous devez alors découvrir les ressources peuvent aider à déterminer un document crucial est de votre organisation.
Rationalisation peut être un peu plus difficile avec des documents. Il y a moins d'objets jetables évidents que vous avez avec les applications. Allouer combien de temps vous pensez qu'il en aura besoin pour déterminer si un document ou une application est portée, selon la complexité de la prise de ces décisions dans votre environnement. L'alternative est de demander aux entreprises utilisateurs (qui travaillent à un coût plus élevé) quels documents sont essentiels et d'allouer un laps de temps pour leur permettre de générer cette liste.
Supposons que vous avez une organisation avec 50 000 utilisateurs qui génèrent une moyenne de 500 documents par personne stocké quelque part sur le réseau, résultant dans les 25 millions de documents. Supposons que les ressources pour faire le travail de rationalisation pour un taux de 100 $ une heure et que cinq minutes est consacré à étudier chaque document.
Voici comment fonctionne le calcul :
25 000 000 x 100 x 0,08 ? 300 x 8 x 100
200,000,000 >> 240,000
Cela s'avère pour être une décision facile. Si vous deviez prendre un inventaire complet et rationaliser, il en coûterait 200 millions $. Et, à ce stade, vous n'avez pas encore déterminé si quelque chose fonctionne encore. L'alternative est de passer un couple cent mille dollars en coût d'opportunité et ont tout simplement les gens créer la liste à la main.
La Loi des grands nombres travaille contre vous quand il s'agit de la rationalisation de l'Office. Si votre intention est d'utiliser des outils, vous devez utiliser l'automation plus que juste un inventaire. Ce que vous cherchez est impact commercial, ce qui est difficile pour les outils de déduire. Un substitut certains est la date de mise à jour sur le dossier, mais c'est pas un substitut imparfait. Un substitut meilleur serait une mesure de l'usage réel des ordinateurs clients.
Nouvelles versions de Bureau mettra en place une fonction de télémétrie. C'est intégré avec le produit (et installables à bas niveau les versions d'Office) et recueille les données des ordinateurs des utilisateurs sur les documents et les compléments qu'ils utilisent. Lors de la génération d'un inventaire de document, regarder plus précisément les documents qui se retrouvent dans la liste plus récemment utilisés (MRU) de l'utilisateur. Cela aide à affiner l'inventaire de « cela représente chaque document que quiconque a jamais réussi à créer » à « cela représente ce que les gens utilisent vraiment tout le temps ».
En utilisant cette approche, vous serez capable de recueillir et d'analyser des données télémétriques qui indique où les risques réels sont plus susceptibles d'exister. Aujourd'hui, cependant, il n'est souvent aucune valeur mieux pour obtenir votre inventaire que simplement demander aux gens de soumettre une liste.
Déclarations de soutien du vendeur
Recherche vendeur est enraciné dans les nombreux processus de app-compatibilité, particulièrement lorsque livré par une usine de compatibilité des applications. La question de la vous devez cela dépend de la question de savoir si vous aurez besoin de soutien du vendeur pour une application donnée. Si vous aurez probablement besoin de soutien du vendeur, vendeur recherche est une exigence de l'entreprise.
La plupart des processus et des listes utilisées par les vendeurs à déterminer si l'application a déjà été pris en charge sur la plate-forme à laquelle vous êtes migrant, et si la demande est activement soutenue. Cela pourrait être un indicateur beaucoup de savoir si elle est susceptible de travailler sur cette plate-forme, parce que les vendeurs prétendent cela avec leur propre soutien de dollars.
Notez qu'il ne répond pas réellement votre question d'entreprise de savoir si l'application a été jamais pris en charge et vous serait prêt à exécuter. Assurez-vous que vous recevez la réponse à la question que vous est posée.
Les mathématiques vient ici pour déterminer si la charge du vendeur est une valeur de l'investissement de temps pour faire cette recherche. La solution s'exécute le processus d'évaluation de compatibilité vous-même. Cependant, beaucoup de gens faire des mauvais mathématiques, comparant le coût de mise à l'essai un app au coût d'une demande de recherche. Cette supposition erronée postule que vous trouverez les instructions pour tout, mais il n'est pas l'approche statistiquement correcte.
Voici une équation efficace : Vous devez la recherche soutien du vendeur lorsque le coût des tests une app fois le pourcentage pas trouvé ou critique ainsi que le coût de la recherche pour un app est inférieur au coût de mise à l'essai un app.
Encore une fois, mettons quelques numéros à cela. Imaginez un processus qui aboutit à des coûts de 150 $ par demande. De même, dire il y a un processus de recherche du vendeur qui est en moyenne de 15 $ par demande. La compagnie peut localiser les déclarations de soutien 12 p. 100 des demandes, et de ceux, vous avez l'intention de tester 10 p. 100 de toute façon parce qu'ils sont essentiels à la mission.
$150 x 89,2 % + 15 $ ? 150
$148.80 < $150
Oui, il logique de faire la recherche de fournisseurs, mais il n'est pas le slam dunk que vous serait avez pensé. Après tout, recherche vendeur semble être un dixième du coût de test des applications. En moyenne, vous vous retrouvez sauver seulement 1,20 $ par demande.
Bien sûr, sauver quoi que ce soit (notamment à l'échelle) est bonne, mais il devrait vous donner une mise en garde que vous êtes assez proche du point de croisement. Le taux d'échec n'a pas besoin d'aller trop avant vous découvrez que vous êtes dans les nombres négatifs. En fait, avec ces hypothèses, dès que le pourcentage de demandes pour lesquelles vous recherchez des déclarations de soutien diminue à moins de 10 %, il commence à devenir plus coûteux pour rechercher les choses sur une liste. Il semble paradoxal, mais l'option avec le coût unitaire plus faible est en réalité moins souhaitable lorsque son taux d'échec est trop faible.
L'énigme de la Conversion
Les dernières versions de bureau ont sensiblement amélioré les capacités. Bon nombre des fonctionnalités d'édition et de la nouvelle création de document nécessitent que vous pouvez utiliser les formats de fichiers plus récents. Si vous souhaitez tirer parti de ces nouvelles fonctionnalités au sein d'un document particulier, vous devez convertir ces fichiers et aller de là.
L'une des questions régulières est de savoir si vous devez passer et mettre à jour tous les documents pour les nouveaux formats de fichier. Le processus semble facile, bien sûr, et il existe des outils pour aider à cela. Cependant, pas tous les documents mettra à niveau proprement. Le coût de la mise à niveau inclut la gestion du risque de s'assurer que la mise à niveau ne provoque pas l'échec de la demande. Certaines fonctionnalités peuvent être perdues (par exemple, la fonction « versions »), pourraient ressembler à certains graphiques différents et liens vers le fichier en utilisant l'ancienne extension de fichier pourraient finir par brisé.
Bien sûr, ce coût entraîne également un avantage. En ignorant les fichiers, vous pouvez mettre à jour manuellement afin de pouvoir utiliser les nouvelles fonctionnalités du produit, chaque fichier bénéficieront de la taille de fichier réduite des nouveaux formats de fichier. Pour faire cette détermination, vous avez une fois de plus à regarder les mathématiques pour déterminer si vous avez un ROI positif d'entreprendre une telle activité. Vous devez en vrac-convertir tous vos documents lorsque le coût de la conversion, plus le coût des tests est inférieur au coût de l'espace disque.
À commencer par les économies de coûts et en supposant que le même nombre comme avant (50 000 utilisateurs avec 500 documents chaque), ajouter une taille moyenne de 1 Mo. Les économies de ces paramètres est le coût de l'enregistrement de 11TB d'espace disque. Pour qui mettre en perspective, disons de calculer le coût de l'espace disque. À l'aide d'une formule calculée par Matthew Komorowski et affiché dans son « une histoire de coût de stockage, « nous estimons que le coût équivaut à 10 à la puissance de-0.2502 (année moins 1980) ainsi que 6.304.
Cette est calculée sur le prix d'achat de médias de disque seul. Alors que cela donne à penser que vous pourriez acheter un disque dur pour stocker des données pour environ 0,02 $ par gigaoctet en 2012, pour étalonner cette contre les coûts totaux, utiliser les coûts de stockage de Windows Azure. Il s'agit de prix actuellement à 128 $ par téraoctet, ou simplement timide de 6,3 fois plus élevé que le coût calculé dans cette formule.
Donc pour calibrer les résultats pour tenter de prévoir le coût total de stockage, modifiez la formule comme suit : Coût est égal à 6,3 fois 10 à la puissance de-0.2502 (année moins 1980) plus 6.304.
En supposant que vous conservez les documents pour une moyenne de 10 ans, les économies nettes totales prévues par cette formule serait de $3,209.53. Même si vous simplement assumé que le coût de stockage sur Windows Azure demeurerait constant, votre épargne totale serait encore 14 080 $.
Donc, si vous testez vos documents pour le succès probable de conversion et de convertir leur total coûtent de moins de 14 080 $ prudente ($3,209.53, si vous assumez les coûts de stockage continuera à décliner à la même vitesse exponentielle), alors il est logique de conversion.
Si cela vous coûte plus que cela à la fois tester et exécuter la conversion, alors il ne fait pas sens pour convertir. Vous devriez laisser vos documents dans le format existant. Bureau 2010 puisse les lire encore très bien. Convertir manuellement lorsque vous avez besoin d'utiliser de nouvelles fonctionnalités.
Le bon outil
Le modèle plus courant lorsqu'il s'agit de compatibilité sur n'importe quelle plate-forme est à la recherche d'un outil trouver — et nous l'espérons corriger — tous mise à jour des problèmes. Vous pouvez supposer un outil associé à ce problème de compatibilité sera réaliser tout ou partie de cet objectif et l'exécuter partout. À un moment donné sur la route, vous pourrez réaliser que vous n'avez pas réellement résolu ce problème complètement.
Le problème est une des contraintes. Un bug de compatibilité, après tout, est simplement un cas particulier d'un bug qui arrive à se manifester sur cette plate-forme particulière. Ce n'est pas différent de trouver et de corriger tous les bugs sur la plate-forme que vous avez déjà. À moins que vous tout simplement n'avez un bureau de l'aide parce que tous vos logiciels fonctionne tout le temps, ma conjecture est que vous avez beaucoup de bugs de compatibilité avec la plate-forme. Ce n'est pas parce qu'il n'est pas compris, mais parce que le problème est insoluble.
La plupart d'entre vous ont au moins une connaissance de passage de de Alan Turing 1937 preuve que vous ne peut pas construire un programme pour détecter si une application va finir la course ou continue de fonctionner pour toujours. Cette contrainte implémente des limites qui affectent la recherche encore aujourd'hui dans le regard des scientifiques pour construire de nouveaux vérificateurs afin d'assurer la justesse du programme. Par exemple :
« Analyse de contexte limité est une approche intéressante pour la vérification de programmes simultanés. Cette approche préconise d'analyser toutes les exécutions d'un programme de concurrente dans laquelle le nombre de contextes exécutée par le thread est délimité par une donnée k constant Le nombre de contextes exécutée par le thread de délimitation réduit la complexité asymptotique de la vérification de programmes simultanés : analyse de le « accessibilité » des programmes Boolean concurrentes est indécidable, la même analyse dans un contexte lié est NP-complet [18, 15]. En outre, il y a des preuves empiriques que les erreurs de synchronisation, telles que les courses de données et les violations de l'atomicité, sont manifestent dans des exécutions simultanées avec un petit nombre de commutateurs de contexte [19, 16]. Ensemble, ces deux propriétés faire analyse de contexte limité une approche efficace pour trouver des erreurs d'accès concurrentiel. Dans le même temps, cadre de délimitation prévoit un compromis utile entre le coût et la couverture de la vérification. »
Vous avez besoin de définir précisément ce que cela signifie d'être un bug. La plupart des gens conviennent à qu'un crash de programme est un bug. Il y a des autres situations où pour déterminer si le comportement du programme est un bogue dépend du contexte. Par exemple, changer la couleur d'un graphe peut modifier négativement sens. Il pourrait également être acceptable ou même souhaitable. Une vérification de la version — qui est une caractéristique technique, parce qu'il a fallu au développeur d'écrire du code pour introduire le comportement — est parfois considéré comme un bug par la personne qui tombe sur le respect des restrictions de la version.
Sachant que vous ne trouvez pas tous les bugs, ou même tous les bogues d'une catégorie particulière, vous avez besoin pour que vous concentrer votre automatisation sur les domaines où l'automatisation est logique. Résoudre le problème de l'arrêt, il était possible, nous donnerait la capacité d'arrêter toutes les boucles infinies — un bogue commun. Qui aurait une énorme récompense.
Si l'on considère le concept de tenter de trouver et corriger tous les bogues, ne sont pas tous auraient une récompense. Il y a théoriquement une infinité de façons d'écrire une programmation bug (si empirique ou contextuelle) et un nombre fini de façons de détecter tous les. Comme le nombre d'incidents de programmation bogues diminue, les bénéfices pour l'automatisation de ces vérifications diminue de la même façon. Cela conduit ce que nous choisissons d'automatiser.
Les mathématiques sont relativement simples. Vous devez écrire des tests automatisés pour trouver des bugs lorsque le coût de création et d'automatisation est inférieur au coût de débogage en cours d'exécution multiplié par la fréquence des bogues.
Cela fonctionne bien pour des problèmes très communs. Dans les applications Windows, par exemple, contrôle de compte d'utilisateur fait courir avec des comptes d'utilisateur Standard plus réaliste pour de nombreuses organisations. Elle expose également un problème de conformité importante avec une grande partie du logiciel destiné à la fois lorsque l'exécution en tant qu'administrateur était considéré comme plus acceptable. Ces problèmes sont si fréquents et si semblables que création d'automation pour détecter tous les avait des bénéfices importants par rapport à la résolution des problèmes individuels.
Fournisseurs qui créent des outils de vérification pour une plate-forme donnée peuvent amortir le coût de la création d'automation sur de nombreux clients. Ils investissent pour rendre la nouvelle création de test plus facile et moins coûteux, afin qu'ils peuvent travailler ce math à l'avantage de l'exécution de tests beaucoup plus. En même temps, les essais qui pourraient être plus facile (et moins cher) pour créer pourrait avoir une incidence très faible. Il devient important de regarder de Type I (faux positifs) et des erreurs de Type II (faux négatif).
Technologies de vérificateur entrée dans de nouvelles versions d'Office pour lutter contre certains des défis avec les versions précédentes de l'outil, qui ont fait l'objet de deux Type I et les erreurs de Type II. Aussi, il y avait confusion au sujet de l'applicabilité à des scénarios particuliers.
La boîte à outils Office Migration Planning Manager, par exemple, analyse et détermine les défis potentiels. Il examine également les défis de la conversion du document de nouveaux formats de fichier (ce qui ne serait pas un problème si vous avez choisi de laisser simplement le document comme il est). La nouvelle orientation de vérification sera sur les questions de déploiement-bloquants, par exemple en utilisant les API obsolètes et accidents d'application (généralement causées par les compléments).
Ce travail en évaluation, d'essai et de conversion est vraiment la dernière étape dans un processus en trois étapes :
- Atténuer les craintes émotionnels afin que vous pouvez penser rationnellement.
- Recueillir les bonnes données.
- Analyser les données afin de convertir des données en information à la connaissance.
Et Voici la base mathématique derrière quelques lignes directrices :
- Vous n'avez pas à faire quelque chose simplement parce que vous le pouvez.
- Vous devez exécuter votre travail de compatibilité des applications comme si vous écriviez pour un journal : Commencez par les choses les plus importantes et travailler votre chemin vers le bas. Pas tout le monde se termine, et que vous souhaitez terminer les choses plus importantes.
- Ne pas confondre tâches obligatoires avec des tâches facultatives, même si elles semblent liées.
Idéalement, aventures à explorer les mathématiques derrière comment prendre de meilleures décisions sur ce qu'il faut inclure dans votre projet de compatibilité Office vous incitera à vos hypothèses en question et améliorer l'efficacité.
.jpg)
Chris Jackson est « L'App Compat Guy » de Microsoft. Il est un consultant principal et le plomb dans le monde entier pour la compatibilité d'application entreprise. Il est un conférencier lors de conférences et développeur et collabore avec les clients et partenaires dans le monde entier. Sa mission est « remettre agilité technologique en supprimant les entraves du logiciel héritage. » Lire plus de Jackson sur son blog (appcompatguy.com) et sur Twitter à twitter.com/appcompatguy.