Sistema de Controle de Fluxo na Cozinha
Senhas digitais e controle de fila com micro:bit + Painel Scratch — 8.º Ano EF II
Ficha Técnica do Projeto
| Campo | Descrição |
|---|---|
| Problema central | Filas longas e desorganização no horário de alimentação escolar: alunos se empurram, professores perdem tempo gerenciando a fila, pessoas com necessidades especiais não têm prioridade garantida |
| Produto final | Sistema de chamada por senha digital: micro:bit emite e exibe senhas (botões A/B + display), painel visual em Scratch exibe a senha atual chamada em tela grande + manual técnico de operação |
| Abordagem pedagógica | ABP com simulação interna (laboratório) e teste real em ambiente controlado (refeitório/fila da escola) |
| Hardware principal | Micro:bit v1/v2 — botão A (avançar senha), botão B (resetar/zerar), display LED 5×5 (exibir número atual) |
| Software | MakeCode (blocos) — lógica do micro:bit; Scratch — painel visual de chamada em tela do computador/projetor |
| Carga horária | 2 dias/semana (segunda e terça) · 2 aulas de 45 min por dia = 4 aulas/semana × 10 semanas = 40 aulas |
| Entregáveis avaliáveis | Diário de bordo (por grupo), código .hex do micro:bit, projeto Scratch do painel, manual técnico ilustrado, relatório de teste real, post no blog |
| Impacto esperado | Sistema funcional testado na fila do refeitório; manual entregue à gestão para possível adoção permanente |
Arquitetura Técnica do Sistema (para o professor)
Como o sistema funciona — visão geral
O sistema é composto por dois elementos que funcionam de forma integrada:
| Elemento | Função | Programado em | Como funciona |
|---|---|---|---|
| Micro:bit — Controlador de Senhas | Emite e controla as senhas | MakeCode (blocos) | Botão A → contador +1, exibe número no display LED. Botão B → reseta o contador para 0. Variável “senha_atual” começa em 0 e vai até 99. |
| Scratch — Painel Visual | Mostra a senha chamada em tela grande | Scratch (eventos + variáveis) | Operador humano digita a senha chamada no Scratch; painel exibe em fonte grande com animação simples. Versão avançada: comunicação via serial USB entre micro:bit e Scratch. |
| Senhas impressas (fichas) | Entregues às pessoas na fila | Impressora / papel cortado | Fichas numeradas (1 a 50) impressas ou escritas à mão. Cada pessoa recebe uma ficha ao chegar. O micro:bit chama as senhas em ordem. |
Lógica do micro:bit (MakeCode — blocos)
- Variável:
senha_atual = 0 - Ao iniciar: mostrar “0” no display
- Botão A pressionado: senha_atual = senha_atual + 1
- Mostrar número (senha_atual) no display
- Botão B pressionado: senha_atual = 0
- Mostrar “0” (reinício do sistema)
- Opcional: tocar nota quando muda a senha
Lógica do painel Scratch
- Fundo colorido (verde = chamando, vermelho = pausa)
- Texto grande centralizado: “Senha: XX”
- Tecla ESPAÇO ou clique → atualiza o número
- Variável “senha_chamada” visível na tela
- Opcional: som de chamada ao mudar a senha
- Versão simples: operador digita o número manualmente
- Versão avançada: leitura automática via porta serial
Cronograma Geral — 10 Semanas
| Semana | Segunda (aulas 1–2) |
Terça (aulas 3–4) |
Fase |
|---|---|---|---|
| Semana 1 | Vivência do problema: fila real e caos | Apresentação do projeto + grupos | Fase 0 — Ambientação |
| Semana 2 | Mapeamento da fila: observação e entrevistas | Persona e declaração do problema | Fase 1 — Empatia |
| Semana 3 | Brainstorming e desenho do sistema | Divisão do sistema em partes + Kanban | Fase 2 — Ideação |
| Semana 4 | Micro:bit: variáveis e botões (MakeCode) | Primeiro contador funcional no display | Fase 3 — Prototipagem |
| Semana 5 | Painel Scratch: tela de chamada básica | Integrar micro:bit + Scratch (operador humano) | Fase 3 — Prototipagem |
| Semana 6 | Fichas de senha + suporte físico do micro:bit | Revisão e checklist do protótipo completo | Fase 3 — Prototipagem |
| Semana 7 | Simulação interna no laboratório (turma faz fila) | Registro de problemas + 1.ª iteração | Fase 4 — Simulação e Testes |
| Semana 8 | Teste real no refeitório (ambiente controlado) | Análise dos dados + 2.ª iteração do código | Fase 4 — Simulação e Testes |
| Semana 9 | Redação do manual técnico (estrutura + rascunho) | Finalização do manual + relatório de teste | Fase 5 — Manual e Documentação |
| Semana 10 | Ensaio da apresentação | Apresentação para a escola + blog | Fase 6 — Apresentação |
Recursos Necessários
Hardware obrigatório
- Micro:bit v1 ou v2 (1 por grupo de 3 alunos)
- Cabo USB para programação e energia
- Computador com navegador (Chrome ou Edge)
- Projetor ou tela grande (para o painel Scratch)
- Impressora (fichas de senha numeradas)
- Impressora 3D (suporte/caixa do micro:bit — opcional)
Software / plataformas
- MakeCode (makecode.microbit.org) — sem instalação
- Scratch (scratch.mit.edu) — sem instalação
- Tinkercad — design 3D do suporte (opcional)
- Google Docs — redação do manual técnico
- Google Planilhas — registro de testes
- Blog (professorcomia.com.br) — publicação
Materiais físicos
- Papel A4 para fichas de senha (cortadas em tiras)
- Papel A3 para sketches e mapas
- Post-its coloridos (ideação)
- Caneta permanente, tesoura, fita adesiva
- Papelão ou caixinha para suporte do micro:bit
- Pasta física (diário de bordo por grupo)
Infraestrutura disponível
- Laboratório de Educação Digital
- 6 mesas coloridas (grupos de 2–3 alunos)
- Wi-Fi de boa qualidade
- Kit ATTO e Arduino Uno (referência técnica)
- Impressora 3D (suporte físico)
Documentos do professor
- Ficha do diário de bordo (template impresso)
- Roteiro de observação da fila (Fase 1)
- Checklist do protótipo completo
- Template do manual técnico
- Ficha de registro de testes (Fase 4)
- Rubrica de avaliação processual
Parcerias necessárias
- Direção/coordenação (autorização para teste no refeitório)
- Funcionário da cozinha/limpeza (parceiro do teste)
- Professor do horário do refeitório (colaboração)
- Eventual: merendeira como usuária-piloto
Sequência Detalhada — Passo a Passo
Fase 0 — Sensibilização e Contrato Pedagógico
-
Aula 1 — Vivência do caos: a fila como problema (45 min)
Comece com uma pergunta simples escrita no quadro: “O que vocês sentem quando estão na fila do refeitório?” Deixe que falem livremente por 5 minutos. Não corrija, não avalie. Anote as palavras no quadro. Provavelmente vão aparecer: raiva, empurra, demora, bagunça, injusto.
Em seguida, proponha uma simulação rápida (10 min) dentro da sala: todos se levantam e tentam chegar ao fundo da sala “buscar o almoço” sem regra nenhuma. Observe o que acontece. Depois pergunte: “O que deu errado? O que poderia organizar isso melhor?”
Apresente o desafio do projeto: “Vamos construir um sistema de senhas digitais — como em banco, em farmácia — para organizar a fila do refeitório da nossa escola.”
45 min · toda a turma Foto das palavras escritas no quadro. Anotação das falas mais significativas dos alunos no caderno do professor. Publicar no blog: “O problema que vamos resolver” — com texto breve e foto. -
Aula 2 — Sistemas de senha no mundo real (45 min)
Mostre imagens ou vídeo curto (3–4 min) de sistemas de senha em banco, cartório, UPA, farmácia. Pergunte: “Onde mais vocês já viram isso?” Discutam coletivamente. Mostre o micro:bit fisicamente e diga: “Com esse dispositivo, programado por vocês, vamos fazer algo parecido para a nossa escola.”
Apresente também uma ficha de senha impressa simples. “Essa é a senha número 7. Quando o micro:bit chamar a senha 7, é a vez dessa pessoa.” Deixe os alunos segurar o micro:bit. Não programe ainda — apenas explorem fisicamente.
45 min · toda a turma Foto dos alunos explorando o micro:bit. Registro escrito: “Antes de hoje eu achava que micro:bit servia para…” (frase incompleta — cada aluno escreve no diário). -
Aula 3 — Formação de grupos e papéis (45 min)
Forme os grupos (3 alunos cada = 5 grupos). Critério de formação: misturar perfis — um aluno com mais facilidade em leitura/escrita, um com mais facilidade com tecnologia, um com habilidade manual ou de comunicação. O professor decide os grupos, não os alunos (para evitar exclusões).
Cada grupo escolhe um nome de time e recebe a pasta do diário de bordo. Apresente os três papéis rotativos (mudam a cada semana): Registrador (escreve, fotografa), Programador (opera computador e micro:bit), Testador (testa o sistema e anota o que funcionou e o que não funcionou).
45 min Tabela de grupos no mural do laboratório (fotografada). Papel de cada integrante na semana 1 anotado na capa do diário. -
Aula 4 — O que sabemos? O que precisamos aprender? (45 min)
Cada grupo recebe um papel A3 dividido em 3 colunas: Já sabemos, Precisamos aprender, Quem pode ajudar. Preencher em 15 min. Apresentar para a turma (2 min por grupo). O professor anota no quadro os gaps mais citados.
Encerrar com o Contrato de Equipe: cada grupo define 3 combinados internos e 1 compromisso com a turma. Assinar e colar no diário.
45 min Foto do A3 de cada grupo. Contrato de equipe assinado e colado no diário. Esse A3 será revisitado na Fase 6 para avaliar o que foi aprendido.
Fase 1 — Empatia e Definição do Problema
-
Aula 5 — Observação de campo: a fila real (45 min)
Cada grupo recebe um Roteiro de Observação impresso com 5 perguntas: (1) Quantas pessoas estão na fila? (2) Quanto tempo a fila demora para andar? (cronometrar 5 min) (3) Tem alguém que passa na frente? (4) Alguém parece irritado ou frustrado? (5) Como a merendeira organiza quem atende primeiro?
Os grupos vão ao refeitório em horários diferentes (combinado com a direção), observam por 10 minutos e retornam. Tempo de observação: 10 min. Tempo de registro e discussão no laboratório: 30 min. Regra combinada antes de sair: não interferir, não conversar em voz alta, não comer.
45 min · campo + laboratório Roteiro de observação preenchido por cada grupo. Foto discreta do ambiente (não de pessoas). Anotação no diário: 3 coisas que chamaram atenção. -
Aula 6 — Entrevistas rápidas com usuários do sistema (45 min)
Cada grupo entrevista 2 pessoas usando um roteiro de 4 perguntas simples (impresso): (1) A fila do refeitório te atrapalha? Como? (2) Tem algum horário que é pior? (3) O que você já tentou fazer para resolver? (4) Se você pudesse mudar uma coisa, o que seria?
Entrevistar: 1 funcionário da escola (merendeira, agente, professor) + 1 aluno de outra turma. Duração: 5 min por entrevista. O Registrador anota. Retornam ao laboratório para organizar as respostas em post-its.
45 min · entrevistas + síntese Folha de entrevista preenchida (nome ou apelido do entrevistado, cargo, respostas). Post-its organizados no A3 por tema. Foto do painel de post-its. -
Aula 7 — Persona: para quem estamos resolvendo? (45 min)
Cada grupo cria uma persona simples em cartolina: nome fictício, papel na escola, problema principal com a fila, o que a persona precisa. Exemplo de persona: “Dona Cida, merendeira, 45 anos. Fica nervosa quando a fila não tem ordem e as crianças brigam. Precisa de um sistema que ela consiga operar sozinha, sem computador na mão.”
Os cartazes ficam expostos no mural. O professor facilita discussão: “Quais problemas são comuns a todas as personas? Qual é o mais importante resolver?”
45 min Cartaz da persona fotografado e colado no diário. Ponto de vista do problema definido coletivamente e escrito em cartaz central: “Nosso sistema precisa resolver [problema] para [persona] porque [insight].” -
Aula 8 — Declaração formal do problema e restrições técnicas (45 min)
Cada grupo redige a Declaração do Problema em 2–3 frases. A turma vota na declaração mais clara e completa. Essa declaração fica no centro do mural e guia todas as decisões do projeto.
O professor apresenta as restrições técnicas de forma simples: “O sistema que vamos fazer tem três partes: (1) o micro:bit que controla as senhas com botões; (2) uma tela no Scratch que mostra qual senha foi chamada; (3) fichas de papel que as pessoas pegam na fila. Vocês vão construir isso.”
45 min Declaração do problema escrita em cartaz central. Foto. Registrada no diário de bordo de cada grupo. O professor registra quais grupos têm clareza do problema e quais precisam de suporte.
Fase 2 — Ideação e Planejamento do Sistema
-
Aula 9 — Brainstorming: como poderia funcionar o sistema? (45 min)
Regra: toda ideia vale, sem crítica agora. Cada aluno escreve em post-its separados ideias de como o sistema poderia funcionar (display, voz, semáforo, cartões, ficha física, QR code, etc.). Tempo: 10 min. Depois, colam no A3 e o grupo organiza por categoria.
O professor mostra imagens de sistemas de senha reais (UPA, banco, farmácia popular). Orienta: “Não copiar — se inspirar. O que desses exemplos podemos adaptar com o que temos aqui no laboratório?”
45 min Foto do painel de post-its de cada grupo. Registrar no diário: 3 ideias favoritas e por que as escolheram. -
Aula 10 — Escolha da solução e divisão do sistema em partes (45 min)
Cada grupo define a solução: o sistema com micro:bit + Scratch + fichas físicas. Em seguida, divide o sistema em 3 partes independentes que podem ser desenvolvidas em paralelo: Parte A (micro:bit — contador de senhas), Parte B (Scratch — painel visual), Parte C (fichas físicas + suporte do dispositivo).
Dentro do grupo, definir quem cuida de cada parte (pode ser rodízio, mas começa com um responsável por parte). Isso antecipa a divisão técnica da Fase 3.
45 min Divisão das partes registrada no diário. Cada parte tem: nome da parte, responsável inicial, o que vai fazer. Foto da divisão. -
Aula 11 — Sketch do sistema e fluxo lógico em linguagem natural (45 min)
Cada grupo faz um sketch à mão do sistema completo: como será a tela do Scratch, como será o display do micro:bit, como é a ficha física, onde cada elemento fica durante o uso real. Em paralelo: escrever o fluxo lógico em linguagem natural, passo a passo:
“1. A pessoa chega e pega a ficha 12. 2. O operador pressiona o botão A do micro:bit. 3. O display mostra o número 12. 4. O operador digita 12 no Scratch. 5. A tela grande mostra ‘Senha 12’. 6. A pessoa com a ficha 12 vai ao balcão.”
45 min Sketch fotografado. Fluxo lógico escrito em linguagem natural no diário de bordo. Esses documentos são referência direta para a programação na Fase 3. -
Aula 12 — Kanban do projeto (45 min)
Cada grupo cria um mini Kanban em papel A3: colunas “A fazer”, “Fazendo”, “Feito”. Lista as tarefas das próximas 3 semanas (Fase 3). Define quem faz o quê, em qual aula, com qual entregável ao final.
O professor revisa cada Kanban e faz perguntas orientadoras: “Essa tarefa está grande demais para uma aula? Divida em duas.” “Essa tarefa depende de outra — qual vem primeiro?” Nenhum grupo começa a próxima fase sem o Kanban validado.
45 min Foto do Kanban de cada grupo. Colado na pasta do diário. O professor anota no caderno os riscos identificados por grupo.
Fase 3 — Prototipagem: Micro:bit + Scratch + Fichas Físicas
Semana 4 — Parte A: Micro:bit como contador de senhas
-
Aula 13 — O que é uma variável? Contador no micro:bit (45 min)
Analogia concreta antes do código: “Variável é como uma caixinha com um número dentro. A gente pode mudar o número. No nosso sistema, a caixinha se chama ‘senha’ e começa com o número 0.”
No MakeCode: criar variável
45 min Screenshot do código. Foto do display do micro:bit mostrando um número. Registrar no diário: “O que a variável faz?” (resposta em 1 frase, com palavras do aluno).senha_atual. Bloco “ao iniciar” → definirsenha_atualcomo 0 → mostrar número. Bloco “ao pressionar botão A” → mudarsenha_atualem 1 → mostrar número. Testar no micro:bit físico. Todo o grupo deve pressionar o botão ao menos uma vez e ver o número mudar. -
Aula 14 — Adicionar reset e limite de senhas (45 min)
Apresentar o botão B: “Botão B vai zerar o sistema — como quando a fila termina e recomeça amanhã.” Bloco “ao pressionar botão B” → definir
senha_atualcomo 0 → mostrar número → mostrar ícone de “check” (indicando reset).Desafio opcional para grupos avançados: fazer o sistema tocar uma nota quando a senha muda. Desafio básico obrigatório: fazer o micro:bit mostrar “FIM” quando a senha chegar a 50 (usando bloco condicional: se
45 min Screenshot do código com botão B e limite. Arquivo .hex salvo no Drive como “senha_microbit_v1.0_[grupo]”. Teste documentado: pressionou A 5 vezes e B — funcionou?senha_atual= 50 → mostrar “FIM”).
Semana 5 — Parte B: Painel Scratch + integração manual
-
Aula 15 — Painel visual no Scratch: tela de chamada (45 min)
No Scratch: criar um projeto novo. Fundo colorido (verde). Adicionar um Sprite de texto grande centralizado. Criar variável
senha_chamada. Configurar para exibir: “SENHA: ” + variável na tela. O operador usa tecla ESPAÇO para atualizar ou clica em botão on-screen.Versão simples (obrigatória): operador digita o número no Scratch quando o micro:bit muda. Isso replica o fluxo real: uma pessoa opera o micro:bit (chama a senha), outra atualiza o painel. Isso é exatamente como funciona em sistemas reais com 2 operadores.
45 min Screenshot do projeto Scratch. Foto da tela exibindo “SENHA: 5” em fonte grande. Registrar: o que o painel mostra? O tamanho do texto está visível a 3 metros? -
Aula 16 — Integração sistema completo: simulação em dupla (45 min)
Simulação com divisão de papéis dentro do grupo: 1 aluno opera o micro:bit (pressiona o botão A), 1 aluno opera o Scratch (atualiza o número na tela), 1 aluno é o “cliente” (recebe a ficha e vai ao “balcão” quando seu número é chamado).
Rodar a simulação 3 vezes com papéis diferentes. Anotar o que funcionou e o que não funcionou. Perguntas orientadoras: “O painel está grande o suficiente para ser lido de longe? A pessoa sabe quando é sua vez?”
45 min Ficha de teste de integração: o que funcionou (✓), o que não funcionou (✗), o que precisa melhorar. Foto da simulação em andamento.
Semana 6 — Parte C: Fichas físicas, suporte e revisão do sistema completo
-
Aula 17 — Fichas de senha e suporte físico do micro:bit (45 min)
Fichas de senha: Cada grupo projeta e imprime (ou escreve à mão) as fichas numeradas de 1 a 50. Formato sugerido: papel A4 cortado em 4 tiras, cada tira com número grande, nome da escola e instrução simples: “Aguarde ser chamado pelo painel.” Plastificar se possível.
Suporte do micro:bit: Projetar no Tinkercad (grupos avançados) ou montar em papelão (todos os grupos) uma caixinha que posicione o micro:bit em local visível ao operador. O display precisa ser legível e os botões A/B acessíveis sem segurar o dispositivo.
45 min Foto das fichas prontas. Foto do suporte físico montado. Registrar no diário: quantas fichas foram feitas, material utilizado, quem fez o quê. -
Aula 18 — Checklist do protótipo completo e validação (45 min)
O professor aplica o checklist técnico em cada grupo. Grupos que passam estão prontos para a simulação da Fase 4. Grupos com pendências têm a 1.ª aula da Semana 7 para resolver antes de simular.
45 min Checklist preenchido e assinado pelo professor. Código .hex versão final salvo. Projeto Scratch salvo e link registrado no diário. Foto do sistema completo montado (micro:bit + tela Scratch + fichas).Checklist técnico — micro:bit
- Botão A avança a senha (+1)?
- Display mostra o número atual?
- Botão B reseta para 0?
- Código salvo como .hex no Drive?
- Suporte físico está estável?
- Botões A e B acessíveis ao operador?
Checklist técnico — Scratch + fichas
- Painel exibe senha em fonte legível a 3m?
- Operador consegue atualizar o número?
- Fundo colorido visível (verde/vermelho)?
- Projeto Scratch salvo na conta?
- Fichas numeradas de 1 a 50 prontas?
- Fluxo testado em dupla sem erros críticos?
Fase 4 — Simulação, Teste Real e Iteração
Semana 7 — Simulação interna no laboratório
-
Aula 19 — Simulação com a própria turma fazendo fila (45 min)
Reorganizar o laboratório: mesas no fundo = “refeitório”, porta = “entrada da fila”. 1 grupo opera o sistema completo (micro:bit + Scratch). Os outros 12 alunos são os “usuários” — cada um pega uma ficha numerada e espera ser chamado pelo painel.
Rodar a simulação com 10 fichas. Cronometrar o tempo de cada chamada. Anotar problemas observados. Após a simulação: feedback coletivo de 15 min. Cada usuário responde 3 perguntas: (1) Você entendeu quando era sua vez? (2) O painel estava visível? (3) O que poderia ser diferente?
45 min · simulação + feedback Ficha de Registro da Simulação: problema observado | gravidade (alto/médio/baixo) | possível solução. Tempo médio por chamada cronometrado. Foto ou vídeo curto (30 seg) da simulação. -
Aula 20 — Análise dos problemas e 1.ª iteração (45 min)
Cada grupo analisa a ficha de problemas da simulação. Selecionar os 2 problemas mais graves para corrigir imediatamente. Exemplos comuns que vão surgir: “o número no display está pequeno” (solução: usar ícone maior), “o Scratch travou” (solução: simplificar o código), “ninguém olhava para a tela” (solução: mudar a posição do computador).
Corrigir o código e/ou o setup físico nesta aula. Salvar nova versão:
45 min Tabela comparativa: problema | solução aplicada | resultado esperado. Screenshot do código v2.0. Versão salva no Drive com nome padronizado.senha_microbit_v2.0e projeto Scratch v2.
Semana 8 — Teste real no ambiente do refeitório
-
Aula 21 — Preparação e protocolo do teste real (45 min)
Combinado com a direção: o grupo vai ao refeitório durante 1 horário de alimentação real (ou uma simulação com outra turma). Definir o protocolo: quem distribui as fichas, quem opera o micro:bit, quem opera o Scratch, quem anota problemas, quem cronometra. Cada integrante sabe exatamente o que faz antes de sair.
Preparar o material: micro:bit carregado, laptop com Scratch aberto, fichas impressas, ficha de registro de teste. Ensaio final de 10 min antes de ir.
45 min · preparação + ensaio Protocolo de teste escrito (quem faz o quê). Material checado e fotografado antes de sair. Autorização da direção registrada no diário. -
Aula 22 — Teste real no refeitório (45 min)
O grupo opera o sistema em ambiente real durante aproximadamente 20 minutos. O professor acompanha. Os outros grupos do projeto observam de forma discreta e anotam o que observam. Após o teste: retorno ao laboratório para debriefing imediato de 15 min. “O que funcionou? O que não funcionou? O que surpreendeu?”
Coletar: tempo médio de atendimento por senha, número de pessoas atendidas, ocorrências (confusão, sistema travou, ficha errada, etc.).
20 min no refeitório + 20 min debriefing Ficha de Teste Real preenchida: total de senhas chamadas, tempo médio por chamada, ocorrências, avaliação geral (1 a 5). Foto ou vídeo curto (com autorização). Fala de pelo menos 1 usuário real sobre o sistema. -
Aulas 23–24 — Análise dos dados do teste real e 2.ª iteração (2 aulas)
Com os dados do teste real, cada grupo compara: “O que foi diferente do que esperávamos? O que o usuário real fez que o simulado não fez?” Identificar os 3 principais pontos de melhoria. Fazer a 2.ª iteração: ajustar código, Scratch, fichas ou protocolo de uso.
Protocolo de feedback entre grupos: Cada grupo que observou o teste de outro grupo entrega uma ficha com 2 pontos positivos e 1 sugestão. O grupo receptor decide o que incorporar.
2 aulas × 45 min Tabela de análise: dado coletado | o que revela | ação de melhoria. Código v3.0 salvo. Folha de feedback entre grupos. Decisões de melhoria incorporadas registradas no diário.
Fase 5 — Manual Técnico e Documentação Final
-
Aula 25 — O que é um manual técnico? Estrutura e linguagem (45 min)
Mostrar exemplos simples de manuais (manual de geladeira, de roteador, de aplicativo). Perguntar: “O que todos têm em comum?” Identificar: título, lista de materiais, passo a passo numerado, imagens/fotos, o que fazer quando der errado (FAQ).
Cada grupo recebe o template do manual técnico (Google Docs) com seções pré-estruturadas: (1) O que é o sistema; (2) O que é necessário; (3) Como configurar; (4) Como operar dia a dia; (5) O que fazer se der erro; (6) Dados do teste real. Início do preenchimento das seções 1 e 2.
45 min Template do manual aberto e iniciado no Google Docs. Seções 1 e 2 com rascunho preenchido. Link do documento no Drive registrado no diário. -
Aula 26 — Redigir o passo a passo de operação (45 min)
A seção mais importante do manual: “Como operar dia a dia”. Deve ser escrita de forma que alguém que nunca viu o sistema consiga operar. Passo a passo numerado, frases curtas, sem jargão técnico. Exemplo de instrução ruim: “Configure a variável no MakeCode.” Instrução boa: “1. Ligue o micro:bit no cabo USB. 2. Espere aparecer o número 0 na tela. 3. Para chamar a próxima senha, aperte o botão A.”
Inserir fotos do sistema nas instruções (capturas de tela do Scratch + fotos do micro:bit). O Registrador do grupo fotografa cada etapa enquanto o Programador opera.
45 min Seção “Como operar” completa no Google Docs com ao menos 8 passos numerados e fotos inseridas. Revisão por pelo menos 2 integrantes. -
Aula 27 — Seção de erros frequentes e dados do teste (45 min)
Seção “O que fazer se der erro”: com base nos problemas reais encontrados nas Fases 3 e 4, cada grupo lista os 3 erros mais comuns e a solução para cada um. Formato: tabela simples (Problema | Causa | Solução).
Seção “Dados do teste real”: apresentar os dados coletados na Fase 4 (tempo médio, senhas chamadas, avaliação dos usuários). Incluir pelo menos 1 gráfico simples (barras) feito no Google Planilhas ou Scratch.
45 min Tabela de erros frequentes preenchida. Dados do teste inseridos no manual. Gráfico inserido (screenshot). Manual com 90% completo salvo no Drive. -
Aula 28 — Finalização, revisão e exportação do manual (45 min)
Revisão final do manual: cada grupo troca o documento com outro grupo para revisão cruzada. O grupo revisor verifica: as instruções estão claras? Falta alguma etapa? Tem alguma palavra que o usuário (merendeira, agente) não vai entender? Devolver com anotações.
Após revisão: finalizar e exportar o manual em PDF. Salvar no Drive. Imprimir 1 cópia física para entrega à gestão da escola.
45 min Manual técnico finalizado em PDF (arquivo no Drive + cópia impressa). Link do PDF registrado no diário. Anotações da revisão cruzada arquivadas na pasta do grupo.
Estrutura do Manual Técnico — Template de Referência
- Capa: Nome do sistema, nome do grupo, escola, data, versão do manual
- O que é o sistema: Descrição em 3–5 frases simples. Para que serve, onde é usado, quem opera
- O que é necessário: Lista de materiais (hardware, software, fichas físicas)
- Como configurar (uma vez só): Instalar código no micro:bit, abrir projeto Scratch, posicionar equipamentos
- Como operar dia a dia: Passo a passo numerado, linguagem simples, fotos em cada etapa
- O que fazer se der erro: Tabela: Problema | Causa provável | Solução
- Dados do teste real: Resultados da Fase 4, gráficos simples, avaliação dos usuários
- Créditos e propriedade: Nomes dos criadores, escola, ano, licença de uso (CC BY-SA recomendada)
Fase 6 — Apresentação, Entrega à Gestão e Publicação
-
Aula 29 — Ensaio da apresentação (45 min)
Cada grupo prepara uma apresentação de 5 minutos: (1) O problema que identificamos; (2) Como o sistema funciona (demonstração ao vivo com micro:bit + Scratch); (3) O que descobrimos nos testes; (4) O que o sistema pode fazer pela escola. Ensaio com cronômetro, 2 rodadas. O professor observa e dá feedback: “Fale mais alto; mostre o sistema funcionando, não só fale sobre ele; o que o usuário sentiu?”
45 min Roteiro da apresentação escrito no diário. Foto do ensaio. Professor anota pontos de melhoria por grupo antes da apresentação real. -
Aula 30 — Apresentação aberta para a escola (45 min)
Apresentação com direção, coordenação, professores e turmas parceiras convidados. Cada grupo apresenta seu sistema com demonstração ao vivo. O público avalia usando um formulário simples (Google Forms, 3 perguntas): entendeu o problema, entendeu a solução, acredita que deveria ser implementado?
O professor entrega formalmente o manual técnico impresso à diretora/coordenadora ao final da apresentação. Este gesto simboliza a transição de “projeto escolar” para “proposta de solução institucional.”
45 min Vídeo curto da apresentação (30–60 seg por grupo). Resultado do formulário de avaliação (Google Sheets). Foto da entrega do manual à gestão. Esse é o documento central do portfólio do projeto. -
Aula 31 — Publicação no blog e redes sociais (45 min)
Cada grupo produz o rascunho de um post para o blog: título chamativo, descrição do problema, o que construímos, foto do sistema em funcionamento, link para o manual técnico, link para o código no MakeCode compartilhado. O professor revisa e publica. Versão para Instagram: carrossel de 5 imagens com texto curto em cada slide.
Orientar sobre propriedade intelectual: “O código que vocês criaram é de vocês. Quando publicam no blog com o nome de vocês, estão exercendo a autoria. Pesquisar imagens para o post: usar filtro de uso livre no Google Imagens.”
45 min Post publicado no blog (URL registrada no diário). Screenshot do post. Link do código MakeCode compartilhado. Screenshot da busca com filtro de licença aplicado. -
Aula 32 — Retrospectiva, avaliação e encerramento (45 min)
Retomar o papel A3 da Fase 0 (“O que já sabíamos, o que precisávamos aprender”). Cada grupo responde: “O que realmente aprendemos?” Comparar com o que escreveram na semana 1 — a diferença é a aprendizagem.
Atividade individual: cada aluno escreve 3 palavras que descrevem o projeto. Coletar para nuvem de palavras (Mentimeter ou feita à mão). Celebração: certificados de participação, foto de turma com os protótipos e os manuais impressos.
45 min Nuvem de palavras (foto). Diário de bordo entregue ao professor para nota. Avaliação final preenchida. Foto de encerramento com todos os grupos e seus sistemas.
Sistema de Registro do Processo
Instrumentos de Registro por Camada
Pasta física com fichas impressas. Preenchido a cada aula pelo Registrador (rodízio semanal). Contém: data, o que fizemos, dificuldades, o que aprendemos, próximo passo. Entregue ao final como portfólio principal.
Uma pasta por grupo no Google Drive. Mínimo 2 fotos por aula. Registra: montagem física, código no display, simulação, teste real, apresentação. Alimenta o manual técnico e o post do blog.
Arquivo .hex salvo com nome padronizado a cada versão: senha_v1.0_[grupo].hex. Upload no Drive. Projeto Scratch salvo na conta com título padronizado. Mínimo: v1.0 (Fase 3), v2.0 (pós-simulação), v3.0 (pós-teste real).
Preenchidas na simulação (Fase 4) e no teste real. Contêm: problema observado, gravidade, solução. São a base da iteração e da seção “erros frequentes” do manual técnico.
Google Docs com template. Desenvolvido na Fase 5. Inclui passo a passo de operação, tabela de erros, dados do teste e fotos. Exportado em PDF e entregue à gestão da escola. Principal entregável institucional do projeto.
Post no blog com descrição do projeto, fotos e link para o manual e o código. Cumpre EF08TPA05. Evidência pública e arquivável da autoria dos alunos.
Frequência e Responsabilidade
| Instrumento | Quando | Responsável | Onde armazena |
|---|---|---|---|
| Diário de bordo (escrito) | Toda aula | Registrador do grupo (rodízio semanal) | Pasta física do grupo |
| Foto do processo | Toda aula (mín. 2 fotos) | Qualquer integrante (celular) | Google Drive — pasta do grupo |
| Screenshot do código | A cada versão salva | Programador do grupo | Google Drive — pasta do grupo |
| Ficha de simulação/teste | Fase 4 — após cada simulação | Testador do grupo | Pasta física + foto no Drive |
| Manual técnico (rascunho progressivo) | Fase 5 (4 aulas) | Todo o grupo em colaboração | Google Docs → PDF final |
| Versão do código (.hex) | A cada iteração (v1, v2, v3) | Programador do grupo | Google Drive — pasta do grupo |
| Post no blog | Fase 6 — Aula 31 | Grupo + revisão do professor | Blog professorcomia.com.br |
| Vídeo da apresentação | Fase 6 — Aula 30 | Professor ou aluno designado | Google Drive + YouTube (opcional) |
Alinhamento às Competências — Currículo da Cidade SP
| Habilidade | Como se manifesta neste projeto | Evidência de registro |
|---|---|---|
| EF08TPA01 Capacidade analítica para planejar projetos estruturados |
Mapeamento da fila (Fase 1), fluxo lógico em linguagem natural (Fase 2), Kanban do projeto, divisão do sistema em 3 partes independentes | Roteiro de observação, fluxo lógico escrito, Kanban fotografado |
| EF08TPA02 Criar projetos por linguagem de programação |
Código MakeCode com variáveis, condicionais e eventos de botão; projeto Scratch com variável e exibição dinâmica | Screenshot dos códigos, arquivo .hex versões 1.0, 2.0 e 3.0, projeto Scratch salvo |
| EF08TPA03 Compilar, depurar e remixar colaborativamente |
Iteração do código em 3 versões (v1.0 → v2.0 → v3.0) com base nos dados da simulação e do teste real; feedback entre grupos incorporado ao produto | Tabela de problemas × soluções, comparativo de versões, folha de feedback entre pares |
| EF08TPA04 Produções autorais para intervenções sociais (robótica/automação) |
Sistema de controle de fluxo testado em ambiente real do refeitório, com manual técnico entregue à gestão para possível adoção permanente | Foto do teste real, manual técnico em PDF, formulário de avaliação dos usuários |
| EF08TPA05 Compartilhar produções em repositórios digitais |
Post no blog com descrição, fotos, link para manual e código; publicação no Instagram da escola | URL do post publicado, screenshot, link do código MakeCode compartilhado publicamente |
| EF08TPA06 Propriedade intelectual no planejamento de produções |
Declaração de autoria no código; seção de créditos no manual técnico; uso consciente de referências com citação de fonte | Seção de créditos no manual, lista de referências, declaração de autoria no arquivo .hex |
| EF08TPA07 Licenças de uso e filtros de busca na web |
Pesquisa de imagens para o blog com filtro de uso livre; identificação da licença Creative Commons no manual técnico (CC BY-SA sugerida) | Screenshot da busca com filtro aplicado, licença inserida no manual |
Estratégias de Diferenciação para Esta Turma
Para alunos com dificuldade de abstração
- Analogia concreta antes de qualquer código: “variável é caixinha com número”
- Fluxo em linguagem natural escrito no papel antes de abrir o MakeCode
- Resultado visível a cada 15 min: o display do micro:bit responde na hora
- Checklists visuais: marcar o que já funciona e o que falta
- Divisão do sistema em partes (A, B, C): cada parte tem entregável próprio
Para alunos com dificuldade de concentração
- Transição de atividade a cada 15–20 min dentro de cada aula
- Missões curtas com entregável imediato (“em 15 min, o botão A tem que funcionar”)
- Papéis rotativos semanais: Registrador, Programador, Testador
- Simulação com papéis físicos (fila real) — atividade em movimento
- Feedback imediato do hardware: erro → micro:bit mostra número errado → corrigir
Para alunos avançados (desafios opcionais)
- Comunicação serial entre micro:bit e Scratch (automação do painel)
- Adicionar som de chamada no micro:bit quando senha muda
- Criar versão 4.0 com prioridade para necessidades especiais (botão especial)
- Modelar a caixa no Tinkercad e imprimir na impressora 3D
- Assumir papel de mentor de outro grupo na Fase 3
Para alunos com dificuldade de leitura e escrita
- Manual técnico pode ter instruções em imagens sequenciais (sem texto)
- Diário de bordo aceita desenhos, colagens e fotos como registro
- Escrita em dupla no relatório e no manual
- Apresentação oral com o protótipo na mão — demonstrar, não ler
- Instrução por vídeo curto gravado pelo próprio grupo (alternativa ao texto)
Conexão com o PPP — Escola Eng. José Amadei
| Dimensão do PPP | Como o projeto atende |
|---|---|
| Gestão democrática e participação | Alunos propõem solução para problema real da comunidade escolar. Manual entregue à gestão como proposta de política operacional. |
| Formação integral e cidadania | O sistema organiza o acesso igualitário ao refeitório. Alunos aprendem que tecnologia pode reduzir conflito e aumentar equidade. |
| Inclusão e equidade | O sistema pode incorporar prioridade para pessoas com mobilidade reduzida ou necessidades especiais (versão avançada). A metodologia garante participação de todos os perfis. |
| Protagonismo estudantil | Os alunos identificam o problema, projetam a solução, testam no ambiente real e entregam o produto à gestão. O professor é facilitador do processo — não o construtor da solução. |
| Tecnologia como meio | O micro:bit não é o objetivo. O objetivo é a organização do refeitório. A tecnologia é a ferramenta escolhida pelos alunos após compreenderem o problema. |
| ODS / Agenda 2030 | ODS 4 (Educação de qualidade): ambiente escolar mais organizado e respeitoso. ODS 16 (Paz, justiça e instituições eficazes): sistema que garante ordem e equidade no acesso ao serviço. |
Expansão Estratégica — Além da Sala de Aula
| Vetor | Possibilidade |
|---|---|
| Adoção institucional | O manual técnico entregue à gestão abre a possibilidade de o sistema ser adotado permanentemente, operado por funcionários da escola. Os alunos seriam os “consultores técnicos” da implantação. |
| Replicabilidade | O sistema pode ser replicado no horário de atendimento da secretaria escolar, na fila da biblioteca, ou na fila de entrada. Cada novo contexto é um novo ciclo de projeto. |
| Portfólio do professor | O projeto documentado no blog — com fotos, código, manual e dados — posiciona o professor como referência em ABP com tecnologia de baixo custo em escola pública. Material para cursos de formação e palestras. |
| Produto educacional open-source | O manual técnico e o código podem ser publicados com licença CC no GitHub ou Scratch, disponíveis para outras escolas da rede PMSP replicarem sem custo. |
| Continuidade no ensino médio técnico | Alunos que participaram chegam ao ensino médio com experiência real em: programação por blocos, versionamento de código, documentação técnica, testes com usuário. Base concreta para o curso técnico em desenvolvimento de sistemas. |
