Descrição Completa – Desafio 2020

Neste post iremos apresentar o cronograma completo do Desafio 2020, bem como descrever o problema da ONG Matemática em Movimento e incluir algumas explicações gerais sobre o Desafio. O início oficial se deu no dia 31/08/2020 com a divulgação deste post.

Cronograma Geral

Seguem abaixo as datas do Desafio 2020:

  • Início do Desafio em 31/08/2020 com a divulgação completa do problema;
  • Os check-points serão realizados via live no Youtube em 01/09, 08/09, 17/09 e 22/09 às 18hrs. Não é obrigatório a presença dos grupos nos check-points;
  • Enviaremos por e-mail o link para a live minutos antes de iniciarmos cada uma;
  • Todas as perguntas podem ser feitas no Fale Conosco do Site do Desafio ou através do e-mail desafiounisoma@unisoma.com.br. Responderemos as perguntas entre 24 e 48 horas. No dia seguinte do Checkpoint, colocaremos no site do Desafio um post com um compilado das perguntas da semana dos grupos;
  • Cabe destacar que alguma eventual demanda pode ser solicitada pelo Cliente no decorrer do Desafio como, por exemplo, relatórios ou algo relacionado à usabilidade. Todas as informações serão previamente colocadas no site do Desafio;
  • Todas as duplas devem entregar até as 23h59 do dia 27/09/2020 um relatório contendo no máximo 5 (cinco) páginas. Para as duplas de desenvolvimento do modelo, o relatório deve conter a descrição da modelagem e da solução encontrada. Para as duplas de desenvolvimento web o relatório deve conter a descrição das páginas e funcionalidades e das soluções encontradas. Todas as duplas devem enviar também o programa contendo o modelo, as soluções e a especificação de tudo que foi utilizado como, por exemplo, as versões das linguagens. O e-mail para entrega do relatório e solução é desafiounisoma@unisoma.com.br;
  • No dia 14/10/2020 será divulgado no site do Desafio as duplas, de ambas as frentes de desenvolvimento, selecionadas para a fase final;
  • No dia 17/10/2020, no período da manhã, ocorrerá um encontro online com as duplas finalistas, as quais iniciarão a fase final do Desafio e terão como objetivo conectar as soluções desenvolvidas pelas frentes de modelo e web.
  • No dia 31/10/2020, no período da manhã, ocorrerá a final do Desafio e os grupos farão a apresentação da solução e do sistema de forma online em uma plataforma ainda a ser divulgada;
  • Todas as informações sobre horário e cronograma da Final serão previamente colocadas no site do Desafio.

Sobre a ONG

A Matemática em Movimento surgiu em 2011 com o intuito de fazer a diferença no ensino de matemática no país. São realizadas aulas aos sábados para alunos do Ensino Médio Público de São Paulo indo além da matemática, como por exemplo, trabalhos envolvendo o raciocínio, passeios, investimento em talentos e sonhos. Com seis anos de existência, Matemática em Movimento já ajudou mais de 200 alunos e conta com cerca de 100 voluntários.

Com o sistema que será desenvolvido durante o Desafio UniSoma 2020 por nós da UniSoma, voluntários da Matemática em Movimento e vocês, alunos de graduação e pós-graduação do Brasil, ajudaremos a ONG alavancar seus atendimentos a partir da melhor solução!

 

Descrição do Problema

A ONG Matemática em Movimento oferece aulas de matemática para alunos de 9º ano do Ensino Fundamental e 1º, 2º e 3º anos do Ensino Médio em escolas de São Paulo. Para isso, ela realiza o planejamento das turmas de acordo com a demanda de alunos e verba.

O Desafio desse ano é criar uma ferramenta que maximize a alocação de alunos por turma, priorizando alunos já matriculados, seguidos dos candidatos por ordem de inscrição. O sistema deverá também estar habilitado a sugerir novas turmas, quando possível, de acordo com a demanda e verba.

Como a ONG dá prioridade para os alunos que já estão matriculados, eles devem ser obrigatoriamente alocados em alguma turma. Além disso, devem se manter na mesma turma que seus colegas da turma anterior, exceto quando são reprovados. Nesse caso, os alunos se mantém na mesma série. Caso o aluno esteja matriculado, mas não continue na ONG, ele deve ser desconsiderado do planejamento.

Já os candidatos de formulário, durante sua inscrição, selecionam qual escola desejam ter aula. Sua série deve ser calculada a partir do ano de referência que consta no próprio formulário. A prioridade de convocação desses candidatos se dá pela ordem de inscrição.  

As turmas têm um número máximo de alunos, porém não há um mínimo. Cada turma também tem um número fixo de professores voluntários, divididos entre pedagógico e ACD (Atividades de Cultura e Desenvolvimento). O custo da turma é computado a partir do custo por aluno e do custo por voluntário, e não deve ultrapassar o limite estipulado pela ONG. 

Ao sugerir turmas novas, a prioridade é escolher turmas com maior quantidade de alunos. Como critério de desempate, podem ser priorizadas turmas mais novas (turmas de 9º ano antes de turmas de 1º ano, por exemplo). Além disso, só podem ser criadas turmas de séries oferecidas pela ONG.

Esse planejamento pode ser realizado de um ano para o outro ou dentro do mesmo ano. Caso seja dentro do mesmo ano, a turma dos alunos já matriculados não muda, exceto quando há necessidade de juntar duas turmas. Se houver demanda, também podem ser criadas novas turmas, mesmo que dentro do mesmo ano.

Ao finalizar o planejamento, a ONG entra em contato com todos os candidatos de formulário selecionados e confirma a participação dos mesmos. Caso algum desses candidatos desista, uma readequação precisa ser feita para que essas vagas sejam ocupadas pelos candidatos que continuam na lista de espera.

O arquivo .xlsx que contém os dados de entrada para a ferramenta e está disponibilizado no Site do Desafio possui a seguinte estrutura (para acessar clique aqui):

Informações de Entrada

  • Parâmetros:
    • Ano do planejamento
    • Otimiza dentro do ano?
    • Possibilita abertura de novas turmas?
    • Limite de custo
    • Custo por aluno
    • Custo por professor
    • Quantidade máxima de alunos por sala (padrão)
    • Quantidade de professores pedagógicos (padrão)
    • Quantidade de professores ACD (padrão)
  • Regiões:
    • Código da região
  • Escolas:
    • Nome da escola
    • Código da região
  • Séries:
    • Descrição da série
    • Ordem
    • Ativa
  • Status:
    • Mensagem (VAI PARTICIPAR/NÃO VAI PARTICIPAR/NÃO SABE)
  • Turmas:
    • Código da turma
    • Nome da escola
    • Descrição da série
    • Quantidade máxima de alunos
    • Quantidade de professores pedagógicos
    • Quantidade de professores ACD
  • Formulário de Inscrição:
    • Nome do aluno
    • CPF do aluno
    • Data e hora da inscrição
    • Descrição da série
    • Ano de referência da série
    • E-mail do aluno
    • Telefone do aluno
    • Nome do responsável
    • Telefone do responsável
    • Nome da escola que pretende estudar
    • Nome da escola de origem
  • Cadastro de Alunos:
    • Nome do aluno
    • CPF do aluno
    • Código da turma
    • Telefone do aluno
    • E-mail do aluno
    • Nome do responsável
    • Telefone do responsável
    • Nome da escola de origem
    • Continua?
    • Reprova?

Informações de Saída

  • Priorização de candidatos do formulário de inscrição:
    • Nome do aluno
    • CPF do aluno
    • Telefone do aluno
    • E-mail do aluno
    • Nome do responsável
    • Telefone do responsável
    • Descrição da série do aluno
    • Nome da escola em que quer ter aula
    • Nome da escola de origem
    • Código da turma em que irá estudar
    • Status (VAI PARTICIPAR/NÃO VAI PARTICIPAR/NÃO SABE)
  • Lista de alunos de continuidade:
    • Nome do aluno
    • CPF do aluno
    • Telefone do aluno
    • E-mail do aluno
    • Nome do responsável
    • Telefone do responsável
    • Nome da escola de origem
    • Código da turma que irá cursar
  • Lista de turmas:
    • Código da turma
    • Nome da escola
    • Descrição da série
    • Quantidade máxima de alunos
    • Quantidade de professores pedagógicos
    • Quantidade de professores ACD
    • Aprova?

O banco SQLite onde os dados de entrada devem ser persistidos pode ser acessado aqui. Vale lembrar que esse banco pode ser modificado, desde que a estrutura básica já fornecida seja mantida.

Produto Esperado 

A aplicação Web desenvolvida pelos participantes deve receber como entrada um arquivo no formato especificado acima e persistir esses dados de entrada em um banco SQLite, também já disponibilizado. A cada nova importação de dados a ferramenta deve apagar todos os dados da rodada anterior.

Esses dados de entrada devem ser validados pela aplicação e inconsistências de alerta e erro devem ser geradas, caso necessário. Ao final da importação dos dados, a aplicação deve mostrar uma tela com essas informações e, se houver erros, o usuário não poderá executar a otimização antes de corrigi-los. No caso de haver somente alertas, ele pode optar por executar a otimização mesmo antes de corrigi-los.

Abaixo, estão descritos alguns exemplos de inconsistências que devem ser tratadas pela ferramenta:

  • Alerta: CPFs duplicados nos dados dos candidatos no formulário de entrada;
  • Erro: o dado de um mesmo aluno não pode estar na tabela de formulário de inscrição e na tabela de alunos ao mesmo tempo;
  • Erro: os dados de entrada não podem vir com colunas/tabelas obrigatórias vazias;
  • Erro: os dados de entrada não podem vir fora do padrão ou com erro de digitação. Nesse caso, se for possível, a aplicação deve tratar esses erros ou mostrá-los como inconsistência.

Após a importação dos dados e tratamento das inconsistências, a aplicação Web deve chamar o script do modelo matemático, passando como parâmetro o endereço do banco SQLite.

O modelo matemático deve ler os dados de entrada do banco SQLite, resolver o problema relacionado a maximização da alocação de alunos por turma e escrever as respostas nas tabelas de solução criadas no banco SQLite disponibilizado. 

As tabelas de solução devem mostrar a alocação de alunos já matriculados e a priorização de candidatos de formulário, além da informação das turmas sugeridas pela solução e turmas pré-existentes (ambas somente nos casos em que há algum aluno alocado). As turmas pré-existentes devem ser marcadas como aprovadas por padrão.

Dessa forma, como a saída do modelo matemático é uma sugestão, a aplicação Web deve exibir uma tela onde a ONG pode aprovar ou não as turmas sugeridas e, caso uma turma sugerida não seja aprovada, esse registro deve ser apagado do banco. As turmas sugeridas aprovadas devem ser criadas na tabela de entrada.

No caso dos candidatos de formulário, deve ser exibido uma lista de candidatos em ordem de prioridade a serem convocados e suas respectivas turmas, onde a ONG pode atualizar o status desses candidatos (VAI PARTICIPAR/NÃO VAI PARTICIPAR/NÃO SABE) após entrar em contato com os mesmos. Ao atualizar o status de todos os candidatos, a aplicação Web deve:

  • Criar um registro na tabela de alunos para os candidatos que vão participar e remover esses registros do formulário de inscrição;
  • Remover os candidatos que não vão participar do formulário de inscrição;
  • Manter os candidatos que não sabem no formulário de inscrição.

Para os alunos já matriculados, deve ser exibida uma lista desses alunos e suas respectivas turmas. A aplicação Web deve atualizar a coluna de turma na tabela de aluno com a informação de turma dada pela solução do modelo matemático. 

Após as atualizações, a aplicação Web deve exportar todas as tabelas de entrada atualizadas no formato .xlsx, permitindo que o usuário importe esses dados na ferramenta novamente (mantendo o mesmo formato de entrada). Esse requisito de saída é obrigatório.

Além disso, é interessante que sejam criadas outras telas de relatório, a critério de cada grupo. Aqui, vale a criatividade para mostrar o potencial da ferramenta!

A metodologia para a resolução do problema é de escolha dos grupos, ou seja, o modelo ou técnica escolhida. A solução do modelo matemático deve ser implementada em Python ou R e a aplicação Web deve ser desenvolvida usando Java. Para o desenvolvimento das telas os alunos podem utilizar algumas ou todas das seguintes tecnologias: HTML5, CSS, JavaScript, JQuery e Angular.

Avaliação

Os grupos que cumprirem todas as normas descritas no Site do Desafio serão avaliados pela banca examinadora, escolhida a livre critério da UniSoma.

Serão avaliados pela banca examinadora itens como:

  1. a solução apresentada,
  2. interação do grupo com a UniSoma e a ONG parceira,
  3. os resultados e relatórios, 
  4. arquitetura e implementação da solução, 
  5. interface (facilidade de uso),
  6. apresentação e 
  7. comunicação.

Cada membro da banca examinadora atribuirá uma nota a cada item avaliado, podendo considerar o conjunto do trabalho avaliado. Cabe destacar que o peso para cada quesito da avaliação é o mesmo.

 

OBS: Caso algum grupo deseje utilizar a formulação do problema proposto do Desafio para a publicação de algum artigo, trabalho, notícia ou demais conteúdos é permitido, contudo é necessário notificar a organização do Desafio e realizar as devidas citações do Desafio UniSoma e da ONG parceira.