Termos e Condições
Acordo
Ao se matricular e participar desta disciplina, você concorda em cumprir os termos descritos nesta página. Leia-os antes da sua primeira aula.
Participação
As aulas seguem um formato de aprendizagem ativa — a leitura prévia é esperada. Cada aula pressupõe que você leu o material indicado com antecedência e está pronto para discuti-lo, questioná-lo e aplicá-lo.
| Expectativa | Detalhes |
|---|---|
| Leitura prévia | Revise as seções indicadas antes de cada aula |
| Engajamento | Faça perguntas, participe das discussões, ajude os colegas |
| Aulas de laboratório | Traga um notebook com o ambiente de desenvolvimento configurado (veja Pré-requisitos) |
Integridade acadêmica
Plágio
Entregar o trabalho de outra pessoa — seja de um colega, de um repositório público ou de uma ferramenta de IA — como se fosse seu é plágio e resulta em nota zero na atividade. Violações reincidentes são encaminhadas ao comitê de integridade acadêmica da instituição.
O que caracteriza plágio nesta disciplina:
- Copiar código, texto ou diagramas da entrega de outro estudante (mesmo com pequenas modificações)
- Entregar a saída de uma ferramenta de IA sem compreendê-la, editá-la e dar o devido crédito
- Reaproveitar o seu próprio trabalho de uma edição anterior da disciplina sem informar
- Copiar de um repositório público do GitHub sem atribuição
O que não é plágio:
- Usar documentação oficial, Stack Overflow e tutoriais — desde que sejam citados
- Usar ferramentas de IA como apoio ao aprendizado — desde que você siga a política de uso de IA
- Discutir abordagens de design com colegas antes de implementar de forma independente
Formato das entregas
Todas as entregas devem ser publicadas no GitHub Pages.
Nenhum outro formato é aceito. Um template de entrega é fornecido: template de documentação
Requisitos para todas as entregas:
| Requisito | Padrão |
|---|---|
| Hospedagem | GitHub Pages — repositório público |
| Tema | MkDocs Material |
| Nome do repositório | Profissional e descritivo (por exemplo, platform, cloud-native-ecommerce) |
| Autoria no git | Os commits devem estar vinculados a contas do GitHub (git config user.email) |
| Idioma | Inglês |
Prazos
Os prazos não são prorrogados.
Entregas atrasadas recebem nota zero, sem exceções. Planeje-se: comece cedo, faça push do progresso incremental e não espere ter uma versão "pronta" para fazer o seu primeiro commit.
Se ocorrer uma falha técnica na plataforma de entrega (e não do seu lado), entre em contato com o professor imediatamente, com evidências — antes do prazo, não depois.
Atividades individuais
As atividades individuais incluem quizzes, exercícios de microsserviços e outras tarefas atribuídas a cada estudante pessoalmente.
- O trabalho deve ser feito de forma independente. Discutir conceitos com colegas é permitido; compartilhar código ou respostas, não.
- Os quizzes são com consulta, mas não com colegas. Você pode consultar anotações e documentação; não pode conversar com colegas durante o período do quiz.
- Pedidos de revisão de nota devem ser enviados em até 5 dias úteis após a publicação da nota. O pedido deve identificar o item contestado e a justificativa; pedidos genéricos do tipo "mereço mais pontos" não são considerados.
Projeto em equipe
Os projetos em equipe simulam um time real de engenharia entregando uma plataforma cloud-native ao longo de um semestre.
Prazo para formação dos grupos
Os grupos devem ser cadastrados até a data indicada na visão geral da disciplina. Depois dessa data, os estudantes sem grupo são alocados em grupos pelo professor.
Regras:
- As equipes têm de 2 a 3 integrantes. Entregas individuais não são aceitas.
- Todos os integrantes recebem a mesma nota. Não há ajuste individual dentro da equipe, a menos que se constate que algum integrante não contribuiu (veja abaixo).
- A contribuição deve estar visível no histórico do git. Um integrante com zero commits no repositório no momento da entrega pode receber nota reduzida ou zero, independentemente do que os colegas relatarem.
- O código deve ficar no repositório da equipe. Não use um fork pessoal como repositório de entrega.
Código de conduta dentro da equipe
Espera-se que as equipes dividam o trabalho de forma equilibrada e se comuniquem de forma proativa. Se um integrante não estiver contribuindo, avise o professor cedo — não na semana da entrega. Reclamações tardias sobre a dinâmica da equipe após a entrega não alteram notas retroativamente.
Comunicação
| Canal | Uso | Tempo de resposta |
|---|---|---|
| Horário de atendimento | Dúvidas de design, dúvidas de arquitetura, contestação de notas | Durante o atendimento |
| GitHub Issues no repositório da disciplina | Erros de conteúdo, links quebrados, instruções pouco claras | Conforme disponibilidade |
| Apenas assuntos pessoais/administrativos | 2 dias úteis |
Não envie soluções ou código por e-mail pedindo revisão de nota. Use o horário de atendimento.
Código de conduta
Esta disciplina trata de práticas de engenharia de nível profissional. Os mesmos padrões valem para a forma como tratamos uns aos outros.
- Critique ideias, não pessoas. Discordar sobre escolhas técnicas é saudável; ataques pessoais, não.
- Não compartilhe o trabalho de outro estudante, credenciais de ambiente ou dados de conta da AWS fora da equipe.
- Trate todos os participantes — estudantes, monitores, professor — com respeito em todos os canais (sala de aula, GitHub, aplicativos de mensagem).
Violações deste código de conduta são comunicadas ao setor da instituição responsável pela conduta dos estudantes.
Alterações destes termos
O professor se reserva o direito de atualizar estes termos durante o semestre. As alterações são anunciadas em aula e refletidas aqui com a data de revisão. Alterações substanciais que afetem a avaliação não serão aplicadas retroativamente.
Última atualização: 2026.