Exportar (0) Imprimir
Expandir Tudo
Expandir Minimizar
Este tópico ainda não foi avaliado como - Avalie este tópico

Planejamento de metas da implantação

Planejamento

Publicado em: 30/11/2006

O planejamento é a primeira fase do processo de implantação global. A fase de planejamento consiste em várias etapas, desde a previsão das metas e da visão da implantação até a coleta de dados e recursos que as equipes usarão nas fases seguintes. A primeira etapa nessa fase é a previsão da implantação.

Nesta página

A fase de previsão
A fase de planejamento

A fase de previsão

A fase de previsão unifica a equipe do projeto com uma visão comum. Ela culmina com um escopo bem definido de trabalho e estrutura do projeto, indicando o acordo entre equipe e cliente quanto à direção do projeto.

Tarefas principais

A Tabela 3 lista as principais tarefas e os resultados finais da fase de previsão, assim como seus proprietários.

Tabela 3. Principais tarefas da fase de previsão , resultados finais , e proprietários

Tarefas principais

Resultados finais

Proprietários

Definindo uma equipe

Todas as seis funções da equipe representadas

Gerenciamento do produto; Gerenciamento do programa

Avaliando a situação atual

Informações compiladas no ambiente computacional

Gerenciamento do programa

Definindo as metas comerciais

Declaração de problemas e objetivos comerciais (parte do documento de visão/escopo)

Gerenciamento do produto

Criando a declaração de visão e definindo o escopo

Uma declaração de visão e definição do escopo (parte do documento de visão/escopo)

Gerenciamento do produto

Criando perfis de usuário

Identificação dos usuários e suas necessidades (parte do documento de visão/escopo)

Gerenciamento do programa

Desenvolvendo o conceito da solução

O conceito da solução (parte do documento de visão/escopo)

Gerenciamento do programa

Criando o documento de avaliação de risco

Um documento preliminar de avaliação de risco e uma lista de principais riscos (a lista faz parte do documento de visão/escopo)

Gerenciamento do programa

Escrevendo uma estrutura de projeto

Um conjunto de padrões inicial (parte do documento de visão/escopo)

Gerenciamento do programa

Aprovando a etapa

Documento de visão/escopo montado e todo o trabalho da fase de previsão aprovado

Todas as funções

Foco da equipe

A Tabela 4 lista as principais áreas de foco de cada grupo de funções durante a fase de previsão.

Tabela 4. Grupos de funções e foco na fase de previsão

Grupo de funções

Foco

Gerenciamento do produto

  • Identificação das necessidades e dos requisitos do cliente

  • Documento de visão/escopo

Gerenciamento do programa

  • Documentação das metas de design

  • Conceito da solução

  • Estrutura do projeto

Desenvolvimento

  • Criação de protótipos

  • Avaliação do desenvolvimento e das opções de tecnologia

  • Análise de viabilidade

Teste

  • Estratégias de teste

  • Critérios de teste

  • Relatórios

Experiência do usuário

  • Necessidades e implicações de formação de usuários

Gerenciamento de liberação

  • Consideração de implantação

  • Gerenciamento de operações e capacidade de suporte

  • Aceitação operacional

  • Descoberta de rede

  • Inventário de aplicativos e hardware

  • Interface com a equipe de recursos de segurança e de operações de TI

A equipe de recursos de segurança e de operações de TI deve ser incluída nas avaliações, para garantir que haja uma visão precisa de suas respectivas áreas.

Etapa intermediária

A fase de previsão do Modelo de processo do MSF contém uma etapa intermediária. Use as informações e técnicas deste guia para completar essa etapa, que é uma lista prioritária de aplicativos que o gerenciamento comercial decidiu incluir na solução.

Equipe de recursos e documentos de ajuda do trabalho

Os seguintes documentos são usados na fase de previsão:

  • Visão/Escopo

  • Modelo de avaliação

  • Guia da Equipe de Recursos de Implantação

  • Guia da Equipe de Recursos de Preparação das Operações

  • Guia da Equipe de Recursos de Segurança

  • Guia da Equipe de Recursos de Teste

O Modelo de equipe do MSF: Definindo a equipe

A Microsoft desenvolveu o Modelo de equipe do MSF durante vários anos, para compensar algumas desvantagens impostas pela estrutura linear e de cima para baixo das equipes de projeto tradicionais. As equipes organizadas sob o Modelo de equipe do MSF são pequenas e multidisciplinares, nas quais os membros dividem responsabilidades e contrabalançam as competências uns dos outros para manter o foco rígido no projeto à mão. Elas compartilham uma visão comum do projeto, um foco na implantação, altos padrões de qualidade (às vezes chamados de busca por defeito zero) e uma grande vontade de aprender. O Modelo de equipe do MSF não prescreve um líder único; os membros trabalham juntos como equipe de colegas com suas próprias funções definidas, cada uma delas tendo por ponto focal diferentes pontos do processo.

Grupos de funções

O Modelo de equipe do MSF define seis funções ou grupos de funções interdependentes e multidisciplinares com a responsabilidade de implementar diferentes aspectos do projeto (consulte a Figura 3). A organização pode escolher entre alterar ou adicionar as responsabilidades listadas conforme forem apropriadas ao projeto, desde que todas as seis funções estejam representadas.

Bb490158.SE_PlanBulid03(pt-br,TechNet.10).gif

Figura 3. O Modelo de equipe do MSF
Grupo de funções de gerenciamento do produto

O gerente do produto atua como advogado do cliente na equipe do projeto, assegurando que a equipe cuide dos requisitos, preocupações, questões e comentários do cliente em todo o projeto. Da mesma forma, o gerente do produto atua como a ligação entre a equipe e o cliente, guiando comunicação de alto nível e gerenciando as expectativas do cliente.

Neste projeto, é provável que o gerente do produto seja um diretor de TI ou um executivo de alto nível com o poder de tomar decisões em relação a escopo, custo e recursos do projeto. O gerente de produto deve demonstrar que tem capacidade de liderança e que realmente acredita no projeto e nos benefícios a serem obtidos por sua implementação.

As responsabilidades do Gerenciamento do produto em um projeto do BDD 2007 incluem:

  • Marketing

  • Valor comercial

  • Defesa do cliente

  • Planejamento do produto

Observação   O gerente do produto deve providenciar uma descrição por escrito de cada uma dessas responsabilidades, de modo que fiquem claramente definidas para o restante da equipe.

Grupo de Funções de Gerenciamento do Programa

O gerente do programa funciona como um “diretor de tráfego” que gerencia e coordena as atividades dos outros integrantes da equipe. O Gerenciamento do programa é responsável por definir o cronograma e relatar o status do projeto. Enquanto que o Grupo de Funções de Gerenciamento do Produto facilita a comunicação externa entre a equipe e o cliente, o Grupo de funções de gerenciamento do programa é responsável por facilitar a comunicação interna entre os integrantes da equipe do projeto. Os deveres do Gerenciamento do programa incluem estabelecer metas de design, dirigir a criação da especificação funcional e o plano do projeto e coordenar o uso dos recursos de desenvolvimento pelos Grupos de funções de desenvolvimento e teste.

O Gerenciamento do programa requer uma compreensão clara de todo o projeto: o que deve ser feito, como deve ser feito, quando deve ser feito e quem o fará. Os gerentes do programa devem ser organizadores capacitados e proficientes tecnicamente. Eles não precisam interagir com o pessoal técnico em um nível muito detalhado, mas devem ter um entendimento técnico suficiente para trabalhar com eles de maneira bem informada e inteligente.

Grupo de Funções de Desenvolvimento

Os integrantes da equipe na função de Desenvolvimento são responsáveis pelo design, pela criação e pelo teste de unidade das arquiteturas de linha de base e de imagem. Isso compreende escrever e adaptar scripts para facilitar a instalação autônoma do Windows e do 2007 Office system em todas as plataformas de hardware incluídas no escopo do projeto. Além de realizar as tarefas de desenvolvimento reais, os desenvolvedores são responsáveis por documentar seu trabalho, inclusive os detalhes de configuração e os procedimentos de instalação. O Grupo de Funções de Desenvolvimento, muitas vezes, é ocupado por vários indivíduos, dependendo da natureza e da complexidade do projeto.

Os desenvolvedores devem demonstrar um alto grau de conhecimento técnico, bem como uma compreensão da arquitetura computacional da organização e de como o Windows e o 2007 Office system se enquadram nela. Eles devem estar familiarizados com os produtos que estão sendo implantados, seus conjuntos de recursos e os componentes pelos quais são especificamente responsáveis. Não atribua as mesmas pessoas aos Grupos de Funções de Desenvolvimento e de Teste, porque isso não proporciona uma verificação adequada do trabalho de desenvolvimento.

Dependendo de suas responsabilidades, os desenvolvedores devem demonstrar proficiência nas seguintes áreas:

  • Script em lotes

  • Conhecimento de VBScript

  • Familiaridade com o Ambiente de Pré-Instalação do Windows (Microsoft Windows PE)

  • Métodos e ferramentas de configuração do Windows

  • Usando e configurando o Windows, inclusive configurações de segurança, diretivas, serviços e rede

  • Uso, implantação, configuração e manutenção do 2007 Office system

  • Usando o Microsoft Office 2007 Resource Kit

  • Imagem de discos rígidos, inclusive o uso de Sysprep para preparar discos para imagem

  • Uso, implantação e configuração de ferramentas de imagem de discos

  • Configurando hardware de desktop e laptop, inclusive o sistema BIOS

  • Ferramentas de pacote de instalação de aplicativos

Para o projeto de implantação, o Grupo de Funções de Desenvolvimento pode ser dividido em subequipes, com freqüência chamadas de equipes de recursos , cada equipe de recursos sendo responsável por áreas como:

  • Sistema de geração de imagem de computador.

  • Gerenciamento de aplicativos.

  • Atualização da compatibilidade de aplicativos.

  • Processo de implantação LTI.

Grupo de Funções de Teste

Os integrantes da equipe que ocupam o Grupo de Funções de Teste são responsáveis por testar a arquitetura e a documentação associada quanto à especificação funcional e garantir que a documentação atenda aos requisitos designados pelo escopo.

Os testadores devem ter experiência em testes e uma compreensão do que o teste requer. Conseqüentemente, devem ser bastante técnicos e orientados, ter um entendimento do ambiente operacional e estar comprometidos em localizar erros de modo proativo. A familiaridade com o ambiente do sistema operacional Windows e com os aplicativos a serem implantados é valiosa.

Grupo de Funções de Experiência do Usuário

Os membros de equipe que ocupam o Grupo de Funções de Experiência do Usuário são responsáveis por definir os requisitos de treinamento e comunicação dos usuários. Enquanto que o Gerenciamento do produto funciona como defesa do cliente, atuando em nome das pessoas que estão encomendando ou pagando pelo projeto, o Grupo de Funções de Experiência do Usuário funciona como defesa do usuário, atuando em nome das pessoas que utilizarão a solução diariamente. Neste projeto, a Experiência do usuário também é responsável por instruir os usuários sobre os benefícios da solução e como eles podem utilizá-la para cumprir seus deveres com mais eficiência.

Os especialistas em Experiência do usuário devem estar familiarizados com os usuários e os trabalhos que eles executam, para conseguirem avaliar as necessidades de comunicação e de treinamento dos usuários. Eles também devem ser capazes de criar e conduzir programas de treinamento.

Grupo de Funções de Gerenciamento de Liberação

O Grupo de Funções de Gerenciamento de Liberação é responsável por coordenar as atividades necessárias para garantir o êxito da distribuição e por definir e documentar as estratégias e os processos de gerenciamento do ciclo de vida. Os membros que ocupam essa função atuam como advogados do suporte às Operações de TI na equipe, inclusive administrando o teste de aceitação, distribuindo a solução e ajudando a disponibilizar a solução ao pessoal do suporte operacional em andamento.

O Gerenciamento de Liberação deve estar familiarizado com o ambiente operacional, inclusive com suporte técnico. Os integrantes da equipe também devem compreender o impacto que a solução terá sobre o ambiente anterior.

O Grupo de Funções de Gerenciamento de Liberação deve incluir recursos para gerenciar o processo de inventário de computadores e o processo de análise de rede. Os integrantes da equipe trabalham para garantir que essas informações sejam transmitidas às equipes de desenvolvimento.

Atribuindo funções

Embora o MSF defina seis grupos de funções de equipe distintos, nem toda a equipe precisa ter seis pessoas. Dependendo da natureza e da extensão do projeto, a organização pode ter uma equipe de projeto básica composta de mais ou menos seis pessoas, algumas das quais podem trabalhar no projeto meio-período.

Em uma organização de grande porte, muitas vezes faz sentido dedicar alguns membros do projeto às suas tarefas, para criar uma arquitetura de desktop robusta e com suporte. Membros dedicados da equipe empenham 100% de seu tempo ao projeto e não têm responsabilidades de operações cotidianas fora do projeto. Em organizações menores, essa configuração pode não ser viável e os integrantes da equipe que dividem seu tempo entre operações do projeto e cotidianas podem gerenciar o escopo do projeto. Leve em conta estas considerações ao planejar e reunir uma equipe para o projeto.

O Modelo de equipe do MSF: Escalando equipes

O tamanho das equipes depende, em grande parte, do tamanho da implantação e da complexidade das responsabilidades de cada equipe.

Montando equipes pequenas

Em projetos pequenos ou de recursos limitados, considere montar uma pequena equipe básica na qual pelo menos um dos membros assuma as responsabilidades de duas ou mais funções. As funções para um projeto de implantação de desktop podem ser combinadas, por exemplo, assim:

  • Gerenciamento de Liberação e Experiência do Usuário.

  • Teste e Experiência do Usuário.

  • Gerenciamento do programa e Gerenciamento de liberação.

Algumas funções não devem ser combinadas. O desenvolvedor não deve ser responsável pelo teste, pois tal combinação não proporciona uma verificação adequada do trabalho de desenvolvimento. Da mesma forma, um integrante da equipe não deve ser responsável pelas funções de Gerenciamento do Programa e Gerenciamento do produto. Embora possa ser tentador atribuir essas funções à mesma pessoa, elas podem representar interesses conflitantes.

Projetos muito pequenos podem ter uma equipe de projeto básica composta de apenas três pessoas: uma responsável por Gerenciamento do programa e Gerenciamento de liberação; outra responsável por Desenvolvimento; e outra responsável por Teste, Experiência do usuário e Gerenciamento do produto. O pessoal de TI pode optar por uma combinação diferente, dependendo da natureza do projeto e das habilidades dos integrantes da equipe, desde que tenham em mente as restrições citadas anteriormente.

Montando equipes maiores

Em projetos maiores, pode convir ao departamento de TI montar uma equipe na qual algumas funções incluam mais de um membro. Isso acontecerá com mais freqüência no Grupo de Funções de Desenvolvimento, que pode ser divido em várias equipes de recursos, dependendo da natureza do projeto.

Crie equipes de recurso com base em divisões lógicas de trabalho. Por exemplo, o TI pode criar uma equipe de recursos de Desktop, que executa atividades de desenvolvimento relacionadas ao Windows; uma equipe de recursos de Aplicativos, que executa atividades relacionadas ao 2007 Office system; e uma equipe de recursos de Mensagens/Internet, que executa atividades relacionadas ao Microsoft Office Outlook® e ao Windows Internet Explorer®. Cada uma dessas equipes de recursos pode ter um ou mais desenvolvedores, sendo que cada um pode trabalhar em uma ou mais equipes de recursos. À medida que mais recursos forem adicionados à equipe, tenha cuidado para garantir que a equipe não se torne grande demais e perca a eficácia como trabalho em grupo.

O Modelo de equipe do MSF: Atribuindo integrantes da equipe às funções

Embora cada função precise estar representada durante a fase de previsão, não é necessário montar a equipe inteira neste momento, tampouco que todos os integrantes da equipe já estejam se dedicando integralmente ao projeto. Cada função, contudo, deve ter um líder identificado durante a fase de previsão.

Todas as seis funções são partes vitais da equipe. Por esse motivo, faça um esforço para empregar integralmente cada líder no projeto desde o início, sem nenhum deles trabalhando em outros projetos. Na realidade, é óbvio que nem sempre é possível que todos os integrantes da equipe abandonem totalmente suas outras responsabilidade para começar a trabalhar no projeto de implantação de desktop.

Ao atribuir funções, siga estas orientações:

  • As pessoas que ocuparão os Grupos de Funções de Gerenciamento do Produto e de Gerenciamento do Programa devem estar com dedicação total já neste momento, se possível.

  • Embora o líder de Desenvolvimento possa estar concluindo outros projetos durante a fase de previsão, essa pessoa deve ter dedicação total a este projeto, se possível. Espere para adicionar mais integrantes da equipe ao Grupo de Funções de Desenvolvimento durante a fase de desenvolvimento.

  • Se for necessário, o líder de Teste pode ter outras atribuições durante a fase de previsão, mas deve estar envolvido com o projeto desde o início e estar disponível para acompanhar decisões importantes. Espere para adicionar mais integrantes da equipe ao Grupo de Funções de Teste durante as fases de desenvolvimento e estabilização, se necessário.

  • O líder de Experiência do usuário coletará informações de perfis de usuário durante a fase de previsão. Essa pessoa pode ter outras atribuições durante a fase de previsão, se necessário. Espere para adicionar mais integrantes da equipe ao Grupo de Funções de Experiência do Usuário durante a fase de desenvolvimento e implantação.

  • O líder do Gerenciamento de Liberação ajudará a avaliar a situação atual durante a fase de previsão. Essa pessoa pode ter outras atribuições durante a fase de previsão, se necessário. Espere para adicionar mais integrantes da equipe ao Grupo de Funções de Gerenciamento de Liberação durante a fase de implantação.

Todo integrante da equipe que trabalhar em outros projetos durante a fase de previsão deve demonstrar a capacidade de gerenciar bem seu tempo e atenção para não negligenciar suas responsabilidades no projeto. Ter integrantes da equipe trabalhando em outros projetos é um risco que deve ser registrado e acompanhado como um risco.

Se o Gerenciamento do programa ou outros líderes souberem de antemão quem será adicionado à equipe em um estágio posterior, anote isso no documento de visão/escopo. Não é crucial envolver esses futuros integrantes da equipe no projeto, ainda. Considere disponibilizar-lhes a documentação do projeto para que leiam de acordo com seus próprios critérios.

Avaliando a situação atual

Um mapa só tem valor para viajantes quando eles sabem onde estão. Da mesma forma, a TI não consegue prever com eficácia um projeto de implantação de desktop sem ter uma compreensão clara do estado atual do ambiente computacional da organização. Isso compreende informações precisas e atualizadas sobre assuntos como a arquitetura dos sistemas da organização, inclusive o hardware e o software já implantados e em quais combinações, e os procedimentos operacionais em vigor atualmente na organização.

Imagine o projeto de implantação como uma fase em um processo contínuo de gerenciamento do ciclo de vida da tecnologia, que dura anos ou até mesmo décadas. Quando o projeto começa, portanto, as equipes se baseiam no trabalho realizado e na experiência adquirida ao longo do tempo. Concluído o projeto, as equipes usam esse trabalho e essa experiência como informação para ações futuras de gerenciamento do ciclo de vida.

Como parte da decisão de explorar a implantação do Windows ou do 2007 Office system, alguém do departamento de TI deve ter avaliado o ambiente computacional atual como ponto de partida para a tomada de decisões. O departamento de TI pode optar por conduzir ele mesmo essa avaliação ou por contratar uma firma de consultoria. O resultado de tal avaliação é, normalmente, um documento que descreve detalhadamente as averiguações do avaliador, o que pode incluir recomendações para ações futuras. Esse documento deve conter informações suficientes sobre o ambiente computacional, inclusive sobre rede, domínio e localização física, para permitir um planejamento bem informado.

Durante a fase de previsão, cabe à equipe do projeto reunir informações relevantes sobre a situação atual e detectar deficiências que o projeto possa sanar. O processo de coleta de informações pode ser simplesmente obter documentos como aquele descrito anteriormente no departamento de TI. Se tais documentos não existirem, a equipe talvez tenha que reunir a documentação existente de várias fontes em toda a organização e avaliá-la quanto à precisão e abrangência ou conduzir ela mesma uma breve análise.

Esse momento, muitas vezes, é ideal para dar início aos processos de detecção de rede e inventário de computadores, para obter uma visão mais precisa do ambiente. Normalmente, o Grupo de Funções de Gerenciamento de Liberação se encarrega de avaliar a situação atual.

O documento de visão/escopo

O principal resultado final da fase de previsão é documento de visão/escopo, que oferece uma direção clara para o projeto e estabelece as expectativas para a organização, assim como para patrocinadores e participantes. Ele é composto de:

  • Metas comerciais. Inclui declarações que definem os problemas que o projeto pretende solucionar e os objetivos comerciais

  • Declaração de visão. Estabelece uma visão para o projeto

  • Definição de escopo. Estabelece o escopo do projeto

  • Perfis de usuário. Identifica os usuários que serão beneficiados pela solução

  • Conceito da solução. Descreve a abordagem da equipe para planejar o projeto

  • Estrutura e padrões do projeto. Orientação a ser seguida pela equipe

  • Riscos. Lista os principais riscos identificados pelo documento de avaliação de riscos

Definindo as metas comerciais

As organizações efetuam implantações de infra-estrutura para atender a necessidades comerciais. Quando o projeto está na fase de previsão do MSF, essas necessidades devem estar claras o bastante para serem expressas e definidas como declarações de problemas e objetivos comerciais correspondentes.

As declarações de problemas identificam deficiências percebidas no ambiente computacional. Os objetivos comerciais definem as metas que a equipe espera atingir, sugerindo ações a serem tomadas para reduzir os problemas identificados. Esses problemas são chamados, às vezes, de oportunidades de negócio ,, pois representam uma oportunidade para a organização aprimorar seus processos.

A equipe não deve se incumbir do projeto com o único propósito de implantar a tecnologia mais recente. Em vez disso, ela deve identificar deficiências e oportunidades específicas na infra-estrutura computacional da organização e no próprio negócio, posicionando o projeto diretamente sobre essas áreas. O Grupo de Funções de Gerenciamento do Produto se encarrega de definir as metas comerciais, que devem ter, no máximo, uma página.

Uma declaração de problema e um objetivo comercial típicos deste projeto seriam:

A organização ainda não tem um padrão de sistema operacional definido. Diversas fusões e aquisições resultaram em diferentes filiais executando Microsoft Windows Me , Windows 2000 Professional , e Windows 98. Essa falta de padronização tem acarretado custos crescentes com suporte. Migrar para um padrão único de sistema operacional representaria uma oportunidade de obter reduções mensuráveis nos custos com suporte.

Aqui, a declaração do problema é a descrição das desvantagens conhecidas de ter vários sistemas operacionais implantados em toda a organização. O objetivo comercial é minimizar ou eliminar essas desvantagens por meio da adoção de um padrão único.

Definindo a visão e o escopo

As principais etapas da fase de planejamento incluem criar a declaração de visão e definir o escopo do projeto. O escopo é o resultado da declaração de visão.

Criando a declaração de visão

A declaração de visão estabelece uma visão de longo prazo para lidar com as declarações de problemas e atingir as metas comerciais. Tendo, normalmente, apenas um ou dois parágrafos de extensão, a declaração de visão não está ligada ao trabalho real que a equipe espera executar como parte do projeto atual, porém deve contrabalançar interesses conflitantes para propiciar uma visão que possa ser compartilhada entre os integrantes da equipe e fornecer contexto para futuras tomadas de decisão.

Uma declaração de visão típica de um projeto de implantação do Windows poderia ser:

O departamento de TI selecionará e implementará uma única plataforma computacional em toda a empresa para cortar o volume de chamadas do centro de suporte em 10% e permitir que os técnicos de campo gastem, pelo menos, 15% de seu tempo em projetos de valor agregado, em lugar de suporte reativo.

Definindo o escopo

O escopo assume a visão global do projeto, conforme expressa na declaração de visão, e incorpora restrições impostas por tempo, recursos, orçamento e outras limitações. Geralmente, este processo envolve usar liberações com versão para definir uma abordagem iterativa do projeto, na qual a equipe do projeto identifica as necessidades mais essenciais da organização e prioriza a implantação com base nessa avaliação.

Por exemplo, a visão poderia solicitar a implantação do Windows Vista, 2007 Office system e um conjunto de aplicativos de outros fabricantes em toda a organização. Restrições de tempo e orçamentárias poderiam tornar impossível realizar a visão inteira como parte de um mesmo projeto. O escopo, por conseguinte, restringiria o projeto atual à implantação do Windows Vista nos computadores desktop e portáteis e do 2007 Office system nos computadores desktop em toda a organização. Outros projetos, no futuro, poderiam compreender a implantação do 2007 Office system nos computadores portáteis e outros programas de software em todos os computadores da organização. Dependendo das necessidades da organização, o escopo poderia restringir a implantação por departamento, por fabricante de computador, por localização geográfica ou por outros fatores.

O triângulo de compensações exibido pela Figura 4 é um componente importante do MSF e ajuda a definir o escopo do projeto. O triângulo de compensações dita que recursos, cronograma e recursos (facilidades) são três elementos interconectados de qualquer projeto e que restringir ou aperfeiçoar um ou mais desses elementos exigirá compensações dos demais. Por exemplo, uma equipe de projeto com recursos disponíveis finitos (pessoal, orçamento, instalações) que se compromete com uma data de conclusão próxima terá, provavelmente, que fazer compensações referentes ao conjunto de recursos (facilidades) para atender à data, adiando a implantação em alguns locais remotos ou em alguns sistemas.

Bb490158.SE_PlanBulid04(pt-br,TechNet.10).gif

Figura 4. O triângulo de compensações do MSF

Criando perfis de usuário

O êxito do projeto depende de cada integrante da equipe possuir noções básicas precisas dos usuários e de suas necessidades. Perfis de usuário identificam os usuários de modo que a equipe possa avaliar as expectativas, os riscos e as metas do projeto e as restrições. Tais perfis, normalmente, contêm informações como localizações geográficas, funções de cargo, estrutura organizacional e padrões de comunicação dos usuários.

A finalidade dos perfis de usuário é delinear quem são os usuários da solução e como serão suas relações com ela. Talvez convenha ao pessoal de TI esboçar diferentes perfis para os usuários , definidos como aqueles que usarão pelo menos parte da solução para executar suas funções comerciais, e os profissionais de TI que serão responsáveis por implantar e manter a solução. Portanto, pode ser necessário identificar diferentes classes de usuário e desenvolver perfis para todas elas.

Desenvolvendo o conceito da solução

O conceito da solução delineia uma abordagem que constitui a base para o planejamento e o escopo do trabalho de análise e investigativo necessários para criar uma especificação. Agora que a equipe já identificou o problema comercial e definiu a visão e o escopo, ela deve criar o conceito da solução, que explica, de maneira geral, como a equipe pretende atender aos requisitos do projeto. O Gerenciamento do projeto se encarrega de desenvolver o conceito da solução, que deve ser razoavelmente sucinto, estendendo-se por poucas páginas.

Enquanto o escopo descreve o que a equipe pretende fazer, o conceito da solução descreve como a equipe pretende executá-lo. O conceito da solução deve se conservar relativamente genérico e tratar de assuntos como:

  • As tarefas de cada uma das seis funções da equipe e as pessoas selecionadas para ocupá-las (pelo menos seus líderes, nesse momento).

  • Uma visão geral do projeto, inclusive as fases, suas etapas de acompanhamento e seus resultados finais, com base no Modelo de processo do MSF.

  • Fatores que delineiem como o êxito do projeto deve ser definido e medido.

  • Cenários de exemplo para quando e como o sistema for implementado e como os usuários devem empregar a nova tecnologia.

  • Uma lista de verificação dos requisitos que devem ser satisfeitos antes de a solução passar para produção.

  • Um esboço geral inicial do cronograma da fase de planejamento.

Escrevendo uma estrutura de projeto

A estrutura do projeto define como a equipe gerencia e oferece suporte ao projeto e descreve a estrutura administrativa para a equipe de projeto que assumirá a fase de planejamento. A principal função da estrutura do projeto é definir padrões a serem utilizados pela equipe durante o projeto. Dentre eles, encontram-se padrões de comunicação, padrões de documentação e padrões de controle de alterações. Considere criar um site de intranet para fins de comunicação e monitoramento do progresso.

O Grupo de Funções de Gerenciamento do Programa se encarrega de definir a estrutura do projeto, que, normalmente, é incluída como componente do documento de visão/escopo.

Planejando a comunicação do projeto

O Grupo de Funções de Gerenciamento do Programa deve usar a estrutura do projeto para definir padrões de comunicação entre os integrantes da equipe. Esses padrões podem incluir uma definição da estrutura de relatórios sob a qual os integrantes da equipe devem operar, procedimentos para levantar problemas, reuniões regulares de status e quaisquer outros padrões de comunicação específicos do projeto que devem ser definidos durante a fase de previsão.

O documento também pode conter nomes de email, aliases, listas de telefones, endereços de email, nomes de compartilhamento de servidor, estruturas de diretório e outras informações cruciais à organização da equipe. Considere estabelecer uma página Web interna na qual essas informações possam residir e ser atualizadas conforme a necessidade.

Planejando os padrões de documentação

A estrutura do projeto também pode definir padrões sobre como criar materiais e documentação de treinamento relacionados ao projeto, inclusive padrões que prescrevem os aplicativos e os materiais de apoio (modelos) que a equipe deve usar para criar documentos.

Planejando o controle de alterações

Alteração, ou a possibilidade de alteração, é um fator integral em todo projeto de implantação de tecnologia de ponta. Os fabricantes lançam novas versões de software ou emitem atualizações e pacotes de serviços para versões existentes com freqüência. Exercitando o controle sobre quaisquer alterações que possam afetar o escopo do projeto, a equipe pode ajudar a garantir que o projeto seja concluído dentro do prazo e do orçamento e evitar desmoronamento do escopo – a tendência de adicionar recursos ao projeto em incrementos até que o efeito agregado das alterações coloque em risco o êxito do projeto.

A função de Gerenciamento do programa deve considerar a inclusão de padrões de controle de alterações na estrutura do projeto. Esses padrões se aplicariam a alterações na estrutura do projeto e no escopo, bem como em scripts. Esses padrões podem compreender compilações diárias prescritas e uso de software de controle de origem, como o Microsoft Visual SourceSafe® 6.0, para controlar o acesso a scripts.

Criando o documento de avaliação de risco

Risco do projeto , ou a possibilidade de resultados negativos associados aos aspectos individuais do projeto, faz parte de cada projeto de implantação. Gerenciamento de riscos é o processo de prever, tratar, reduzir e evitar riscos. No MSF, o gerenciamento de riscos é algo que a equipe pratica continuamente durante todo o projeto, em vez de apenas a intervalos predefinidos.

O gerenciamento de riscos é proativo: a equipe se concentra em avaliar continuamente o que poderia dar errado e como evitá-lo ou minimizar a perda que seria causada, em vez de esperar até que algo dê errado e lidar com seus efeitos.

Observação   O BDD disponibiliza o material de apoio e a Woodgrove Risk Template Tool para ajudar a identificação e priorização de riscos.

Avaliação de risco inicial

Durante a fase de previsão, a equipe pratica gerenciamento de riscos criando um documento de avaliação de risco inicial, que reúne todos os riscos conhecidos e os avalia quanto a probabilidade (a chance de o risco ocorrer) e impacto (a quantidade de perda que resultará se o risco ocorrer). O Grupo de Funções de Gerenciamento do Programa se encarrega de criar o documento de avaliação de riscos.

Se as equipes usarem escalas numéricas para avaliar a probabilidade e o impacto dos riscos, elas calcularão cada exposição a risco multiplicando os dois números, tal como probabilidade x impacto = exposição. Esse cálculo possibilita comparar riscos entre si para determinar sua severidade e prioridade relativas, que talvez não sejam imediatamente aparentes se, digamos, um risco tiver uma probabilidade alta, mas baixo impacto e outro tiver baixa probabilidade e impacto alto. Por exemplo, se uma equipe usa um número entre 1 e 4 para designar a probabilidade e o impacto de cada risco, sendo 4 o mais alto e 1 o mais baixo, a multiplicação de ambos dará um fator de exposição a risco entre 1 e 16, permitindo, assim, que os integrantes da equipe cuidem primeiro dos riscos mais graves.

As equipes não precisam usar a mesma escala numérica para avaliar a probabilidade e o impacto. Se os integrantes da equipe puderem calcular com precisão a perda financeira que cada risco causaria, eles poderão expressar o impacto em termos de valor monetário. É importante, contudo, que usem uma escala consistente para calcular a probabilidade de cada risco, assim como o impacto. O uso de um valor monetário para expressar o impacto de alguns riscos e uma escala numérica para outros riscos torna impossível comparar os riscos entre si.

Assim que a equipe tiver criado o documento de avaliação de riscos e classificado cada risco de acordo com sua exposição, uma lista dos principais riscos possibilitará à equipe se concentrar nos riscos de prioridade mais alta. Muitas vezes chamada de lista dos 10 mais , essa lista não precisa conter exatamente 10 riscos, mas pode conter mais ou menos dependendo do número de riscos identificados e da natureza exata dos riscos e do projeto global. O Gerenciamento do programa deve examinar essa lista freqüentemente durante todo o projeto, adicionando e removendo riscos à medida que eles forem ganhando ou perdendo importância e que novos riscos forem identificados.

Riscos potenciais

Alguns dos riscos que a equipe pode ter que gerenciar ao implantar o Windows, o 2007 Office system e outros aplicativos compreendem:

  • Componentes da tecnologia selecionada podem conter bugs que obstruirão sua capacidade de execução conforme planejada.

  • O tempo alocado para o projeto pode ser agressivo demais para permitir uma implementação aceitável pela equipe.

  • Os integrantes da equipe podem não estar familiarizados com os conceitos e princípios do MSF e com as funções que ocupam.

  • Os integrantes da equipe atribuídos ao projeto podem estar ocupados com outros deveres.

  • Os gerentes de TI em toda a empresa, especialmente aqueles em locais remotos, podem estar acostumados a trabalhar com certo grau de autonomia e resistir aos padrões impostos pelos gerentes.

  • Alguns aplicativos internos podem não funcionar corretamente no Windows XP ou no Windows Vista.

É quase certo que a equipe do projeto não enfrente todos esses riscos, assim como é certo que enfrente outros que nem mesmo se encontram nesta lista. Lembre-se, ainda, de que o gerenciamento de riscos é um processo contínuo, sendo que alguns riscos aparecerão somente em fase bem adiantada do processo.

Saiba mais sobre a avaliação de risco

Realizar uma avaliação de risco adequada requer uma compreensão das filosofias subjacentes ao gerenciamento de riscos em geral e ao gerenciamento de riscos do MSF em particular. Um white paper detalhado sobre a Disciplina de Gerenciamento de Risco do MSF está disponível em http://www.microsoft.com/downloads/details.aspx?FamilyID=6c2f2c7e-ddbd-448c-a218-074d88240942 e um material de apoio (modelo) do documento de avaliação de riscos acompanha essa solução.

Etapa principal: Visão/escopo aprovados

A etapa visão/escopo aprovados encerra a fase de previsão. Nessa altura, a equipe do projeto e o cliente concordaram com o direcionamento global do projeto, inclusive quanto aos recursos que estarão ou não incluídos na solução, e uma tabela de prazos geral para a entrega.

Definidas as funções da equipe e criados os resultados finais da fase de previsão, o gerente de programa deve reuni-los no documento de visão/escopo. Esse documento torna-se, então, uma linha de base e serve como base para o planejamento do projeto.

Lista de verificação da fase de previsão

Antes de passar à fase de planejamento, os seguintes itens devem ser inspecionados:

  • Caso comercial

  • Principais equipes identificadas:

    • Gerenciamento do programa

    • Gerenciamento do produto

    • Desenvolvimento

    • Teste

    • Experiência do usuário

    • Gerenciamento de liberação

  • Equipes de recursos identificadas:

    • Compatibilidade de aplicativos

    • Sistema de gerenciamento de imagens de computador

    • Gerenciamento de aplicativos

    • Implantação

    • Atualização da infra-estrutura

    • Prontidão das operações

    • Segurança

    • Teste

    • Migração de perfil do usuário

  • Pode ter sido realizada detecção de rede

  • Operações de TI integradas ao projeto

  • Estrutura do projeto aprovada

  • Avaliação de risco completa

  • Equipe de recursos de segurança integrada ao projeto

  • Documento de visão/escopo aprovados

  • Pode ter sido realizado inventário de computadores

Após a conclusão das tarefas da fase de previsão, a equipe deve expressar formalmente que o projeto chegou à Etapa de visão/escopo aprovados. Com a aprovação dessa etapa, os integrantes da equipe indicam que estão satisfeitos com o trabalho realizado em suas áreas de responsabilidade.

As equipes de projeto geralmente registram a conclusão de uma etapa com uma aprovação formal. As principais partes interessadas, normalmente representantes de cada função da equipe e demais representantes de clientes importantes que não estão na equipe do projeto, assinalam sua aprovação da etapa assinando ou iniciando um documento que declara que a etapa foi cumprida. O documento de aprovação torna-se um resultado final do projeto e é arquivado para consulta futura. O projeto, agora, pode passar à fase de planejamento.

A fase de planejamento

A fase de planejamento é o período durante o qual a equipe define a solução: o que criar, como criá-la e quem a criará. A fase de planejamento culmina na Etapa planos do projeto aprovados, que indica que a equipe, o cliente e as principais partes interessadas do projeto concordam com os detalhes do plano.

A meta da equipe durante a fase de planejamento é documentar a solução em um conjunto de planos em um grau suficiente a ponto de a equipe poder produzir e implantar a solução correta de maneira pontual e econômica. Tratam-se de documentos dinâmicos, que a equipe continuará a atualizar por toda a fase de desenvolvimento.

A fase de planejamento possui quatro resultados finais principais: a especificação funcional, que inclui o design da solução; o plano do projeto; o cronograma do projeto; e o ambiente de desenvolvimento e teste.

Tarefas principais

A Tabela 5 lista as principais tarefas e resultados finais do planejamento do projeto e seus respectivos proprietários.

Tabela 5. Principais tarefas da fase de planejamento , resultados finais , e proprietários

Tarefas principais

Resultados finais

Proprietários

Desenvolvendo o design da solução

O documento de design da solução

Gerenciamento do programa (com grande participação do Desenvolvimento)

Criando a especificação funcional

Um esboço inicial da especificação funcional

Gerenciamento do programa (com grande participação do Desenvolvimento)

Desenvolvendo o plano do projeto

O plano do projeto (uma síntese de todos os planos individuais)

Gerenciamento do programa (com cada função responsável pelas seções que lhe foram atribuídas)

Criando o cronograma do projeto

O cronograma do projeto

Gerenciamento do programa (com cada função responsável pelas seções que lhe foram atribuídas)

Identificando e priorizando aplicativos

Lista de aplicativos, SMEs (especialistas no assunto), mídia e configurações

Gerenciamento de liberação

Fazendo um inventário de hardware e aplicativos

Ferramenta Analisador implantada; relatórios sobre compatibilidade de aplicativos e inventário de hardware gerados

Gerenciamento de liberação

Criando o plano de migração dos aplicativos básicos

Plano de migração

Desenvolvimento

Criando as diretivas e estratégias de segurança

Diretivas, estratégias e configuração de segurança

Desenvolvimento

Analisando a rede

Diagramas de topologia de rede e do inventário de dispositivos de rede

Gerenciamento de liberação

Criando o plano de teste

Plano de teste

Teste

Criando o laboratório de teste

Laboratório de teste pronto para testes

Teste, desenvolvimento

Aprovando a etapa

Todo o trabalho da fase de planejamento aprovado

Todas as funções

Foco da equipe

A Tabela 6 esboça as principais atividades de cada grupo de funções durante a fase de planejamento.

Tabela 6. Grupos de funções e foco na fase de planejamento

Grupo de funções

Foco

Gerenciamento do produto

  • Entrada no design conceitual

  • Análise dos requisitos comerciais

  • Plano de comunicações

Gerenciamento do programa

  • Design conceitual e lógico

  • Especificação funcional

  • Plano e cronograma do projeto

  • Orçamento

Desenvolvimento

  • Avaliações da tecnologia

  • Design lógico e físico

  • Plano e cronograma de desenvolvimento

  • Estabelecimento do laboratório

  • Estratégia de migração

  • Diretivas e estratégias de segurança

Teste

  • Estratégia, tipos, plano e cronogramas de teste

Experiência do usuário

  • Cenário/casos de uso, requisitos do usuário e requisitos de localização/acessibilidade

  • Plano de documentação e treinamento do usuário, cronogramas

Gerenciamento de liberação

  • Avaliação do design

  • Requisitos das operações

  • Planejamento/cronograma de piloto e implantação

  • Descoberta de rede

  • Inventário de aplicativos e hardware

  • Interface com a equipe de recursos de segurança e de operações de TI

A equipe de recursos de segurança e de operações de TI está inclusa nas avaliações, para garantir que haja uma visão precisa de suas respectivas áreas. A comunidade de usuários está incluída, para garantir que os planos e os designs que estão sendo compilados estejam consistentes com suas necessidades.

Caso ainda não tenha sido feita, uma análise dos aplicativos implantados será conduzida para verificar quais aplicativos serão implantados novamente e quais poderão ser retirados. O Gerenciamento de liberação prioriza, inicialmente, os aplicativos, a fim de estabelecer uma seqüência para automatizar sua implantação.

O Gerenciamento de liberação também conduz um exame inicial do inventário de hardware (caso ainda não tenha sido feito como parte do planejamento do ciclo de vida da tecnologia) para determinar quais computadores podem permanecer inalterados, quais necessitam de modificações (por exemplo, RAM, disco) e quais podem ser substituídos.

Equipe de recursos e documentos de ajuda do trabalho

Os seguintes documentos são usados na fase de planejamento:

  • Especificação funcional

  • Avaliação de riscos

  • Cronograma do projeto

  • Plano do projeto, inclusive:

    • Plano de desenvolvimento

    • Plano de teste

    • Plano de implantação

    • Plano piloto

    • Plano de comunicações

    • Plano de treinamento

    • Plano de instalações e hardware

    • Plano orçamentário

  • Guia da Equipe de Recursos de Compatibilidade de Aplicativos

  • Guia da Equipe de Recursos de Gerenciamento de Aplicativos

  • Guia da Equipe de Recursos do Sistema de Geração de Imagens de Computador

  • Guia da Equipe de Recursos de Implantação

  • Guia da Equipe de Recursos de Monitoramento da Configuração Desejada

  • Guia da Equipe de Recursos de Atualização de Infra-estrutura

  • Guia da Equipe de Recursos de Preparação das Operações

  • Guia da Equipe de Recursos de Segurança

  • Guia da Equipe de Recursos de Teste

  • Guia da Equipe de Recursos de Migração de Perfil do Usuário

Estabelecendo o laboratório

Caso as equipes ainda não tenham, é recomendável estabelecer um ambiente de laboratório dedicado e isolado a ser usado no desenvolvimento e no teste da solução. O laboratório deve espelhar o mais próximo possível o ambiente de produção para assegurar que todos os aspectos do ambiente possam ser considerados no processo de desenvolvimento.

O laboratório deve incluir, no mínimo:

  • Um domínio do serviço de diretório Microsoft Active Directory® (Microsoft Windows Server® 2003 ou Windows 2000 Server) com privilégios administrativos.

  • Windows Server 2003 com SP1. (Windows Server 2003 R2 é preferível, pois fornece um mecanismo útil de replicação.)

  • Microsoft Virtual Server 2005 (opcional).

  • Serviços DHCP.

  • Serviços DNS (sistema de nome de domínio).

  • Serviços do WINS (serviço de cadastramento na Internet do Windows) (opcional).

  • MOM 2005 (opcional).

  • Windows DS (Serviços de Implantação do Windows da Microsoft).

  • SMS 2003 com SP1 e SMS Operating System Deployment (OSD) Feature Pack.

  • SQL Server 2000.

  • SQL Server 2000 Reporting Services Standard Edition.

  • Acesso à Internet (para baixar atualizações, arquivos etc.).

  • Um servidor de arquivos com capacidade suficiente para hospedar o servidor de imagens; recomenda-se 50 gigabytes (GB).

  • Computadores de teste que reflitam os computadores de produção com precisão.

  • Gravador de CD e CDs graváveis (obrigatórios) ou gravador de DVD e DVDs graváveis (opcional).

  • Mídia de backup, como um sistema de backup em fita e fitas.

  • Biblioteca de software, incluindo Windows, o 2007 Office system, aplicativos, software de imagem de disco, Windows PE e drivers de hardware.

Desenvolvendo o design da solução

O design da solução é o primeiro documento abrangente de design e faz parte da especificação funcional. Ele prepara os integrantes da equipe para suas responsabilidades durante a fase de desenvolvimento. O design se baseia na visão desenvolvida pela equipe e nas informações sobre tecnologia reunidas por ela durante a fase de previsão e define os designs conceitual, lógico e físico da solução. Imagine os processos que produzem esses designs como três estágios de sobreposição de um processo de design que se inicia antes da fase de previsão e continua durante todo o projeto e depois dele, sendo que o projeto em si é apenas um componente de um processo maior de gerenciamento do ciclo de vida da tecnologia.

O processo de design

O processo de design é como um projeto de construção de uma casa. O design conceitual é análogo aos esboços e croquis rascunhados pelo arquiteto em conjunto com o cliente. O design lógico é criado pela equipe do arquiteto e traça a estrutura da solução e os caminhos de comunicação entre os elementos; ele corresponde a um plano de pavimento e elevação, no qual se organizam elementos como as relações espaciais. O design físico corresponde às cópias heliográficas do empreiteiro mostrando os elementos físicos de uma estrutura: fiação, encanamento, calefação e ventilação. Os planos (design físico) do empreiteiro acrescentam detalhes aos planos (design lógico) do arquiteto e refletem as restrições de construção do mundo real.

Design conceitual

O design conceitual envolve a compreensão dos requisitos comerciais e a definição dos recursos e das funções necessárias para que os usuários executem seus trabalhos. O Gerenciamento do produto se encarrega de criar o design conceitual, que inicia durante a fase de previsão e continua por toda a fase de planejamento. O design conceitual deste projeto deve incluir:

  • Metas de design que descrevam os objetivos do projeto de uma forma que aborde as declarações de problemas e as oportunidades de negócios identificadas no documento de visão/escopo.

  • A lista de recursos e funções contidas na solução. O design conceitual normalmente expõe essa lista em termos do sistema operacional e dos aplicativos que devem ser implantados (neste caso, Windows e quaisquer aplicativos adicionais), a arquitetura da instalação autônoma (inclusive servidores de distribuição) e a arquitetura de imagem de disco.

  • As situações de uso que antecipam o modo como diferentes tipos de usuários implementarão, administrarão e usarão a solução. Verifique novamente os perfis de usuário definidos no documento de visão/escopo e descreva como os tipos de usuários identificados trabalharão com a solução. As tarefas a serem documentadas podem incluir administração da arquitetura de distribuição, instalação e configuração da solução em novos computadores, configuração do Windows para a primeira utilização e uso de diferentes componentes da solução para implementar os objetivos comerciais.

Design lógico

O design lógico usa o design conceitual e o estado atual da infra-estrutura da tecnologia para definir a nova arquitetura em um nível superior. O design lógico deste projeto deve incluir:

  • Uma definição geral da arquitetura de instalação autônoma que será usada pela equipe de recursos de implantação para iniciar o processo de implantação em cada computador afetado, bem como a configuração e o posicionamento dos servidores de implantação. Essa definição não inclui necessariamente o local físico exato de cada servidor de implantação, mas deve descrever as razões implícitas para a escolha dos locais desejados.

  • Uma definição similar da arquitetura de imagem de disco rígido, inclusive uma justificativa para usar imagens de disco, uma descrição das instalações necessárias para realizar duplicação de disco e uma descrição das ferramentas de software utilizada pela equipe para preparar os discos rígidos para a duplicação (normalmente, Sysprep).

Design físico

O design físico apresenta a arquitetura desejada com mais detalhes e define as configurações de hardware e os produtos de software a serem usados. O design físico deste projeto deve incluir:

  • Especificações das configurações de hardware incluídas no escopo do projeto.

  • Especificações do software a ser instalado.

  • As ferramentas a serem usadas para desenvolvimento do projeto.

Como regra geral, o design da solução deve conter detalhes suficientes para permitir que a equipe comece a trabalhar no plano do projeto.

A equipe deverá concluir os designs conceitual e lógico no final da fase de planejamento. O design físico serve de “linha de base” para esboçar o design da solução, mas continuará sendo refinado durante o restante do projeto e alterado conforme as decisões de desenvolvimento e implantação tomadas e revisadas pela equipe.

Criando a especificação funcional

A especificação funcional cuida do que a solução deve incluir. Ela representa o contrato entre o cliente e a equipe do projeto e é a base para a criação dos planos e cronogramas do projeto. Durante a fase de planejamento, a especificação funcional torna-se a linha de base e é colocada sob controle de alterações. O Gerenciamento do programa se encarrega de compilar a especificação funcional com as entradas dos líderes de função relativas a suas áreas de responsabilidade. Os Grupos de Funções de Desenvolvimento, Gerenciamento de Produto e Experiência do Usuário são, com freqüência, ativos na determinação do que incluir na especificação funcional.

Assim como no plano e no cronograma do projeto, a principal finalidade da especificação funcional é especificar que trabalho será feito, e como será feito, nas fases de desenvolvimento, estabilização e implantação.

Linha de base inicial , congelamento tardio é uma prática recomendada do MSF. A especificação funcional é um documento dinâmico, que a equipe continua a atualizar e incrementar por todo o projeto. O Grupo de Funções de Gerenciamento do Programa deve tornar a especificação funcional uma linha de base, de modo que ela contenha detalhes suficientes para possibilitar um planejamento e um cronograma precisos. Desenvolver a especificação é um processo iterativo: o Grupo de Funções de Gerenciamento do Programa deve esperar para adicionar e refinar o documento conforme o planejamento for progredindo e, em certa medida, durante as fases de desenvolvimento e de implantação, quando o documento está sob controle de alterações. A equipe congela a especificação funcional ao final da fase de desenvolvimento, antes de passar à fase de implantação.

Inicialmente, criar a especificação funcional, em geral, é questão de reunir os resultados finais produzidos durante as fases de previsão e planejamento e identificar as áreas a serem expandidas mais adiante no projeto.

Determinando o conteúdo da especificação funcional

A especificação funcional documenta o processo de design, incorporando os designs conceitual, lógico e físico. Por conseqüência, decisões de design gerais, como posicionamento de servidores e configuração de rede, bem como aspectos do design físico, como documentos de configuração e inicialização, devem ser documentados na especificação funcional. A equipe não criará alguns destes documentos antes das fases de desenvolvimento, estabilização e implantação, de modo que não é possível incluir esses componentes como parte da linha de base. Para a especificação funcional, contudo, podem ser identificados componentes que a equipe deverá desenvolver posteriormente.

A especificação funcional deve incluir o seguinte, no todo ou em parte:

  • Um resumo do documento de visão/escopo conforme acordado e refinado, incluindo informações gerais que coloquem a solução em contexto comercial

  • Quaisquer requisitos adicionais de usuário e cliente, além daqueles já identificados no documento de visão/escopo

  • Especificações dos componentes que farão parte da solução, como Windows e o 2007 Office system

Durante a fase de previsão, a equipe do projeto definiu o escopo do projeto conforme ditado por tempo, orçamento e outras considerações. Parte da criação da especificação funcional é decidir quais componentes específicos da solução estão dentro do escopo e quais não estão. Documentar elementos como:

  • A quais configurações de hardware o esforço do desenvolvimento dará suporte (por exemplo, discos rígidos, placas de vídeo, outros periféricos).

  • Quais aplicativos incluir como parte da linha de base.

  • Informações de versão de todos os programas de software a serem implantados.

  • Os métodos a serem usados para implantar as linhas de base (por exemplo, servidores e/ou CD-ROMs, instalações por imagens e/ou autônomas).

Desenvolvendo o plano do projeto

O plano do projeto é um conjunto de planos que abordam as tarefas que as seis funções da equipe executarão para executar o projeto conforme definido pela especificação funcional. Nem todo projeto exige cada plano listado aqui, sendo que alguns projetos podem exigir planos adicionais. Esta seção inclui os seguintes planos:

  • Plano de desenvolvimento

  • Plano de teste

  • Plano de implantação

  • Plano piloto

  • Plano de comunicações

  • Plano de treinamento

  • Plano de instalações e hardware

  • Plano orçamentário

A maioria dos planos do projeto deve ter apenas algumas páginas de extensão. O Grupo de Funções de Gerenciamento do Programa se encarrega de atribuir a redação dos planos às funções apropriadas, auxiliando-os quando necessário e montando o plano do projeto.

Para facilitar o desenvolvimento do plano de teste, o BDD 2007 contém os materiais de apoio de exemplo Plano de teste , Especificação de teste e Pasta de trabalho de casos de teste. Os materiais de apoio Requisitos de compilação do cliente e Visão/escopo oferecem suporte ao plano de desenvolvimento. Acompanham também os materiais de apoio Plano de comunicações , Plano piloto e Plano de treinamento.

Criando o plano de implantação

O plano de desenvolvimento é um componente crucial de qualquer projeto de implantação de infra-estrutura. Ele descreve a abordagem escolhida pela equipe do projeto para desenvolver a solução durante a fase seguinte, de modo a satisfazer aos requisitos de visão e escopo. O Grupo de Funções de Desenvolvimento assume a criação desse plano.

Dentre as áreas que o plano de desenvolvimento pode abranger, estão:

  • Funções e responsabilidades da equipe, especificamente, detalhes das áreas de responsabilidade de cada desenvolvedor.

  • Uma lista e descrição dos resultados finais a serem produzidos pelos desenvolvedores. Normalmente, compreendem:

    • Os scripts reais produzidos, inclusive toda modificação feita aos scripts e arquivos de configuração.

    • Uma descrição da arquitetura da linha de base e das etapas realizadas pela equipe para entregá-la.

    • Uma lista dos aplicativos adicionais a serem implantados como parte da linha de base, inclusive o 2007 Office system, junto com quaisquer pacotes de instalação que a equipe deva criar ou personalizar.

    • Os tipos de documento, como procedimentos de instalação e configurações de software, que o Grupo de Funções de Desenvolvimento espera criar durante a fase de desenvolvimento.

  • Um breve tratamento da abordagem da equipe quanto a instalações autônomas versus imagens de disco. Isto será expandido no plano de implantação.

  • Planos de compilações intermediárias, inclusive a quantidade a ser criada e quais aspectos da solução estará compreendida em cada uma delas.

Embora o plano de desenvolvimento se destine, principalmente, aos desenvolvedores, uma outra meta do plano é formalizar processos e planos para ajudar no suporte e no gerenciamento contínuo da solução. Quando a equipe do projeto distribui a responsabilidade pela solução ao suporte contínuo e ao pessoal de operações, esse último grupo deve ser capaz de usar esses documentos (abrangendo tarefas como procedimentos de instalação e configuração de software) para implantar o Windows em novos computadores e fornecer suporte técnico. Os desenvolvedores devem se esforçar em concluir e enviar essa documentação simultaneamente ao envio dos scripts correspondentes da solução, de modo que o suporte e o pessoal de operações tenham acesso imediato a todas as informações disponíveis na solução.

Criando o plano de teste

O plano de teste delineia a estratégia utilizada pela equipe para testar a solução. Nessa solução, são gerados diferentes planos de teste. Para a iniciativa global, o plano de teste cuida da verificação do processo, da imagem e da infra-estrutura necessários para implantar as novas imagens de desktop e os aplicativos suplementares exigidos. A equipe de recursos Compatibilidade de aplicativos requer um plano de teste detalhado para identificar os aplicativos comerciais relevantes a serem testados, bem como quais testes realizar. A equipe de recursos de Sistema de geração de imagens de computador deve definir os perfis de hardware com suporte da infra-estrutura alvo e testar as diferentes imagens quanto a requisitos de driver específicos do hardware. Uma parte significativa da iniciativa de migração será gasta no teste; logo, separe um tempo para identificar os requisitos e o plano de teste adequadamente.

Normalmente, o Grupo de Funções de Teste assume a criação do plano de teste. Dentre as áreas abrangidas, estão:

  • Uma descrição do ambiente de teste. Diagramas e esquemas podem ajudar a ilustrar o ambiente.

  • Controle de alterações e como ele será imposto.

  • Procedimentos de acompanhamento de problemas. Descreva o banco de dados de acompanhamento de problemas que será usado, inclusive o programa usado para criá-lo, quem terá acesso a ele e os campos a serem usados.

  • Quem é responsável por testar cada componente da solução.

  • Matrizes de testes que abordam quais componentes da solução os integrantes da equipe devem testar e de que maneira. Por exemplo, uma equipe pode planejar desenvolver matrizes de teste para instalação, configuração, sistema operacional e para conjunto de aplicativos.

  • Os materiais que a equipe do projeto deve criar nos ambientes de desenvolvimento e de teste.

O plano de teste deve especificar os tipos de teste executados pela equipe durante a fase de desenvolvimento. São tipos de teste típicos:

  • Teste de instalação. O teste de instalação assegura que cada componente seja instalado sem erros. O testador instala uma compilação e verifica se a Instalação do Windows é executada e encerrada corretamente, se a instalação dos aplicativos e os programas de configuração são executados e encerrados corretamente e se o processo instala corretamente cada componente contido na compilação.

  • Teste de configuração. O teste de configuração assegura que o processo de instalação configure cada componente corretamente, conforme indicado na documentação de configuração.

  • Teste de funcionalidade. O teste de funcionalidade assegura que funções básicas de aplicativo e sistema operacional funcionem conforme o esperado e sem erros. O teste de funcionalidade não é uma repetição do teste realizado pelos fabricantes do hardware ou do software. Em vez disso, ele verifica cenários de uso típicos. A esse respeito, o teste de funcionalidade se assemelha bastante com o teste de aceitação do usuário, exceto pelo fato de que os integrantes da equipe do projeto o realizam antes do teste de aceitação do usuário.

  • Teste de aceitação do usuário. O teste de aceitação do usuário assegura que o sistema opere, como um todo, de maneira adequada para os usuários. Normalmente, esse teste envolve expor alguns usuários e o pessoal de implantação de TI à solução e verificar se eles conseguem utilizá-lo para executar suas tarefas.

A equipe pode optar por executar outros tipos de teste, como teste de regressão e de conformidade, segundo os requisitos do projeto.

Criando o plano de implantação

O plano de implantação delineia a estratégia utilizada pela equipe para implantar a solução. A principal função do plano é definir as tarefas que devem ser executadas durante a implantação e quem as executará. Com esse fim, o plano de implantação pode conter informações como:

  • Se a equipe planeja implantar a solução em fases ou de uma vez.

  • A ordem na qual os locais receberão a solução, se aplicável.

  • Se a implantação será executada pelo pessoal de TI interno ou pelos consultores externos.

  • As listas de verificação que os integrantes da equipe utilizarão para executar as tarefas de implantação em cada local. A equipe criará essas listas de verificação mais adiante no projeto.

  • Planos para que o banco de dados mantenha o controle das necessidades dos usuários.

  • Procedimentos a serem usados para migrar dados e aplicativos para o Windows, após uma instalação limpa em um computador existente, e para testar aplicativos migrados.

  • Como lidar com os comentários dos usuários afetados pela implantação.

Normalmente, o Grupo de Funções de Gerenciamento de Liberação se encarrega pelo desenvolvimento desse plano.

Criando o plano piloto

O plano piloto descreve as metas da equipe na condução do piloto, de modo a preparar da melhor maneira para a implantação completa. Normalmente, o Grupo de Funções de Gerenciamento do Produto ou de Gerenciamento de Liberação se encarrega de desenvolver este plano.

Geralmente, este é um bom momento no processo de planejamento para selecionar um grupo para o piloto, a menos que questões políticas ou organizacionais sejam empecilhos. Para garantir que o grupo do piloto forneça os melhores comentários para a equipe de recursos de Implantação, o grupo selecionado para o piloto deve ser representativo da organização como um todo. O Grupo de Funções de Gerenciamento do Produto ou, em alguns casos, de Gerenciamento de Liberação deve liderar o esforço de constituir um grupo piloto. Se a equipe já tiver uma boa idéia de qual grupo será formado para o piloto, inclua essas informações no plano piloto. Caso contrário, registre os critérios da equipe quanto ao grupo piloto ideal, inclusive considerações como:

  • O número de usuários a ser incluso na implantação piloto.

  • As configurações de hardware que devem estar representadas no grupo piloto.

  • Quaisquer considerações de local, como empregar usuários de um mesmo local físico ou usuários espalhados por escritórios distantes.

  • Considerações políticas ou organizacionais.

Além de descrever as característica do grupo piloto, o plano piloto deve identificar características do próprio piloto, como:

  • Quanto tempo durará o piloto.

  • Quais componentes da solução serão incluídos como parte do piloto.

  • Como lidar com os comentários do piloto, inclusive quanto a fazer modificações na solução em decorrência deles.

  • Os critérios de êxito do piloto.

Criando o plano de comunicações

O plano de comunicações descreve como a equipe se comunica com os grupos afetados pela solução. Identifique todos que tiverem uma relação com a solução e o nível de comunicação necessário. Normalmente, isso inclui não apenas usuários, mas também pessoal de suporte técnico, outros funcionários de TI, a equipe de gerenciamento responsável pelo orçamento do projeto, pessoal cujo trabalho será interrompido por atividades relacionadas ao projeto e outros.

O plano de comunicações deve prescrever estratégias de comunicação para cada um dos grupos identificados de pessoas afetadas pelo projeto. A equipe terá, provavelmente, uma ampla gama de opções para a comunicação, dentre as quais:

  • Reuniões presenciais.

  • Email, inclusive listas de endereçamento.

  • Boletins informativos impressos ou eletrônicos. Esta etapa pode envolver a publicação de boletins informativos específicos do projeto ou a inclusão de informações do projeto nos boletins informativos organizacionais existentes. Considere informes ou boletins informativos de TI, boletins informativos específicos a departamento ou a local e boletins gerais da organização.

  • Sites de intranet informativos.

  • Correio de voz.

O plano de comunicações deve fornecer estratégias para assegurar que cada grupo afetado obtenha as informações de que precisa quando elas forem necessárias, sem sobrecarregar as pessoas com informações demais. Parte desta tarefa inclui selecionar pessoas com boa capacidade de comunicação para fornecer as informações. O plano deve identificar as pessoas responsáveis por comunicar as mensagens desejadas às pessoas que necessitam dessas informações.

Criando o plano de treinamento

Normalmente, o Grupo de Funções de Experiência do Usuário se encarrega de desenvolver o plano de treinamento. Assim como no plano de comunicações, a função deve considerar os diferentes tipos de público que necessitam de treinamento. Na pior das hipóteses, haverá duas amplas categorias de pessoas a considerar: usuários e equipe de TI, inclusive administradores de sistema e pessoal de suporte técnico. A função pode identificar outras categorias, dependendo dos requisitos do projeto.

Não há uma única maneira certa de fazer o treinamento. Desenvolver um plano de treinamento sempre leva em conta as restrições do projeto. São fatores que podem influenciar a forma de realização do treinamento, o conhecimento do usuário, o tempo, o orçamento e a disponibilidade de monitores capacitados e de pessoas para desenvolver o treinamento. A cultura e o tipo de negócio da organização podem ditar veículos de treinamento particulares ou a duração ou o nível técnico do treinamento.

Se os usuários da organização estiverem familiarizados com o Windows XP e o Windows 2000, por exemplo, eles não precisarão de muito treinamento para manter a mesma produtividade, ou até mesmo uma produtividade melhor, com o Windows Vista. No entanto, um treinamento adicional pode lhes permitir um melhor aproveitamento dos novos recursos do Windows Vista, aumentando ainda mais a produtividade. Profissionais de TI, normalmente, precisarão de instruções mais minuciosas sobre as diferenças entre Windows 2000, Windows XP e Windows Vista.

Da mesma forma, usuários acostumados com o Microsoft Office XP ou o Office 97 devem ser capazes de aprender as versões posteriores do sistema Microsoft Office sem muito treinamento. Uma abordagem a considerar nesses casos é um guia de recursos com base na Web a partir do qual os usuários possam saber mais sobre os novos recursos do Windows Vista e do 2007 Office system, além de como utilizá-los para se tornarem mais produtivos.

Se os usuários não tiverem familiaridade com o sistema operacional Windows e o 2007 Office system e precisarem de mais treinamento, existem várias opções disponíveis, dentre as quais:

  • Treinamento prático, no qual o usuário aprende o software utilizando-o.

  • Treinamento em estilo de apresentação, no qual o usuário tem aulas sobre o uso do software.

  • CBT (treinamento baseado em computador) ou WBT (treinamento baseado na Web), nos quais um software de treinamento especial instrui o usuário.

  • Treinamento um-para-um.

  • Materiais de apoio ou folhetos.

Ao criar treinamento para equipe de TI, considere se eles devem compreender o processo inteiro de instalação autônoma ou apenas partes dele e se eles terão que saber como restaurar um computador para a configuração de linha de base. Considere métodos de treinamento prático e autodidata. Os documentos criados pela equipe como parte da especificação funcional podem ser de utilidade inestimável para o aprendizado da equipe de TI.

Observação   O Microsoft Learning Solutions é uma solução de aprendizado econômico e de hospedagem independente que fornece materiais valiosos de treinamento e referência em software sobre produtos e tecnologias Microsoft. Para obter mais informações sobre o Microsoft Learning Solutions, visite o site http://www.microsoft.com/learning/mls. Além disso, a Microsoft Press® oferece uma variedade de livros e materiais de aprendizagem a serem considerados para o treinamento. Para obter mais informações sobre esses materiais, inclusive informações sobre pedidos, visite o site da Microsoft Press em http://mspress.microsoft.com.

O plano de treinamento deve descrever a abordagem da equipe do projeto quanto ao treinamento, observando quaisquer restrições ou requisitos e explicando por que a equipe optou por essa abordagem.

Criando o plano de instalações e hardware

Se o projeto envolver a implantação da solução em sistemas computacionais existentes, considere redigir um plano de instalações e hardware detalhando quantos sistemas computacionais da organização atendem a esses requisitos e quantos são insuficientes. Se um número significativo de computadores não atenderem aos requisitos do Windows Vista ou a algum dos aplicativos de software a serem implantados, por exemplo, use este plano para descrever como a equipe abordará esses computadores. São condutas possíveis a adotar:

  • Implantar somente nos computadores aptos a executar a solução e não mexer nos demais até que sejam atualizados ou substituídos, no futuro.

  • Planejar atualizações e substituições dos computadores menos potentes no decorrer do tempo e incluir os custos de atualização no orçamento do projeto.

  • Adquirir novo hardware, como RAM e discos rígidos, para os computadores menos potentes, de modo a alinhá-los com a especificação do projeto.

Assim como nos demais componentes do plano do projeto, não há uma maneira certa de desenvolver o plano de instalação ou de hardware. As restrições impostas por tempo, orçamento e outras considerações externas ditarão, em parte, a abordagem da equipe.

Normalmente, o Grupo de Funções de Gerenciamento do Programa ou de Gerenciamento de Liberação se encarrega de desenvolver este plano. Uma área que deve ser considerada com atenção no plano de instalações e hardware é o volume potencial de armazenamento em disco necessário durante o processo de implantação. No processo de implantação, duas opções podem afetar significativamente a quantidade de espaço em disco necessária no servidor durante a implantação. A primeira é o uso de USMT para capturar todos os arquivos de dados, configurações e preferências dos usuários, do computador para um compartilhamento de rede no servidor de dados. Essa opção pode aumentar rapidamente a quantidade de espaço necessária no servidor de dados. A segunda opção é criar uma imagem de backup do computador inteiro antes da migração. Essa opção pode adicionar gigabytes por usuário à quantidade de espaço necessária no servidor. A maioria das organizações retém esses dados apenas temporariamente, de maneira que os requisitos de disco também sejam temporários. As equipes podem colocar essas opções em vigor alternando entre elas de acordo com o usuário.

Para uma descrição detalhada dos requisitos de capacidade, consulte o Guia do Lite Touch Installation.

Criando o plano orçamentário

Se o custo for um fator decisivo para a forma de implementação da solução pela equipe – o que acontece na maioria dos casos – a equipe deve redigir um plano orçamentário detalhando como o dinheiro disponível será gasto. O plano orçamentário deve ser o componente final do plano do projeto. O Gerenciamento do programa se encarrega de desenvolver esse plano, aguardando que o restante do plano do projeto esteja pronto para poder finalizar o orçamento de modo a assegurar sua precisão tanto quanto possível, com todos os itens contabilizados. São áreas a considerar ao criar um orçamento para o projeto:

  • O software que a organização deve comprar ou licenciar para a solução, inclusive o Windows, o 2007 Office system e quaisquer softwares de outros fabricantes a serem implantados como parte da solução.

  • Ferramentas de desenvolvimento ou outros programas de software que a equipe do projeto comprará como parte do processo de implantação.

  • Hardware e equipamento de sistemas de rede que a equipe implantará ou usará durante o desenvolvimento.

  • Prestadores de serviços ou outros profissionais externos que a equipe contratará para auxílio em desenvolvimento, teste, treinamento ou outras atividades relacionadas ao projeto.

  • Materiais didáticos ou outros materiais de treinamento.

Criando o cronograma do projeto

O cronograma do projeto é uma compilação dos cronogramas criados pelos integrantes da equipe com a finalidade de planejar suas atividades. Ele pode conter o seguinte, no todo ou em parte, conforme for apropriado:

  • Um cronograma de desenvolvimento

  • Um cronograma de teste

  • Um cronograma de experiência do usuário

  • Um cronograma de gerenciamento de liberação

  • Um cronograma de implantação

Qualquer função pode optar por dividir seu cronograma por área funcional. Por exemplo, se subequipes de desenvolvimento diferentes trabalharem nas arquiteturas de imagens e pacotes de aplicativos, cada subequipe poderá criar seu próprio cronograma.

Criando cronogramas do projeto

Cada líder de função realiza uma divisão e uma priorização funcional das responsabilidades da função, ao passo que os integrantes da equipe efetuam estimativas em nível de tarefa. A duração de uma tarefa individual deve ser desde a metade de um dia até uma semana. Se a duração da tarefa for curta demais, a sobrecarga no gerenciamento da tarefa poderá ser muito alta. Se for longa demais, será difícil gerenciar o escopo do trabalho.

Além de planejar as durações das tarefas, os integrantes da equipe que criam os cronogramas devem atribuir nomes a elas. Após criar o documento de visão/escopo, o documento de design da solução e o planos do projeto, os líderes das funções devem saber quais integrantes da equipe serão responsáveis pelas áreas específicas. Os cronogramas tornam essas atribuições mais específicas, para que todos os integrantes da equipe saibam o que farão e quando.

Projetos dessa natureza podem acontecer em toda parte, durando desde semanas até vários meses. Ao fazer o cronograma do projeto, considere fatores como:

  • O tamanho da organização.

  • A extensão da implantação.

  • O número de configurações de hardware afetadas.

  • O número de aplicativos a oferecer suporte.

  • Como manipular a migração de dados.

  • A disponibilidade de recursos.

  • A quantidade de personalização necessária.

  • Os requisitos dos diferentes grupos que orientam as alterações à especificação funcional.

  • Se a equipe do projeto conta com a assistência de terceiros, como consultores, que têm experiência com projetos similares.

A fase de desenvolvimento nos projetos típicos de implantação de desktop em organizações de médio porte (5.000 a 10.000 usuários afetados) e grande porte (mais de 10.000 usuários afetados) pode levar de 6 a 10 semanas. Programas de software de gerenciamento de projetos, como o Microsoft Office Project, podem ajudar a criar o cronograma do projeto. Os programas de software de gerenciamento de projetos têm recursos que permitem às equipes atribuir duração, recursos e pré-requisitos a tarefas e calcular automaticamente datas importantes.

Montando o cronograma do projeto

O Gerenciamento do programa compila e coordena os cronogramas que as diferentes funções enviam, para que os integrantes da equipe possam trabalhar com eficiência. O documento resultante é o cronograma do projeto.

O Gerenciamento do programa deve incluir o tempo de buffer no cronograma, para compensar o não cumprimento do cronograma causado por demoras imprevistas. Os integrantes da equipe não devem ver o tempo de buffer como um descanso no desenvolvimento, mas usá-lo somente se necessário e segundo o critério do gerente de programa. Para proteger o tempo de buffer contra influências externas, designe etapas internas visíveis somente à equipe e separadas das etapas visíveis externamente por tempo de buffer (consulte a Figura 5). Por exemplo, a equipe pode planejar a conclusão da fase de desenvolvimento para 10 de abril, mas designar 17 de abril como conclusão da fase de desenvolvimento enquanto etapa visível externamente. O período entre 10 e 17 de abril seria um tempo de buffer.

Bb490158.SE_PlanBulid05(pt-br,TechNet.10).gif

Figura 5. Planejando o tempo de buffer

Criando o ambiente de desenvolvimento e de teste

Uma tarefa principal da fase de planejamento é a criação de um ambiente no qual os integrantes da equipe possam desenvolver e testar a solução sem afetar as operações do dia a dia de outros usuários. O ambiente de desenvolvimento deve estar fisicamente separado do ambiente de teste, embora possam compartilhar alguns dos mesmos recursos, em momentos diferentes.

O ambiente de desenvolvimento e de teste é normalmente chamado de laboratório , embora talvez nem sempre esteja fisicamente separado do ambiente de produção existente. Pondere os custos e os benefícios da separação física antes de criar o laboratório. Por outro lado, todo o trabalho de desenvolvimento e de teste deve acontecer em uma rede isolada ou em um domínio Windows e segmento de rede fora da produção, se possível. Os usuários da produção não devem ter acesso aos recursos computacionais do laboratório, como também o trabalho executado por desenvolvedores e testadores não devem afetar o trabalho executado pelos usuários.

O laboratório deve conter, pelo menos, um computador para cada configuração de hardware identificada no design físico. Lembre-se de que os computadores podem ser compartilhados entre os Grupos de Funções de Desenvolvimento e de Teste, embora não ao mesmo tempo. Use essa configuração para cortar os custos de desenvolvimento, se necessário. Por exemplo, o desenvolvimento pode usar alguns computadores e domínios e, posteriormente, passá-los ao teste, na fase de desenvolvimento.

Crie o ambiente de teste de modo a emular o ambiente de produção o mais próximo possível, como no seguinte exemplo:

A rede WAN corporativa engloba 540 computadores em seis configurações de hardware básicas. A WAN é uma VPN que consiste na sede de Minneapolis, cincos escritórios de vendas espalhados por Minnesota , Wisconsin e Dakota do Sul conectados à Internet por meio de linhas T-1, e uma central de serviços em Eden Prairie , Minnesota , em um link ADSL. O ambiente de teste conterá um computador para cada configuração de hardware , cada um dos quais estará, de tempos em tempos, conectado à LAN ou à Internet , seja por linha T-1 dedicada, seja por linha ADSL instalada no laboratório de testes.

Etapa intermediária: Validação de tecnologia concluída

Para cumprir essa etapa, a equipe do projeto deve instalar manualmente os componentes tecnológicos da solução em hardware puro no ambiente que melhor os acomodar. As metas dessa etapa são minimizar variáveis extrínsecas e assegurar que os componentes tecnológicos funcionem em conformidade com a especificação funcional.

Etapa principal: Planos do projeto aprovados

Na Etapa planos do projeto aprovados, a equipe do projeto e as principais partes interessadas concordam que as etapas intermediárias foram cumpridas, as datas de prazo são realistas, as funções e as responsabilidades no projeto estão bem definidas e há mecanismos prontos para cuidar de áreas de risco do projeto. A especificação funcional, o plano do projeto e o cronograma do projeto constituem a base para futuras decisões de compensação.

Depois que a equipe aprova as especificações, os planos e os cronogramas, os documentos se tornam a linha de base do projeto. A linha de base leva em conta as diversas decisões tomadas por consenso, aplicando as três variáveis de planejamento do projeto: recursos, cronograma e características. Concluída e aprovada a linha de base, ela é colocada sob controle de alterações. Isso não significa que todas as decisões tomadas na fase de planejamento sejam finais. Significa, porém, que, à medida que o trabalho progredir na fase de desenvolvimento, a equipe deverá examinar e aprovar formalmente toda sugestão de alteração à linha de base.

Lista de verificação da fase de planejamento

Antes de passar à fase de desenvolvimento, os seguintes itens devem ser inspecionados:

  • Lista de aplicativos, SMEs e mídia

  • Pacote de aplicativos a caminho

  • Plano de migração dos aplicativos básicos

  • Especificação funcional aprovada

  • Ambiente de laboratório estabelecido para desenvolvimento e teste

  • Diagramas de rede criados e analisados

  • Revisão/avaliação das operações da especificação funcional

  • Plano do projeto criado

  • Cronograma do projeto criado

  • Plano de gerenciamento de riscos atualizado e revisado

  • Diretivas, estratégias e configuração de segurança

  • Revisão/avaliação da segurança da especificação funcional

  • Abordagem tecnológica validada

  • Plano de teste criado

  • Inventário de aplicativos do computador conduzido e revisado

  • Inventário de hardware do computador executado e revisado

Passando à fase de desenvolvimento

Após a conclusão de todas as tarefas da fase de planejamento, a equipe deve expressar formalmente que o projeto atingiu a Etapa planos do projeto aprovados. Com a conclusão da etapa, os membros indicam que estão satisfeitos com o trabalho executado em suas áreas de responsabilidade.

Como antes, as equipes do projeto geralmente marcam a conclusão de uma etapa com uma aprovação formal, inclusive com a anuência do cliente e das principais partes interessadas. O documento de aprovação torna-se um resultado final do projeto e é arquivado para consulta futura.

Isso foi útil para você?
(1500 caracteres restantes)
Agradecemos os seus comentários
Mostrar:
© 2014 Microsoft. Todos os direitos reservados.