Tópicos

Decidir Como Executar o Workflow Para o início da página

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

  • Decida como executar o workflow consultando Implementação: Workflow. Analise o diagrama com suas ../glossary.htm#guard_condition -- This hyperlink in not present in this generated websitecondições de guarda e as diretrizes a seguir. Decida os detalhes do workflow a serem executados e em qual ordem. 
  • Decida que partes dos detalhes do workflow de Implementação deverão ser executadas. Estão relacionadas a seguir algumas partes que podem ser incluídas com certa independência entre si.

Parte do workflow

Comentários

Gerenciamento de build e integração A função Integrador e a Atividade: Planejar a Integração do Sistema juntamente com o Artefato: Plano de Construção de Integração são geralmente inseridos logo no início do projeto. As outras atividades relacionadas à integração, como Atividade: Planejar a Integração do Subsistema, Atividade: Integrar Subsistema e Atividade: Integrar Sistema são inseridas logo que a integração é iniciada. 
Implementação de componentes As funções Implementador e Revisor de Código, e suas atividades e artefatos, são inseridos no início da implementação, em cada iteração.

  • Durante o ciclo de vida do projeto, decida quando incluir cada parte do workflow. Geralmente, você pode aguardar até a fase de Elaboração para inserir toda a disciplina Implementação. Qualquer criação de protótipos que ocorra na fase de Iniciação geralmente tem um caráter exploratório e não é conduzida com o mesmo rigor (em relação a artefatos e revisões, por exemplo), conforme requerido pelo workflow Implementação completo durante a elaboração e construção.

Documente as decisões como parte do processo específico do projeto.

Decidir Como Utilizar Artefatos Parte superior da página

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 uma análise das vantagens e desvantagens desse artefato específico, leia a seção intitulada "Adaptação" para cada artefato.

Para cada artefato, decida como o artefato deve ser utilizado: Obrigatório, Recomendável, Opcional ou Desnecessário.

Artefato Finalidade

Adaptação (Opcional, Recomendada)

Modelo de Implementação

(Subsistema de Implementação, Elemento de Implementação)

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.

Uma implementação é composta de elementos de implementação, que incluem código (origem, binários e executáveis), e de arquivos contendo informações (por exemplo, um arquivo de inicialização ou um arquivo LEIA-ME).

Um subsistema de implementação é uma coleção de elementos e outros subsistemas de implementação que é utilizada para estruturar o modelo de implementação dividindo-o em partes menores.

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

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

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

Plano de Construção de Integração Define a ordem em que os componentes devem ser implementados, quais construções devem ser criadas durante a integração do sistema e como eles devem ser avaliados.

Opcional.

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


Ajustar cada artefato para as necessidades do projeto. Para obter as considerações de ajuste, consulte a seção de ajuste da página de descrição dos artefatos

Decidir a Cobertura do Teste Unitário Para o início da página

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

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 o teste unitário 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 Para o início da página

Decida qual será o grau de revisão de código. 

As vantagens das revisões de código são:

  • Implementar e estimular um estilo de codificação comum no projeto. A revisão do código é uma maneira eficiente de fazer com que os membros do projeto sigam o Guia de Programação. Para assegurar isso, é mais importante revisar os resultados de todos os autores e implementadores do que revisar todos os arquivos de código-fonte.
  • Localizar erros que os testes automatizados não detectam. As revisões de código localizam erros que não tenham sido detectados nos testes.
  • Compartilhar conhecimento entre as pessoas e transferi-lo das mais experientes para as menos experientes.

As desvantagens das revisões de código são:

  • Demanda tempo e recursos.
  • Se a revisão não for feita de forma apropriada, pode ser ineficaz. Há um risco de a revisão do código ser feita "apenas porque precisa ser feita" e não como um complemento eficiente para testes automatizados.

Para obter informações adicionais sobre revisão do código, consulte também Atividade: Rever 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", por várias razões:

  • Não foram coletados dados suficientes para verificar se a revisão do código realmente funciona.
  • Foram coletados dados em demasia.
  • Os implementadores são muito protecionistas em relação ao código.
  • As revisões se prendem demais a formalidades.
  • A administração das revisões exige muito esforço.

Para fazer o melhor uso possível das revisões de código, lembre-se:

  • Colete apenas dados adequados.
  • Meça o desempenho das revisões e exiba o resultado.
  • Utilize as revisões sem "excessos".


Rational Unified Process   2003.06.15