Ciclo de desenvolvimento de software

TLDR

Independente do tipo, para iniciar um projeto que envolve desenvolvimento de software com qualidade é necessário que alguns protocolos sejam seguidos. Nesse artigo eu tento citar o fluxo de trabalho que utilizo no desenvolvimento dos meus projetos pessoais de software.

Notas

Artigo destinado a pessoas com o conhecimento mínimo em ferramentas de controle de versão.
Alguns termos são apresentados em inglês quando não encontradas palavras adequadas para tradução.
Como trata-se do desenvolvimento de software, a criação do repositório de código não será mencionada, sendo o passo 0 do ciclo apresentado.

Na Figura 1 é apresentada uma visão geral do fluxo que uso no desenvolvimento de software. Abaixo serão descritos cada um desses passos.

flowchart LR
  A(Planejamento) ==> B(Implementação) ==> C(Teste)
  E ==> A
  C ==> E(Implantação e Manutenção)

Figura 1: Ciclo de vida do desenvolvimento de software.

Planejamento

Todo projeto começa com a ideia, que é desenvolvida por meio de discussões e pesquisas. Nesse ponto devem estar envolvidos todos os interessados com o projeto (quando possível), desde os usuários até a equipe de desenvolvimento, passando pela equipe de design. Ou, só você mesmo, caso seja o desenvolvimento solitário. Nessa etapa tudo deverá ser anotado, desenhado e descrito. Você pode precisar de uma ferramenta de criação de mapas mentais e diagramas, além de um sistema de comunicação.

Depois de definir uma ideia geral, ela será dividida em várias ideias menores, contendo "problemas", ou issues, que precisam ser resolvidas. Uma issue pode ser, por exemplo, uma funcionalidade do software ou mesmo parte dela.

Com um conjunto de issues em mãos, devemos organizá-las em milestones (marcos) e releases (lançamentos) de acordo com a prioridade, necessidade e dificuldade. Tal divisão nos ajudará a definir o que irá ser realizado primeiro.

Ferramentas

whimsical: Criação de diagramas.
Github: Hospedagem do repositório e criação de issues.

Implementação

Esta é a etapa real de resolução das issues. Nela será realizada a codificação e a revisão do código gerado. Nessa etapa geralmente são utilizados um ambiente de desenvolvimento e uma ferramenta de controle de versão (geralmente o git).

Quando a resolução da mesma requer o desenvolvimento de software, precisamos criar a funcionalidade requerida através da escrita de código, bem como de testes e documentação. Além disso, somente a utilização do git não resolverá o problema de controle de versão e trabalho em grupo, devemos adotar um padrão de fluxo de ramificações. O padrão mais utilizado atualmente é o gitflow. No entanto, podemos utilizar versões mais simplificadas, como o github workflow. Na Figura 2 é apresentado o detalhamento da etapa de implementação.

flowchart TB
  A([issue]) ==> C
  C[Código principal] ==> |banch| D(Codificação) ==>|commit| D
  D ==>|pull request| F(Revisão) ==> |correção| D
  F ==> |merge| C

Figura 2: Etapa de implementação.

Para cada issue, você deverá criar uma branch, que guardará uma cópia do código principal do software naquele momento. Cada modificação inserida será guardada através da criação de um commit. Depois de ter codificado o suficiente para dar como encerrada a issue, você deverá efetuar um pull-request. Nesse ponto, o código é enviado para uma equipe responsável pela realização de uma série de testes e análises, para confirmação da resolução da issue ou mesmo requisição de correções. Quando forem requisitadas correções, voltaremos a codificação, efetuaremos as modificações necessárias e retornaremos a revisão. Quando tudo estiver funcionando como deveria, é hora de inserir as modificações no código principal através do merge.

Nesta etapa também precisaremos utilizar uma ferramenta para monitorar a resolução das issues. Uma ótima ferramenta são quadros Kaban. Para o uso em desenvolvimento de software, geralmente tal quadro contém as seguintes etapas:

To do: issues que ainda entrarão em processo de desenvolvimento.
In progress: issues que já entraram em processo de desenvolvimento, ou seja, existe alguém codificando ou realizando tal tarefa.
Review in progress: depois que a issue foi resolvida, é enviada para uma equipe, responsável pela realização de uma série de testes e análises, para confirmação da resolução da issue.
Review approved: após a verificação da resolução da issue, os revisores podem aprovar a tarefa. Desse modo, o código poderá ser anexado ao código principal, no repositório central.
Done: uma vez que o código foi anexado ao código principal, podemos dar como resolvida aquela issue.

Ferramentas

Visual Studio Code: Ambiente de desenvolvimento.
Jupyter Lab: Ambiente de desenvolvimento para projetos de ciência de dados.
Git: Sistema de controle de versão.
Github: Criação de quadro Kanban através da área de projetos.
gitflow: Padrão geral para fluxo de ramificações.
github workflow: Variação do gitflow.

Teste

Para tornar o código estável e robusto, torna-se necessária a execução de testes. Nesta etapa os defeitos do produto são relatados, rastreados, corrigidos e retestados, até que o produto atinja os padrões de qualidade definidos. Cada linguagem tem suas ferramentas especiais aqui e você também pode utilizar ferramentas de integração contínua para automatizar parte desta tarefa.

Implantação e manutenção

Uma vez que o produto esteja testado e pronto para ser implantado, ele é lançado formalmente. Geralmente, a implantação do produto acontece em etapas de acordo com a estratégia de negócios dessa organização. O produto pode ser lançado primeiro em um segmento limitado e testado no ambiente real de negócios. Em seguida, com base no feedback, o produto pode ser lançado como está ou com melhorias sugeridas no segmento de mercado-alvo.

Após o lançamento do produto, é feita sua manutenção. Esse é o momento de olhar para trás e verificar qual etapa do trabalho precisa ser melhorada.

Assim como a etapa de teste, existem ferramentas dependendo da linguagem e nesse caso também pode-se automatizar essa tarefa.