Diretrizes: Decisões Importantes em Implementação

As seguintes decisões devem ser tomadas em relação ao fluxo de trabalho da disciplina Implementação:

Parte do fluxo de trabalho	Comentários
Gerenciamento de build e integração	O papel Integrador e a Atividade: Planejar Integração do Sistema, em conjunto com o Artefato: Plano de Integração do Build, costumam ser incluídos logo no início do projeto. As outras atividades relacionadas à integração (como, por exemplo, a Atividade: Planejar Integração do Subsistema, a Atividade: Integrar Subsistema e a Atividade: Integrar Sistema) são incluídas apenas no momento em que a integração é iniciada.
Implementação de componentes	Os papéis Implementador e Revisor de Código, assim como seus respectivos artefatos e atividades, são incluídos no início da implementação, em cada iteração.

Documente as decisões no Caso de Desenvolvimento, no tópico Disciplinas, Implementação, Fluxo de Trabalho.

Decidir Como Usar Artefatos

Decida os artefatos a serem usados e como usar cada um deles. A tabela abaixo descreve os artefatos que você obrigatoriamente deve ter e os que são usados apenas em alguns casos. Para obter informações mais detalhadas sobre como adaptar cada artefato e conhecer as vantagens e desvantagens de cada um deles, consulte a seção "Adaptação" para cada artefato desejado.

Para cada artefato, decida como ele deverá ser usado: Obrigatório, Recomendável, Opcional ou Desnecessário. Para obter mais detalhes, consulte Diretrizes: Classificação de Artefatos.

Artefato

Finalidade

Adaptação (Opcional, Recomendada)

Modelo de implementação

(Subsistema de implementação, Componente)

O modelo de implementação consiste no código-fonte, nos executáveis e em todos os outros artefatos necessários para criar e gerenciar o sistema no ambiente em tempo de execução.

Um subsistema de implantação é um conjunto de componentes e outros subsistemas de implementação que é usada para estruturar o modelo de implementação dividindo-o em partes menores.

Um componente representa um trecho de um código de software (fonte, binário ou executável) ou um arquivo contendo informações (por exemplo, um arquivo de inicialização ou um arquivo Leiame). Ele também pode ser uma agregação de outros componentes (por exemplo, um aplicativo formado por vários executáveis).

Todos os projetos de software possuem um modelo de implementação com componentes que incluem, no mínimo, alguns executáveis e códigos-fonte.

Alguns projetos também incluirão subsistemas, bibliotecas e modelos visuais.

Os subsistemas são úteis quando há um grande número de componentes para serem organizados.

Plano de Integração do Build

Define a ordem em que os componentes e os subsistemas devem ser implementados, os builds que devem ser criados durante a integração do sistema e como eles devem ser avaliados.

Opcional.

Recomendada se for necessário planejar a integração. Omita-o apenas quando a integração for trivial.

Decidir a Cobertura de Teste Unitário

Decida qual será o grau de execução do teste unitário e o nível de cobertura de código, cuja escala varia de informal a 100%. Essa escala está descrita no Plano de Teste.

O nível de cobertura do teste unitário costuma ser determinado pelas necessidades dos testadores de sistemas e de integração, para os quais o código foi encaminhado. Os testadores de sistemas dependem da qualidade do código para efetuarem seu trabalho. Se houver muitos defeitos no código, esses testadores o devolverão aos implementadores com muita freqüência. Isso é sinal de um processo de desenvolvimento de baixa qualidade; a solução pode ser exigir que os implementadores realizem testes unitários mais completos.

É claro que não se pode esperar que o código não apresente mais nenhum defeito depois da execução do teste de unidade. No entanto, é necessário encontrar um equilíbrio "saudável" entre os testes unitários e a qualidade.

O nível de cobertura do teste unitário também pode variar de acordo com as diferentes fases. Nem mesmo um projeto cuja segurança seja muito importante e que exija 100% de cobertura do código durante a construção e a transição costuma exigir esse mesmo nível durante a elaboração, porque muitas classes são implementadas apenas parcialmente nessa etapa.

Decidir Como Revisar o Código

A revisão do código valoriza significativamente o projeto. Pode-se observar uma melhora no desempenho dos revisores em todos os projetos que medem os níveis de erros e de problemas de manutenção relacionados a revisões de código. Em muitas organizações, porém, é difícil fazê-las "decolar". Os motivos são vários: