Merge pull request #5 from leomurca/release/v0.1

Escrita da seção de Metodologia
This commit is contained in:
cseveriano 2024-03-19 19:02:53 -03:00 committed by GitHub
commit 921d694ce4
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
10 changed files with 163 additions and 1 deletions

4
.gitignore vendored
View file

@ -298,4 +298,6 @@ TSWLatexianTemp*
# REVTeX puts footnotes in the bibliography by default, unless the nofootinbib
# option is specified. Footnotes are the stored in a file with suffix Notes.bib.
# Uncomment the next line to have this generated file ignored.
#*Notes.bib
#*Notes.bib
*.pdf

Binary file not shown.

After

Width:  |  Height:  |  Size: 63 KiB

BIN
images/gitflow.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 98 KiB

BIN
images/login.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 32 KiB

BIN
images/pagina-inicial.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 74 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 63 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 84 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 70 KiB

View file

@ -2,7 +2,10 @@
\usepackage{template/sbc}
\usepackage{graphicx,url}
\usepackage{float}
\usepackage[brazil]{babel}
\graphicspath{ {./images/} }
\sloppy
@ -29,4 +32,6 @@
10 lines and must be in the first page of the paper..
\end{abstract}
\input{sections/metodologia.tex}
\end{document}

155
sections/metodologia.tex Normal file
View file

@ -0,0 +1,155 @@
\section{Metodologia}
O desenvolvimento deste trabalho ocorreu por meio da utilização dos recursos metodológicos descritos
desde a subseção 3.2 até a 3.7, 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 desenvolvimento que permite aos desenvolvedores criar, armazenar, gerenciar e compartilhar seu código.
\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{Definição da proposta de trabalho}
Inicialmente, foi discutido diversas propostas para este trabalho de conclusão de curso, sendo elas:
\begin{itemize}
\item{Gerenciador de quantidade de pessoas em ambientes internos utilizando dispositivos Bluetooth;}
\item{Plataforma de Ensino para os Institutos Federais;}
\end{itemize}
Devido à complexidade e custo de desenvolvimento da primeira proposta citada acima, foi escolhida segunda proposta. A prerrogativa
da plataforma ser de código aberto teve uma forte contribuição para sua escolha.
\subsection{Prototipação 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.
\begin{figure}[ht]
\centering
\includegraphics[width=.7\textwidth]{login}
\caption{Login}
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=.7\textwidth]{pagina-inicial}
\caption{Página inicial}
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=.7\textwidth]{turma-detalhes-comunicados}
\caption{Sala de aula Comunicados}
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=.7\textwidth]{turma-detalhes-atividades}
\caption{Sala de aula Atividades}
\end{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=.7\textwidth]{turma-detalhes-pessoas}
\caption{Sala de aula Pessoas}
\end{figure}
\vfill
\cleardoublepage{}
\begin{figure}[ht]
\centering
\includegraphics[width=.7\textwidth]{atividade-detalhes.png}
\caption{Detalhes de atividade}
\end{figure}
A estrutura lógica das telas prototipadas foram baseadas 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\@.
\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 \textit{Andrew Hunt} e \textit{David Thommas} em seu livro \textit{O Programador Pragmático} chamada de \textit{Projéteis Luminosos}.
Essa abordagem é uma analogia à 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.
Os projéteis luminosos no contexto do desenvolvimento do IF Salas foi necessário 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 pareciam ainda um pouco obscuros e, não tinhamos uma ideia clara
de como o sistema funcionaria na prática. Mesmo que \textit{Google Classroom} tenha sido utilizado anteriormente em alguns contextos,
a ferramenta 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}
Em relação à manutenção e versionamento de código, foi adotada a metodologia 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. Observe o diagrama abaixo:
\begin{figure}[ht]
\centering
\includegraphics[width=.7\textwidth]{gitflow.jpg}
\caption{Git Flow Adaptado}
\end{figure}
\subsection{Implantação 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{htps://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.