Microsoft Office: O cálculo de compatibilidade do Office
Ao planejar uma atualização do Office, cálculos simples o ajudarão a determinar o cenário de teste de compatibilidade.
Chris Jackson
"Fatos são coisas teimosas; e qualquer que seja nossos desejos, nossas inclinações ou os ditames da nossa paixão, eles não podem alterar o estado dos fatos e provas." — John Adams
Então você decidiu implantar uma nova versão do Office em toda a organização. Quanto tempo você deve esperar que ela tenha entre assinar na linha pontilhada, e quando os usuários são produtivos em seu trabalho diário? Para a organização de média, que pode ser em qualquer lugar entre 12 e 18 meses.
Muito desse atraso é devido aos esforços de gerenciamento de risco. Certifique-se que você não interromper o negócio com seus esforços de implantação. Enquanto isso pode parecer frustrante, você não pode abandonar completamente gerenciamento de risco. Como você consegue conciliar esses objetivos conflitantes?
A abordagem típica é resolver estes problemas com a tecnologia. Você pode usar ferramentas para coletar dados, como se a existência de dados de alguma forma de acelerar o processo. Adicionando ainda mais dados não aliviar a experiência emocional natural do medo. Haverá medo que sua atualização fará com que alguma falha de negócios de missão crítica. Você pode aplicar a seguinte equação: O custo do fracasso pode ser igual a infinito.
Você também tem de lidar com o medo da mudança e a insistência de que nada pode ser quebrado. Você pode optar por manter uma cópia virtual da versão herdada do Office disponível. Se você tiver um problema com um documento ou aplicativo, você pode direcionar o usuário imediatamente aproveitar esta rede de segurança e obter produtivo novamente. Você também poderia remediar a aplicação a fim de voltar para o ambiente atualizado tão rapidamente como possível.
Demais depositar as suas esperanças na infalibilidade de uma ferramenta, o processo ou o parceiro sem parar para pensar sobre o que todos estas decisões significam. Eles tentam a todo custo evitar o fracasso. Uma vez que você reduziu o custo do fracasso de "catastrófico" para "razoável e prudente", você deve explorar alguns da matemática por trás dessas decisões. Isso irá ajudá-lo a tomar melhores decisões e avaliar as reivindicações que outros estão fazendo.
Quando o custo do fracasso multiplicado pela probabilidade de falha é maior que o custo do teste, você deve testar seus aplicativos para compatibilidade.
Como com qualquer fórmula generalizada, isto requer alguma interpretação. Teste de compatibilidade não é para ser considerado um luxo, nem é um imposto do teste de compatibilidade de aplicativo. Pense nisso como um investimento em gerenciamento de risco.
O que significa isso para o resto de seus documentos e aplicativos — o que você não testar? Isso não significa que você deve ignorá-los. Você simplesmente optou por não investir em teste proativo. Em vez disso, você investe em testes reativos. Você corrigi-los quando um usuário informa eles estão quebrados (e você deve torná-lo extremamente fácil para os usuários a fazer isso).
Imagine que você tenha um documento que é realmente importante, mas não causará interrupção indevida no caso de falha. O usuário irá chamar o help desk e com seu app reativa-compatibilidade suporte, você pode resolver o problema em uma média de 30 minutos. Que o tempo será menor se é fundamental e você precisa usar a virtualização e começar imediatamente produtivo novamente.
Supondo que você está acompanhando a falta de documento, você descobrir que você tem uma taxa de falha de 5 por cento para documentos do Office nesta migração específica. Supondo que o tempo do usuário é no valor de r $250 uma hora, essa falha vai custar US $125 vezes 5%, ou r $6,25. Se o custo amortizado do seu processo proativo de teste exceder $6.25, mesmo por apenas um centavo, você não deve se preocupar proativamente testando o documento em tudo.
Inventário primeiro?
O fluxo do processo de inventário, racionalizar, testar e corrigir"é difundida e enraizada. As empresas passam por todos os tipos de contorções perseguindo um inventário preciso. A matemática realmente indica que isso vale a pena?
A resposta, claro, depende das entradas que você traz para a equação. Vale a pena fazer a matemática, embora, para determinar como você deve executar a descoberta. Você deve ter um inventário completo quando o número de documentos multiplicada por meio de taxa, multiplicado pelo tempo para determinar o nível de importância é menor que a taxa alta vezes tempo lista documentos.
A primeira variável é quantos documentos você normalmente geram. Esse número tem um desvio-padrão grande dependendo da natureza do seu negócio. Então você precisa descobrir quais recursos podem ajudar a determinar a crítica como um documento é a sua organização.
Racionalização pode ser um pouco mais difícil com documentos. Há menos itens descartáveis óbvios do que com aplicativos. Aloca a quanto tempo você acha que será necessário para determinar se um documento ou aplicativo está no escopo, dependendo da complexidade de fazer essas determinações em seu ambiente. A alternativa é pedir os usuários de negócios (que trabalham em um custo mais elevado) quais os documentos que são essenciais e alocar alguma quantidade de tempo para que possam gerar essa lista.
Suponha que você tem uma organização com 50.000 usuários que geram uma média de 500 documentos por pessoa, armazenado em algum lugar na rede, resultando em 25 milhões de documentos. Assuma os recursos para fazer o trabalho de racionalização para uma taxa de US $100 uma hora e que cinco minutos é gasto investigando cada documento.
Aqui está como funciona a matemática:
25.000.000 x 100 x 0,08? 8 x 300 x 100
200,000,000 >> 240,000
Isso acaba por ser uma decisão fácil. Se você fosse fazer um inventário completo e racionalizá-lo, custaria US $200 milhões. E, neste ponto, você ainda não determinou se nada funciona ainda. A alternativa é passar um par de centenas de milhares de dólares em custo de oportunidade e simplesmente ter pessoas criar a lista manualmente.
A lei dos grandes números trabalha contra você quando se trata de racionalização do escritório. Se sua intenção é usar as ferramentas, você tem que usar a automação mais do que apenas um inventário. O que você está procurando é o impacto nos negócios, que é difícil para ferramentas para deduzir. Um substituto algum uso é a data de modificado o arquivo, mas isso é um substituto de imperfeito. Um substituto melhor seria alguma medição de uso real dos computadores cliente.
Novas versões do Office apresentar um recurso de telemetria. Isso é integrado com o produto (e instalável no nível mais baixo versões do Office) e coleta de dados dos computadores dos usuários nos documentos e suplementos que estão usando. Ao gerar um inventário de documento, Olhe especificamente para documentos que acabam na lista de mais usados recentemente (MRU) de um usuário. Isso ajuda a refinar o inventário de "Isto representa cada documento que ninguém nunca conseguiu criar" para "Isto representa o que as pessoas estão realmente usando o tempo todo."
Usando essa abordagem, você será capaz de coletar e analisar dados de telemetria que indica onde o risco é mais provável que existam. Hoje, no entanto, muitas vezes há nenhum valor melhor para obter seu inventário do que simplesmente pedindo às pessoas para apresentar uma lista.
Instruções de suporte de fornecedor
Pesquisa de fornecedor está enraizada em muitos processos de compatibilidade de aplicativo, sobretudo quando emitido por uma fábrica de compatibilidade de aplicativos. A questão de fazer você precisa isto depende se você vai exigir o suporte de fornecedores para um determinado aplicativo. Se provavelmente vai precisar de suporte de fornecedor, fazer pesquisa de fornecedor é um requisito de negócio.
Muitos dos processos e usadas por fornecedores de listas ajudam a determinar se o aplicativo já foi apoiado na plataforma para o qual você está migrando e se o pedido for apoiado ativamente hoje. Isso pode ser um grande indicador de que seja susceptível de funcionar nessa plataforma, porque os vendedores afirmam isso com seu próprio apoio dólares.
Note que ele realmente não vai responder à sua pergunta de negócios de se o aplicativo já foi suportado e você estaria disposto a executá-lo. Certificar-se de que você receberá a resposta para a pergunta que você fez.
A matemática vem aqui para determinar se o suporte do fornecedor é vale a pena o investimento de tempo para fazer essa pesquisa. A alternativa é executar o processo de avaliação de compatibilidade você mesmo. No entanto, muitas pessoas fazem mau matemática, comparando o custo dos testes um app para o custo de um aplicativo de pesquisa. Esta suposição falha postula que você vai encontrar instruções para tudo, mas não é a abordagem estatística correcta.
Aqui está uma equação eficaz: Quando o custo dos testes um app vezes a porcentagem não encontrada ou crítica, mais o custo da investigação para um app é menor que o custo de uma app de teste, você deve Pesquisar suporte do fornecedor.
Mais uma vez, vamos colocar alguns números para isso. Imagine um processo de teste que acaba custando US $150 por aplicativo. Da mesma forma, dizer que há um processo de pesquisa de fornecedor que calcula a média de $15 por aplicativo. A empresa pode localizar instruções de suporte para 12 por cento dos aplicativos, e desses, você pretende testar 10 por cento de qualquer forma porque eles são essenciais.
$150 x 89,2% + $15? 150
$148.80 < $150
Sim, faz sentido fazer pesquisa de fornecedores, mas não é o slam dunk que você pensaria. Afinal, a pesquisa de fornecedor parece ser um décimo do custo dos testes de aplicativo. Em média, você acaba salvando apenas r $1,20 por aplicativo.
Claro, salvar alguma coisa (particularmente em escala) é bom, mas deve dar-lhe aviso que você está muito perto do ponto de cruzamento. A taxa de falha não precisa mover-se muito antes de você descobrir que você é em números negativos. Na verdade, com estes pressupostos, tão logo o percentual de aplicativos para que você localize declarações de apoio cai para menos de 10 por cento, ele começa a tornar-se mais caro para procurar coisas numa lista. Parece contra-intuitivo, mas a opção com o menor custo de unidade é realmente menos desejável quando sua taxa de falha é muito baixa.
O enigma de conversão
As últimas versões do Office têm melhorado significativamente os recursos. Muitos a nova criação de documentos e recursos de edição exigem que você use os formatos de arquivo mais recentes. Se você quiser aproveitar os novos recursos dentro de um determinado documento, você deve converter os arquivos e de lá ir.
Uma das perguntas regulares é que se deve percorrer e atualizar todos os documentos para os novos formatos de arquivo. O processo parece fácil, é claro, e existem ferramentas para ajudar com isso. No entanto, nem todos os documentos vão atualizar corretamente. O custo de atualização inclui o gerenciamento de riscos, de garantir que a atualização não causa uma falha de aplicativo. Algumas funcionalidades poderão ser perdidas (como o recurso de "versões"), alguns gráficos podem olhar diferentes e links para o arquivo usando a extensão de arquivo antigo pode acabar quebrado.
Naturalmente, esse custo também incorre em um benefício. Ignorando arquivos você pode atualizar manualmente a fim de usar os novos recursos do produto, cada arquivo irá beneficiar o tamanho de arquivo reduzido de novos formatos de arquivo. Para fazer essa determinação, você tem mais uma vez a olhar para a matemática para determinar se você tem um ROI positivo da realização dessa actividade. Você deve em massa-converter todos os seus documentos quando o custo de conversão mais o custo do teste é menor que o custo do espaço em disco.
Começando com a redução de custos e assumindo que os mesmos números como antes (50.000 usuários com 500 documentos cada), adicionar um tamanho médio de 1 MB. O potencial de economia com esses parâmetros é o custo de salvar 11 TB de espaço em disco. Para colocar isso em perspectiva, vamos calcular o custo desse espaço de disco. Usar uma fórmula calculada por Matthew Komorowski e Postado em seu "uma história de custo de armazenamento," encontramos que custo é igual a 10 à potência de-0.2502 (ano menos 1980) mais 6,304.
Este é calculado com base no preço de compra de mídia de disco sozinho. Enquanto isso sugiro que você poderia comprar um disco rígido para armazenar dados de cerca de r $0,02 por gigabyte em 2012, para calibrar isso contra os custos totais, use os custos de armazenamento do Windows Azure. Estes são atualmente custa US $128 por terabyte, ou é apenas tímido de 6,3 vezes maior do que o custo calculado desta fórmula.
Portanto para calibrar os resultados para tentar prever o custo total de armazenamento, modificar a fórmula da seguinte maneira: Custo é igual a 10 de 6,3 vezes o poder de-0.2502 (ano menos 1980) mais 6,304.
Supondo que você manter documentos para uma média de 10 anos, a poupança líquida total prevista por esta fórmula seria $3,209.53. Mesmo se você simplesmente assumiu que o custo de armazenamento no Windows Azure permaneceria constante, sua economia total ainda seria $14.080.
Portanto, se você testar seus documentos para conversão de provável sucesso e convertê-los para um total custam inferior a US $14.080 conservadora (US $3,209.53 se você assume os custos de armazenamento vai continuar a diminuir com a mesma taxa exponencial), então faz sentido para converter.
Se ele custa mais do que isso para testar e executar a conversão, então não faz sentido para converter. Você deve deixar seus documentos no formato existente. Office 2010 ainda pode lê-los muito bem. Convertê-los manualmente, quando você precisa usar os novos recursos.
A ferramenta certa
O padrão mais comum quando se trata de compatibilidade em qualquer plataforma está à procura de uma ferramenta para encontrar — e esperançosamente corrigir — todos os problemas de atualização. Você pode pressupor uma ferramenta associada com o problema de compatibilidade irá alcançar todo ou parte deste objetivo e executá-lo em toda parte. Em algum ponto abaixo da estrada, você vai perceber que você realmente não tenha resolvido esse problema completamente.
O problema é de restrição. Um erro de compatibilidade, afinal, é apenas um caso especial de um bug que acontece a manifestar-se sobre uma plataforma em particular. Isso não é diferente de localizar e corrigir todos os erros na plataforma que você já tem. A menos que você simplesmente não tem um suporte técnico, porque todos os seus softwares trabalha o tempo todo, meu palpite é que você tem a abundância de bugs de compatibilidade com essa plataforma. É por que não, porque ele não é compreendido, mas porque o problema é intratável.
A maioria de vocês tem pelo menos uma familiaridade com Alan Turing 1937 prova que você não pode construir um programa para detectar se um aplicativo irá concluir a execução ou continuar a funcionar para sempre. Esta restrição implementa limites de longo alcance que afetam a pesquisa ainda hoje como cientistas olhar para construir novos verificadores para garantir a correção do programa. Por exemplo:
"Análise de contexto-limitada é uma abordagem atraente para verificação de programas simultâneos. Esta abordagem defende a análise de todas as execuções de um programa simultâneo, em que o número de contextos executado por segmento é delimitado por uma determinada constante k Limite o número de contextos executado por thread reduz a complexidade assintótica da verificação de programas simultâneos: enquanto a análise de "acessibilidade" de programas simultâneos de booleanos é indecidível, a mesma análise sob um contexto-limite é NP-completo [18, 15]. Além disso, há ampla evidência empírica de que erros de sincronização, como corridas de dados e violações de atomicidade, manifestam-se em execuções simultâneas com um pequeno número de alternâncias de contexto [19, 16]. Essas duas propriedades juntos fazem análise de contexto-delimitada uma abordagem eficaz para encontrar erros de simultaneidade. Ao mesmo tempo, delimitação de contexto fornece um útil trade-off entre o custo e a cobertura de verificação."
Você precisará definir precisamente o que significa ser um bug. A maioria das pessoas concorda que uma falha de programa é um bug. Existem outras situações onde determinar se o comportamento do programa é um bug depende do contexto. Por exemplo, alterando a cor em um gráfico pode alterar negativamente o significado. Também poderia ser aceitável ou até mesmo desejável. Uma verificação de versão — que é tecnicamente um recurso, porque é necessário que o desenvolvedor escreva código para introduzir o comportamento — é às vezes considerado um bug por quem cai fora de conformidade com as restrições da versão.
Sabendo que você não pode encontrar todos os erros, ou mesmo de todos os erros de uma determinada categoria, você precisa garantir a que você concentrar sua automação em áreas onde a automação faz sentido. Resolver o problema da parada, se fosse possível, nos daria a capacidade de parar todos os loops infinitos — um erro comum. Que teria um retorno enorme.
Quando você considerar o conceito de tentar encontrar e corrigir todos os erros, nem todos que tem um retorno. Teoricamente, há um número infinito de maneiras de escrever uma programação bug (seja empírica ou contextuais) e um número finito de formas de detectá-los todos. Como o número de incidentes de programação erros diminui, a recompensa para automatizar essas verificações da mesma forma declina. Isso leva a que escolher para automatizar.
A matemática é relativamente simples. Você deve escrever testes automatizados para encontrar bugs, quando o custo de criação e execução de automação é menor que o custo de depuração multiplicado pela incidência de erros.
Isso funciona bem para problemas extremamente comuns. Em aplicativos do Windows, por exemplo, o controle de conta de usuário feita executando com contas de usuário padrão mais realista para muitas organizações. Ele também exposto a um problema de conformidade significativa com muito do software projetado para tempos quando executando como administrador foi considerado mais aceitável. Estes problemas foram tão comum e tão semelhantes que criação de automação para detectar todos eles tiveram retorno significativo quando comparado com a solução de problemas individuais.
Fornecedores que criam ferramentas de verificação para uma determinada plataforma podem amortizar o custo da criação de automação mais muitos clientes. Eles investem em fazer criação de novo teste mais fácil e barato, para que possam trabalhar essa matemática para a vantagem de correr muito mais testes. Ao mesmo tempo, os testes que podem ser mais fácil (e barato) criar, pode ter uma incidência muito baixa. Ver tipo I (falso positivo) e erros de tipo II (falso negativo) torna-se importante.
Tecnologias de verificador chegando em novas versões do Office para combater alguns dos desafios com versões anteriores da ferramenta, que foram objecto de tanto tipo I e tipo II erros. Também houve confusão quanto à aplicabilidade para cenários específicos.
O conjunto de ferramentas do Office Migration Planning Manager, por exemplo, analisa e determina todos os possíveis desafios. Olha também os desafios de converter o documento para novos formatos de arquivo (o que não seria um desafio, se você escolheu simplesmente deixar o documento como está). O novo foco de verificação será sobre questões de implantação-bloqueadores, como o uso de APIs obsoletas e falhas do aplicativo (geralmente devidas a Adicionar-ins).
Este trabalho para avaliar, testar e converter é realmente a etapa final em um processo de três etapas:
- Aliviar medos emocionais para que você possa pensar racionalmente.
- Colete os dados certos.
- Analise esses dados para convertê-lo a partir de dados em informações para o conhecimento.
E aqui está a base matemática por trás de algumas orientações:
- Você não tem que fazer algo só porque você pode.
- Você deve executar seu trabalho de compatibilidade de aplicativos, como se você estivesse escrevendo para um jornal: Comece com coisas mais importantes e trabalhar sua maneira para baixo. Nem toda a gente termina, e você quer terminar as coisas mais importantes.
- Não confundir tarefas obrigatórias com tarefas opcionais, mesmo se eles parecem relacionados.
Idealmente, aventuras em explorar a matemática atrás como fazer melhores decisões sobre o que incluir em seu projeto de compatibilidade do Office irão inspirá-lo a questionar seus pressupostos e melhorar a eficiência.
.jpg)
Chris Jackson é "O App Compat Guy" da Microsoft. Ele é um consultor principal e a liderança em todo o mundo para compatibilidade de aplicativos da empresa. Ele é palestrante assíduo em conferências de desenvolvedores e IT e trabalha com clientes e parceiros em todo o mundo. Sua missão é "Restaurando agilidade tecnologia removendo-se dos grilhões do software legado." Leia mais a partir de Jackson em seu blog (appcompatguy.com) e no Twitter em twitter.com/appcompatguy.