Diretrizes:
|
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. |
Documente as decisões como parte do processo específico do projeto.
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) |
---|---|---|
|
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
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.
Decida qual será o grau de revisão de código.
As vantagens das revisões de código são:
As desvantagens das revisões de código são:
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:
Para fazer o melhor uso possível das revisões de código, lembre-se:
Rational Unified Process
|