A ilustração mostra o relacionamento dos fluxos de trabalho em uma iteração tardia da fase de transição — se o 'Fechamento do Projeto' do Detalhamento do Fluxo de Trabalho for chamado, essa será a iteração final. Ela será construída a partir dos Detalhamentos do Fluxo de Trabalho da forma como aparecerem naquele momento. O intuito é indicar as dependências e mostrar onde ocorrem fluxos de trabalho em paralelo. Os comprimentos das barras no gráfico (indicando a duração) não têm significado absoluto. Por exemplo, não se pretende transmitir que Refinar a Arquitetura e Teste de Aceitação (no site de desenvolvimento) têm a mesma duração. Também não é a intenção sugerir a aplicação de um nível de esforço uniforme no decorrer dos fluxos de trabalho. Uma indicação do esforço relativo pode ser vista em Visão Geral do Processo. É possível navegar para as páginas correspondentes do Detalhamento do Fluxo de Trabalho a partir de cada linha do gráfico; basta clicar no nome do Detalhamento do Fluxo de Trabalho. Essa ilustração foi criada a partir de um Plano do Microsoft Project.

 

Plano de Iteração de Exemplo

Gerenciamento de Projeto

No final da Fase de Transição, o principal condutor de planejamento em Atividade: Desenvolver Plano de Iteração é a liberação de um software confiável, com desempenho aceitável e funcionalidade completa, ao cliente. Da mesma forma, as Solicitações de Mudanças (na maioria defeitos e feedback do teste beta) são as principais informações de planejamento fornecidas de que dispõe o Gerente do Projeto para continuar o desenvolvimento. Baseado no número e na gravidade das Solicitações de Mudança, o Gerente do Projeto pode lançar mão de atividades de gerenciamento de risco (através de Artefato: Lista de Riscos), por exemplo, no gerenciamento de requisitos variáveis ou no refinamento de arquitetura.

 O Gerente do Projeto também tem de planejar a produção do material de instalação e de suporte ao usuário final, assim como os aspectos formais contratuais do teste de aceitação. 

O Gerente do Projeto inicia a iteração em Atividade: Iniciar Iteração, em seguida, monitora e relata o status do projeto em Detalhamento do Fluxo de Trabalho: Monitorar e Controlar o Projeto. No fim, os resultados são examinados em Atividade: Avaliar Iteração e, se esta for a iteração final, o gerente do projeto preparará o projeto para uma paralisação.

Requisitos e Análise e Design

Dada a natureza do processo de desenvolvimento iterativo, espera-se que os requisitos estejam bem estáveis, se não completamente congelados, a esta altura. Mesmo assim, algum feedback que afete o sistema, ou a sua interpretação, deve ser antecipado e o impacto disso no escopo deve ser compreendido e controlado em Detalhamento do Fluxo de Trabalho: Gerenciar Requisitos Variáveis. É importante não permitir que o sistema mude de uma forma ad hoc durante a transição. 

Da mesma forma, o objetivo de análise e design nesta fase, em Detalhamento do Fluxo de Trabalho: Refinar a Arquitetura, é manter a integridade da arquitetura e executar a sintonia em tempo de execução e os ajustes de distribuição física para atender os requisitos de desempenho, capacidade e confiabilidade.

Implementação

O planejamento para a implementação durante a transição em Detalhamento do Fluxo de Trabalho: Planejar a Integração é conduzido pelo feedback do teste beta e de outras Solicitações de Mudança levantadas durante o teste pelo próprio projeto. À medida que os defeitos forem corrigidos em Atividade: Corrigir um Defeito e os subsistemas amadurecerem, eles serão integrados nos builds para teste. Na transição, o trabalho principal é corrigir defeitos nos componentes, não adicionar novos componentes. O teste unitário (em Atividade: Realizar Testes Unitários) ainda é necessário, mas a finalidade na transição é verificar mudanças e evitar regressões, e não concluir a verificação funcional. Na integração de subsistema e sistema durante a transição, (em Detalhamentos do Fluxo de Trabalho: Integrar Cada Subsistema e Integrar o Sistema), estarão disponíveis componentes completos, sendo desnecessário o uso de 'stubs', e, novamente, a finalidade será verificar e validar mudanças e verificar as regressões. Nem sempre é necessário realizar a integração com muita freqüência como durante a construção porque as interfaces são estáveis nesse momento e o Integrador pode seguir uma abordagem mais otimista.

Teste

O foco do teste durante a transição se volta para melhorar a qualidade e evitar regressão. Além disso, sempre haverá um requisito para teste de aceitação formal, que pode envolver uma repetição do todos ou parte dos testes no nível do sistema. O planejamento para a teste durante a transição (em Detalhamento do Fluxo de Trabalho: Definir Missão de Avaliação), portanto, precisa fornecer esforço e recursos para algum nível de design e implementação contínuos (por causa do desenvolvimento contínuo); o teste de regressão do qual dependerão o esforço e os recursos da abordagem escolhida (por exemplo, retestar tudo, retestar para um perfil operacional ou retestar o software mudado); e o teste de aceitação, que pode não exigir novos testes.

À medida que os defeitos forem corrigidos e o feedback do beta for incorporado, builds sucessivos serão testados usando o ciclo de teste normal dos Detalhamentos do Fluxo de Trabalho:

  • Validar a Estabilidade do Build - executar um subconjunto de testes para validar que o build seja estável o suficiente para o teste detalhado e que a avaliação possa começar.
  • Testar e Avaliar - os testes são implementados, executados e avaliados.
  • Realizar Missão Aceitável - os resultados dos testes são avaliados em comparação com os objetivos do teste. Testes adicionais são feitos se necessário.
  • Aprimorar Vantagens do Teste - os artefatos de teste são melhorados conforme a necessidade para suportar o próximo ciclo de testes.

Quando o sistema for considerado adequado para se submeter ao teste de aceitação (talvez através da repetição de todos ou partes dos testes no nível do sistema), um ciclo separado de testes será realizado focalizando a execução de testes e avaliação de resultados. Na transição, principalmente durante o teste de aceitação, o Cliente, o Designer de Teste e o Gerente de Implantação colaborarão durante o Detalhamento do Fluxo de Trabalho: Realizar Missão Aceitável, para decidir quais resultados dos testes são aceitáveis, se o teste deve continuar e quais testes devem ser repetidos.

Implantação

O Planejamento de Implantação (em Detalhamento do Fluxo de Trabalho: Planejar Implantação) nesse estágio da transição está relacionado ao estabelecimento da programação e dos recursos (em Artefato: Plano de Implantação) para o desenvolvimento (contínuo) de material de suporte ao usuário final, teste de aceitação, e produção, empacotamento e distribuição das unidades de implantação do software. O teste beta foi concluído em iterações anteriores da transição. O Gerente de Implantação também produz Artefato: Lista de Materiais neste detalhamento do fluxo de trabalho.

Qualquer trabalho restante para produzir Artefato: Material de Suporte para o Usuário Final (por exemplo, manuais do usuário, manuais operacionais, manuais de manutenção) e Artefato: Materiais de Treinamento será concluído por Papel: Redator Técnico e Papel: Desenvolvedor do Curso, respectivamente, em Detalhamento do Fluxo de Trabalho: Desenvolver Material de Suporte.

Quando o sistema estiver adequado, começará o teste de aceitação gerenciado pelo Gerente de Implantação em Atividade: Gerenciar Teste de Aceitação. Após o teste com êxito no local de desenvolvimento, o Gerente de Implantação inicia a produção das unidades de implantação (para instalar no local do cliente), produzindo Artefato: Notas de Release. Isso e Artefato: Artefatos de Instalação, produzido por Papel: Implementador, são informações fornecidas (juntamente com outras) a Atividade: Criar Unidade de Implantação (na disciplina Gerenciamento de Configuração). 

Com freqüência, pelo menos parte do teste de aceitação é realizado no local do cliente, normalmente depois de um teste de aceitação inicial no local de desenvolvimento.

Em paralelo com o teste de aceitação, a arte-final para o empacotamento do produto é desenvolvida por Papel: Artista Gráfico em Atividade: Criar Arte-final do Produto. Por fim, o gerente de implantação inicia a produção do produto para distribuição em Atividade: Liberar para Manufatura e verifica a qualidade em Atividade: Verificar Produto Manufaturado, antes que o produto seja despachado.

Ambiente

Neste estágio, haverá pouco ou nenhum trabalho de desenvolvimento a ser feito, o trabalho durante a transição deverá ser quase totalmente de suporte e manutenção, em Detalhamento do Fluxo de Trabalho: Ambiente de Suporte Durante uma Iteração.

Gerenciamento de Configuração

As atividades de gerenciamento de configuração continuam em paralelo com a implementação restante e teste, com ênfase crescente na formalidade do controle de mudanças. O Artefato: Unidade de Implantação é criado no Detalhamento do Fluxo de Trabalho: Gerenciar Baselines e Releases pelo Gerente de Configuração, como um percursor do empacotamento do produto final. 

Todas as solicitações de mudança exigirão sanção de um CCB no nível do projeto (e do cliente) durante a transição, como parte do Detalhamento do Fluxo de Trabalho: Gerenciar Solicitações de Mudança

Por fim, como parte da aceitação, normalmente é necessário fazer uma Auditoria de Configuração Funcional (FCA) e uma Auditoria de Configuração Física (PCA) em Atividade: Realizar Auditoria de Configuração.

Resultado

Essa iteração final na fase de transição atinge o ponto máximo na liberação para o cliente de um sistema completo (e artefatos de suporte auxiliares) com a funcionalidade e o desempenho que foram especificados e demonstrados no teste de aceitação. O cliente apropria-se do software após um teste de aceitação bem-sucedido.

Copyright  (c) 1987 - 2001 Rational Software Corporation


Exibir o Rational Unified Process usando quadros

Rational Unified Process