126 lines
8.6 KiB
TeX
126 lines
8.6 KiB
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.
|