Omega (Ω) - Visão do Produto e Projeto¶

Versão 1.1¶

Equipe¶

Matrícula	Nome	Função
231011892	Arthur Sismene Carvalho	Desenvolvedor Frontend
221022480	Carlos Henrique de Paiva Munis	Desenvolvedor Frontend
231030691	Guilherme Ferreira Brandao	Desenvolvedor Backend
232002996	Heyttor Augusto de Assis Silva	Desenvolvedor Backend
202045348	Ingrid Alves Rocha	Dono do Produto
232003661	João Pedro Araujo de Freitas Lyra	Líder e Dono do Produto
222022135	Letícia de Carvalho dos Santos	Analista de Qualidade
211045178	Luis Guilherme Borges Monteiro	Analista de Qualidade
221007608	Nayra Silva Nery	Analista de Testes
211031440	Pedro Gomes Oliveira	Analista de Testes
232024026	Rivadalvio Joaquim da Silva Filho	Cliente
232014271	Yasmin Sousa Abdon	Cliente

Histórico de Revisões¶

Data	Versão	Descrição	Autor(es)
14/04/2025	0.1	Informações iniciais a respeito do projeto e da equipe	Luis Guilherme Borges
14/04/2025	0.2	Complementando os parâmetros iniciais (1.1)	João Pedro Araújo de Freitas Lyra
15/04/2025	0.3	Declaração de posição do Produto (1.2)	Heyttor Augusto de Assis Silva, João Pedro Araújo de Freitas Lyra
15/04/2025	0.3	Edição da Visão Geral do Produto (1.1), Bibliografia e diagrama da visão geral do produto	Yasmin Sousa Abdon, Pedro Gomes Oliveira
15/04/2025	0.3	Montagem do diagrama de ciclo de vida (2.1)	Guilherme Ferreira Brandão, João Pedro Araújo de Freitas Lyra, Rivadalvio Joaquim da Silva Filho
15/04/2025	0.3	Objetivo do Produto (1.3)	João Pedro Araújo de Freitas Lyra, Yasmin Sousa Abdon
15/04/2025	0.3	Nomeação do projeto	Votação com todos os integrantes
15/04/2025	0.3	Tecnologias a serem utilizadas (1.4)	Vitória Aquere Matos, Leticia Carvalho dos Santos, João Pedro Araújo de Freitas Lyra, Guilherme Ferreira Brandão, Ingrid Alves Rocha
14/05/2025	1.0	Organização do Projeto (2.2)	Leticia Carvalho dos Santos
14/05/2025	1.0	Planejamento das fases (2.3)	João Pedro Araújo de Freitas Lyra
14/05/2025	1.0	Matriz de comunicação (2.4)	Heyttor Augusto de Assis Silva
14/05/2025	1.0	Gerenciamento de riscos (2.5)	Pedro Gomes Oliveira, Nayra Silva Nery
14/05/2025	1.0	Critérios de planejamento (2.6)	Nayra Silva Nery, Heyttor Augusto de Assis Silva
14/05/2025	1.0	Processo de desenvolvimento de software (3)	Carlos Henrique de Paiva Munis
14/05/2025	1.0	Backlog do Produto (4.1)	Guilherme Ferreira Brandão, João Pedro Araújo de Freitas Lyra
14/05/2025	1.0	Perfis (4.2)	Guilherme Ferreira Brandão, Carlos Henrique de Paiva Munis
14/05/2025	1.0	Cenários (4.3)	Guilherme Ferreira Brandão
14/05/2025	1.0	Tabela backlog (4.4)	Guilherme Ferreira Brandão, João Pedro Araújo de Freitas Lyra
16/05/2025	1.1	Diagrama de processos (3)	Ingrid Alves Rocha
16/05/2025	1.1	GQM de medições (5.1)	Arthur Sismene Carvalho
16/05/2025	1.1	Estratégia de Testes (6.1)	Nayra Silva Nery
16/05/2025	1.1	Roteiro de Testes (6.2)	Luis Guilherme Borges, Yasmin Sousa Abdon

Pontos de Contribuição¶

Matrícula	Nome	% de Pontos de Contribuição no trabalho
231011892	ARTHUR SISMENE CARVALHO	4,79%
221022480	CARLOS HENRIQUE DE PAIVA MUNIS	5,99%
231030691	GUILHERME FERREIRA BRANDAO	14,97%
232002996	HEYTTOR AUGUSTO DE ASSIS SILVA	7,18%
202045348	INGRID ALVES ROCHA	4,79%
232003661	JOAO PEDRO ARAUJO DE FREITAS LYRA	14,97%
222022135	LETICIA DE CARVALHO DOS SANTOS	12,57%
211045178	LUIS GUILHERME BORGES MONTEIRO	5,99%
221007608	NAYRA SILVA NERY	9,58%
211031440	PEDRO GOMES OLIVEIRA	4,79%
232024026	RIVADALVIO JOAQUIM DA SILVA FILHO	3,59%
232014271	YASMIN SOUSA ABDON	10,79%

Sumário¶

Visão Geral do Produto
    1.1 Problema
    1.2 Declaração de Posição do Produto
    1.3 Objetivos do Produto
    1.4 Tecnologias Utilizadas
Visão Geral do Projeto
    2.1 Ciclo de Vida
    2.2 Organização do Projeto
    2.3 Planejamento das Fases
    2.4 Matriz de Comunicação
    2.5 Gerenciamento de Riscos
    2.6 Critérios de Replanejamento
Processo de Desenvolvimento de Software
Declaração de Escopo do Projeto
    4.1 Backlog do produto
    4.2 Perfis
    4.3 Cenários
    4.4 Tabela de Backlog do produto
Métricas e Medições
5.1 GQM de medições
Testes de Software
    6.1 Estratégia de testes contendo
        6.1.1 Níveis de Testes Abordados
        6.1.2 Tipos de Testes Abordados
        6.1.3 Ambientes de Testes
        6.1.4 Métricas de Análise do SonarQube
        6.1.5 Plano de Testes Unitários
    6.2 Roteiro de teste
Referências Bibliográficas

VISÃO GERAL DO PRODUTO E PROJETO¶

1.Visão Geral do Produto¶

1.1 Problema¶

O Grupo OTHALA ficou responsável por desenvolver uma aplicação alinhada ao ODS 4 – Educação de Qualidade, que faz parte da Agenda 2030 da Organização das Nações Unidas (ONU). Este objetivo tem como missão “assegurar a educação inclusiva, equitativa e de qualidade, e promover oportunidades de aprendizagem ao longo da vida para todos” (ONU, 2015). De forma mais específica, nosso projeto atende diretamente à meta 4.6, que estabelece que, até 2030, “todos os jovens e uma proporção substancial de adultos, homens e mulheres, devem alcançar a alfabetização e o conhecimento básico de matemática” (ONU, 2015). Essa meta é essencial, pois reconhece que tanto a alfabetização quanto o domínio de operações matemáticas básicas são direitos fundamentais, que impactam diretamente na autonomia, cidadania, inclusão social e desenvolvimento econômico dos indivíduos. A ONU reforça que o acesso à educação básica é um dos pilares mais importantes para romper ciclos de pobreza, ampliar oportunidades no mercado de trabalho, garantir participação ativa na sociedade e fomentar o desenvolvimento sustentável (ONU, 2015; UNESCO, 2019). No entanto, apesar dos esforços internacionais e nacionais, o Brasil ainda enfrenta índices alarmantes de analfabetismo e anumerismo.

Contexto: Atualmente, no Brasil, cerca de 7% da população, o equivalente a 11,4 milhões de pessoas, ainda é analfabeta, de acordo com o censo de 2022 do IBGE. Além disso, a matemática é considerada uma grande dificuldade, sendo apontada pelo Programa Internacional de Avaliação de Alunos (PISA) como "o maior gargalo educacional" do país (Agência Brasil, 2023). Esses números refletem não apenas falhas no sistema educacional, mas também a exclusão de muitos cidadãos dos direitos básicos, como o acesso ao conhecimento, à cidadania e ao mercado de trabalho. Esses dados revelam não apenas um problema educacional, mas também um grave problema social, que impacta o desenvolvimento do país. Esse cenário é agravado por diversos fatores, como as dificuldades econômicas, a falta de acesso à tecnologia, metodologias de ensino pouco atrativas e a falta de incentivo familiar. Todos esses aspectos estão organizados no Diagrama de causa e efeito do baixo nível de alfabetização e conhecimento matemático entre jovens e adultos na Figura 1, que ilustra como esses elementos contribuem para o baixo nível de alfabetização e conhecimento matemático entre jovens e adultos no Brasil.
Problema: A falta de educação básica tem consequências profundas na sociedade, criando uma barreira significativa para a participação de muitos indivíduos no mercado de trabalho e no consumo. A solução proposta é uma aplicação móvel, que será desenvolvida com o objetivo de oferecer um aprendizado interativo e progressivo. A aplicação seguirá os princípios de Paulo Freire sobre a educação, focando no ensino de leitura e nas quatro operações matemáticas básicas, de forma gradual. Assim, o aplicativo se destina a ensinar tópicos importantes na área de português e matemática como pontuação de frases e resolução de expressões numéricas.

Figura 1 – Diagrama de causa e efeito do baixo nível de alfabetização.Fonte: Os Autores.

1.2 Declaração de Posição do Produto¶

O quadro abaixo tem como objetivo descrever de forma clara e concisa o objetivo do grupo Othala em relação ao posicionamento do aplicativo Omega (Ω) no mercado, destacando o público-alvo, a necessidade que busca atender, a proposta de valor e o impacto esperado em sua ausência.

Quadro 1 - Declaração de Posição do Produto


Para:	Pessoas de faixa etária de 15 a 21 anos que sejam semi-analfabetas nível básico, que tenham dificuldade com operações matemáticas, dificuldade em escrita correta, interpretação com um nível de leitura básica.
Necessidade:	Por mais que tenha sido reduzida com o passar dos anos, de acordo com o IBGE, ainda existem cerca de 9,3 milhões de brasileiros com algum nível de analfabetismo, então vê-se a necessidade de auxiliar nessa luta com o projeto desenvolvido.
O Omega:	O produto é um app mobile com o nome omega (Ω)
Que:	Acredita-se que o projeto, se bem aplicado, contribuiria significativamente no combate ao analfabetismo e ao anumerismo (a incapacidade de compreender e interpretar informações numéricas e estatísticas no cotidiano).
Ao contrário:	Acredita-se que, caso nosso produto não exista, a taxa de analfabetismo continuará a mesma, e nenhuma mudança na situação acontecerá.
Nosso produto:	Nosso produto se propõe a ser uma maneira simplificada, rápida, acessível a todos e divertida no aprendizado.

Fonte: Os autores

1.3 Objetivos do Produto¶

Objetivo Principal: Auxiliar no combate ao analfabetismo e anumerismo, promovendo a inclusão educacional de jovens e adultos com dificuldades em leitura, escrita e habilidades matemáticas básicas. Conforme definido pela Organização para a Cooperação e Desenvolvimento Econômico (OCDE) e adotado pela UNESCO no indicador 4.6.1 dos Objetivos de Desenvolvimento Sustentável (ODS), “Anumerismo é a capacidade de acessar, usar, interpretar e comunicar informações e ideias matemáticas, a fim de se engajar e lidar com as demandas matemáticas em diversas situações da vida adulta.” (UNESCO-UIS, 2019). Objetivo secundário: Motivar jovens e adultos a aprenderem a ler, escrever e dominar matemática básica de forma acessível, prática e lúdica, com a finalidade de incentivar o retorno aos estudos e promover sua inclusão social e econômica.

1.4 Tecnologias a Serem Utilizadas¶

No desenvolvimento desse projeto foram usadas várias ferramentas tecnológicas para realização do aplicativo mobile.São elas:

Frontend:
React Native: é uma biblioteca desenvolvida pelo Facebook para a criação de aplicações móveis utilizando JavaScript e React. Com ela, é possível desenvolver aplicativos nativos para Android e iOS utilizando a mesma base de código, promovendo agilidade e reutilização de componentes.
Typescript: é uma linguagem baseada em JavaScript que adiciona tipagem estática ao código. Sua utilização no frontend ajuda a reduzir erros, melhora a legibilidade e proporciona melhor suporte em editores como o VSCode.
Backend:
Typescript: Assim como no frontend, o uso de TypeScript no backend aumenta a segurança do código, permitindo o desenvolvimento de APIs mais robustas, principalmente quando utilizado com frameworks como Express.js ou similares.
SQL: Será utilizado um banco de dados relacional com linguagem SQL para armazenamento estruturado das informações da aplicação. A escolha se deve à confiabilidade, maturidade e ampla documentação dessa tecnologia.
Ambiente de desenvolvimento:
Github: será utilizado como plataforma de versionamento e colaboração. Com ele, é possível manter o controle de versões do projeto, criar branches para novas funcionalidades, além de facilitar o trabalho em equipe.
VsCode: Visual Studio Code é o editor de código escolhido por sua leveza, grande variedade de extensões, integração nativa com GitHub, suporte a TypeScript e ótima usabilidade.
Docker: será utilizado para criar ambientes padronizados de desenvolvimento e produção, evitando problemas relacionados a configurações distintas em máquinas diferentes. Com ele, a aplicação poderá ser facilmente empacotada e executada em qualquer ambiente compatível com Docker.

2.Visão Geral do Projeto¶

2.1 Ciclo de vida do projeto de desenvolvimento de software¶

Imagem do WhatsApp de 2025-06-29 à(s) 23 27 28_d7840785 Figura 2 – Diagrama de Ciclo de Vida.Fonte: Os autores.

2.2 Organização do Projeto¶

O quadro 2 apresenta a organização da equipe envolvida no desenvolvimento do projeto, detalhando os papéis assumidos, as atribuições de cada função, os responsáveis diretos e os participantes colaboradores. A estrutura foi pensada para garantir uma divisão clara de responsabilidades, promovendo o bom andamento do projeto, a integração entre áreas e a entrega eficiente das funcionalidades planejadas.

Quadro 2 - Organização do Projeto

Papel	Atribuições	Responsável	Participantes
Desenvolvedor Frontend	Implementação da Interface do Usuário (UI)\<br>Criação de Componentes Interativos\<br>Responsividade e Acessibilidade\<br>Integração com APIs\<br>Otimização de Performance\<br>Segurança no Frontend	Arthur Sismene Carvalho	Arthur Sismene Carvalho\<br>Carlos Henrique de Paiva Munis
Desenvolvedor Backend	Design e Implementação de APIs\<br>Gerenciamento de Banco de Dados\<br>Autenticação e Autorização\<br>Integração com Sistemas Externos\<br>Performance e Escalabilidade do Servidor\<br>Tratamento de Erros e Logs\<br>Segurança no Backend\<br>Manutenção e Deploy da Aplicação	Guilherme Ferreira Brandão	Guilherme Ferreira Brandão\<br>Heyttor Augusto de Assis Silva
Dono do Produto	Atualizar o escopo do produto\<br>Organizar o escopo das sprints\<br>Validar as entregas	João Pedro Araújo de Freitas Lyra	Ingrid Alves Rocha\<br>João Pedro Araújo de Freitas Lyra
Analista de Qualidade	Garantir a qualidade do produto\<br>Garantir o cumprimento do conceito de pronto\<br>Realizar inspeções de código	Leticia de Carvalho dos Santos	Leticia de Carvalho dos Santos\<br>Luis Guilherme Borges Monteiro
Analista de Testes	Análise de Requisitos\<br>Planejamento de Testes\<br>Criação de Casos de Teste\<br>Execução de Testes Manuais\<br>Automação de Testes\<br>Identificação e Reporte de Bugs\<br>Reexecução de Testes Após Correções\<br>Validação de Funcionalidades	Nayra Silva Nery	Nayra Silva Nery\<br>Pedro Gomes Oliveira
Cliente	Definição de Requisitos\<br>Priorização de Funcionalidades\<br>Validação dos Resultados\<br>Disponibilidade para Feedback\<br>Participação em Reuniões (como refinamento ou revisão)	Rivaldo Joaquim da Silva Filho	Rivaldo Joaquim da Silva Filho\<br>Yasmin Sousa Abdon

Fonte: Os autores

2.3 Planejamento das Fases e/ou Iterações do Projeto¶

O quadro 3 descreve o planejamento das fases e iterações do projeto, organizadas em sprints. Cada sprint representa um ciclo de desenvolvimento com objetivos específicos, prazos definidos e entregas programadas, seguindo a abordagem ágil do manifesto ágil (Manifesto Ágil, 2025). A tabela detalha o produto ou resultado esperado de cada sprint, as datas de início e fim, os entregáveis previstos, os responsáveis diretos pela execução e o percentual de conclusão associado. Ao final, a soma total das entregas corresponde a 100%, refletindo a integralidade do desenvolvimento planejado.

Quadro 3 -Planejamento das Fases e/ou Iterações do Projeto

Sprint	Produto (Entrega)	Data Início	Data Fim	Entregável(eis)	Responsáveis	Descrição e % Conclusão
Sprint 1	Definiu-se que se trata de um app mobile, de combate ao analfabetismo e anumerismo.	14/04/2025	14/05/2025	documentação	João Pedro Araújo de Freitas Lyra	Divisão de tarefas início efetivo do projeto; 11,10%
Sprint 2	MVP e Planejamento do Projeto	14/05/2025	16/05/2025	documentação	João Pedro Araújo de Freitas Lyra;\<br>Guilherme Ferreira Brandão	Definiu-se o objetivo de cada sprint; 11,10%
Sprint 3	Reunião com uma parte dos integrantes para definir algumas metodologias para agilizar o processo de desenvolvimento. Também foi feito o primeiro commit de pastas que serão utilizadas para organização do trabalho.	21/05/2025	25/05/2025	Projeto/documentação	João Pedro Araújo de Freitas Lyra;\<br>Guilherme Ferreira Brandão	Definiu-se os times de backend e frontend para trabalhar em conjunto, com a integração sendo feita pelo frontend. Times de teste ficam 1 sprint atrás do time de desenvolvimento. 11,10%
Sprint 4	Cadastro e Login	26/05/2025	01/06/2025	projeto	todos os integrantes	A Sprint 4 implementou o cadastro e login de usuários, permitindo autenticação segura e integração entre frontend e backend. 11,10%
Sprint 5	Realização de atividades/teste Sprint 4	02/06/2025	08/06/2025	projeto	todos os integrantes	A Sprint 5 focou na execução das atividades do Sprint 4 e testes das funcionalidades de cadastro e login, garantindo que o sistema estivesse funcionando corretamente e integrando melhorias necessárias. 11,10%
Sprint 6	Sistema de Progresso/Teste Sprint 5	09/06/2025	15/06/2025	projeto	todos os integrantes	Implementação do sistema de progresso, permitindo aos usuários retomar suas atividades. Também foram realizados testes para validar as entregas do Sprint 5. 11,10%
Sprint 7	Gerenciamento de Conteúdo/Teste sprint 6	16/06/2025	22/06/2025	projeto	todos os integrantes	Desenvolvimento do gerenciamento de conteúdo para administradores e continuação dos testes das funcionalidades do Sprint 6, implementação da cartilha assegurando que o sistema fosse flexível e sem falhas. 11,10%
Sprint 8	Teste final e geração de apk/teste sprint 7	23/06/2025	29/06/2025	projeto	todos os integrantes	Testes finais realizados e geração do APK para testar em dispositivos reais. Todos os testes do Sprint foram feitos, garantindo o aplicativo estivesse pronto para distribuição. 11,10%
Sprint 9	Ajustes finais	30/06/2025	30/06/2025	projeto	todos os integrantes	Correção de erros finais e ajustes de última hora para garantir que o produto estivesse completamente pronto para entrega, com todos os requisitos atendidos. 11,10%

Fonte: Os autores

2.4 Matriz de Comunicação¶

O quadro 4 apresenta a Matriz de Comunicação do projeto. Ela descreve como as informações importantes serão comunicadas, para quem, com que frequência e quais documentos serão gerados a partir dessas comunicações. O objetivo é garantir que a equipe e as partes interessadas estejam sempre alinhadas sobre o andamento do projeto.

Quadro 4 - Matriz de Comunicação

Descrição	Área/Envolvidos	Periodicidade	Produtos Gerados
• Acompanhamento das Atividades em Andamento	• Equipe do Projeto	• Semanal	• Ata de reunião\<br>• Relatório de situação do projeto
• Acompanhamento dos Riscos, Compromissos, Ações Pendentes, Indicadores	• Equipe do projeto	• Semanal	• feedback do resto equipe sobre as atividades exercidas pela equipe de desenvolvimento
• Comunicar situação do projeto	• Equipe\<br>• Prof/Monitor	• Semanal	• Ata de reunião\<br>• Relatório de situação do projeto

Fonte: Os autores.

2.5 Gerenciamento de Riscos¶

O quadro 5, a seguir, detalha o plano de Gerenciamento de Riscos do projeto. Nela, são identificados os principais riscos que podem afetar o andamento dos trabalhos, seu grau de exposição, as ações de mitigação para evitar que ocorram e os planos de contingência para lidar com eles caso se concretizem.

Quadro 5- Gerenciamento de Riscos

Risco	Grau de Exposição	Mitigação	Plano de Contingência
Atrasos na entrega	Alto	Estabelecer cronograma com prazos realistas e reuniões de acompanhamento	Priorizar tarefas, focar nas funcionalidades essenciais.
Bugs e falhas no aplicativo	Alto	Testar cada funcionalidade antes de avançar para a próxima etapa	Corrigir imediatamente, usar ferramentas de depuração e controle de versões
Falta de engajamento da equipe	Médio	Divisão clara de tarefas, comunicação constante e metas curtas	Redistribuir tarefas
Má gestão do tempo	Alto	Uso de cronogramas e métodos ágeis	Eliminar ou adiar itens de menor prioridade para garantir entrega mínima viável
Problemas com ferramentas	Médio	Usar ferramentas estáveis, backups frequentes e controle de versão (Git)	Mudar a ferramenta, restaurar backup

Fonte: Os autores

2.5.1 Critérios para atrasos na entrega (Risco alto)¶

A identificação de possíveis atrasos de entrega é importante para garantir a fluidez e saúde do projeto e pensar em possíveis ações corretivas. Os seguintes critérios foram utilizados para classificar uma situação como risco alto relacionado a atrasos na entrega: Atraso superior a 20% no cronograma planejado Caso o avanço do projeto esteja mais de 20% abaixo do previsto, isso será considerado um indicador de risco alto, exigindo revisão imediata do cronograma e ações corretivas. Duas sprints consecutivas com menos de 70% das entregas concluídas A baixa taxa de conclusão nas sprints consecutivas pode indicar falhas no planejamento, dimensionamento incorreto das tarefas ou problemas de execução. Isso configura um risco significativo para a continuidade e o cumprimento dos prazos do projeto. Impossibilidade de cumprimento de um marco crítico na data prevista Caso um marco (milestone) essencial para o projeto esteja em risco ou seja inviável de ser entregue na data estipulada, isso será classificado como um risco alto, demandando replanejamento estratégico.

2.6 Critérios de Replanejamento¶

2.6.1 Critérios relacionados ao cronograma de entregas¶

Para um controle de projeto proativo e eficaz, foram definidos critérios quantitativos que funcionam como indicadores de alerta. O quadro 6 abaixo detalha esses critérios, associando cada um a um risco específico e a um plano de ação predefinido. Este plano se divide em ações de mitigação, de caráter preventivo e contínuo, e ações de contingência, a serem executadas caso o critério de alerta seja atingido. O objetivo é formalizar as respostas a desvios, agilizando a tomada de decisão.

Quadro 6 - Critérios relacionados ao cronograma de entregas

Critério	Descrição	Risco Associado	Plano de Mitigação/Contingência
Atraso de Sprint	Sprint com menos de 70% das histórias concluídas	Risco de atraso na entrega final	Mitigação: Revisão diária do progresso das tarefas\<br>Contingência: Realocação de recursos ou ajuste de escopo
Acúmulo de débito técnico	Débito técnico ultrapassando 20% do backlog total	Risco de comprometimento de qualidade	Mitigação: Reservar tempo na Sprint para tratamento de débitos\<br>Contingência: Sprint dedicada à redução de débito técnico
Desvio no tempo de entrega	Desvio superior a 15% do planejado por duas sprints consecutivas	Risco de não cumprimento do prazo final	Mitigação: Monitoramento diário das estimativas\<br>Contingência: Revisão do Escopo ou aumento da equipe

Fonte: Os autores

2.6.2 Critérios relacionados aos requisitos e usabilidade¶

Para assegurar a aderência do produto aos requisitos e a sua aceitação pelo público-alvo, foram estabelecidos critérios de monitoramento específicos, detalhados no Quadro 7. Esta matriz associa gatilhos quantitativos, como o percentual de alterações no escopo ou o feedback dos usuários, a riscos específicos de qualidade e satisfação. Para cada critério, um plano de mitigação e contingência é definido para orientar a equipe na tomada de ações corretivas e preventivas de forma ágil e estruturada.

Quadro 7 - Critérios relacionados aos requisitos e usabilidade

Critério	Descrição	Risco associado	Plano de mitigação/Contingência
Alterações significativas em requisitos	Mudanças que impactam mais de 25% das funcionalidades	Risco de escopo inadequado	Mitigação: Validação contínua com stakeholders\<br>Contingência: Congelamento de escopo com priorização
Baixa usabilidade para o público-alvo	Menos dos 70% dos usuários analfabetos conseguirem completar tarefas básicas	Risco de baixa adoção	Mitigação: Testes frequentes com usuários reais\<br>Contingência: Redesenho de interface com foco em acessibilidade
Feedback negativo recorrente	Funcionalidade com feedback negativo de mais de 50% dos usuários	Risco de insatisfação do cliente	Mitigação: Protótipos validados antes da implementação\<br>Contingência: Redesenho da funcionalidade problemática

Fonte: Os autores

2.6.3 Critérios relacionados à qualidade e testes¶

Com o objetivo de assegurar a qualidade do produto final e minimizar riscos ao longo do desenvolvimento, é essencial estabelecer critérios específicos que orientem a equipe em relação à identificação e mitigação de falhas. O Quadro 8 a seguir apresenta os principais critérios relacionados à qualidade e testes, detalhando suas descrições, os riscos associados e os respectivos planos de mitigação e contingência. Esses critérios foram definidos com base em práticas consolidadas de engenharia de software, como o uso de TDD, revisões de código e estratégias de refatoração, visando garantir entregas mais estáveis, funcionais e alinhadas aos requisitos do projeto.

Quadro 8 - Critérios relacionados à qualidade e testes

Critérios	Descrição	Risco associado	Plano de mitigação/Contingência
Taxa de bugs elevadas	Mais de 5 bugs críticos/bloqueadores por Sprint	Risco de instabilidade do produto	Mitigação: Práticas TDD e revisão de código\<br>Contingência: Sprint focada em correção de bugs
Reprovação em homologação	Funcionalidade reprovada mais de 2 vezes	Risco de atraso na entrega	Mitigação: Testes de aceitação\<br>Contingência: Revisão dos critérios de aceitação
Falhas recorrentes	Mesmo componente com falhas em mais de 3 ciclos	Risco de degradação da arquitetura	Mitigação: Revisão arquitetural proativa\<br>Contingência: Refatoração do componente problemático

Fonte:Os Autores.

2.6.4 Critérios relacionados a recursos e infraestrutura¶

A equipe envolvida e os recursos disponíveis exercem papel fundamental na viabilidade e continuidade do desenvolvimento de software. Limitações nesse âmbito podem comprometer diretamente a estabilidade do projeto e sua entrega dentro dos prazos estipulados. Dessa forma, o Quadro 9 apresenta os principais critérios relacionados a recursos e recursos humanos, descrevendo os riscos associados e propondo estratégias de mitigação e contingência. Esses critérios foram definidos com o objetivo de antecipar falhas técnicas, garantir a compatibilidade entre sistemas, assegurar a disponibilidade de ferramentas essenciais e promover a adaptação contínua frente a eventuais obstáculos técnicos.

Quadro 9 - Critérios relacionados a recursos humanos

Critérios	Descrição	Risco associado	Plano de mitigação/Contingência
Limitações técnicas	Identificação de limitações que comprometam a arquitetura do sistema	Risco de inviabilidade técnica	Mitigação: Provas de conceito antecipadas.\<br>Contingência: Redesenho da solução técnica.
Problemas de integração	Falhas de integração persistentes por mais de uma sprint	Risco de incompatibilidade de sistemas	Mitigação: Testes de integração contínuos.\<br>Contingência: Desenvolvimento de adaptadores ou APIs alternativas.
Indisponibilidade de ferramentas de desenvolvimento	Falhas nas ferramentas utilizadas para o desenvolvimento do sistema, como IDEs, repositórios, etc	Risco de interrupção no progresso do desenvolvimento	Mitigação: Garantir a utilização de ferramentas estáveis e backups frequentes.\<br>Contingência: Mudar a ferramenta, restaurar backup.

Fonte: Os autores

2.6.5 Processo de monitoramento e atualização:¶

Os critérios de replanejamento serão revisados e atualizados com o decorrer do trabalho, para que não ocorram débitos técnicos que atrapalhem o andamento do projeto : - Ao final de cada ciclo/Sprint - Após a identificação de novos riscos - Quando um replanejamento for realizado Cada atualização nos critérios de planejamento ou qualquer alteração no projeto que demande replanejamento resultará em uma nova versão deste documento, seguindo controle de versões estabelecido.

3.PROCESSO DE DESENVOLVIMENTO DE SOFTWARE¶

Metodologia Adotada¶

De acordo com estudos sobre a metodologia Scrum como Scrum Guide de Ken Schwaber e Jeff Sutherland realizamos: A equipe optou por utilizar uma abordagem baseada em metodologias ágeis, especialmente os conceitos do Scrum e do XP. A aplicação desses métodos visa garantir uma organização eficiente do trabalho, entregas contínuas, priorização de valor para o usuário e capacidade de adaptação ao longo do projeto

Visão Geral do Processo¶

O processo de desenvolvimento é cíclico e iterativo, seguindo os seguintes estágios principais: - Backlog e Escopo: levantamento inicial das funcionalidades desejadas, criando uma lista priorizada de tarefas. - Design de UI/UX: criação de protótipos de interface e fluxos de navegação. - Sprints: o desenvolvimento é dividido em ciclos curtos (sprints), com entregas incrementais e reuniões de planejamento, acompanhamento e retrospectiva. - Testes: validação constante do sistema com testes manuais e automatizados. - Desenvolvimento Continuo: integração frequente de novas funcionalidades e correções.

Procedimentos Técnicos¶

Nesta seção, são descritas as principais decisões técnicas adotadas para a implementação da solução: - Backend: desenvolvido em TypeScript, proporcionando maior segurança e legibilidade no código. - Banco de Dados: utiliza o PostgreSQL para uma solução robusta e confiável para armazenamento e gerenciamento das informações. - Frontend: construído com React Native utilizando Expo, permitindo maior agilidade no desenvolvimento de aplicativos mobile.

Métodos Utilizados¶

Durante o desenvolvimento do projeto,foram adotadas metodologias que proporcionam organização,flexibilidade e organização do processo, dentre elas destacam-se:

Aplicação de práticas do Scrum e XP, com foco em:
Desenvolvimento incremental. O sistema foi construído por etapas, com funcionalidades sendo implementadas gradualmente, o que permitiu validar e ajustar o projeto ao longo do tempo.
Comunicação constante entre os membros da equipe. Foram realizadas reuniões frequentes entre os membros do grupo para discutir questões pertinentes do projeto e garantir que todos estavam na mesma página.
Entregas frequentes e com feedback.
Código limpo e práticas como refatoração (quando aplicável). Buscou-se manter boas práticas de programação e a qualidade do código para manter a legibilidade e entendimento do que foi implementado.
O projeto é orientado a funções, priorizando funcionalidades com valor claro ao usuário.

Ferramentas¶

A escolha das ferramentas foi orientada pelos princípios de produtividade, padronização e colaboração entre os membros da equipe. - VSCode: Ambiente de desenvolvimento utilizado por toda a equipe por sua flexibilidade, integração com extensões e suporte a múltiplas linguagens.
- GitHub: plataforma de versionamento e colaboração no código, permitindo controle de versão, integração contínua e rastreamento de mudança de código. - Docker: utilizado para criação de ambientes consistentes e padronizados, garantindo consistência e facilidade de implementação.

Diagrama em branco (1) 1

4.DECLARAÇÃO DE ESCOPO DO PROJETO¶

4.1 Backlog do produto¶

O backlog do produto foi construído com base em pesquisas sobre a temática da ODS 4 (analfabetismo e anumerismo em território nacional), reuniões de brainstorm semanais, levando em consideração o prazo até entrega final, decidiu-se focar na simplicidade e interatividade da aplicação mobile, definiu-se graus de prioridade(must, should, could), conforme a importância de cada parte.

4.2 Perfis¶

Aluno: usuário que acessa os conteúdos e faz os exercícios.
Administrador: gerencia os conteúdos, usuários, questões e progresso do usuário. Para garantir a segurança, organização e usabilidade do sistema, é fundamental estabelecer perfis de acesso com permissões específicas para cada tipo de usuário. Essa definição permite o controle adequado sobre as funcionalidades disponíveis a cada grupo, além de facilitar a manutenção e o gerenciamento da aplicação. O quadro 10 apresenta os principais perfis de acesso, com suas respectivas características e permissões, diferenciando, por exemplo, o perfil de Aluno, voltado ao consumo de conteúdo educacional, e o de Administrador, responsável pela gestão de usuários e conteúdos do sistema, porém este é uma simples proposta de melhoria do projeto, não sendo item necessário para o funcionamento do projeto.

Quadro 10 : Perfis de acesso

#	Nome do perfil	Características do perfil	Permissões de acesso
`<1/>`	Aluno	Usuário que acessa os conteúdos educacionais.	Acesso às aulas, e as listas de exercícios.
`<2>`	Administrador	Responsável por manter os perfis de acesso da aplicação, criar novos usuários, alterar usuários já existentes, ou excluir usuários (Manter usuários).	Permissões para criar, editar e remover conteúdos educacionais, gerenciar usuários, visualizar estatísticas e relatórios de desempenho dos alunos, configurar categorias, níveis e parâmetros do sistema.

Fonte: Os autores

4.3 Cenários¶

Durante o desenvolvimento do sistema Omega, foram definidos diferentes cenários funcionais que representam os principais blocos de funcionalidades a serem implementadas ao longo das sprints. Esses cenários orientam o planejamento e a execução das entregas incrementais, garantindo que cada funcionalidade essencial seja abordada de forma estruturada e em conformidade com as prioridades do projeto. O quadro 11 apresenta os cenários funcionais identificados, com sua respectiva numeração, descrição e a sprint prevista para sua realização.

Quadro 11 : Cenários funcionais

Nº	Cenário	Sprint
01	Cadastro e Login	1
02	Realização de Atividades	2
03	Sistema de Progresso	3
04	Gerenciamento de Conteúdo	4
05	Testes, cartilha e Geração do APK	5

Fonte: Os autores

4.4 Backlog¶

O backlog do produto é uma lista priorizada de funcionalidades e requisitos necessários para o desenvolvimento do sistema, organizada em sprints e acompanhada de histórias de usuário (user stories) que traduzem as necessidades dos usuários finais. Essa estrutura permite que a equipe compreenda, planeje e implemente as entregas de forma iterativa e incremental. O quadro 12 apresenta o backlog do produto do sistema Omega (Ω), detalhando a numeração dos itens, tipo e prioridade dos requisitos, uma descrição resumida de cada um deles, bem como as histórias de usuário associadas, promovendo uma visão clara e orientada ao valor para o desenvolvimento do sistema.

Quadro 12 - Backlog do produto

Numeração (Cenário/ requisito)	Sprint	Nome do requisito	Tipo de requisito (Funcional / não funcional)	Priorização do requisito (Must, Should, Could)	Descrição sucinta do requisito	User stories (U.S.) associadas
1.1	1	Cadastro de Usuário	Funcional	Must	O sistema deve permitir que o aluno crie uma conta com email e senha	Como aluno, quero poder me cadastrar para acessar o conteúdo do aplicativo.
1.2	1	Login de Usuário	Funcional	Must	O sistema deve permitir autenticação por email e senha.	Como aluno, quero poder fazer login para continuar meus estudos.
2.1	2	Questões de português	Funcional	Must	Deve ter 3 questões em cada um dos 3 níveis em português. 1- estrutura gramatical. 2- pontuação e 3- interpretação básica de texto	Como aluno, quero poder realizar questões de portugues.
2.2	2	Questões de matemática e tela de regras	Funcional	Must	Deve ter 3 questões em cada um dos 3 níveis em matemática. 1- multiplicação (tabuada). 2- divisão/fração. 3- expressão numérica (soma, subtração, divisão, multiplicação)	Como aluno, quero poder realizar questões e aprender matemática básica, também quero entender como obter acesso ao material de estudo.
3.1	3	Sistema de progresso	Funcional	Could	Deve ser possível recomeçar da atividade onde o usuário parou na última interação com o aplicativo; deve haver uma tela de regras para explicar o funcionamento básico do botão omega ao usuário.	Como aluno, quero poder ter continuidade nos estudos com um sistema de progressão
3.2	3	Sistema de correção	Funcional	Must	Ao término de cada nível, será dado ao usuário um feedback sobre as atividades, erros e acertos, corretos grifados em verde, errados em grifados vermelha, e se tiver uma taxa de acerto menor que 2, o usuário volta ao início do nível, após o feedback visual, o teórico deverá ser acessado ao clicar no botão omega(Ω) disponível na tela de regras e nas atividades.	Como aluno, quero saber quais questões acertei e quais errei.
4.1	4	Painel do administrador	Funcional	Should	O administrador deve poder adicionar, editar ou remover atividades dentro dos níveis. Não há acesso direto do administrador aos dados do usuário, apenas ao sistema de questões.	Como administrador, quero atualizar os conteúdos do aplicativo.
4.2	4	Aba de créditos	Não funcional	Should	O aplicativo deve ter uma aba que indica os créditos de cada questão.	Como aluno, quero saber o material bibliográfico das questões que realizo para aprofundar os estudos
5.1	5	Testes finais, geração do apk	Funcional	Must	O aplicativo deve funcionar perfeitamente sem bugs ou erros, mesmo havendo testes após cada sprint será feito um teste geral intenso no final. Logo após esse teste intenso será feito o deploy que no caso é a geração do APK.	Como aluno, quero baixar o aplicativo em meu celular (android), ter uma boa experiência com o app, realizando as atividades de forma linear e com as funcionalidades sem bugs.
5.2	5	Modo Offline	Não funcional	Could	O aplicativo deve funcionar parcialmente sem conexão, salvando a progressão do usuário.	Como aluno, quero poder estudar mesmo sem internet.
5.3	5	Cartilha	Funcional	Must	A Cartilha deve ser acessível ao clicar em qualquer botão com o símbolo do aplicativo para acessar os materiais usados na criação de questões, livros e recomendações de estudo.	Como aluno, quero saber ter acesso ao conteúdo de cada questão que errei e auxílio para continuar estudando mesmo chegando ao fim das questões do app.

Fonte: Os autores.

5.MÉTRICAS E MEDIÇÕES¶

5.1 GQM de medições¶

Para garantir a qualidade e eficácia do aplicativo mobile voltado à alfabetização de pessoas analfabetas e semianalfabetas, adotamos a abordagem GQM (Goal / Question / Metric) como método de definição e acompanhamento de métricas. - Objetivo (Goal) Analisar o aplicativo de alfabetização com o propósito de avaliar sua usabilidade, eficácia pedagógica e impacto no aprendizado, do ponto de vista dos usuários e educadores, no contexto da inclusão digital e social. - Questões (Questions) - O aplicativo é fácil de usar, mesmo por pessoas com baixa familiaridade com tecnologia? - Os usuários estão conseguindo se desenvolver com o uso do aplicativo? - Quanto tempo os usuários dedicam ao uso do app diariamente? - Quanto tempo os usuários dedicam ao uso do app diariamente? - O desempenho dos usuários melhora com o uso contínuo do aplicativo? - O conteúdo é acessível e adequado aos diferentes níveis de alfabetização?

Métricas (Metrics)
Taxa de conclusão de atividades: Percentual de atividades concluídas com sucesso por usuário, indicando o progresso de aprendizagem.
Tempo médio por sessão de uso: Média de tempo gasto pelos usuários durante cada sessão, refletindo o nível de engajamento.
Número de palavras aprendidas por semana: Quantidade média de palavras aprendidas por usuário, semanalmente.
Número de acessos diários/mensais: Frequência com que os usuários acessam o aplicativo, tanto diariamente quanto mensalmente.
Nível de erro nas atividades de escrita e leitura: Percentual de erros antes e após determinado período de uso, indicando evolução nas habilidades de escrita e leitura.
Pontuação média nas avaliações integradas ao app: Média das notas ou pontuações obtidas pelos usuários nas avaliações de conhecimento.
Tempo até o abandono da aplicação (churn rate): Tempo médio até que os usuários abandonem o aplicativo, indicando a satisfação e o engajamento do usuário.
Feedback qualitativo dos usuários e educadores: Avaliação subjetiva sobre a eficácia e a experiência com o aplicativo, coletada por meio de formulários ou entrevistas.
Quantidade de recursos multimodais utilizados: Número de recursos como áudio, imagens e vídeos empregados pelos usuários para facilitar a compreensão do conteúdo.
Formas alternativas e/ou informais
Modelo ISO/IEC 25010 ( Funcionalidade, Usabilidade, Confiabilidade, Eficiência, Portabilidade, Manutenibilidade, Segurança, Compatibilidade).
Indicadores de Acessibilidade Digital (WCAG)
Análise de Logs e Eventos
Observação direta dos usuários
Testes com Usuários
Relatos de educadores e mediadores
Observações de uso em campo

Métricas da Sprints

A avaliação contínua do desempenho do sistema e do engajamento dos usuários é essencial para validar as entregas realizadas em cada sprint. Por meio de métricas quantitativas e qualitativas, é possível acompanhar a evolução do produto, identificar pontos de melhoria e tomar decisões baseadas em dados. O quadro 13 apresenta as métricas obtidas ao longo das sprints, incluindo indicadores como taxa de conclusão de atividades, tempo médio por sessão, número de acessos, taxa de erro, feedback dos usuários e recursos multimodais utilizados, permitindo uma análise abrangente da eficácia do sistema Omega.

Quadro 13: Métrica da Sprint 1

Métrica	Tempo/valor	Observações
Tempo da Sprint	7 dias	Nada significativo nesse tema.
Desvio do cronograma	15%	Houve bugs no sistema de usuário, rapidamente solucionado, 1 dia.
Tempo de Resolução	7 dias	6 dias de trabalho 1 de resolução de bugs.
Precisão das Estimativas	65-70%	Os testes realizados deram como resultado 65-70% de precisão, no critério dos testes de software.
Taxa de retrabalho	15%	Foi necessário solucionar os bugs.

Fonte: Os autores

Quadro 14: Métrica da Sprint 2

Métrica	Tempo/valor	Observações
Tempo da Sprint	7 dias	Nada de significativo neste tema.
Desvio do cronograma	40%	Houve a não entrega das várias telas do app, o que gerou débito técnico e atraso no cronograma.
Tempo de Resolução	9 dias	7 dias da sprint 2, houve necessidade de tomar 3 dias da sprint 2.
Precisão das Estimativas	65-70%	Os testes realizados deram como resultado 65-70% de precisão, no critério dos testes de software.
Taxa de retrabalho	50%	Foi necessário refazer quase tudo dessa sprint devido ao atraso da entrega de membros.

Fonte: Os autores

Quadro 15: Métrica da Sprint 3

Métrica	Tempo/valor	Observações
Tempo da Sprint	7 dias	Nada significativo nesse tema.
Desvio do cronograma	50%	Devido ao tempo perdido na sprint anterior foi necessário acelerar o tempo real da sprint, e remanejar o tempo de debug da sprint 3.
Tempo de Resolução	4 dias	Tudo relacionado a sprint 3 foi feito em 4 dias.
Precisão das Estimativas	65-69%	Os testes realizados deram como resultado 65-70% de precisão, no critério dos testes de software.
Taxa de retrabalho	15%	Quase não houve bugs nessa sprint.

Fonte: Os autores

Quadro 16: Métrica da Sprint 4

Métrica	Tempo/valor	Observações
Tempo da Sprint	7 dias	Nada significativo nesse tema.
Desvio do cronograma	15%	Houveram problemas nas telas de questões e sistema de retry.
Tempo de Resolução	7 dias	6 dias de trabalho e 1 de debug.
Precisão das Estimativas	65-69%	Os testes realizados deram como resultado 65-70% de precisão, no critério dos testes de software.
Taxa de retrabalho	20%	Foi necessário remanejar a lógica de algumas telas.

Fonte: Os autores

Quadro 17: Métrica da Sprints 5

Métrica	Tempo/valor	Observações
Tempo da Sprint	7 dias	Nada significativo nesse tema.
Desvio do cronograma	35%	Documentação em atraso, foi necessário passar dos dias da sprint, demais objetivos foram cumpridos.
Tempo de Resolução	8 dias	7 dias da sprint normal, e 1 extra para resolução de atrasos
Precisão das Estimativas	65-69%	Os testes realizados deram como resultado 65-70% de precisão, no critério dos testes de software.
Taxa de retrabalho	30%	Necessário ir além do tempo dos objetivos do sprint, e resolver a documentação

Fonte: Os autores

6.TESTES DE SOFTWARE¶

6.1 Estratégia de testes contendo:¶

6.1.1 Níveis de Testes Abordados¶

A definição de uma estratégia de testes eficaz é essencial para assegurar a qualidade e a confiabilidade do sistema desenvolvido. Essa estratégia deve contemplar diferentes níveis de testes, cada um com objetivos específicos e prioridades distintas, a fim de garantir que tanto os componentes individuais quanto o sistema como um todo funcione conforme esperado. O quadro 18 apresenta os níveis de testes abordados no projeto, descrevendo suas características, prioridades e objetivos, desde testes unitários até os testes de aceitação, de modo a cobrir todas as etapas críticas da validação do software.

Quadro 18 - Níveis de testes

Nível de Teste	Descrição	Prioridade	Objetivo
Testes Unitários	Testes isolados de componentes individuais	Alta	Validar o funcionamento correto das funções e métodos específicos que implementam a lógica educacional
Testes de Integração	Verificação da comunicação entre módulos	Média	Garantir que os diferentes componentes da aplicação funcione corretamente quando integrados
Testes de Sistema	Avaliação do sistema como um todo	Baixa	Verificar o funcionamento completo da aplicação em um ambiente próximo ao de produção
Testes de Aceitação	Validação dos requisitos de negócio	Média	Confirmar que a aplicação atende às expectativas

Fonte: Os autores

6.1.2 Tipos de Testes Abordados¶

Além da definição dos níveis de testes, é fundamental identificar os diferentes tipos de testes aplicados ao longo do desenvolvimento, cada um voltado à validação de aspectos específicos do sistema. Esses testes abrangem desde a verificação funcional até avaliações mais amplas, como desempenho, segurança, acessibilidade e usabilidade. O quadro 19 apresenta os principais tipos de testes realizados, incluindo suas descrições, as técnicas aplicadas e as ferramentas utilizadas, garantindo uma abordagem abrangente para assegurar a qualidade e a confiabilidade do sistema em múltiplas dimensões.

Quadro 19 - Tipos de testes

Tipo de Teste	Descrição	Técnicas Aplicadas	Ferramentas
Testes Funcionais	Verificação das funcionalidades específicas	Particionamento de equivalência, análise de valor limite	Jest
Testes de Usabilidade	Avaliação da experiência do usuário	Testes com usuários representativos, heurísticas de Nielsen	Ferramentas de gravação de sessão
Testes de Desempenho	Análise do tempo de resposta e uso de recursos	Testes de carga, testes de estresse	JMeter, Gatling
Testes de Segurança	Verificação de vulnerabilidades	OWASP Top 10, análise estática de código	SonarQube, OWASP ZAP
Testes de Acessibilidade	Validação da acessibilidade para diferentes perfis	WCAG 2.1, testes com tecnologias assistivas	Lighthouse, Axe

Fonte: Os autores.

6.1.3 Ambientes de Testes¶

A realização de testes em diferentes ambientes garante maior confiabilidade no processo de validação do sistema. Cada ambiente possui um propósito específico, com configurações adequadas para o tipo de teste executado e responsabilidades bem definidas entre os membros da equipe. O quadro 20 descreve os principais ambientes de testes utilizados, destacando suas características e responsáveis por sua execução.

Quadro 20- Ambiente de testes

Ambiente	Propósito	Configuração	Responsável
Desenvolvimento	Execução de testes unitários durante o desenvolvimento	Ambiente local com frameworks de teste	Desenvolvedores
Integração Contínua	Execução automática de testes após cada commit	Pipeline CI/CD com Jenkins/GitHub Actions + SonarQube	DevOps e QA
Pré-produção	Testes integrados em ambiente similar ao de produção	Configuração espelhando o ambiente de produção	Equipe de QA
Dispositivos Físicos	Testes em diferentes hardwares e sistemas operacionais	Conjunto de smartphones com diferentes especificações e versões de SO	Equipe de QA

Fonte: Os autores

6.1.4 Métricas de Análise do SonarQube¶

Para garantir a qualidade contínua do código-fonte, foram utilizadas as métricas fornecidas pela ferramenta SonarQube. Essas métricas permitem identificar falhas, problemas de segurança e pontos de melhoria na manutenibilidade do sistema. O quadro 21 apresenta as principais métricas de análise adotadas, suas descrições, metas estabelecidas e o impacto esperado no projeto.

Quadro 21 - Métricas de Análise do SonarQube

Métrica	Descrição	Meta	Impacto
Cobertura de Código	Percentual de código coberto por testes unitários	$\ge$ 70%	Garantir que a maioria do código foi testada
Bugs	Problemas que representam falhas no código	0 (críticos e altos)	Evitar erros durante a execução
Vulnerabilidades	Potenciais brechas de segurança	0 (críticas e altas)	Proteger dados dos usuários
Code Smells	Problemas de manutenibilidade	< 20 por 1000 linhas	Facilitar manutenção futura
Duplicação de Código	Código repetido	< 5%	Melhorar manutenibilidade
Complexidade Ciclomática	Complexidade de caminhos de execução	< 10 por método	Facilitar manutenção e testes
Débito Técnico	Tempo estimado para resolver issues	< 5% do tempo de desenvolvimento	Manter qualidade ao longo do tempo

Fonte: Os autores.

6.1.5 Plano de Testes Unitários¶

Para garantir o funcionamento correto dos componentes do sistema de forma isolada, foi elaborado um plano de testes unitários. Cada componente foi mapeado com seus respectivos casos de teste, recursos necessários para simulação (mocks) e critérios de aceitação, assegurando que cada parte do sistema atenda aos requisitos esperados antes da integração com outros módulos. O quadro 22 apresenta os testes unitários planejados por componente, visando validar desde funcionalidades básicas até aspectos de usabilidade e acessibilidade.

Quadro 22 - Plano de Testes Unitários

Componente	Casos de Teste	Mocks Necessários	Critérios de Aceitação
Módulo de português	Telas de pontuação, sintaxe gramatical e interpretação de texto	API de imagens, serviço de feedback	100% de assertividade no reconhecimento das temáticas
Módulo de Matemática Básica	Operações básicas (multiplicação, divisão/fração) e expressões numéricas	Gerador de problemas, calculadora	Cálculos corretos e verificação de resultados
Sistema de Progressão	Avanço entre níveis, desbloqueio de conteúdo, relatórios de progresso	Perfil de usuário, histórico de atividades	Correto controle de acesso aos níveis baseado no desempenho
Interface do Usuário	Renderização de elementos, resposta a interações, feedback visual.	Simulador de eventos de UI, renderizador	Conformidade com diretrizes de design e acessibilidade

Fonte: Os autores.

6.2 Roteiro de Teste¶

O roteiro de teste detalha a execução prática dos testes planejados, registrando informações como objetivos, pré-condições, critérios de aceitação, resultados obtidos e eventuais reparos realizados. Essa estrutura garante o rastreamento e a repetibilidade dos testes, além de facilitar a análise da estabilidade e qualidade das funcionalidades testadas. O quadro 23 apresenta o roteiro de teste aplicado ao sistema, com dados organizados por ID de teste, nível, tipo e ciclos de execução, contribuindo para um processo de validação completo e documentado.

Quadro 23 - Roteiro de teste

ID do Teste	Nome do Teste	Objetivo do Teste	Nível	Tipo	Pré-condições	Critério de Aceitação	Resultado / Evidência	Reparos Executados	Ciclos Executados
T01	CreateUserService.spec.ts	Verificar se é possível criar um novo usuário com dados válidos	Unitário	Funcional	Banco de dados disponível, aplicação rodando	Usuário cadastrado com sucesso e resposta HTTP 201	Teste executado com sucesso dia 08/06/2025	Correção de erro de autenticação no banco (senha do postgres)	2
T02	DeleteUserController.spec.ts	Verificar se é possível excluir um usuário existente	Integração	API/Backend	Usuário previamente cadastrado no banco	Usuário excluído com sucesso e resposta HTTP 200 ou 204	Teste executado com sucesso dia 08/06/2025	Ajuste na configuração do Docker e na criação do banco de dados (nome do banco estava como 'user', gerando conflito)	3
T03	UpdateUserController.spec.ts	Verificar se é possível atualizar os dados de um usuário	Integração	API/Backend	Usuário previamente cadastrado no banco	Dados atualizados corretamente e resposta HTTP 200	Teste executado com sucesso dia 08/06/2025	Não houve	2
T04	PreLogin.spec.tsx	Verificar se a tela PreLogin renderiza corretamente e navega para a tela de Login	Unitário	Interface com Interação	App rodando, dependências instaladas	Tela renderiza textos principais e botão 'Entrar' funciona corretamente	Teste executado com sucesso dia 15/06/2025	Ajuste nos mocks de navegação para evitar erro 'navigation not initialized'	2
T05	Fluxo.spec.tsx	Verificar o fluxo completo: PreLogin → Login → Regras → Home → Questões de Português	Integração	Fluxo Completo	App rodando, API mockada, banco configurado	Navega corretamente por todas as telas do fluxo, validando presença dos componentes esperados	Teste executado com sucesso dia 15/06/2025 e adicionado novas páginas no fluxo dia 22/06/2025	Ajuste no mock da API, correção do erro 'navigation not initialized' e aumento de timeout para 30000ms	2
T06	QuestaoMT01.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoMT01	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 15/06/2025	Não houve	1
T07	QuestaoPT01.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoPT01	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 15/06/2025	Não houve	1
T08	QuestaoMT02.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoMT02	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T09	QuestaoMT03.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoMT03	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T10	QuestaoMT04.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoMT04	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T11	QuestaoMT05.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoMT05	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T12	QuestaoMT06.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoMT06	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T13	QuestaoMT07.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoMT07	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T14	QuestaoMT08.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoMT08	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T15	QuestaoMT09.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoMT09	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T16	QuestaoPT02.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoPT02	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	0
T17	QuestaoPT03.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoPT03	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T18	QuestaoPT04.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoPT04	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T19	QuestaoPT05.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoPT05	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T20	QuestaoPT06.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoPT06	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T21	QuestaoPT07.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoPT07	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T22	QuestaoPT08.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoPT08	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T23	QuestaoPT09.spec.tsx	Verificar renderização, respostas e navegação da tela QuestaoPT09	Unitário	Interface com Interação	App rodando	Renderiza, responde e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T24	HomeButton.spec.tsx	Validar renderização e navegação do botão Home	Unitário	Componente com Interação	App rodando	Renderiza botão e navega corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T25	StartButton.spec.tsx	Validar renderização e clique do botão Start	Unitário	Componente com Interação	App rodando	Renderiza botão e executa função corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T26	Button.spec.tsx	Validar renderização e clique do botão genérico	Unitário	Componente com Interação	App rodando	Renderiza botão e executa função corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T27	Loading.spec.tsx	Validar renderização do componente de carregamento	Unitário	Visual	App rodando	Renderiza corretamente o indicador de carregamento	Teste executado com sucesso dia 22/06/2025	Não houve	1
T28	ProgressBar.spec.tsx	Validar renderização e atualização da barra de progresso	Unitário	Visual	App rodando	Renderiza progresso atual e atualiza corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T29	Retry.spec.tsx	Validar renderização e interações do componente Retry	Unitário	Componente com Interação	App rodando	Renderiza mensagens e botões corretamente e executa funções	Teste executado com sucesso dia 22/06/2025	Não houve	1
T30	BackButton.spec.tsx	Validar renderização e funcionalidade do botão Voltar (goBack)	Unitário	Componente com Interação	App rodando, dependências instaladas	Renderiza, responde, voltar e executa navigation.goBack() corretamente	Teste executado com sucesso dia 22/06/2025	Não houve	1
T31	Parabens.spec.tsx	Validar a renderização e mensagem ao concluir atividades	Unitário	Visual	App rodando, atividade finalizada	Tela exibe mensagem de parabéns ao final da tarefa	Teste executado com sucesso dia 26/06/2025	Não houve	1
T31	EsqueceuSenha.spec.tsx	Validar renderização dos campos e botão na tela de redefinição de senha	Unitário	Interface (Renderização)	App rodando, dependências instaladas	Tela exibe título, campos de e-mail e nova senha e botão 'Recuperar'	Teste executado com sucesso dia 26/06/2025	Não houve	1
T32	EsqueceuSenhaFluxo.spec.ts	Validar fluxo completo de redefinição de senha (navegar, preencher e confirmar) de forma automatizada	Integração	Fluxo de Troca de Senha	App rodando, conta de teste existente	Fluxo executado com sucesso: recuperação de senha concluída e mensagem de confirmação exibida	Teste executado com sucesso dia 29/06/2025	Não houve	1
T33	Teste Manual APK (Vídeo)	Validar usabilidade do fluxo de redefinição de senha no APK instalado, incluindo gravação de uso real	Usabilidade	Fluxo Completo (Uso Real)	APK instalado no dispositivo, conta de teste criada	Usuário consegue redefinir a senha e navegar sem dificuldades, conforme esperado	Teste executado com sucesso dia 30/06/2025 (vídeo anexado - https://youtu.be/ChI2nIlxacg)	Não houve	1

Fonte: Os autores¶

7.REFERÊNCIAS BIBLIOGRÁFICAS¶

BECK, Kent. Extreme Programming Explained: Embrace Change. 2. ed. Boston: Addison-Wesley, 2004. Disponível em: https://ptgmedia.pearsoncmg.com/images/9780321278654/samplepages/9780321278654.pdf. Acesso em: 29 de jun. 2025.

IBGE. Censo 2022: taxa de analfabetismo cai de 9,6% para 7,0% em 12 anos, mas desigualdades persistem. Agência de Notícias IBGE, Rio de Janeiro, 17 maio 2024. Disponível em: https://agenciadenoticias.ibge.gov.br/agencia-noticias/2012-agencia-de-noticias/noticias/40098-censo-2022-taxa-de-analfabetismo-cai-de-9-6-para-7-0-em-12-anos-mas-desigualdades-persistem. Acesso em: 15 abr. 2025

MANIFESTO ÁGIL. Princípios do Manifesto Ágil. Disponível em: https://agilemanifesto.org/iso/ptbr/principles.html. Acesso em: 28 jun. 2025.

OCDE. Resultados do PISA 2022: O desempenho dos estudantes em matemática, leitura e ciências. Paris: Organização para a Cooperação e Desenvolvimento Econômico, 2023. Disponível em: https://www.oecd.org/pisa/. Acesso em: 22 jun. 2025.

ONU. Objetivos de Desenvolvimento Sustentável. 2015. Disponível em: https://brasil.un.org/pt-br/sdgs. Acesso em: 22 jun. 2025.

SCRUM GUIDE. Metodologias de desenvolvimento Scrum. Disponível em: https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf. Acesso em: 29 jun. 2025.

TOKARNIA, Mariana. Resultados do Pisa reforçam gargalo no ensino de matemática no Brasil. Agência Brasil, Rio de Janeiro, 5 dez. 2023. Disponível em: https://agenciabrasil.ebc.com.br/educacao/noticia/2023-12/resultados-do-pisa-reforcam-gargalo-no-ensino-de-matematica-no-brasil. Acesso em: 15 abr. 2025.

UNESCO – UIS. Definitions of adult functional literacy and numeracy for SDG indicator 4.6.1. Montreal: UNESCO Institute for Statistics, 2019. Disponível em: http://gaml.uis.unesco.org/wp-content/uploads/sites/2/2019/05/GAML6-WD-4-Definitions-of-adult-functional-literacy-and-numeracy-for-SDG-indcator-4.6.1-1.pdf. Acesso em: 22 jun. 2025.