Implementar tarefas de desenvolvimento
Uma tarefa de desenvolvimento é uma pequena parte do trabalho de desenvolvimento que deriva de um requisito. Implementar uma tarefa de desenvolvimento envolve adicionar a nova funcionalidade apropriada ao seu software. Depois de concluir uma tarefa de desenvolvimento, ele deve ser testada de unidade, revisado, código analisado e integrado na base de código existente.
Neste tópico
Estimar
Documentos de design
Revisão de design
Testes de unidade
Análise de Código
Processo de revisão de código
Refatorar
Integrar as alterações
Estimar
Estimar o custo de controle de ajuda de tarefas de desenvolvimento do escopo de recursos e agenda o trabalho de desenvolvimento. Estimativas de custo para todas as tarefas de desenvolvimento devem ser concluídas e todos os problemas devem ser resolvidos antes da reunião de planejamento de iteração. Se o custo total das tarefas de desenvolvimento é mais do que pode ser feito em uma iteração, uma tarefa deve ser adiada ou reatribuída. Após o desenvolvimento de um tarefa é escolhida, é responsabilidade do desenvolvedor para a tarefa de custo.
Criar um item de trabalho de tarefa para cada tarefa de desenvolvimento escolhido e vinculá-lo ao requisito do qual ele foi criado. Isso é feito a partir da guia de implementação na tarefa ou o item de trabalho de requisito. Base suas estimativas sobre o tempo necessário para concluir tarefas semelhantes, e não se esqueça de considerar o custo de escrever testes de unidade. Para cada tarefa, insira a estimativa o campo Estimativa Original do item de trabalho tarefa.
O formulário de tarefa funcionam itens armazena dados os campos e guias que mostram as ilustrações a seguir:
Depois de tarefas foram criados e estimado, use a consulta de detalhamento de trabalho para exibir a análise de todos os seus requisitos e tarefas. Para obter mais informações, consulte Consultas compartilhadas (CMMI).
Documentos de design
Os documentos de design devem incluir informações suficientes para descrever a um desenvolvedor como escrever código para implementar o requisito do produto.
Documentos de design podem ser uma coleção de especificações, itens de trabalho de requisito e outros documentos, dependendo do processo de equipe.
Considere o uso de padrões de design, design orientado a objeto, modelos estruturais, linguagens de modelagem, modelos de relação de entidade e outras técnicas nas diretrizes para o design é determinado para sua equipe. Também é uma boa idéia para documentar a lógica para decisões importantes que foram feitas. Por exemplo, se houver um impacto significativo sobre o custo, o agendamento ou desempenho técnico, documentar o motivo de decisões que envolvem esses efeitos e incluir essas informações no seu design.
Depois de criar os documentos de design necessárias, armazená-los em que os membros da equipe possam compartilhá-las. Para obter mais informações, consulte Gerenciar documentos e bibliotecas de documentos.
Revisão de design
Uma revisão de design é usada para garantir que o projeto novo ou revisado é tecnicamente precisas, completas, pode ser testado e de alta qualidade e que ele implementa o requisito corretamente. Revisões de projeto são um método principal de garantia de qualidade no início ao identificar problemas antes de aparecerem no código. Revisões de design também fornecem informações adicionais sobre o design de outros desenvolvedores.
O desenvolvedor responsável pela criação do design deve organizar a revisão de design identificando os revisores, a revisão de agendamento e distribuir o design para todos os revisores.
Qualquer participantes que estão envolvidos ou afetados pelo design devem participar da revisão. Normalmente, isso pode incluir o gerente de projeto, o desenvolvedor líder e testador para a área de design. Todos os desenvolvedores que estejam na mesma equipe como o desenvolvedor cujo código está sendo revisado também deve participarem da revisão.
Agendar a reunião de revisão e distribuir os documentos de design cedo o suficiente para dar a cada tempo suficiente de revisor para lê-los. Planeje o comprimento da reunião de revisão para corresponder ao quantos detalhes técnicos devem ser examinados.
Verificar a qualidade
Certifique-se de que o design é testável. Ele compila o código que não pode ser verificado e validado de forma razoável? Nesse caso, você não pode garantir a qualidade do código e o design deve ser reformulado. Examine os documentos de design para problemas que levarão a erros de código. Procure descrições da interface incorreta, erros de design ou nomenclatura confusão. Compare os documentos de design em relação a critérios existentes, como padrões de interface de operador, padrões de segurança, restrições de produção, design tolerâncias ou padrões de partes. Criar itens de trabalho que descrevem quaisquer falhas encontradas nos documentos de design de bug e atribuí-los para o desenvolvedor responsável.
Criar um Item de trabalho de revisão do design
Um item de trabalho de revisão é criado para documentar os resultados da revisão de design. A equipe de análise deve decidir as próximas etapas para o design, que depende da magnitude das alterações necessárias. Se nenhuma alteração é necessária, definir o estado do item de trabalho fechado, defina o motivo aceitos (como) e observe que a codificação pode iniciar o projeto. Se alterações forem necessárias, definir o estado do item de trabalho como resolvido e definir o motivo para aceito com algumas pequenas alterações. Isso indica que a codificação pode iniciar depois de implementar as pequenas alterações no design. Se as principais alterações forem necessárias, definir o estado do item de trabalho como resolvido e definir o motivo para aceito com as principais alterações. O design deve ser reformulado e outra revisão de design deve ser executada antes de codificação pode iniciar o projeto.
Testes de unidade
Testes de unidade Verifique a implementação correta de uma unidade de código. Escrever e executar testes de unidade identifica bugs antes de teste é iniciado e, portanto, ajuda a reduzir o custo de controle de qualidade. Os desenvolvedores devem escrever testes de unidade para todo o código que será gravado como parte da implementação de uma tarefa de desenvolvimento ou corrigindo um bug. Para obter mais informações, consulte Teste de unidade de código.
Análise de Código
Análise de código verifica o código em relação a um conjunto de regras que ajudam a aplicar as diretrizes de desenvolvimento. O objetivo da análise de código é não têm nenhum violações de análise de código ou avisos. Análise de código pode inspecionar o código para mais de 200 possíveis problemas no design de bibliotecas, convenções de nomenclatura, localização, segurança e desempenho.
Se você começar a executar análise de código no início do seu ciclo de desenvolvimento, você pode minimizar violações e avisos em uma base contínua.
No entanto, se você executar a análise de código no código existente que não foi verificado antes, você pode ter muitas violações de regra. Se esse for o caso, você talvez queira criar um conjunto de linha de base de regras críticas que o código deve passar e, em seguida, expanda a regra definida como os problemas mais críticos são resolvidos. Dessa forma, uma equipe pode avançar sobre a nova funcionalidade como ele melhora sua base de código existente.
Para obter mais informações, consulte Analisando a qualidade do aplicativo usando as ferramentas de análise de código e Melhorando a qualidade do código com políticas de check-in do projeto da equipe.
Processo de revisão de código
Desenvolvedor-chefe deve organizar a revisão de código identificando os revisores, agendar a revisão de código e enviar o código para revisão para todos os revisores. Para preparar para a revisão de código, execute as seguintes etapas:
Crie um item de trabalho de revisão para acompanhar as decisões feitas da revisão. Se nenhuma alteração é necessária, definir o estado do item de trabalho fechado, defina o motivo aceitos (como) e observe que a codificação pode iniciar o projeto. Se alterações forem necessárias, definir o estado do item de trabalho como resolvido e definir o motivo para aceito com algumas pequenas alterações, que indica que a codificação pode iniciar depois de implementar as alterações secundárias. Se as principais alterações forem necessárias, definir o estado do item de trabalho como resolvido e definir o motivo para aceito com as principais alterações. O design deve ser reformulado e outra revisão de design deve ser executada antes de codificação pode iniciar o projeto.
Determine os participantes da revisão de código. Normalmente, pelo menos o desenvolvedor líder e arquiteto responsável pela área de código devem participar da revisão.
Agendar uma reunião de revisão com os revisores e permita tempo suficiente para cada revisor de ler e entender o código antes da reunião. Planeje o comprimento da reunião de revisão para corresponder à quantidade de código deve ser examinado.
Revisão de Código
Uma revisão de código é usada para garantir que o código novo ou alterado atenda um nível de qualidade estabelecidos antes que ele está integrado na compilação diária. Considerações de qualidade são padrões, conformidade de arquitetura e design, desempenho, legibilidade e segurança de código. Revisões de código também fornecem informações adicionais de outros desenvolvedores sobre como o código deve ser gravado.
Verifique se a relevância do código |
O código que está sendo revisado é relevante para a tarefa para a qual o código é gravado. Nenhuma alteração de código deve ser permitida que aborda a funcionalidade que é implementada ou corrigida. |
Verifique se a extensibilidade |
O código é escrito de forma que ele pode ser estendido, se essa for a intenção ou reutilizado em outras áreas do sistema. Constantes de cadeia de caracteres que são usadas no código são colocados corretamente em recursos que podem ser internacionalizados. |
Verifique se a complexidade do código mínimo |
Repetidas de código podem ser simplificada para funções comuns. Funcionalidade semelhante é colocada em uma função ou procedimento comum. |
Verifique se a complexidade algorítmica |
O número de caminhos de execução no código que é analisado é minimizado. |
Verifique se a segurança do código |
O código é verificado para a proteção de ativos, níveis de privilégio e o uso de dados em pontos de entrada. |
Refatorar o código
Código é refatorado após uma revisão de código determinou que as alterações devem ser feitas para abordar a arquitetura, desempenho ou a qualidade do código.
Leia as notas de item de trabalho de revisão de código para determinar como você irá refatorar o código.
Aplica a refatoração incrementalmente, uma alteração de cada vez. Alterar o código e todas as referências à área modificada conforme necessário.
Execute testes de unidade para que a área permanece semanticamente equivalente após a refatoração. Corrija qualquer teste de unidade que não funcionam. Executar análise de código e corrigir todos os avisos. Execute novamente os testes de unidade se forem feitas alterações de código como resultado da análise de código.
Integrar as alterações
A etapa final é integrar as alterações verificando-los ao controle de versão. Antes que o código é verificado, todos os testes que são exigidos por seu processo devem ser executados. Para obter mais informações sobre como verificar o código para problemas antes de check-in, consulte Melhorando a qualidade do código com políticas de check-in do projeto da equipe.
Se o item de trabalho que está associado com as alterações é um cenário ou uma qualidade de requisito de serviço das quais você não é o proprietário, notificar o proprietário para que as alterações forem concluídas. Definir o item de trabalho tarefa resolvido e atribuí-la a um dos testadores que criou os casos de teste para o item de trabalho.
Se o item de trabalho que está associado com as alterações é um bug, defina o item de trabalho bug como resolvido e atribuí-la à pessoa original que criou.