Artefato:  Build

Build	Build é uma versão operacional de um sistema ou parte de um sistema que demonstra um subconjunto dos recursos a serem fornecidos no produto final. Ele é constituído de um ou mais componentes (geralmente executáveis), que são construídos a partir de outros componentes, normalmente por um processo de compilação e vinculação do código-fonte.
Representação em UML:	Pacote no modelo de implementação (seja como um pacote de nível superior ou um subsistema de implementação), estereotipado como "build".
Papel:	Integrador
Finalidade Propriedades Ocorrência Responsabilidade Adaptação

Entrada para Atividades: Executar Conjunto de Testes Implementar Teste Implementar Conjunto de Testes Verificar Mudanças no Build Criar Unidade de Implantação Desenvolver Artefatos de Instalação Desenvolver Materiais de Treinamento Desenvolver Material de Suporte

Saída de Atividades: Integrar Sistema Integrar Subsistema

Finalidade

A finalidade de um build, construído a partir de outros componentes no modelo de implementação, é liberar um subconjunto testável dos recursos e funções em tempo de execução do sistema. O Rational Unified Process (RUP) sugere que uma seqüência de builds seja construída durante uma iteração, adicionando capacidade a cada um deles à medida que componentes de subsistemas de implementação forem adicionados ou aprimorados.  É possível construir builds em todos os níveis de um sistema, abrangendo um único sistema ou vários. No RUP, porém, estamos interessados especialmente nos builds definidos em Artefato: Plano de Integração do Build, pois eles constituem o meio para que a iteração seja concluída.  Se o tamanho ou a complexidade do sistema garantir isso, o Plano de Integração do Build poderá se estender por vários planos, abrangendo subsistemas individuais.

Observe que os builds informais podem ser construídos por um implementador por vários motivos (teste unitário, por exemplo), usando componentes provenientes do espaço de trabalho de desenvolvimento particular do implementador e dos espaços de trabalho de integração do sistema e subsistema, conforme apropriado. Contudo, como o termo é usado aqui, os builds são construídos por um integrador a partir de versões identificadas de componentes liberados pelos implementadores aos espaços de trabalho de integração do sistema ou subsistema, como definido em Artefato: Plano de Integração do Build.

Propriedades

Ocorrência

Os builds serão construídos como definido em Artefato: Plano de Integração do Build para cada iteração. O RUP não requer nenhuma ocorrência ou freqüência específica, pois esses itens são selecionados para atender às necessidades específicas de um projeto. Com o grau correto de automatização, certamente é possível adotar uma estratégia de builds diários, utilizando um stream estável de componentes provenientes de implementadores, integrando-os e testando o build resultante durante a noite. Esse procedimento não será adequado para todos os projetos, especialmente para os de grande porte, que requerem um teste de regressão demorado.

Responsabilidade

O Integrador é responsável pela produção de builds. Se o desenvolvimento for planejado com base em subsistemas (com equipes associadas), que depois são integrados ao sistema, pode ser que haja várias pessoas desempenhando o papel de Integrador. Talvez até mesmo uma em cada equipe de subsistema, para realizar a integração nesse nível, e outra para realizar a integração no nível do sistema.

Adaptação

É evidente que os builds são obrigatórios, porém os tipos de builds produzidos por um projeto serão alterados ao longo do ciclo de vida. Na fase de iniciação, a preocupação pode ser produzir protótipos como uma maneira de compreender melhor o problema ou de se comunicar com o cliente. Na elaboração, pode ser produzir uma arquitetura estável e, na construção, adicionar funcionalidade. Na transição, o objetivo é garantir que o software atinja uma qualidade apropriada.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process