6. Processo de Software e Etapas do Desenvolvimento

Escolha do Processo de Software

O processo de software utilizado foi o modelo iterativo, que consiste em realizar iterações de ciclos de desenvolvimento até que o software atinja a fase de manutenção. O desenvolvimento desta primeira etapa ocorreu, basicamente, em 4 iterações. Vale mencionar que essas iterações não foram definidas por intervalo de data, mas sim por determinação de qual produto teríamos que entregar. Por exemplo, a 1ª entrega do integrador; depois, o front_end; depois a integração, etc. Para o desenvolvimento, foram criados dois projetos no GitHub, uma para o front_end e outro para o back_end. Nele, as tarefas eram separadas em 5 categorias: Backlog, que serviam para tirarmos as ideias da cabeça e detalhar as tarefas (o que, infelizmente, acabou não acontecendo muito); Ready, quando elas estavam prontas para serem assumidas por um integrante; Doing, Review e Done.

1ª Iteração

A 1ª foi aquela durante a qual focamos em definir o problema, estudá-lo e definir o escopo do projeto. Foi nesta etapa também que criamos as histórias de usuários, detalhamos alguns requisitos funcionais, criamos o diagrama de casos de uso, modelo lógico, definição da arquitetura do sistema, estilo arquitetônico e definição de endpoints da API. Não houve muitas dificuldades aqui, visto que o próprio grupo eram os clientes e tínhamos a ideia do sistema muito bem definida, além de ser um sistema simples.

2ª Iteração

A 2a iteração consistiu no desenvolvimento da aplicação back-end utilizando toda a documentação disponível. Durante o desenvolvimento, foi utilizada a metodologia ágil Kanban, que atende bem às nossas necessidades, visto que o nosso time de desenvolvimento é composto de somente duas pessoas que moram na mesma residência. Ele também nos permite visualizar o andamento das tarefas de maneira clara. Ainda, o Kanban nos dá a possibilidade de trabalhar com prazos mais flexíveis e que podemos ajustar à nossa rotina de modo que adapte o fluxo de trabalho ao tempo disponível, sem a complexidade de definir intervalos de implementação bem estabelecidos de outras metodologias como o Scrum. Ainda nesta etapa, houveram algumas mudanças nos requisitos e modelagem de dados, nos fazendo voltar às fases de planejamento para defini-los melhor. A maior dificuldade nesta iteração foi a utilização e integração da biblioteca django-simple-history, visto que a manipulação dos querysets não era muito bem conhecida. Além disso, a criação de filtros baseados nesse histórico se tornou uma tarefa bastante complexa.

3ª Iteração

A 3ª iteração foi focada completamente no desenvolvimento da parte visual do site, isto é, o front-end. Devido à greve que ocorreu no instituto, durante um período de quase 3 meses, o time de desenvolvimento ficou parado. Nas últimas semanas antes da volta às aulas, voltamos a trabalhar no projeto. Antes de começarmos o desenvolvimento, foi idealizado um Figma com o design do website, o que facilitou e acelerou bastante a implementação. Antes da implementação de fato, foi feito uma análise do Figma e a divisão dos componentes React que iriam compor a interface e as páginas. A partir disso, foram criadas tasks no quadro Kanban do projeto GitHub do front_end. Depois do desenvolvimento do código de cada componente reutilizável e separado, foi o momento de criação das páginas estáticas e sem interação com a API desenvolvida na segunda iteração. Por conta do planejamento bem feito desta iteração, o desenvolvimento foi muito rápido e sem dificuldades.

4ª Iteração

Na 4ª iteração, era a hora de integrar com o back_end. Nesse ponto, começaram a surgir alguns problemas relativos a isso, como dificuldade em fazer login social, erros não tratados na API, listagens sem paginação e features completamente não funcionais, como o filtro por período de tempo dos dados do dashboard. Esta etapa foi a mais trabalhosa, pois demandou muito dos dois integrantes tanto na modificação e integração com a API quanto na alteração do front_end para buscar e interagir com dados reais. À medida que íamos percebendo as faltas e erros de como os queríamos os dados no front_end, íamos alterando o back_end on the fly. Após a finalização da integração, percebemos que ainda haviam algumas pendências na aplicação Django: as ferramentas para que o administrador do sistema pudesse visualizar o histórico de alterações feitas nos modelos, sendo capaz de filtrar por data e outros campos; e o back_up automático do banco de dados. Além disso, ao mesmo tempo que íamos criando essas funcionalidades, as documentações do sistema estavam sendo feitas. Por conta disso, a 4ª iteração acabou sendo a mais pesada e também a mais diversa, visto que acabou pegando, em boa quantidade, tarefas relacionadas a código e a documentação. É importante mencionar que a grande maioria das tarefas de documentação não foram registradas no quadro Kanban.

Considerações Finais

A utilização do Kanban facilitou bastante a divisão de tarefas. Além disso, foi possível ver o progresso sendo feito, dando uma noção de quanto faltava para acabar a implementação. Isso permitia a gente a gerenciar melhor o tempo, especialmente com as tarefas da faculdade, vendo em quais momentos teríamos que concluir mais tarefas do integrador para que fosse possível conciliá-lo a outras atividades sem ser muito prejudicado.