Finalidade
  • Integrar os subsistemas de implementação por partes em um build.
Função:  Integrador  
Freqüência: Pelo menos uma vez por build. 
Etapas
Artefatos de Entrada:    Artefatos Resultantes:   
Mentores de Ferramentas:   
Informações Adicionais: 

Detalhes de Detalhamento do Fluxo de Trabalho::   

Aceitar Subsistemas e Produzir Builds Intermediários Para o início da página

Quando esta atividade começa, os subsistemas de implementação já foram liberados para satisfazer aos requisitos do build seguinte (o 'destino'), descrito no Artefato: Plano de Integração do Build, lembrando que o Plano de Integração do Build pode definir a necessidade de vários 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 de baixo para cima 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.

Diagrama descrito no texto de acompanhamento.

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. 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.

Promover Baselines Para o início da página

À medida que um build é aprovado em diversos níveis de teste, as baselines associadas são promovidas de acordo. 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 pela Função: Gerenciador de Configuração como parte da definição das políticas de configuração do projeto. Os níveis de promoção são importantes para os consumidores da baseline; por exemplo, um implementador precisará saber se uma baseline é estável e foi testada antes de atualizar (ou 'criar nova baseline') 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   2003.06.15