Skip to main content

Introdução à compatibilidade de aplicativos em uma implantação do Windows

Este artigo explica como iniciar o processo de avaliação do impacto da compatibilidade de aplicativos no seu projeto de implantação. Você aprenderá a fazer um inventário, priorizar aplicativos e identificar quais deles devem ser incluídos em uma imagem de implantação específica baseada em função.

Neste artigo:


Introdução à compatibilidade de aplicativos em uma implantação do Windows

Se você já participou de um projeto de implantação de sistema operacional no passado, deve se lembrar da compatibilidade de aplicativos como a fonte de muitos dos maiores desafios enfrentados. Ela pode exigir maior esforço, demorar mais tempo e gerar alguns dos problemas de bloqueio mais sérios. Se estiver participando de um projeto de implantação de sistema operacional pela primeira vez, você já deve ter ouvido histórias horríveis sobre a compatibilidade de aplicativos; ou talvez não tenha ouvido nada e, assim, o escopo do trabalho pode ser uma completa surpresa. Seja qual for sua situação, com o planejamento adequado, o projeto pode se tornar consideravelmente mais previsível e gerenciável.

O importante é se lembrar de que a compatibilidade de aplicativos é, basicamente, uma atividade de gerenciamento de risco. Quanto mais alta for a porcentagem de aplicativos com (estatisticamente falando) probabilidade de falhar, mais trabalho você deverá investir no teste proativo, a fim de ajudar a garantir que um aplicativo essencial não seja um desses aplicativos. À medida que essa porcentagem diminui, o número de aplicativos que vale a pena testar exaustivamente é reduzido. Isso significa que se você estiver migrando do Windows XP com usuários que sejam basicamente administradores locais, você deverá esperar que uma porcentagem razoável de seus aplicativos possivelmente falhe e se planejar adequadamente para investir mais e gerenciar esse risco. Se você já fez o trabalho de migração para o Windows 7, você deve esperar que muito poucos aplicativos tenham a probabilidade de falhar e se planejar para investir menos, uma vez que há menos risco. (Obviamente, como de costume, você deve confiar, mas verificar.)

No entanto, gerenciar esse risco de aplicativos começa com a compreensão precisa do que esse risco envolve, e isso significa entender quais aplicativos você possui. Tudo isso começa com a criação ou atualização do seu Portfólio de Aplicativos Gerenciados. Se você não tiver um, certamente não é o único, mas agora é o momento perfeito de criar um. O ideal é que você mantenha essa lista após a conclusão do projeto de implantação a fim de melhorar sua agilidade. É essa lista que representa pelo quê você será responsável para ajudar a garantir a funcionalidade do seu ambiente à medida que ele muda. Você está emitindo apólices de seguro para esses aplicativos, de modo que entender o quanto de risco você está assegurando é de fato uma abordagem inteligente!

Este documento ajuda a entender as etapas que devem ser executadas para você se preparar para o teste de compatibilidade de aplicativos e a avaliação durante um projeto de implantação do Windows 8. Em muitos casos, no entanto, os princípios descritos aqui são universais e se aplicam às migrações de qualquer plataforma. Depois de ler este documento, você deverá ter uma clara ideia de por onde começar a avaliar o impacto da compatibilidade de aplicativos no seu projeto de implantação, bem como de algumas das habilidades e técnicas específicas que você precisará começar a aplicar e assim ser mais efetivo.

Voltar ao início


Noções básicas sobre o desafio da compatibilidade de aplicativos

No cerne do desafio da compatibilidade de aplicativos está a lei de grandes números. As organizações podem ter dezenas de milhares ou, até mesmo, centenas de milhares de desktops. Cada ponto de extremidade pode ter dezenas de aplicativos instalados, e talvez você nem esteja ciente do que está instalado (especialmente se os usuários forem administradores locais). Desse modo, até o momento de considerar cada um desses desktops, é possível ter centenas, milhares ou dezenas de milhares de aplicativos únicos instalados em todos os seus desktops. E estamos falando apenas dos aplicativos do Windows! Quando você considera aplicativos Web, é preciso levar em conta cada site exclusivo no mundo todo, pois é plausível que um bom número de aplicativos Web de vários locais dentro e fora da organização tenham funcionado em um fluxo de trabalho produtivo em algum lugar dentro da empresa. Os números realmente começam a explodir, e se você não tomar cuidado pode acabar absolutamente paralisado de medo devido ao grande número de partes móveis envolvidas!

Por isso você precisa ser pragmático. E por isso o que você está oferecendo é uma apólice de seguro. À medida que o ambiente e o mundo muda, você está assegurando que alguns softwares que as pessoas estão usando continuarão sendo executados. Mas não é muito justo para você expandir o que põe no seguro para incluir qualquer aplicativo que qualquer usuário gerencia para instalação, ou qualquer site que o usuário gerencia para localização e navegação, independentemente da qualidade ou durabilidade. Desse modo, você precisa definir algumas categorias. Qual software você garante que funcionará imediatamente, independentemente da mudança? A garantia desse software custa mais, uma vez que você precisa executar um processo de verificação estruturado, mas é necessário para seus aplicativos mais críticos.

Em seguida, qual software você garante que funcionará, e se ele falhar, você atenderá a chamada e o corrigirá? Ainda há um custo quando as coisas não dão certo, mas você acaba pagando apenas por esses aplicativos que falharam, em vez de pagar por tudo (mesmo quando a maioria provavelmente funcione). Em seguida, estão os aplicativos para os quais você não faz garantias - os usuários são livres para usá-los, mas se eles falharem, os usuários se responsabilizam. Por fim, você tem a categoria de aplicativos que realmente prefere que os usuários não usem de jeito nenhum e pode, de fato, tomar algumas medidas para ajudar a impedi-los de fazer isso.

descrição das etapas

Assim que você começar a aplicar essa estrutura, ela começará a mudar seu modo de pensar. Você pode estar disposto a assegurar uma versão de um aplicativo, mas está disposto a assegurar cada versão que cada pessoa por acaso execute, com o contrato de nível de serviço mais alto? Na maioria das vezes, não. E isso é o que você deseja executar: um processo que determine em quais aplicativos você deve investir mais, em quais fazer o investimento para gerenciar seus riscos e depois migrar para a plataforma mais nova.

O risco que você está esperando gerenciar é o da paralisação nos negócios que resulta da falha do aplicativo. Muitos dos aplicativos que você está executando serão compatíveis com o Windows 8 (especialmente se você já estiver executando o Windows 7). Entretanto, alguns podem ter problemas, cuja gravidade pode variar - qualquer item de um aplicativo que "não pareça correto" em uma opção do menu não funcionará na falha de um aplicativo.

Então por onde você começa? Nossos clientes mais bem-sucedidos usam esta abordagem:

  1. Descobrir os aplicativos aos quais você deve ficar atento: comece com os aplicativos que você já está gerenciando centralmente e adicione mais aplicativos que ainda não estejam sendo gerenciados centralmente.
  2. Racionalizar os aplicativos a serem assegurados para que o portfólio de aplicativos gerenciados não aumente tanto a ponto de não ser possível gerenciá-lo, bem como categorizá-los e priorizá-los a fim de orientar seu projeto de compatibilidade de aplicativos.
  3. Testar os aplicativos para confirmar que a funcionalidade comercial que você exige ainda funcione corretamente na nova plataforma.
  4. Corrigir todos os problemas descobertos, o que pode incluir o uso de recursos internos de compatibilidade da plataforma, a alteração de uma política para permitir o comportamento de falha, a atualização ou substituição de um aplicativos e, às vezes, a desativação do aplicativo.

Este artigo se concentra nas duas primeiras etapas: descoberta e racionalização. No fim desse processo, você poderá gerar seu orçamento e plano para seguir com o projeto, de modo que é muito importante executar essas etapas também.

Voltar ao início


Descoberta de aplicativos

No passado, a "Descoberta de Aplicativos" era chamada de "Inventário de Aplicativos": a mudança para "Descoberta de Aplicativos" foi intencional. Descobrimos que a palavra "Inventário" levava os clientes a acreditar que eles tinham que encontrar absolutamente tudo que estava em execução no ambiente e alimentar essa lista completa em um processo de racionalização. E sabe de uma coisa? Você podia se contentar com isso para aplicativos instalados do Windows. (O maior inventário de aplicativos do Windows instalados do qual temos ciência tem 130.000 aplicativos. Sem dúvida, é muito grande, mas nem tanto que impossibilite a racionalização.) No entanto, a migração de uma plataforma para uma nova versão do Windows geralmente também inclui uma nova versão do Internet Explorer. Qual é o tamanho da lista de URLs exclusivas navegadas por todas as pessoas de uma organização? Enorme! Muitos clientes também atualizam a versão do Microsoft Office que estão usando durante a migração (Chris Jackson discute o cálculo para fazer um inventário completo e a racionalização dos documentos do Office em seu artigo na TechNet Magazine " Microsoft Office: o cálculo de compatibilidade do Office". Como você pode ver, muita vezes não faz sentido encontrar tudo. Ao mesmo tempo, você não quer descobrir esses itens que representam um verdadeiro risco aos negócios durante a migração!

O processo de descoberta depende de muitos fatores, incluindo:

Ambiente gerenciado ou não gerenciado: é muito mais fácil fazer descobertas em ambientes gerenciados porque normalmente você controla quais aplicativos são instalados em computadores gerenciados e, portanto, já está ciente deles. Comece com uma lista de aplicativos aprovados e com suporte, bem como os detalhes sobre em quantos computadores ele estão instalados (e talvez até mesmo quantos deles são usados). Em um ambiente não gerenciado o processo é mais desafiador, já que muitas vezes você inicia o projeto sem saber quais aplicativos estão sendo usados, especialmente aqueles que os usuários têm instalados (e, às vezes, foram criados) por conta própria. A maioria das organizações encontra-se no meio do caminho: elas têm alguns aplicativos com suporte e gerenciados centralmente e vários aplicativos que são tratados como exceções (dos quais a empresa nem tem conhecimento).

TI centralizada ou autônoma: as organizações com uma infraestrutura de TI centralizada se beneficiarão com a descoberta de aplicativos, uma vez que já estarão cientes de todos os departamentos dentro da organização e em contato com eles. As infraestruturas de TI descentralizadas oferecem mais agilidade local, mas a execução da tarefa de descoberta requer mais coordenação conforme você consolida as informações e a estratégia pela organização, no centro de custos e pelos limites geográficos.

Ferramentas de inventário de ativos gerenciados disponíveis: as organizações com um ambiente gerenciado muitas vezes têm uma ferramenta de gerenciamento de ativos de software, como o Microsoft Asset Inventory Service (uma ferramenta disponível no Microsoft Desktop Optimization Pack for Software Assurance) ou Microsoft System Center Configuration Manager. Essa ferramenta já pode conter a lista de softwares que é ativamente gerenciada. Alguns clientes optam por manter uma lista separada de softwares gerenciados e com suporte, como o Microsoft SharePoint ou Microsoft Excel. Aqueles que atualmente não estão cientes de quais softwares estão em execução, ou que temem que o inventário de softwares gerenciados possa estar incompleto, muitas vezes procuram por ferramentas adicionais para criar ou suplementar essa lista. Uma maneira direta de fazer o inventário é simplesmente pedindo às unidades de negócios; mas, em algumas organizações, fazer a coleta adicional de dados antes da solicitação pode aumentar enormemente a conformidade das unidades de negócios. O Microsoft Application Compatibility Toolkit fornece uma ferramenta de coleta de inventário para aplicativos instalados do Windows (bem como complementos Web) por esse motivo.

Escopo: o número de computadores dentro de uma organização é certamente um fator ao fazer a descoberta de aplicativos, mas não é o único. O número de funções exclusivas também determina a variação no software usado e pode aumentar a quantidade de trabalho exigido para ajudar a assegurar que toda a funcionalidade comercial continue funcionando após a migração. Com usuários altamente autônomos que podem instalar seus próprios softwares, pode haver até mesmo variações significativas em uma função; determinar qual dessas variações é essencial para a organização em oposição a quais variações simplesmente adicionam complexidade desnecessária pode ser um desafio.

Executando uma descoberta manual

Em um mundo ideal, as unidades de negócios devem ir até você. Afinal de contas, elas é que pedem para assegurar esses aplicativos contra falhas em um ambiente tecnológico que se transforma rapidamente. Assim, não faz sentido que elas, pelo menos, informem o que desejam que você assegure? Entretanto, há chances de que isso não esteja acontecendo (ainda), então você terá algum trabalho para fazer.

Para organizações muito pequenas, pode ser mais vantajoso falar com os usuários individualmente e, talvez, reservar algum tempo observando os respectivos menu Iniciar para ver o que eles têm instalado e conversar sobre quais aplicativos são essenciais e quais foram simplesmente instalados.

No entanto, para a maioria das organizações, visitar cada usuário é uma tarefa totalmente impraticável. Uma abordagem comum nessa situação é escolher um representante de cada departamento ou função para fazer relatórios sobre o software exigido na execução desse trabalho. Essa função pode ter muitos nomes (por exemplo, coordenador técnico do departamento), mas deve ser de alguém que entenda não apenas da empresa, mas que também saiba qual software a impulsiona. Você pode trabalhar com essa pessoa (ou pessoas) para criar a lista de aplicativos necessários para executar esse aspecto da empresa.

Depois de concluir um trabalho que complete essa lista, você também deve considerar a criação de processos formais para adicionar, revisar e remover aplicativos dessa lista mestre - e criar esses processos para serem o mais livre possível de atrito para estimular a participação da empresa nos seus esforços de gerenciamento de ativos de software.

Automatizando o processo de descoberta

Uma vez que a descoberta de aplicativos envolve a correspondência do software com o valor comercial, é um processo que, geralmente, não pode ser totalmente automatizado. Entretanto, em muitos ambientes, os usuários empresariais e os coordenadores de departamento podem não estar cientes de tudo que está direcionando a empresa. Se você estiver executando suas primeiras etapas para as práticas de gerenciamento de ativos de software na organização, gerenciar o risco de perder algo é um sinal de parceria saudável entre a empresa e a tecnologia.

Se você tiver um ambiente gerenciado, é possível obter uma lista atualizada de aplicativos instalados na organização e em cada departamento. Essa lista pode servir com um grande ponto de partida para conversas.

Entretanto, se seu portfólio de aplicativos não for gerenciado centralmente, você pode procurar ferramentas que possam ajudar a criar essa lista e facilitem essa conversa. Muitos clientes optam por usar o Application Compatibility Toolkit, que fornece essa funcionalidade como um download gratuito da Microsoft. A ferramenta Application Compatibility Manager (entre outras ferramentas que são úteis na solução de problemas e na correção de aplicativos) pode coletar inventário de aplicativos de um subconjunto de sua organização ou de toda a organização.

Voltar ao início


Racionalizando aplicativos

À medida que você colabora com a empresa para determinar quais aplicativos devem ser classificados como gerenciados ou com suporte (aplicativos gerenciados são especificamente testados para regressão antes da mudança; aplicativos com suporte não são, mas têm suporte, somente se por acaso venham a falhar no novo ambiente), será preciso tomar algumas decisões difíceis para determinar quais aplicativos pertencem à qual lista.

A primeira análise dos aplicativos descobertos é bastante direta.

Versão do aplicativo: sua organização possui várias versões de um aplicativo, incluindo versões desatualizadas e sem suporte. Novamente, enquanto algumas organizações oferecerão suporte a mais de uma versão em algumas circunstâncias, a maioria gerencia ativamente apenas uma - geralmente uma versão recente, se não a versão mais atual. Ao selecionar uma única versão padrão, você também poderá reduzir os custos de suporte.

Redundância de aplicativos: sua organização tem mais de um aplicativo executando a mesma tarefa - a maioria das organizações pode optar por oferecer suporte a mais de um em algumas circunstâncias, mas gerenciam ativamente apenas um. Ao selecionar um único aplicativo padrão, você pode não apenas reduzir o custo por licenças com descontos por maior volume, mas também reduzir os custos de suporte apenas mantendo um contrato de suporte.

Necessidade de aplicativos: sua organização possui aplicativos que são irrelevantes ao trabalho diário realizado nela. Frequentemente, isso é resultado de alterações passadas na estratégia organizacional, após as quais esses aplicativos nunca foram desativados. A maioria das organizações simplesmente desativa esses aplicativos e apenas ocasionalmente opta por oferecer suporte a eles (embora não os gerencie ativamente) em circunstâncias excepcionais.

Não é um aplicativo: se você estiver iniciando seu processo de racionalização de uma lista gerada automaticamente, provavelmente descobrirá que muitos dos "aplicativos" descobertos não são bem aplicativos - pelo menos, não são aplicativos com os quais você se importe. Muitos pacotes de drivers de software deixam a evidência da instalação em locais onde muitas ferramentas de inventário procuram, como a lista Adicionar/Remover Programas. Você desejará limpar esses rastros da sua lista antes de iniciar as conversas. Você também pode identificar aplicativos com os quais nunca se importará e não precisa inseri-los na discussão com os colegas da empresa com quem está fazendo a racionalização; entre eles estão jogos ou aplicativos de jogos de azar online que muitos clientes descobrem que os usuários instalaram.

Com essa lista reduzida pela remoção de candidatos óbvios, agora você está pronto para iniciar conversas produtivas com a empresa. Nessas conversas, você quer confirmar que essa lista está completa e garantir que você está aplicando uma quantidade apropriada de gerenciamento de risco nesses aplicativos ao entender a gravidade de cada aplicativo. Embora a terminologia individual possa variar, veja alguns níveis de prioridade frequentemente usados a serem considerados:

Crítico para os negócios: um aplicativo que paralisa um departamento, uma função ou até mesmo a organização por completo em caso de falha. Esse é um parâmetro bem alto a ser atingido, e somente alguns aplicativos de cada cliente entram nessa categoria! Os aplicativos críticos para os negócios, em geral, possuem SLAs (contratos de nível de serviço) que estipulam que a equipe de suporte deve responder a uma falha em 15 minutos ou menos. Os aplicativos críticos aos negócios sempre entram na categoria "gerenciados" e exigem testes estruturados antes de uma migração.

Prioridade alta: um aplicativo que executa uma função vital em um departamento ou em uma organização. Uma falha em um aplicativo de alta prioridade pode desabilitar um departamento ou uma única função de negócio da organização. Se um aplicativo de alta prioridade falhar, a organização poderá continuar fechando negócios, mas um ou mais departamentos poderão ficar seriamente prejudicados. Um SLA típico para um aplicativo de alta prioridade é avaliado em horas. Os aplicativos de alta prioridade geralmente entram na categoria "gerenciados" e exigem testes estruturados antes de uma migração.

Importante: um aplicativo usado com frequência, mas que não causará a interrupção do trabalho se falhar. Os SLAs para aplicativos importantes geralmente são avaliados em dias. Os aplicativos importantes geralmente entram na categoria "com suporte" e dependem mais de um teste orgânico e piloto do que de testes formais, exceto em casos excepcionais.

Opcional: um aplicativo aprovado, mas limitado em uso e indiretamente relacionado a uma função importante de negócios. Aplicativos nessa categoria, normalmente, não são cobertos por um SLA e o suporte pode ser considerado como "melhor esforço". Aplicativos opcionais entram, quando muito, na categoria "com suporte", dependendo de testes orgânicos e piloto em vez de testes formais para identificação de falhas.

A atribuição de níveis de prioridade a aplicativos muitas vezes é um processo subjetivo e, como tal, pode precisar de revisão periódica. Apoiamos práticas formais de gerenciamento de ativos de software, que mantêm uma equipe ou comissão para monitorar o portfólio de aplicativos mesmo entre implantações do sistema operacional.

O aprimoramento da proficiência do gerenciamento de ativos de software também pode ter outras vantagens. Por exemplo, muitos clientes acham que estão mais aptos a otimizar seus custos de licenciamento e reduzir o risco de penalidade por executar software não licenciado. Eles também acham que podem otimizar os respectivos ambientes existentes e fazer mais com o quê já têm.

Identificando aplicativos críticos para os negócios

Alguns aplicativos críticos para os negócios são fáceis de identificar, enquanto outros não são. Se a sua organização faz negócio por meio da presença na Internet, aplicativos de processamento de texto, manipulação de imagens e codificação de páginas, os aplicativos podem ser considerados críticos para os negócios. A categorização de crítico para os negócios também varia conforme a função da tarefa. Para um call center, um aplicativo que monitora a estabilidade do servidor pode ser considerado crítico, enquanto outros departamentos não o consideram valioso.

Se sua organização tiver um DRP (plano de recuperação de desastres) ou um BCP (plano de continuidade de negócios) definido, os aplicativos críticos para os negócios já devem ter sido identificados nesses planos.

Alguns critérios para identificar aplicativos críticos para os negócios são:

  • O aplicativo representa uma função básica da organização (por exemplo, um software de processamento de texto ou design para uma editora).
  • A organização sofrerá um impacto financeiro significativo se o aplicativo falhar.
  • Se o aplicativo falhar depois do expediente, alguém será avisado em questão de minutos.

Identificando aplicativos de alta prioridade

Os aplicativos de alta prioridade podem ser fáceis de identificar no seu próprio departamento, mas difíceis em outros. Às vezes, é possível identificar um aplicativo de alta prioridade pela porcentagem de computadores em que foi instalado, mas isso pode ser um engano. Por exemplo, um aplicativo desenvolvido internamente para monitorar a quantidade de toner nas impressoras da empresa pode ser implantado em todos os computadores, mas ser realmente usado (ou ser considerado essencial) por poucas pessoas. Se a sua organização tiver um DRP ou um BCP em vigor, os aplicativos de alta prioridade para os negócios já poderão ter sido identificados nesses planos.

Alguns critérios para identificar aplicativos de alta prioridade para os negócios são:

  • O aplicativo é usado na maioria dos turnos de trabalho.
  • O aplicativo é usado por uma grande porcentagem de usuários na organização.
  • Sem o aplicativo, seria difícil para a organização ou o departamento realizar o negócio normalmente.
  • Sem o aplicativo, as operações diárias seriam afetadas e poderia haver um impacto financeiro considerável.

Voltar ao início


Mapeando aplicativos para funções

O conceito de funções de usuário pode ser instrumental para determinar um excelente plano de implantação do sistema operacional. Os usuários com uma determinada função tendem a usar muito do mesmo software, e poder iniciar a implantação após a conclusão do trabalho de compatibilidade de aplicativos para essa função, em vez de aguardar até que você tenha concluído o trabalho em todos os softwares da sua organização, pode não somente alimentar a moral da equipe (que agora tem uma métrica de sucesso da qual se orgulhar), mas também promover a aprendizagem importante de funções subsequentes que, de outra forma, podem não ser beneficiadas com a implantação.

As funções/equipes normalmente definidas incluem:

  • Recursos humanos
  • Operadores de informações
  • Suporte de TI
  • Marketing
  • Desenvolvedor
  • Executivo

Também há, é claro, aplicativos padrão em todas as funções. Os exemplos podem incluir aplicativos de email e antivírus.

As funções de implantação também podem ser priorizadas para reduzir o esforço necessário nos testes de compatibilidade de aplicativos. As configurações baseadas em função para operações críticas devem passar pela maioria dos testes e as funções de prioridade mais baixa podem passar por menos quantidades de testes - impulsionando o conceito de investir com inteligência no gerenciamento de riscos de acordo com o risco real, em vez de em uma motivação cara e, em essência, inexequível pela perfeição.

Voltar ao início


Próximas etapas

O processo descrito neste documento deve produzir um catálogo de aplicativos para a sua organização que seja priorizado em termos de testes necessários, funções de usuário específicas e dos aplicativos que serão implantados com o Windows 8. O catálogo fornece as informações brutas necessárias para avançar para as próximas etapas no processo. Usando as informações do seu catálogo de aplicativos, suas próximas etapas deverão incluir:

  • Formação da equipe: depois de compreender o escopo do trabalho envolvido na sua organização, você precisará formar a equipe para cuidar das decisões técnicas e comerciais que deverão ser tomadas. O tamanho e o escopo da equipe dependerá do tamanho e do escopo da sua implantação. Você pode ser o gerente de projetos, coordenador de testes e recurso de trabalhos gerais. As organizações maiores precisarão de uma equipe mais formal com funções bem definidas. As orientações para reunir uma equipe podem ser encontradas no Microsoft Deployment Toolkit.
  • Criação de um plano de teste: os aplicativos gerenciados que serão formalmente testados exigirão um plano estruturado de como executar esses testes. Quanto trabalho a equipe técnica executará para descobrir os problemas de compatibilidade? Como você administrará os testes de aceitação do usuário? Esses fatores têm um impacto significativo na velocidade e no custo.
  • Criação de um ambiente de teste: os aplicativos gerenciados exigirão um ambiente no qual executar testes de compatibilidade de aplicativos. Em geral, ele também é usado para realizar os testes nas imagens de implantação. Considere o uso de software de virtualização, como o Microsoft Hyper-V, uma alternativa para computadores dedicados à maioria dos testes de aplicativo; isso ajudará a reduzir os custos de hardware e a simplificar as redefinições de ambiente para o próximo aplicativo.
  • Correção: identifique aplicativos com problemas de compatibilidade e encontre a melhor correção. Teste a correção para garantir que os problemas foram mesmo resolvidos. O Application Compatibility Toolkit contém informações sobre correções de problemas de compatibilidade em sua documentação.
  • Criação de piloto: identifique os membros do seu grupo de teste de implantação piloto. Você deve selecionar pessoas que representem cada função principal dentro da organização para que seja possível obter comentários valiosos sobre os aplicativos, especialmente aqueles que têm suporte (mas não são gerenciados) e, portanto, não foram formalmente testados antes do piloto. Considere a posição de alta gerência no grupo piloto. Alguns executivos que com conhecimento técnico podem optar por dedicar um computador ao teste piloto.
  • Aceitação de aplicativos: conforme os aplicativos gerenciados são validados por meio do teste de aceitação do usuário, registre cada aceitação. Assim que todos os aplicativos usados por uma função forem certificados, as implantações piloto podem ser iniciadas e gradualmente expandidas até que toda a implantação esteja completa.
  • Implantação: assim que todos os aplicativos gerenciados forem certificados, o processo se tornará mecânico. Continue a implantação até passar por todos os computadores da organização.

Pode haver ainda outras tarefas envolvidas, dependendo das necessidades e da cultura da sua organização. As decisões que você tomar em relação à prioridade e ao teste dos aplicativos também podem ser afetadas pela estrutura da sua organização. Por exemplo, você pode querer incluir uma etapa para reavaliar a lista de aplicativos a serem implantados com o sistema operacional para verificar se há novos aplicativos que devem ser adicionados.

Essas etapas adicionais são discutidas em mais detalhes em outra documentação, como no Microsoft Deployment Toolkit.

Voltar ao início

Principais tarefas

Sobre o autor

Foto de Chris JacksonChris Jackson, também conhecido como " O cara da compatibilidade de aplicativos", é um consultor principal e líder técnico da equipe SWAT da Experiência com Aplicativos do Windows. Um especialista mundialmente reconhecido no campo da compatibilidade de aplicativos do Windows, Chris criou documentações técnicas, treinamentos e ofertas de serviços usados dentro e fora da Microsoft, com base nos anos de experiências reais com clientes corporativos e fornecedores independentes de software.

Chris é o autor ou coautor de vários documentos e artigos técnicos que discorrem sobre a compatibilidade de aplicativos, além de ser um colaborador da TechNet Magazine. Ele também é um palestrante de destaque em grandes conferências do setor no mundo todo, incluindo TechEd, IT Forum e Microsoft Management Summit.

Recursos relacionados

Mantenha-se informado

A Microsoft está realizando uma pesquisa online para saber sua opinião sobre o site. Se você optar por participar, a pesquisa online lhe será apresentada quando você sair do site.

Deseja participar?