Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

Link para esta página de comparações

Próxima revisão
Revisão anterior
pcodifica [2016/06/13 07:40]
rogerio.thome criada
pcodifica [2016/08/25 07:25] (atual)
mario
Linha 1: Linha 1:
 ====== 3.2 Desenvolvimento ====== ====== 3.2 Desenvolvimento ======
  
-Inclui as seguintes ​ações:+O processo de desenvolvimento de um sistema, de forma geral, é formado por um conjunto de ações ​que se repetem durante sua execução. O desenvolvimento pode ser longo, durando meses ou até anos. Por este motivo, se faz necessária um divisão do todo em etapas menores, que possam ser executadas iterativamente até que o todo esteja concluído. Estas etapas são chamadas de Marcos.
  
-  - Versionar/sincronizar código; +Um **Marco** pode ser definido como sendo uma etapa de um processo de desenvolvimento. Cada Marco é composto por um conjunto de tarefas, chamadas de //tickets//, que indicam todas as tarefas que serão executadas por um desenvolvedor. De forma geral, um requisito ​pode ser derivado em N tarefas de desenvolvimento. Cada tarefa possui uma priorização e um tipo (defeito, melhoria e análise). 
-  - Codificar ​requisito; + 
-  - Realizar teste unitário+Durante o desenvolvimento de um Marco, diversas ações são executadas. Este processo inclui as seguintes ações: 
-  - Estabilizar versão+ 
-  - Gerar versão final+  - Preparação do ambiente de desenvolvimento
-  - Realizar commit+  - Aceitação de uma tarefa e seu desenvolvimento
-  - Atualizar controle (trac)+  - Revisão e integração
 +  - Testes de usuário e estabilização
 +  - Finalização de uma versão;
   - Documentação do código (request commit).   - Documentação do código (request commit).
 +
 +Com exceção da primeira ação, que costuma ser executada apenas uma vez no início do processo de desenvolvimento,​ todas as outras são executadas iterativamente enquanto existirem Marcos.
 +
 +  1.Preparação do ambiente de desenvolvimento
 +  ​
 +A ação de preparar o ambiente consiste em deixar um desenvolvedor apto a desenvolver os //tickets// contidos em um Marco. Esta ação em geral é executada uma vez ao início do processo de desenvolvimento,​ e costuma não ser mais necessária durante o resto do processo. ​
 +
 +O primeiro passo necessário é fazer uma cópia do repositório principal para a conta do desenvolvedor. Essa cópia é chamada de //fork// e é realizada no servidor remoto. Uma vez que esta cópia foi realizada, o passo seguinte é baixar o repositório do servidor remoto para o computador que será utilizado para o desenvolvimento.
 +
 +Neste passo de preparação também estão inclusos a instalação da IDE a ser utilizada para o desenvolvimento,​ bem como a preparação das bibliotecas de terceiros que serão utilizadas durante o processo.
 +
 +  2.Aceitação da tarefa e seu desenvolvimento
 +  ​
 +Uma vez que o ambiente de desenvolvimento está pronto, a ação seguinte consiste em aceitar uma tarefa dentre as tarefas disponíveis e realizar o seu desenvolvimento. Em geral, existe sempre um Marco corrente ao qual os desenvolvedores devem focar seu desenvolvimento. Porém não é incomum a necessidade de desenvolver tarefas de correções em Marcos anteriores, ou até tarefas que estão previstas somente para Marcos posteriores.
 +
 +O desenvolvimento começa com a aceitação de uma tarefa por parte de um desenvolvedor. Esse passo irá indicar ao grupo que determinado desenvolvedor passou a ser o responsável pelo desenvolvimento de determinada tarefa. Em seguida o desenvolvimento se inicia. Ao final do desenvolvimento da tarefa, caberá ao desenvolvedor executar os devidos testes para verificar se tudo está correto e se a tarefa está realmente completa.
 +
 +Quando a tarefa estiver completa, o passo seguinte é o de integrar este desenvolvimento ao repositório principal. Primeiramente,​ o desenvolvedor integrará as modificações aos repositórios existentes na sua conta, e em seguida requisitar a revisão e integração das modificações ao repositório principal.
 +
 +  3.Revisão e integração
 +
 +Antes que um código desenvolvido seja integrado ao repositório principal, existe a necessidade de que ele seja analisado e revisado. Esta ação pode conter tanto revisões atendidas quanto por revisões automáticas. De forma geral, as revisões automáticas dizem respeito à testes de compilação,​ testes unitários e análise estática, mas podem conter outras formas. Já a revisão atendida é realizada por um desenvolvedor experiente onde ele irá analisar a sintaxe, semântica, formatação e boas práticas.
 +
 +Caso seja necessário,​ o desenvolvedor irá modificar o código a partir das sugestões levantadas na revisão. Logo após todas as sugestões terem sido desenvolvidas,​ o código é então integrado ao repositório principal.
 +
 +  4.Testes de usuário e estabilização
 +
 +Quando todas as tarefas de um marco estão finalizadas,​ ação seguinte é o início da fase de testes de usuário e estabilização. O objetivo desta fase é verificar se todas as tarefas que foram desenvolvidas atendem aos requisitos aos quais elas estão associadas. Um usuário com experiência nas regras de negócio do sistema irá realizar testes e analisar os resultados. Este usuário pode qualquer stakeholder,​ tanto interno quanto externo, e de forma geral deve conhecer as regras de negócio do sistema.
 +
 +Se durante a fase de testes alguma inconsistência for encontrada, como por exemplo falha na execução, ou um resultado diferente do esperado, a tarefa será reaberta para que o desenvolvedor possa efetuar as devidas adaptações e correções. Este processo iterativo de testes e ajustes é chamado de estabilização.
 +
 +  5.Finalização de uma versão
 +  ​
 +Uma vez que os testes realizados verificaram que todos as tarefas do Marco foram atendidas, o Marco é dado como estabilizado. Neste momento, inicia-se o desenvolvimento de um novo Marco.
 +
 +Além do início de um novo Marco, outros processos são realizados. O principal deles é a manutenção de uma cópia exata do estado de desenvolvimento ao final do desenvolvimento de cada Marco. Isso se faz necessário uma vez que podem haver entregas de versões, e pode ser preciso efetuar correções pontuais nesta versão entregue. Como não é desejável que aumentemos a instabilidade,​ essas correções devem ser realizadas no próprio Marco que havia sido finalizado.
 +
 +Dependendo do projeto, podem ocorrer entregas de versões nessa etapa. Consequentemente,​ pode ser necessário o empacotamento do sistema e de outros arquivos que compõem as entregas.