| 1 | \chapter{Metodologias}
|
| 2 |
|
| 3 | % TODO: Rewrite this thing, Jesus
|
| 4 | De forma a prosseguir e conseguir viabilizar construir um \textit{software} com
|
| 5 | qualidade, é necessário adotar algumas metodologias para fundamentar a ideia do
|
| 6 | projeto em si, como primeiro passo. Isso ajuda tanto em como priorizar
|
| 7 | funcionalidades quanto no aspecto de conseguir gerar dados para construir o
|
| 8 | mesmo de forma que entregue o que de fato é necessário para utilização do
|
| 9 | mesmo. Com esses elementos em mente, esse capítulo se debruça tanto na
|
| 10 | abordagem da metodologia de pesquisa do projeto quanto detalhar o método de
|
| 11 | desenvolvimento de \textit{software} utilizado no projeto.
|
| 12 |
|
| 13 | \section{Metodologia de Desenvolvimento de \textit{software}}
|
| 14 |
|
| 15 | Existem diversos métodos de desenvolvimento, cada um com seus respectivos prós
|
| 16 | e contras. Todos tentam, de sua forma, responder à necessidade de dar forma ao
|
| 17 | processo de desenvolvimento, de forma que ele tente fluir e assegurar que os
|
| 18 | requisitos daquele \textit{software} sejam atendidos, que os membros envolvidos
|
| 19 | no processo, tanto de desenvolvimento em si, quanto dos atores envolvidos e
|
| 20 | interessados no sistema tenham seus anseios respondidos de forma minimamente
|
| 21 | transparente e satisfatória.
|
| 22 |
|
| 23 | Além disso, a escolha de uma boa metodologia, adequada para as necessidades do
|
| 24 | sistema, permite que os prazos de entrega sejam melhor controlados e mais
|
| 25 | precisos \cite{pressman:2021}, minimizando a ocorrência de falhas e gestão do
|
| 26 | tempo.
|
| 27 |
|
| 28 | As ideias fundamentais que norteiam esse projeto são baseadas em dois conceitos
|
| 29 | chaves da engenharia de \textit{software}: desenvolvimento incremental e
|
| 30 | desenvolvimento de \textit{software} ágil. O IEEE define que a engenharia de
|
| 31 | \textit{software} é:
|
| 32 |
|
| 33 | \begin{quote}
|
| 34 | Engenharia de \textit{software}: A aplicação de uma abordagem sistemática,
|
| 35 | disciplinada e quantificável no desenvolvimento, na operação e na manutenção de
|
| 36 | \textit{software}; isto é, a aplicação de engenharia ao \textit{software}.
|
| 37 | \cite[p.~67]{ieee:1990}
|
| 38 | \end{quote}
|
| 39 |
|
| 40 | Portanto, a engenharia de \textit{software} propõe estruturar a criação de
|
| 41 | \textit{software} de forma mais organizada e eficiente. Pressman vai destacar
|
| 42 | os modelos de desenvolvimento de \textit{software} sequenciais e incrementais
|
| 43 | que moldam boa parte das práticas de engenharia de \textit{software} nas
|
| 44 | últimas décadas.
|
| 45 |
|
| 46 | O modelo em cascata (\textit{waterfall}) é um modelo sequencial, dos mais
|
| 47 | tradicionais e antigos a existirem, cujo qual necessita que cada etapa –
|
| 48 | levantamento de requisitos, projeto, implementação, testes – estejam concluídos
|
| 49 | antes da próxima etapa começar. Embora forneça uma estrutura rígida e lógica, é
|
| 50 | frequentemente criticado pela baixa adaptabilidade em relação às mudanças
|
| 51 | durante o processo de desenvolvimento.
|
| 52 |
|
| 53 | Em outro âmbito, o modelo incremental, trabalha com a premissa de que um
|
| 54 | desenvolvimento, feito em pequenas porções, agrupam-se para totalizar o projeto
|
| 55 | em si. Trabalho a concepção de incrementos funcionais, permitindo uma maior
|
| 56 | flexibilidade com as mudanças no processo ao todo. Também ajuda a iterar
|
| 57 | rápidamente em cima do desenvolvimento do sistemas, criando um produto mínimo
|
| 58 | viável, que possa preencher a proposta, usando o mínimo de tempo, reduzindo as
|
| 59 | funcionalidades ao seu estado basal. Essa metodologia também ajuda a reduzir
|
| 60 | custos e riscos, já que necessita que as funcionalidades estejam em seu estado
|
| 61 | mínimo, porém funcionais.
|
| 62 |
|
| 63 | Outros modelos tradicionais citados por Pressman incluem o modelo de
|
| 64 | prototipação e o modelo em espiral, o primeiro trabalhando na ideia de
|
| 65 | elaboração de protótipos pequenos que validem a hipótese, e depois passe para a
|
| 66 | implementação final; e o modelo em espiral une a natureza iterativa da
|
| 67 | prototipação com os aspectos sistemáticos do modelo em cascata, sendo que acaba
|
| 68 | por ser um modelo geralmente usado para desenvolvimento de aplicações em larga
|
| 69 | escala, visto que oferece mais segurança ao processo de desenvolvimento. Apesar
|
| 70 | da influência histórica, tais modelos acabam por serem um tanto quanto
|
| 71 | burocráticos e em um projeto com um escopo de equipe reduzida e onde necessita
|
| 72 | um nível de flexibilidade maior, como este, portanto, uma adoção de uma
|
| 73 | metodologia mais flexível se faz necessária.
|
| 74 |
|
| 75 | Pressman, comenta que, por meados de 2001, um grupo de desenvolvedores
|
| 76 | deflagrou o "Manifesto Ágil", um documento desenhando uma nova metodologia de
|
| 77 | desenvolvimento, destacando a satisfação dos patrocinadores do sistema,
|
| 78 | entregas mais rápidas, flexibilidade durante o desenvolvimento do
|
| 79 | \textit{software} de forma a evitar que os desenvolvedores ficaram empacados e
|
| 80 | reduzisse rigidez. Os principais destaques da abordagem ágil é a proposta de
|
| 81 | que a mesma não é escrita em pedra, ou seja, permite flexibilidade no como
|
| 82 | aplicá-la. Nesse cenário, existem algumas abordagens sobre ela, como o
|
| 83 | \textit{Kanban} e o \textit{Scrum}, que dão um pouco mais de forma a ideia
|
| 84 | apresentada com o desenvolvimento ágil o que casa relativamente bem com o
|
| 85 | modelo de desenvolvimento incremental.
|
| 86 |
|
| 87 | Com base nesse panorama, o presente trabalho adota uma abordagem baseada na
|
| 88 | filosofia ágil, estruturada por meio da utilização de um quadro de Kanban,
|
| 89 | adaptado à realidade de um desenvolvimento individual. Diferentemente de
|
| 90 | modelos tradicionais que envolvem um maior formalismo, o \textit{Kanban}
|
| 91 | permite visualizar e gerenciar o fluxo de trabalho de forma contínua, com foco
|
| 92 | na entrega incremental de funcionalidades. Por ser um método não prescritivo, o
|
| 93 | \textit{Kanban} oferece liberdade para que as tarefas possam ser priorizadas,
|
| 94 | ajustadas ou redefinidas conforme a evolução do desenvolvimento, característica
|
| 95 | especialmente útil quando há apenas um desenvolvedor responsável por todas as
|
| 96 | etapas do processo. Vale ressaltar também, que a metodologia adotada acaba por
|
| 97 | ajudar a manter o fluxo de desenvolvimento contínuo sem sobrecarga, já que
|
| 98 | limita a quantidade de tarefas em progresso, gerando um movimento de maior
|
| 99 | produtividade e entregas.
|
| 100 |
|
| 101 | A escolha pelo \textit{Kanban}, portanto, oferece um equilíbrio sustentável
|
| 102 | entre estrutura e flexibilidade, permitindo que o desenvolvimento avance de
|
| 103 | maneira organizada, e sem os entraves burocráticos dos modelos mais rígidos.
|
| 104 | Essa abordagem permite que o projeto se beneficie dos princípios ágeis, tais
|
| 105 | como a entrega contínua de valor, adaptação a mudanças e foco na simplicidade,
|
| 106 | ao mesmo tempo que mantém o controle sobre o progresso e a qualidade do produto
|
| 107 | final.
|
| 108 |
|
| 109 | \section{Metodologia de Pesquisa}
|
| 110 |
|
| 111 | Entende-se por pesquisa científica, a investigação de um fenômeno, de forma a
|
| 112 | encontrar a solução para algum problema \cite{Coelho:2020}. Portanto, a
|
| 113 | metodologia científica se torna o conjunto de procedimentos para esta
|
| 114 | investigação, cujo qual perpassa a coleta e análise de dados. Neste capítulo,
|
| 115 | abordaremos as metodologias adotadas e suas respectivas justificativas, para
|
| 116 | além dos dados encontrados para tal.
|
| 117 |
|
| 118 | \subsection{Tipo de Pesquisa}
|
| 119 |
|
| 120 | Segundo \cite{Lakatos:2022}, a a pesquisa científica pode ser classificada
|
| 121 | quanto aos seus objetivos como exploratória, descritiva ou explicativa. Este
|
| 122 | trabalho caracteriza-se principalmente como uma pesquisa aplicada de natureza
|
| 123 | exploratória, uma vez que busca investigar práticas, limitações e necessidades
|
| 124 | relacionadas a ferramentas digitais para acompanhamento emocional, com o
|
| 125 | objetivo de desenvolver uma solução tecnológica prática.
|
| 126 |
|
| 127 | Conforme Jung (2009), a pesquisa aplicada visa gerar conhecimento para
|
| 128 | aplicação direta em problemas específicos, com interesse prático e utilitário,
|
| 129 | sendo comum em projetos de desenvolvimento de \textit{software}, especialmente
|
| 130 | nas áreas de Sistemas de Informação e Ciência da Computação, nas quais o
|
| 131 | produto final visa resolver uma demanda concreta do público-alvo.
|
| 132 |
|
| 133 | \subsection{Instrumento de coleta de dados}
|
| 134 |
|
| 135 | Como instrumento de coleta de dados, optou-se pela aplicação de um questionário
|
| 136 | estruturado, elaborado com o intuito de compreender hábitos, preferências e
|
| 137 | resistências de usuários em relação ao uso de aplicativos voltados para o
|
| 138 | acompanhamento emocional e práticas de autorreflexão.
|
| 139 |
|
| 140 | A escolha do questionário se justifica pela sua abrangência, agilidade na
|
| 141 | coleta de dados e facilidade de análise quantitativa e qualitativa. Além disso,
|
| 142 | como a amostra é composta por usuários potenciais, a aplicação do questionário
|
| 143 | de forma digital (via um formulário online) permite alcançar um público mais
|
| 144 | amplo com baixo custo e maior comodidade, como também reforça Jung (2009).
|
| 145 |
|
| 146 | O questionário foi bem recebido, e obteve por volta de 52 respostas válidas.
|
| 147 | Como a divulgação foi de forma aberta, existia uma pergunta inicial com uma
|
| 148 | função chaveadora, a fim de verificar se os respondentes se encaixavam no
|
| 149 | perfil de potenciais usuários. Isso se justifica pela natureza sensível do
|
| 150 | tema, que envolve saúde mental e experiências subjetivas.
|
| 151 |
|
| 152 | Na pergunta ``Você já teve algum interesse ou experiência com o monitoramento do
|
| 153 | seu humor ou estado emocional?'', apenas 8\% afirmaram que não tem e não teriam
|
| 154 | interesse em realizar esse tipo de acompanhamento. Esse dado corrobora outro
|
| 155 | resultado relevante: 53\% dos participantes afirmaram já ter, em algum momento
|
| 156 | da vida, realizado algum tipo de monitoramento de humor.
|
| 157 |
|
| 158 | Em outros horizontes, mais da metade dos participantes expressou interesse em
|
| 159 | acompanhar como o humor varia ao longo do tempo, muitas vezes com sugestões
|
| 160 | explícitas como: “Seria legal ver um gráfico semanal ou mensal do meu humor”.
|
| 161 | Tal observação reforça a receptividade dos participantes em relação à ideia de
|
| 162 | detecção de padrões emocionais, sugerindo que esse tipo de funcionalidade
|
| 163 | representa um diferencial positivo frente aos aplicativos existentes.
|
| 164 |
|
| 165 | É notável que os participantes demonstram uma preocupação recorrente com a
|
| 166 | privacidade dos dados coletados. Aproximadamente 67\% dos participantes
|
| 167 | indicaram desconforto com a exposição de suas informações em plataformas que
|
| 168 | não explicam de forma clara como os dados são usados ou armazenados. Essa
|
| 169 | percepção está alinhada com a literatura sobre saúde digital. Por exemplo,
|
| 170 | \cite{Iwaya:22}, argumentam que a ausência de mecanismos transparentes de
|
| 171 | consentimento, controle e anonimização pode minar a confiança dos usuários em
|
| 172 | aplicativos de bem-estar e monitoramento contínuo de saúde, especialmente em
|
| 173 | contextos sensíveis como saúde mental.
|
| 174 |
|
| 175 | Outro ponto importante revelado pelo levantamento é o desejo por um tom mais
|
| 176 | humano, subjetivo e acolhedor. Cerca de 52\% dos participantes relataram
|
| 177 | incômodo com ferramentas que adotam uma linguagem genérica, motivacional ou
|
| 178 | automatizada demais. Isso reforça a necessidade de uma interface mais empática,
|
| 179 | que valorize tanto a escrita livre quanto a análise assistida. Também foram
|
| 180 | mencionadas sugestões de funcionalidades consideradas excepcionais, como
|
| 181 | inferência automática de ciclos de humor (66\% demonstraram interesse),
|
| 182 | personalização da forma de visualização das informações (como gráficos ou
|
| 183 | comparativos), e integração com dados contextuais ou ambientais, reforçando a
|
| 184 | ideia de um sistema que vá além do simples diário, oferecendo inteligência
|
| 185 | emocional útil, mas sem perder a sensibilidade que o tema exige.
|
| 186 |
|
| 187 | \subsection{Análise de Similares}
|
| 188 |
|
| 189 | A metodologia trata-se de uma avaliação sobre os sistemas relacionados ao tema
|
| 190 | proposto, observando e levantando desafios e possibilidades, validação de
|
| 191 | \textit{softwares} e a satisfação dos usuários (Martins, 2018). Seguindo assim,
|
| 192 | foram pesquisados sistemas similares encontrados na internet com o objetivo de
|
| 193 | realizar uma revisão crítica-reflexiva, analisando os aplicativos que oferecem
|
| 194 | algum tipo de diário digital de humor, ou permite algum acompanhamento
|
| 195 | reflexivo de variações de emoções.
|
| 196 |
|
| 197 | Para realizar esse processo, de forma a simular também um usuário, foi
|
| 198 | pesquisado na Google Play Store \footnote{Google Play Store — Disponível em:
|
| 199 | https://play.google.com}, por \textit{mood tracker}, retornando centenas de
|
| 200 | resultados. Nesse quesito, estabeleceu os seguintes critérios objetivos: (1)
|
| 201 | pode ser um aplicativo em português ou inglês; (2) o aplicativo tem que
|
| 202 | apresentar algum tipo de gráfico das entradas feitas (3) tem que possuir
|
| 203 | entrada textual.
|
| 204 |
|
| 205 | \subsubsection{Baseline}
|
| 206 |
|
| 207 | O Baseline é um aplicativo de código aberto voltado ao acompanhamento do
|
| 208 | bem-estar emocional por meio de uma abordagem minimalista. A ferramenta permite
|
| 209 | o registro diário de humor utilizando entradas textuais ou gravações de áudio,
|
| 210 | além de disponibilizar notificações personalizadas e revisões periódicas dos
|
| 211 | registros realizados.
|
| 212 |
|
| 213 | Entre os aspectos observados, destaca-se a natureza open-source da aplicação,
|
| 214 | característica que favorece a transparência e a possibilidade de adaptação por
|
| 215 | terceiros. Sua interface apresenta baixo nível de complexidade e reduz a
|
| 216 | quantidade de interações necessárias para o registro das informações.
|
| 217 | Entretanto, o sistema não oferece visualizações temporais avançadas nem
|
| 218 | mecanismos de personalização mais aprofundados. Além disso, o acompanhamento
|
| 219 | emocional é realizado principalmente por meio de uma pontuação de humor, sem
|
| 220 | identificar ciclos emocionais ou relacionar registros a gatilhos e intervenções
|
| 221 | específicas.
|
| 222 |
|
| 223 | \subsubsection{DailyBeans}
|
| 224 |
|
| 225 | O DailyBeans é um dos aplicativos de monitoramento de humor mais populares
|
| 226 | disponíveis atualmente, possuindo como principal característica a simplicidade
|
| 227 | de uso. O sistema utiliza ``feijões'', e possui uma linguagem bem lúdica e
|
| 228 | informal, além de categorias de sentimentos e atividades para facilitar o
|
| 229 | registro rápido do estado emocional do usuário.
|
| 230 |
|
| 231 | Entre suas funcionalidades estão o registro de humor, categorização de
|
| 232 | atividades, geração de gráficos históricos. A aplicação apresenta boa qualidade
|
| 233 | visual e fornece recursos adequados para o acompanhamento da evolução do humor
|
| 234 | ao longo do tempo. O usuário do aplicativo também consegue relacionar
|
| 235 | indicadores de sono, como momento em que foi dormir e momento que acordou.
|
| 236 |
|
| 237 | Como limitações, observa-se que o software possui código fechado e restringe
|
| 238 | parte de suas funcionalidades mais avançadas à versão paga. Além disso, o foco
|
| 239 | em registros rápidos reduz a flexibilidade para inserção de reflexões textuais
|
| 240 | mais detalhadas.
|
| 241 |
|
| 242 | \subsubsection{Moodnotes}
|
| 243 |
|
| 244 | O Moodnotes é um diário emocional baseado em princípios da Terapia
|
| 245 | Cognitivo-Comportamental (TCC), buscando auxiliar usuários na identificação e
|
| 246 | reformulação de padrões de pensamento considerados disfuncionais.
|
| 247 |
|
| 248 | O aplicativo oferece registros textuais reflexivos, sugestões de reestruturação
|
| 249 | cognitiva, gráficos históricos e geração automática de insights relacionados
|
| 250 | aos padrões emocionais identificados. Sua proposta diferencia-se por incorporar
|
| 251 | conceitos psicológicos de maneira mais explícita ao processo de registro.
|
| 252 |
|
| 253 | Apesar dos recursos disponíveis, trata-se de uma solução proprietária e
|
| 254 | predominantemente paga. Adicionalmente, apresenta limitações relacionadas à
|
| 255 | exportação dos dados registrados e à personalização das informações
|
| 256 | armazenadas.
|
| 257 |
|
| 258 | \subsubsection{Reflectly}
|
| 259 |
|
| 260 | O Reflectly é um aplicativo de diário pessoal que utiliza recursos de
|
| 261 | inteligência artificial para promover práticas de autorreflexão e
|
| 262 | acompanhamento emocional. Sua proposta enfatiza a experiência do usuário e a
|
| 263 | construção de narrativas pessoais a partir dos registros realizados.
|
| 264 |
|
| 265 | Entre suas funcionalidades estão entradas textuais livres, perguntas guiadas
|
| 266 | diárias, análises emocionais automatizadas e personalização visual da
|
| 267 | interface. O sistema apresenta uma experiência moderna e intuitiva,
|
| 268 | incentivando o uso contínuo por meio de elementos de engajamento.
|
| 269 |
|
| 270 | Como pontos observados, destaca-se o fato de ser uma solução proprietária e
|
| 271 | dependente de coleta significativa de dados para alimentar seus mecanismos de
|
| 272 | análise. Além disso, sua abordagem está mais voltada ao diário pessoal do que
|
| 273 | ao acompanhamento sistemático de indicadores de saúde mental.
|
| 274 |
|
| 275 | \subsubsection{T2 Mood Tracker}
|
| 276 |
|
| 277 | O T2 Mood Tracker foi desenvolvido com foco em contextos clínicos e
|
| 278 | acompanhamento estruturado do humor. A ferramenta permite que usuários
|
| 279 | monitorem diferentes aspectos emocionais por meio de escalas configuráveis.
|
| 280 |
|
| 281 | Entre os recursos oferecidos estão escalas deslizantes de avaliação, criação de
|
| 282 | categorias personalizadas e geração de gráficos históricos para análise
|
| 283 | temporal dos registros. Sua proposta é particularmente útil para profissionais
|
| 284 | e pacientes que necessitam acompanhar indicadores específicos ao longo do
|
| 285 | tempo.
|
| 286 |
|
| 287 | Entretanto, a aplicação apresenta limitações relacionadas à experiência do
|
| 288 | usuário, possuindo interface considerada desatualizada quando comparada a
|
| 289 | soluções contemporâneas. Também não oferece suporte para registros textuais
|
| 290 | extensos ou entradas por voz, reduzindo a riqueza contextual das informações
|
| 291 | coletadas.
|
| 292 |
|
| 293 | \subsection{Análise comparativa}
|
| 294 |
|
| 295 | \begin{table}[h]
|
| 296 | \centering
|
| 297 | \caption{Comparativo de funcionalidades entre aplicativos analisados}
|
| 298 | \label{tab:comparativo_apps}
|
| 299 | \begin{tabular}{lccccc}
|
| 300 | \hline
|
| 301 | Funcionalidade &
|
| 302 | Baseline &
|
| 303 | Daylio &
|
| 304 | Moodnotes &
|
| 305 | Reflectly &
|
| 306 | T2 \\
|
| 307 |
|
| 308 | \hline
|
| 309 | Registro de humor & Sim & Sim & Sim & Sim & Sim \\
|
| 310 | Registro de sono & Não & Não & Não & Não & Não \\
|
| 311 | Texto livre & Sim & Parcial & Sim & Sim & Não \\
|
| 312 | Gráficos & Não & Sim & Sim & Sim & Sim \\
|
| 313 | Gatilhos/intervenções & Não & Parcial & Não & Não & Parcial \\
|
| 314 | Exportação de dados & Sim & Parcial & Parcial & Parcial & Sim \\
|
| 315 | Código aberto & Sim & Não & Não & Não & Não \\
|
| 316 | \hline
|
| 317 | \end{tabular}
|
| 318 | \source{Elaborado pelo autor (2026)}
|
| 319 | \end{table}
|
| 320 |
|
| 321 | Com esses dados em mente, podemos compreender alguns elementos fundamentais:
|
| 322 | poucos sistemas analisados são \textit{open-source}, o que indica que, em sua
|
| 323 | grande maioria, são sistemas comerciais. A maior parte dos sistemas também
|
| 324 | oferecem algum aspecto de pagamento, bloqueando funcionalidades importantes
|
| 325 | atrás de algum tipo de modelo de subscrição. Existe também o fato de
|
| 326 | personalização e de exportação de dados, que poucos ou nenhum sistema oferece,
|
| 327 | o que faz com que o sistema não tenha portabilidade dos dados inseridos,
|
| 328 | criando assim, um \textit{walled garden}, ou um jardim fechado – uma técnica de
|
| 329 | fazer com que o usuário não consiga migrar entre sistemas, prendendo-o a usar
|
| 330 | aquela aplicação já que seus dados estão lá.
|
| 331 |
|
| 332 | \subsection{Relação entre os dados coletados e o desenvolvimento}
|
| 333 |
|
| 334 | A análise dos sistemas similares, quando considerada em conjunto com os dados
|
| 335 | coletados por meio do questionário, revela lacunas e oportunidades relevantes
|
| 336 | para o desenvolvimento de uma nova solução. Observa-se, por exemplo, que a
|
| 337 | maior parte das ferramentas disponíveis no mercado segue modelos comerciais,
|
| 338 | frequentemente com funcionalidades essenciais bloqueadas por sistemas de
|
| 339 | pagamento ou assinaturas. Além disso, é comum que tais sistemas sejam fechados,
|
| 340 | sem disponibilização de código-fonte ou possibilidade de exportação dos dados
|
| 341 | inseridos, o que configura uma prática de \textit{walled garden}, dificultando
|
| 342 | a migração entre plataformas e restringindo a autonomia dos usuários sobre suas
|
| 343 | próprias informações.
|
| 344 |
|
| 345 | Esses aspectos, quando contrastados com o interesse expressivo dos respondentes
|
| 346 | por visualizar padrões emocionais ao longo do tempo e por maior personalização,
|
| 347 | sugerem direções claras para o desenvolvimento de um sistema que não apenas
|
| 348 | atenda a essas demandas, mas também adote princípios de transparência, abertura
|
| 349 | e controle por parte do usuário. A seguir, serão discutidas as decisões de
|
| 350 | projeto que nortearam a construção da ferramenta proposta, baseadas tanto nas
|
| 351 | limitações identificadas nos sistemas existentes quanto nas necessidades e
|
| 352 | expectativas manifestadas pelo público-alvo da pesquisa.
|