Você precisa determinar uma estratégia, baseada no Design de como irá implementar o item de trabalho que está tratado neste momento. Suas opções são:

1. Aplique recursos reutilizáveis existentes.
2. Modele o design detalhadamente e gere o código fonte (pela transformação do modelo).
3. Escreva o código fonte.
4. Qualquer combinação das opções descritas.

Complete a implementação reutilizando código sempre que possível.

Identifique algum código existente ou elementos de implementação que você possa reutilizar na parte da Implementação que você está criando ou alterando. Uma compreensão detalhada de todo o design é muito útil porque é mais fácil encontrar oportunidades de reuso quando se tem uma completa compreensão da solução proposta.

Se você estiver usando ferramentas de modelagem sofisticadas, poderá gerar uma parte do código fonte necessário a partir do modelo. Note que a programação sempre será necessária para terminar a implementação, após o modelo de design ter sido transformado em código.

Você deve tentar o reúso ou a geração automática de código sempre que possível, mas ainda necessitará de alguma programação. Para isso, considere o seguinte:

• Examine os requisitos. Pelo fato de algumas informações dos requisitos não se traduzirem diretamente em seu design você deve examinar os requisitos (incluindo os Casos de Uso e Requisitos Suplementares) para se assegurar que estejam inteiramente contemplados na implementação.
• Refatore o código para melhorar o design. A Refatoração é uma técnica onde a qualidade do código é melhorada através de pequenas mudanças.
• Ajuste os resultados da implementação existente melhorando o desempenho, a interface de usuário, a segurança, e outras áreas não funcionais.
• Adicione detalhes faltantes, tais como a conclusão da lógica das operações ou a adição de classes e de estruturas de dados de suporte
• Cuide das condições limítrofes.
• Trate as circunstâncias incomuns ou os estados de erro.
• Restrinja o comportamento (impedindo que os usuários executem fluxos, cenários ou combinações de opções ilegais).
• Adicione seções críticas para código multi-thread ou reentrante.
  

Crie uma nova Construção. Isto pôde significar simplesmente a atualização e/ou a execução de um script de construção.

Verifique que a implementação esteja ajustada à sua finalidade. Examine o código para determinar se ele executa a função desejada. Esta é uma etapa de garantia da qualidade que é executada além dos testes e é descrita em outras tarefas. Considere estas estratégias:

• Programação em pares. Pela divisão da equipe em pares de implementadores, você avalia eficazmente o código assim que ele começa a ser escrito.
• Leia o código para encontrar erros comuns. Considere manter uma lista de verificação dos erros encontrados para servir como uma memória de referência.
• Use ferramentas para verificar erros de implementação e código impróprio. Por exemplo, use um verificador de regras de código estático ou ajuste o compilador para o nível mais detalhado de advertências.
• Use ferramentas que possam visualizar o código. A visualização de código, tal como as visualizações UML na IDE Eclipse, ajudam os desenvolvedores a identificar questões tais como acoplamento excessivo ou dependências circulares.
• Execute inspeções informais direcionadas ao código. Peça aos colegas para revisar pequenas seções críticas do código. Evite a revisão de grandes seções de código.
• Use o Testador para assegurar que a implementação é compreensível e testável para testar os recursos.

Melhore a implementação baseada nos resultados destas avaliações.

Comunique o impacto de mudanças inesperadas no design e nos requisitos.

As questões e as restrições descobertas durante a implementação do sistema devem ser comunicadas à equipe. O impacto das questões descobertas durante a implementação deve ser incorporado nas decisões futuras. Se for apropriado, atualize os casos de uso e os requisitos suplementares para refletir as ambigüidades identificadas e resolvidas na implementação de modo que possam ser testadas, tornando possível controlar as expectativas dos Stakeholders.Similarmente, atualize o design para refletir novas restrições e questões descobertas durante a implementação para ter certeza que a nova informação será comunicada para os outros desenvolvedores.

Normalmente, não há necessidade de efetuar uma solicitação de mudança se a mudança requerida for pequena e se a mesma pessoa estiver projetando e implementando a classe. Esse indivíduo pode fazer a mudança no design diretamente. Se a mudança requerida tiver um grande impacto, tal como uma mudança em um método público, pode ser necessário comunicar essa mudança aos outros membros da equipe através de uma solicitação de mudança.