Atividade:
| ||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes: |
| Papel: Integrador | |
| Detalhamentos do Fluxo de Trabalho: |
Quando esta atividade começa, os subsistemas de implementação já foram liberados para satisfazer aos requisitos do build seguinte (o 'alvo'), descrito em Artefato: Plano de Integração do Build, lembrando que esse Plano pode definir a necessidade de diversos builds em uma iteração. Dependendo da complexidade e do número de subsistemas a ser integrado, geralmente é mais eficiente produzir o build-alvo em diversas etapas, adicionando mais subsistemas a cada uma delas e produzindo vários 'minibuilds' intermediários - assim, cada build planejado para uma iteração pode, por sua vez, ter sua própria seqüência de builds intermediários transitórios. Esses builds estão sujeitos a um teste mínimo de integração (em geral, um subconjunto dos testes descritos no Plano de Integração do Build do build-alvo) para garantir que as adições sejam compatíveis com o que já existe no espaço de trabalho de integração do sistema. Essa abordagem permite isolar e diagnosticar problemas com mais facilidade.
O integrador aceita os subsistemas liberados gradativamente no espaço de trabalho de integração do sistema e resolve quaisquer conflitos de mesclagem no processo. Para fazer isso, é recomendável que seja utilizada uma abordagem do tipo bottom-up com relação à estrutura em camadas, certificando-se de que as versões dos subsistemas sejam consistentes e levando em consideração as importações. O incremento de subsistemas é compilado e vinculado a um build intermediário, que será fornecido para o testador de modo que execute um teste mínimo de integração do sistema.
Esse diagrama mostra um build produzido em três incrementos. Alguns subsistemas são necessários apenas como stubs, para permitir a compilação e a vinculação dos outros subsistemas, e apresentam o comportamento essencial mínimo de tempo de execução.
O incremento final de uma seqüência produz o build-alvo, conforme planejado no Plano de Integração do Build. Quando esse build tiver sido minimamente testado, uma baseline inicial ou provisória será criada para ele e disparará a Atividade: Criar Baselines na disciplina Gerenciamento de Configuração. O build é, então, disponibilizado para o testador para o teste completo do sistema. A natureza e o detalhamento desse teste seguirão as especificações do Plano de Integração do Build, e o build final de uma iteração estará sujeito a todos os testes definidos no Plano de Teste da Iteração.
À medida que um build é aprovado em diversos níveis de teste, as baselines associadas são promovidas de acordo. Para fazer isso, é necessário disparar a Atividade: Promover Baselines na disciplina Gerenciamento de Configuração. A promoção é uma maneira de marcar baselines como aprovadas ou reprovadas em determinado nível de teste. Os nomes dos níveis de promoção são definidos pelo Papel: Gerente de Configuração, como parte da definição das políticas de configuração do projeto (no Artefato: Plano de Gerenciamento de Configuração). Os níveis de promoção são importantes para os consumidores da baseline: por exemplo, é aconselhável que um implementador saiba que uma baseline é estável e foi testada antes de atualizar (ou 'criar nova baseline para') um espaço de trabalho de desenvolvimento privado, para que fique consistente com uma baseline no espaço de trabalho de integração do sistema.
|
Rational Unified Process
|
