flowchart TD
subgraph F["Fundamentos"]
M1[Introdução à ES]
M2[Fundamentos]
M3[Ciclos de Vida]
M4[Ágil e Prototipação]
end
subgraph R["Engenharia de Requisitos"]
M5[Análise de Requisitos]
M6[Funcionais e Não-Funcionais]
M7[Técnicas de Levantamento]
M8[Casos de Uso e Histórias]
M9[Estudo de Caso]
end
subgraph P["Projeto e Modelagem"]
M10[Projeto de Software]
M11[Modelagem UML]
end
subgraph Q["Verificação e Qualidade"]
M12[Testes de Software]
M13[TDD]
M14[Qualidade e Métricas]
M15[Modelos de Qualidade]
end
F --> R --> P --> Q
style F fill:#cfe2ff,stroke:#084298
style R fill:#d1e7dd,stroke:#0f5132
style P fill:#e2d9f3,stroke:#59359a
style Q fill:#fff3cd,stroke:#664d03
Bem-vindo ao Laboratório de Engenharia de Software
Antes de tudo, um combinado. Este material foi escrito para ser lido por você, sozinho, antes de cada encontro. Não é um resumo de slides nem uma apostila para folhear na véspera da prova. É a nossa conversa, adiantada no tempo: aqui eu explico com calma o que, em sala, teríamos pouco espaço para aprofundar. Se você chegar tendo lido, a aula deixa de ser o lugar onde você ouve pela primeira vez e passa a ser o lugar onde você tira dúvidas, discute e aplica. Essa troca é o coração de tudo o que vem a seguir.
Deixe-me começar sendo honesto sobre onde você está. Ao longo do curso, você aprendeu a programar: escreveu algoritmos, estruturou dados, resolveu problemas. Isso é uma base valiosa, mas é apenas metade da história. Construir software de verdade — aquele que outras pessoas usam, que uma equipe mantém por anos, que precisa ser confiável mesmo quando ninguém está olhando — exige um conjunto de conhecimentos que raramente cabe numa aula de programação. É essa outra metade que vamos percorrer juntos. A engenharia de software é a disciplina que transforma a habilidade individual de escrever código na capacidade coletiva de entregar sistemas que sobrevivem ao tempo.
O que você vai aprender, e em que ordem
O material está dividido em quinze módulos, e a ordem deles não é acidental. Cada bloco de temas prepara o terreno para o próximo, como se estivéssemos construindo um edifício andar por andar. Nós partimos das fundações conceituais, descemos ao trabalho de entender o que o software precisa fazer, subimos para a decisão de como ele será estruturado e terminamos garantindo que aquilo que construímos tem qualidade. O diagrama a seguir mostra esse percurso e como cada etapa se apoia na anterior.
Repare na lógica do caminho. Não faz sentido projetar um sistema antes de entender o que ele deve fazer, e não faz sentido testar sem antes ter algo projetado. Por isso começamos entendendo a natureza da engenharia de software e seus modelos de processo, depois mergulhamos fundo em requisitos, em seguida aprendemos a projetar e modelar, e só então tratamos de testes e qualidade. Quando você chegar ao último módulo, terá percorrido o ciclo completo pelo qual um software nasce, cresce e se mantém saudável.
Por que aprendemos deste jeito
Você vai perceber, desde a primeira semana, que esta disciplina não funciona como uma sequência de aulas em que o professor fala e você anota. Essa escolha é deliberada, e quero que você entenda a razão dela, porque entender o método faz você aproveitá-lo melhor.
A engenharia de software é uma prática antes de ser uma teoria. Ninguém aprende a levantar requisitos ou a projetar um sistema apenas ouvindo sobre isso, do mesmo modo que ninguém aprende a nadar assistindo a uma palestra sobre natação. Aprende-se fazendo, errando, refazendo. Por isso o material teórico vem até você antecipadamente: a ideia é que você absorva os conceitos em casa, no seu ritmo, para que o nosso tempo juntos seja gasto naquilo que só acontece com as pessoas na mesma sala — a prática guiada, a discussão e a resolução de dúvidas reais.
As abordagens que sustentam a disciplina se reforçam mutuamente. A sala de aula invertida desloca a exposição para o estudo prévio e libera o encontro presencial para a aplicação. A cultura maker, o velho princípio de aprender fazendo, coloca você para construir com as próprias mãos, porque é assim que o conhecimento se fixa. A aprendizagem baseada em problema parte de situações concretas em vez de definições abstratas, para que a teoria apareça como resposta a uma necessidade que você sentiu. A aprendizagem baseada em projeto dá continuidade e propósito, transformando temas soltos em algo que se acumula. A aprendizagem baseada em times reconhece que software é atividade coletiva e que boa parte do que você precisa dominar só se aprende trabalhando com outras pessoas. E o design thinking ensina a começar pela empatia com quem usará o sistema, antes de pensar em qualquer linha de código.
Nenhuma dessas escolhas é moda pedagógica. Cada uma responde a uma característica real da profissão. Software se constrói em equipe, sob incerteza, para pessoas cujas necessidades nem sempre estão claras. Um método de ensino que ignora isso forma programadores; um método que abraça isso forma engenheiros.
Como usar este material
Quero ser prático quanto ao seu jeito de estudar, porque a forma como você lê determina o quanto aproveita. O material de cada módulo foi pensado para o estudo autônomo e traz mais do que texto. Há diagramas que tornam visíveis relações que em palavras ficariam abstratas; há tabelas que organizam comparações; e há exemplos de código, escritos em Dart, que mostram os conceitos encarnados em algo executável. A linguagem foi escolhida pela clareza: ela não vai competir com a sua atenção, e o que você aprender sobre projeto, testes e qualidade vale para qualquer linguagem que você venha a usar depois.
DicaUm roteiro de estudo que funciona
Leia o módulo da semana antes do encontro, sem pressa. Ao encontrar um diagrama, pare e tente reconstruí-lo mentalmente antes de seguir. Ao encontrar um trecho de código, não o leia passivamente: imagine como você o escreveria e compare. Anote as dúvidas que surgirem, porque elas são o material mais valioso que você levará para a aula. Depois de ler, tente explicar o tema em voz alta, com suas palavras. Se conseguir, você entendeu; se travar, sabe exatamente onde voltar.
Cada módulo se encerra sugerindo uma forma de consolidar o que foi lido, e ao longo da disciplina você terá exercícios e questionários que servem menos para medir e mais para revelar, a você mesmo, o que ainda não está firme. Encare esses instrumentos como espelhos, não como julgamentos. Errar durante o estudo é barato e ensina; errar depois, num sistema real, é caro e machuca. É melhor descobrir agora.
Como o material está organizado
A mecânica é simples e se repete a cada semana. O material do módulo é disponibilizado com antecedência, para que você o estude antes do nosso encontro. Quando nos reunimos, dedicamos um primeiro momento à explanação dos pontos mais delicados e ao esclarecimento das dúvidas que você trouxe da leitura, e o restante do tempo à prática e à aplicação daquilo que foi estudado. Esse ritmo — estudar antes, aplicar depois — é o que dá sentido a todo o resto e é a razão pela qual a leitura prévia não é opcional.
Para começar: siga direto para o primeiro módulo, sobre a introdução à engenharia de software. Ele estabelece as ideias que sustentam tudo o que vem depois, e eu escrevi cada módulo seguinte contando que você carregaria essas ideias adiante. Leia com atenção, traga suas dúvidas, e vamos construir isto juntos.