\chapter{Metodologias}

% TODO: Rewrite this thing, Jesus

De forma a prosseguir e conseguir viabilizar construir um \textit{software} com

qualidade, é necessário adotar algumas metodologias para fundamentar a ideia do

projeto em si, como primeiro passo. Isso ajuda tanto em como priorizar

funcionalidades quanto no aspecto de conseguir gerar dados para construir o

mesmo de forma que entregue o que de fato é necessário para utilização do

mesmo. Com esses elementos em mente, esse capítulo se debruça tanto na

abordagem da metodologia de pesquisa do projeto quanto detalhar o método de

desenvolvimento de \textit{software} utilizado no projeto.

\section{Metodologia de Desenvolvimento de \textit{software}}

Existem diversos métodos de desenvolvimento, cada um com seus respectivos prós

e contras. Todos tentam, de sua forma, responder à necessidade de dar forma ao

processo de desenvolvimento, de forma que ele tente fluir e assegurar que os

requisitos daquele \textit{software} sejam atendidos, que os membros envolvidos

no processo, tanto de desenvolvimento em si, quanto dos atores envolvidos e

interessados no sistema tenham seus anseios respondidos de forma minimamente

transparente e satisfatória.

Além disso, a escolha de uma boa metodologia, adequada para as necessidades do

sistema, permite que os prazos de entrega sejam melhor controlados e mais

precisos \cite{pressman:2021}, minimizando a ocorrência de falhas e gestão do

tempo.

As ideias fundamentais que norteiam esse projeto são baseadas em dois conceitos

chaves da engenharia de \textit{software}: desenvolvimento incremental e

desenvolvimento de \textit{software} ágil. O IEEE define que a engenharia de

\textit{software} é:

\begin{quote}

  Engenharia de \textit{software}: A aplicação de uma abordagem sistemática,

  disciplinada e quantificável no desenvolvimento, na operação e na manutenção de

  \textit{software}; isto é, a aplicação de engenharia ao \textit{software}.

  \cite[p.~67]{ieee:1990}

\end{quote}

Portanto, a engenharia de \textit{software} propõe estruturar a criação de

\textit{software} de forma mais organizada e eficiente. Pressman vai destacar

os modelos de desenvolvimento de \textit{software} sequenciais e incrementais

que moldam boa parte das práticas de engenharia de \textit{software} nas

últimas décadas.

O modelo em cascata (\textit{waterfall}) é um modelo sequencial, dos mais

tradicionais e antigos a existirem, cujo qual necessita que cada etapa –

levantamento de requisitos, projeto, implementação, testes – estejam concluídos

antes da próxima etapa começar. Embora forneça uma estrutura rígida e lógica, é

frequentemente criticado pela baixa adaptabilidade em relação às mudanças

durante o processo de desenvolvimento.

Em outro âmbito, o modelo incremental, trabalha com a premissa de que um

desenvolvimento, feito em pequenas porções, agrupam-se para totalizar o projeto

em si. Trabalho a concepção de incrementos funcionais, permitindo uma maior

flexibilidade com as mudanças no processo ao todo. Também ajuda a iterar

rápidamente em cima do desenvolvimento do sistemas, criando um produto mínimo

viável, que possa preencher a proposta, usando o mínimo de tempo, reduzindo as

funcionalidades ao seu estado basal. Essa metodologia também ajuda a reduzir

custos e riscos, já que necessita que as funcionalidades estejam em seu estado

mínimo, porém funcionais.

Outros modelos tradicionais citados por Pressman incluem o modelo de

prototipação e o modelo em espiral, o primeiro trabalhando na ideia de

elaboração de protótipos pequenos que validem a hipótese, e depois passe para a

implementação final; e o modelo em espiral une a natureza iterativa da

prototipação com os aspectos sistemáticos do modelo em cascata, sendo que acaba

por ser um modelo geralmente usado para desenvolvimento de aplicações em larga

escala, visto que oferece mais segurança ao processo de desenvolvimento. Apesar

da influência histórica, tais modelos acabam por serem um tanto quanto

burocráticos e em um projeto com um escopo de equipe reduzida e onde necessita

um nível de flexibilidade maior, como este, portanto, uma adoção de uma

metodologia mais flexível se faz necessária.

Pressman, comenta que, por meados de 2001, um grupo de desenvolvedores

deflagrou o "Manifesto Ágil", um documento desenhando uma nova metodologia de

desenvolvimento, destacando a satisfação dos patrocinadores do sistema,

entregas mais rápidas, flexibilidade durante o desenvolvimento do

\textit{software} de forma a evitar que os desenvolvedores ficaram empacados e

reduzisse rigidez. Os principais destaques da abordagem ágil é a proposta de

que a mesma não é escrita em pedra, ou seja, permite flexibilidade no como

aplicá-la. Nesse cenário, existem algumas abordagens sobre ela, como o

\textit{Kanban} e o \textit{Scrum}, que dão um pouco mais de forma a ideia

apresentada com o desenvolvimento ágil o que casa relativamente bem com o

modelo de desenvolvimento incremental.

Com base nesse panorama, o presente trabalho adota uma abordagem baseada na

filosofia ágil, estruturada por meio da utilização de um quadro de Kanban,

adaptado à realidade de um desenvolvimento individual. Diferentemente de

modelos tradicionais que envolvem um maior formalismo, o \textit{Kanban}

permite visualizar e gerenciar o fluxo de trabalho de forma contínua, com foco

na entrega incremental de funcionalidades. Por ser um método não prescritivo, o

\textit{Kanban} oferece liberdade para que as tarefas possam ser priorizadas,

ajustadas ou redefinidas conforme a evolução do desenvolvimento, característica

especialmente útil quando há apenas um desenvolvedor responsável por todas as

etapas do processo. Vale ressaltar também, que a metodologia adotada acaba por

ajudar a manter o fluxo de desenvolvimento contínuo sem sobrecarga, já que

limita a quantidade de tarefas em progresso, gerando um movimento de maior

produtividade e entregas.

A escolha pelo \textit{Kanban}, portanto, oferece um equilíbrio sustentável

entre estrutura e flexibilidade, permitindo que o desenvolvimento avance de

maneira organizada, e sem os entraves burocráticos dos modelos mais rígidos.

Essa abordagem permite que o projeto se beneficie dos princípios ágeis, tais

como a entrega contínua de valor, adaptação a mudanças e foco na simplicidade,

ao mesmo tempo que mantém o controle sobre o progresso e a qualidade do produto

final.

\section{Metodologia de Pesquisa}

Entende-se por pesquisa científica, a investigação de um fenômeno, de forma a

encontrar a solução para algum problema \cite{Coelho:2020}. Portanto, a

metodologia científica se torna o conjunto de procedimentos para esta

investigação, cujo qual perpassa a coleta e análise de dados. Neste capítulo,

abordaremos as metodologias adotadas e suas respectivas justificativas, para

além dos dados encontrados para tal.

\subsection{Tipo de Pesquisa}

Segundo \cite{Lakatos:2022}, a a pesquisa científica pode ser classificada

quanto aos seus objetivos como exploratória, descritiva ou explicativa. Este

trabalho caracteriza-se principalmente como uma pesquisa aplicada de natureza

exploratória, uma vez que busca investigar práticas, limitações e necessidades

relacionadas a ferramentas digitais para acompanhamento emocional, com o

objetivo de desenvolver uma solução tecnológica prática.

Conforme Jung (2009), a pesquisa aplicada visa gerar conhecimento para

aplicação direta em problemas específicos, com interesse prático e utilitário,

sendo comum em projetos de desenvolvimento de \textit{software}, especialmente

nas áreas de Sistemas de Informação e Ciência da Computação, nas quais o

produto final visa resolver uma demanda concreta do público-alvo.

\subsection{Instrumento de coleta de dados}

Como instrumento de coleta de dados, optou-se pela aplicação de um questionário

estruturado, elaborado com o intuito de compreender hábitos, preferências e

resistências de usuários em relação ao uso de aplicativos voltados para o

acompanhamento emocional e práticas de autorreflexão.

A escolha do questionário se justifica pela sua abrangência, agilidade na

coleta de dados e facilidade de análise quantitativa e qualitativa. Além disso,

como a amostra é composta por usuários potenciais, a aplicação do questionário

de forma digital (via um formulário online) permite alcançar um público mais

amplo com baixo custo e maior comodidade, como também reforça Jung (2009).

O questionário foi bem recebido, e obteve por volta de 52 respostas válidas.

Como a divulgação foi de forma aberta, existia uma pergunta inicial com uma

função chaveadora, a fim de verificar se os respondentes se encaixavam no

perfil de potenciais usuários. Isso se justifica pela natureza sensível do

tema, que envolve saúde mental e experiências subjetivas.

Na pergunta "Você já teve algum interesse ou experiência com o monitoramento do

seu humor ou estado emocional?", apenas 8\% afirmaram que não tem e não teriam

interesse em realizar esse tipo de acompanhamento. Esse dado corrobora outro

resultado relevante: 53\% dos participantes afirmaram já ter, em algum momento

da vida, realizado algum tipo de monitoramento de humor.

Em outros horizontes, mais da metade dos participantes expressou interesse em

acompanhar como o humor varia ao longo do tempo, muitas vezes com sugestões

explícitas como: “Seria legal ver um gráfico semanal ou mensal do meu humor”.

Tal observação reforça a receptividade dos participantes em relação à ideia de

detecção de padrões emocionais, sugerindo que esse tipo de funcionalidade

representa um diferencial positivo frente aos aplicativos existentes.

É notável que os participantes demonstram uma preocupação recorrente com a

privacidade dos dados coletados. Aproximadamente 67\% dos participantes

indicaram desconforto com a exposição de suas informações em plataformas que

não explicam de forma clara como os dados são usados ou armazenados. Essa

percepção está alinhada com a literatura sobre saúde digital. Por exemplo,

\cite{Iwaya:22}, argumentam que a ausência de mecanismos transparentes de

consentimento, controle e anonimização pode minar a confiança dos usuários em

aplicativos de bem-estar e monitoramento contínuo de saúde, especialmente em

contextos sensíveis como saúde mental.

Outro ponto importante revelado pelo levantamento é o desejo por um tom mais

humano, subjetivo e acolhedor. Cerca de 52\% dos participantes relataram

incômodo com ferramentas que adotam uma linguagem genérica, motivacional ou

automatizada demais. Isso reforça a necessidade de uma interface mais empática,

que valorize tanto a escrita livre quanto a análise assistida. Também foram

mencionadas sugestões de funcionalidades consideradas excepcionais, como

inferência automática de ciclos de humor (66\% demonstraram interesse),

personalização da forma de visualização das informações (como gráficos ou

comparativos), e integração com dados contextuais ou ambientais, reforçando a

ideia de um sistema que vá além do simples diário, oferecendo inteligência

emocional útil, mas sem perder a sensibilidade que o tema exige.

\subsection{Análise de Similares}

A metodologia trata-se de uma avaliação sobre os sistemas relacionados ao tema

proposto, observando e levantando desafios e possibilidades, validação de

\textit{softwares} e a satisfação dos usuários (Martins, 2018). Seguindo assim,

foram pesquisados sistemas similares encontrados na internet com o objetivo de

realizar uma revisão crítica-reflexiva, analisando os aplicativos que oferecem

algum tipo de diário digital de humor, ou permite algum acompanhamento

reflexivo de variações de emoções.

Para realizar esse processo, de forma a simular também um usuário, foi

pesquisado na Google Play Store \footnote{Google Play Store — Disponível em:

https://play.google.com}, por \textit{mood tracker}, retornando centenas de

resultados. Nesse quesito, estabeleceu os seguintes critérios objetivos: (1)

pode ser um aplicativo em português ou inglês; (2) o aplicativo tem que

apresentar algum tipo de gráfico das entradas feitas (3) tem que possuir

entrada textual.

% TODO: Quadro 1

Com esses dados em mente, podemos compreender alguns elementos fundamentais:

poucos sistemas analisados são open-source, o que indica que, em sua grande

maioria, são sistemas comerciais. A maior parte dos sistemas também oferecem

algum aspecto de pagamento, bloqueando funcionalidades importantes atrás de

algum tipo de modelo de subscrição. Existe também o fato de personalização e de

exportação de dados, que poucos ou nenhum sistema oferece, o que faz com que o

sistema não tenha portabilidade dos dados inseridos, criando assim, um walled

garden, ou um jardim fechado – uma técnica de fazer com que o usuário não

consiga migrar entre sistemas, prendendo-o a usar aquela aplicação já que seus

dados estão lá.

\subsection{Relação entre os dados coletados e o desenvolvimento}

A análise dos sistemas similares, quando considerada em conjunto com os dados

coletados por meio do questionário, revela lacunas e oportunidades relevantes

para o desenvolvimento de uma nova solução. Observa-se, por exemplo, que a

maior parte das ferramentas disponíveis no mercado segue modelos comerciais,

frequentemente com funcionalidades essenciais bloqueadas por sistemas de

pagamento ou assinaturas. Além disso, é comum que tais sistemas sejam fechados,

sem disponibilização de código-fonte ou possibilidade de exportação dos dados

inseridos, o que configura uma prática de \textit{walled garden}, dificultando

a migração entre plataformas e restringindo a autonomia dos usuários sobre suas

próprias informações.

Esses aspectos, quando contrastados com o interesse expressivo dos respondentes

por visualizar padrões emocionais ao longo do tempo e por maior personalização,

sugerem direções claras para o desenvolvimento de um sistema que não apenas

atenda a essas demandas, mas também adote princípios de transparência, abertura

e controle por parte do usuário. A seguir, serão discutidas as decisões de

projeto que nortearam a construção da ferramenta proposta, baseadas tanto nas

limitações identificadas nos sistemas existentes quanto nas necessidades e

expectativas manifestadas pelo público-alvo da pesquisa.