eletrotupi / tcc/ monografia/chapters/methodologies.texea4bc966634518411555ecdf8d0a620443e8d7a8
19.6 KB | 352 lines Raw
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.