undegraduate-thesis/sections/metodologia.tex

\section{Metodologia}

O desenvolvimento deste trabalho ocorreu por meio da utilização dos recursos metodológicos descritos
desde a subseção \ref{subsec:prototipacao-do-layout} até a \ref{subsec:coleta-de-feedbacks}, presentes a seguir.

\subsection{Ferramentas utilizadas}

\begin{itemize}
	\item \textbf{Git}:
	      Sistema de controle de versão distribuído gratuito e de código aberto.

	\item \textbf{Github}:
		  Plataforma de primariamente de hospedagem de código-fonte e arquivos com controle de versão usando o Git.

	\item \textbf{Github Actions}:
	      Serviço integrado de integração contínua e implantação contínua (CI/CD) fornecido pelo GitHub. Ele permite que
	      os desenvolvedores automatizem fluxos de trabalho, incluindo construção, teste e implantação de aplicativos
	      diretamente em seus repositórios GitHub.

	\item \textbf{React}:
	      Biblioteca JavaScript \textit{front-end} gratuita e de código aberto para construir interfaces de usuário baseadas em componentes.

	\item \textbf{Figma}:
	      Applicação web colaborativa para design de interface.

	\item \textbf{Taiga}:
	      Sistema de gerenciamento de projetos gratuito e de código aberto para startups, desenvolvedores ágeis e designers.

	\item \textbf{Jitsi}:
	      Uma coleção de aplicativos multiplataforma de voz, videoconferência e mensagens instantâneas gratuitos e de código aberto para a
	      plataforma Web, Windows, Linux, macOS, iOS e Android.

	\item \textbf{Material Design}:
	      \textit{Design System} desenvolvido pelo Google para criar interfaces visuais consistentes, modernas e intuitivas em
	      aplicativos e websites. Caracterizado por elementos tridimensionais, sombras e animações suaves, o Material Design visa
	      proporcionar uma experiência de usuário coesa em diferentes dispositivos e plataformas.

	\item \textbf{Visual Studio Code (VS Code)}:
	      Um editor de código otimizado para criar e depurar aplicativos modernos da Web e da nuvem.

\end{itemize}

\subsection{Prototipação do layout}
\label{subsec:prototipacao-do-layout}

Nesta etapa foram feitos protótipos das telas principais do sistema: Página Inicial, Informações, Calendário Acadêmico, Login e Sala
de Aula.

A estrutura lógica das telas prototipadas foi baseada no sistema \textit{Google Classroom} visando
a facilidade de uso por parte dos usuários, uma vez que a ferramenta é bem difundida no ambiente acadêmico do IFMG\@. As figuras do 
protótipo inicial está disponível em \ref{subsec:prototipos-iniciais}.


\subsection{Codificação do protótipo}

Após a prototipação das telas principais, iniciou-se o desenvolvimento da aplicação utilizando uma abordagem proposta
por Andrew Hunt e David Thommas em seu livro O Programador Pragmático \cite{pragmatic-programmer} chamada de \textit{Projéteis Luminosos}. 
Essa abordagem é uma analogia a atiradores de armas de fogo que utilizam projéteis luminosos. Esses projéteis são carregados a intervalos
no pente de munição com as balas comuns. Quando disparados, seu fósforo se acende e deixa uma trilha pirotécnica da arma até o que quer 
que atinjam. Se os projéteis estiverem atingindo o alvo, as balas comuns também estarão. O feedback é imediato e, já que eles operam no 
mesmo ambiente da munição real, os efeitos externos são reduzidos.

No contexto do IF Salas, as "balas reais"\ representam as funcionalidades finais e completas da aplicação, ou seja, as 
características e fluxos que devem ser totalmente implementados e funcionar conforme esperado para o usuário final. 
Já os "projéteis luminosos"\  simbolizam as versões intermediárias ou protótipos dessas funcionalidades, que foram desenvolvidos para testar 
e validar se as ideias ou fluxos funcionam na prática antes de serem totalmente desenvolvidos e integrados na aplicação.

Os projéteis luminosos também foram necessários para validar como certos fluxos, antes prototipados no Figma, funcionariam na prática. 
Essa abordagem foi escolhida pelo fato do IF Salas ser algo que nunca foi construído e utilizado anteriormente no contexto do IFMG Sabará. 
Ou seja, alguns requisitos ainda pareciam incógnitos e não tínhamos uma ideia nítida de como o sistema funcionaria na prática. Mesmo que 
\textit{Google Classroom} tenha sido utilizado anteriormente em alguns contextos, a ferramenta da Google ainda era de propósito geral, e certos fluxos 
comuns não foram cobertos pela ferramenta, como por exemplo todo o fluxo de criação, atribuição e correção de atividades interdisciplinares.

A arquitetura e organização dos arquivos do código do projeto foi estruturada seguindo as práticas mais difundidas no mercado de 
desenvolvimento web utilizando o ecossistema React. Dentre essas práticas estão:

\begin{itemize}
	\item Modularização das pastas do projeto por agrupamento lógico. Exemplo: arquivos utilitários ficam em uma pasta chamada utils;
	\item Convenções de nomes de arquivos. Exemplo: arquivos de estilos nomeados como styles.js;
	\item Context API para gerenciamento de estado global;
\end{itemize}

\subsection{Versionamento de código}

Em relação à manutenção e versionamento de código, foi adotada a metodologia Git Flow \cite{git-flow} com adaptação ao contexto do IF Salas. 
O Git Flow é uma metodologia de desenvolvimento de software baseada em Git que define um conjunto de regras e práticas para 
gerenciar o fluxo de trabalho de uma equipe de desenvolvimento. Essa abordagem é baseada em dois ramos principais: master e develop. 
O ramo master contém o código em produção, enquanto o ramo develop é usado para integração contínua e desenvolvimento de novas funcionalidades. 
Além desses ramos principais, o Git Flow introduz outros tipos de ramos, como ramos de feature, release e hotfix, cada um com sua 
função específica dentro do ciclo de vida do desenvolvimento.

Os ramos de feature são criados a partir do ramo develop e são usados para desenvolver novas funcionalidades ou melhorias no código. 
Uma vez concluído o trabalho na feature, ela é mesclada de volta ao ramo develop. Os ramos de release são criados a partir do develop 
para preparar uma nova versão do software para implantação em produção. Após testes e ajustes finais, o código da release é mesclado 
ao master e ao develop. Por fim, os ramos de hotfix são criados a partir do master para corrigir problemas críticos em produção, sendo então 
mesclados tanto ao master quanto ao develop. 

Entretanto, houve uma adaptação da metodologia Git Flow para o contexto IF Salas, sendo ela a não utilização dos ramos hotfix e release,
uma vez que não houve a implantação do software em ambiente de produção.

\begin{figure}[ht]
	\centering
	\includegraphics[width=1\textwidth]{gitflow.jpg}
	\caption{Git Flow Adaptado}
\end{figure}


\subsection{Implantação do software}
\label{subsec:implantacao-do-software}

Além da estrutura git descrita anteriormente, foi criada uma automação que é ativada quando qualquer código for integrado ao ramo principal (master). 
Essa automação é um pipeline que é executado utilizando a ferramenta Github Actions, na qual a aplicação do IF Salas é disponibilizada de forma 
online no domínio \url{https://ifsalas.xyz}. O mesmo pipeline é disparado quando qualquer código é integrado ao ramo de desenvolvimento (development).
Entretanto, a aplicação será disponibilizada de forma online no domínio \url{https://dev.ifsalas.xyz} para fins de testes.

\subsection{Coleta de feedbacks}
\label{subsec:coleta-de-feedbacks}

A coleta de feedbacks foi feita de maneira informal, seguindo uma abordagem holística e participativa, envolvendo tanto discentes quanto docentes 
para garantir uma visão abrangente da usabilidade do software. Inicialmente, foi estabelecido um ambiente acolhedor e receptivo, incentivando os usuários 
a compartilharem suas experiências de forma franca e aberta. Foram organizadas também sessões de demonstração, onde os participantes puderam experimentar o software 
em situações simuladas de uso, como visualizar atividades avaliativas, por exemplo. Durante essas interações, foi observado atentamente as reações dos 
usuários, seus padrões de navegação e eventuais dificuldades encontradas ao utilizar o IF Salas. A coleta de feedbacks também se estendeu para além 
dos ambientes controlados, aproveitando oportunidades informais de conversas durante o dia a dia acadêmico. Essa abordagem multifacetada permitiu uma 
compreensão detalhada das necessidades e expectativas dos usuários em relação à usabilidade do IF Salas, fornecendo percepções valiosas para refinamentos 
futuros e melhorias contínuas.