Série: Fundamentos de Engenharia de Software | Parte 2 de 19 > Ministrada na Universidade Potiguar (UnP) em 2010
Hoje foi a segunda aula do curso de Engenharia de Software na Universidade Potiguar (UnP), e focamos em um tema fundamental: processo, modelos e propósito. Desde o início, quis enquadrar a ideia de que o caos no desenvolvimento de software não é destino — é uma realidade que pode ser gerenciada com a mentalidade certa, colaboração e práticas bem pensadas.
Abertura com propósito
Começamos provocando: de que você tem fome e sede? Tecnologia? Resultado? Controle?
Essa pergunta não foi apenas simbólica — ela gerou discussões interessantes e espontâneas entre os alunos. Percebi ali que muitos ainda enxergam o desenvolvimento de software como uma sequência de decisões técnicas, mas que poucos param para pensar no que move essas decisões. Foi uma forma poderosa de dar início à aula com consciência e alinhamento humano.
Software não é só código
Discutimos que software não é apenas código. É especificação, configuração, documentação, experiência.
Essa visão mais holística ajuda a desconstruir a ideia de que o valor está unicamente no produto final funcional. Valor também está na clareza de requisitos, na arquitetura compreensível, na documentação que ensina, no teste que protege, e na experiência que encanta. Ao trazer isso, comecei a moldar um pensamento mais sistêmico nos alunos — algo que quero reforçar ao longo do curso.
Falamos também da famosa “Crise do Software”. É curioso como os desafios mudaram de forma, mas não desapareceram. Hoje, o problema é menos sobre “fazer software funcionar” e mais sobre “fazer o software certo, do jeito certo e de forma sustentável”.
Atividade: analisando contextos
A proposta foi simples e eficaz: os alunos se dividiram em grupos e escolheram um contexto — real ou fictício. Analisaram quem eram os atores envolvidos, os processos visíveis, as tecnologias utilizadas, e como a cultura influenciava as decisões.
Facilitar essa atividade requer criar um espaço onde todas as ideias sejam válidas no início. O mais importante não é acertar, mas observar. Alguns grupos notaram que haviam conflitos de processos não documentados, outros perceberam dependências críticas não gerenciadas. O objetivo era plantar uma semente de pensamento sistêmico e crítico.
Processos, modelos e escolhas
Apresentei diferentes formas de representar um processo: como fluxo de atividades, sequência de ações entre papéis, ou mesmo como modelo de ciclo de vida. Expliquei os principais tipos: o modelo cascata, o incremental, o iterativo, o RUP e até CBSE.
Ressaltei que cada um desses modelos nasceu de um contexto específico e resolveu um conjunto particular de problemas. Entender os trade-offs é parte do amadurecimento profissional. Nenhum modelo é errado por si só — mas pode ser inadequado se mal aplicado.
Atividade: problemas e metodologias
Para fechar, propus uma reflexão em grupo com duas perguntas: “Quais problemas você já enfrentou ao desenvolver software?” e “O que você esperaria de uma metodologia para te ajudar com esses problemas?”.
Esse momento foi extremamente rico. Alunos compartilharam dificuldades como comunicação entre times, retrabalho por requisitos mal entendidos, prazos mal dimensionados e falta de testes. Quando cada grupo apresentou suas dores e expectativas, ficou claro como o conteúdo da aula começa a ganhar sentido prático.
Para quem está do outro lado
Facilitar esse tipo de aula é um exercício de escuta, adaptação e cuidado. É preciso trazer o conteúdo, mas também criar o ambiente certo. É sobre dar espaço para quem quer falar, mas também provocar quem ainda não se sente à vontade.
Senti que a turma está começando a se soltar. Ainda há hesitação, mas ela vem acompanhada de curiosidade. E isso é ótimo. Quando o aluno começa a perceber que pode participar ativamente da construção do conhecimento, é sinal de que estamos no caminho certo.
Publicado como registro de uma aula onde a complexidade não venceu. Seguimos aprendendo a projetar juntos — com processo, propósito e participação.
Navegação da Série
- Anterior: Parte 1 - Por que Engenharia de Software?
- Atual: Parte 2 - Domando a Complexidade
- Próxima: Parte 3 - Modelo Cascata
- Série completa: Por que Engenharia de Software? | Domando a Complexidade | Modelo Cascata | Modelos Evolucionários | Mentalidade Ágil | Scrum Produtividade | Ciclo Scrum | XP Qualidade & Coragem | XP Princípios & Práticas | XP na Prática | Domain-Driven Design