Engenharia de Software
O processo
Software não é só código
"Você pediu uma pizza. Chegou farinha, molho, queijo e pepperoni numa caixa separada. Tecnicamente, são todos os ingredientes certos. Mas não é pizza."
Só os ingredientes
Linhas de instrução, variáveis, funções, classes. São os ingredientes. Mas não são software.
O conjunto completo
Código + lógica + interface + dados + tratamento de falhas + documentação + processo de evolução. Isso é software.
O que é software afinal?
Mais do que instruções que executam funções, o software é um artefato multidimensional.
-
Produto e Serviço: Atende pessoas e opera dentro de organizações do mundo real.
-
Evolução Contínua: Tem um processo que garante que continue funcionando daqui a anos.
-
Compromisso com o tempo: Diferente de hardware, seus problemas (débito técnico) são invisíveis até que o sistema colapse.
Um sistema que resolve o problema errado com perfeição técnica não é bom software, é engenharia de precisão aplicada na direção errada.
A Crise do Software
A crise do software nunca foi resolvida, apenas mudou de forma. Cada década trouxe novas ferramentas que resolveram parte da equação e abriram novos vetores de falha.
Anos 70 a 2000
Problemas com estimativas, crescimento de complexidade e sistemas legados intratáveis desenvolvidos com atalhos.
Década de 2020
Veloz ilusão de que a IA resolve falhas sem a necessidade do engenheiro e de um processo estruturado.
O Nascimento da Engenharia de Software
Garmisch, Alemanha (Outubro de 1968)
A OTAN reuniu cientistas e engenheiros para discutir sistemas estourando orçamento, entregando menos do que prometiam ou falhando de formas criativas.
Pela primeira vez, a comunidade técnica reconheceu formalmente que construir software não se resolvia apenas com programadores talentosos ou computadores rápidos.
Precisava de método. Precisava de Engenharia de Software.
Ariane 5
Foguete de lançamento, 1996
O Caso Ariane 5
O foguete explodiu 40 segundos após a sua primeira decolagem.
Prejuízo de U$ 500 milhões.
Foi aproveitado um pacote de software de navegação do Ariane 4 que não tinha erros.
Denver International Airport
Atrasou a inauguração do aeroporto. Custo do sistema: US$ 193 milhões.
Inauguração estava prevista para Outubro/1993.
Em Julho/1994 o sistema ainda não funcionava e causava prejuízos de US$ 1,1 milhão/dia.
Therac-25
O controle de segurança feito pelo hardware em máquinas anteriores foi removido e passou a ser feito pelo software.
O software falhou na tarefa. O feixe de elétrons e o dispositivo que controla a concentração do feixe em níveis seguros deixaram de funcionar.
USS Vincennes
Derrubada do voo Iran Air 655, um Airbus A320 comercial com 290 passageiros e tripulantes a bordo.
Iran Air A320
Voo comercial em rota regular sobre o Golfo Pérsico, com 290 civis a bordo.
USS Vincennes (CG-49)
Cruzador da Marinha dos EUA equipado com o sistema de combate Aegis.
O bug que matou 290 pessoas
O sistema Aegis confundiu o alvo
O software de identificação classificou o Airbus A320 comercial como um caça F-14 Tomcat iraniano. A interface do sistema não diferenciou adequadamente os sinais.
Dois mísseis SM-2 disparados
Com base na identificação errada do software, a tripulação disparou. O avião foi destruído em segundos. Nenhum sobrevivente.
vítimas fatais
em indenizações pagas pelo governo dos EUA
A lição: o software "funcionava". O problema era que os requisitos de identificação de alvos civis não foram tratados com o rigor necessário. Mais um caso onde a ausência de processo custou vidas.
O que é processo?
Como você faz as coisas?
Todos nós repetimos certas atividades para realizar tarefas rotineiras. Essa sequência é um processo.
Já melhorou suas atividades?
Quando melhoramos atividades e o resultado final melhora, estamos refinando o processo.
Processo de software
É um conjunto de atividades necessárias para construir um software de alta qualidade.
Camadas da Engenharia de Software
IDEs, compiladores, agentes de IA, frameworks
Requisitos, análise, projeto, construção, testes
Organiza e sequência as atividades
A base que sustenta tudo
Como se constrói um software
Requisitos
Entender o problema real que o software vai resolver.
Análise
Decompor, priorizar e validar os requisitos levantados.
Projeto
Definir a arquitetura, módulos e fluxo de dados.
Construção
Escrever o código seguindo o que foi projetado.
Teste
Verificar se o software funciona nas condições reais.
Implantação
Colocar em produção de forma incremental e reversível.
Manutenção
60-80% do custo totalCorrecao, adaptação, evolução. O sistema não termina no deploy: ele começa ali. E cada atalho tomado antes cobra seu preço aqui.
Qual é a melhor
sequência das tarefas?A resposta define o modelo de processo. Cada modelo organiza as mesmas atividades em ritmos e estruturas diferentes.
Modelo Cascata
Fases sequenciais, uma após a outra, como uma cascata de agua. Logica impecável no papel. Projetos reais não seguem lógica de papel.
Cliente não sabe todos os requisitos no inicio
Equipes ficam bloqueadas esperando a fase anterior
Cliente so recebe o software no final
Iterativo Incremental
Pequenas cascatas empilhadas. Cada incremento entrega uma parte funcional do sistema. O cliente recebe algo rapidamente.
Núcleo essencial
Funcionalidades básicas
Complementar
Refina e expande
Avançado
Features adicionais
Sistema completo
Ate a conclusao
- Entrega rápida ao cliente
- Mudancas tem impacto localizado
- Problemas aparecem cedo
- Usuario pode se entusiasmar com a v1
- Termina quando o SW é entregue
Modelo Espiral
Ciclos progressivos com quatro quadrantes. A cada volta, o sistema ganha profundidade e os riscos são reduzidos de forma explicita.
Objetivos
Riscos
Desenvolvimento
Avaliação
Perene: não termina quando o SW é entregue. Suporta redução de risco explícita e é mais versátil para lidar com mudanças.
Cuidado: exige experiência e disciplina. Pode ser pesado para equipes pequenas.
Prototipação
Se o cliente não sabe o que quer, construa algo rápido para ele ver e reagir. O protótipo não é o produto: é uma ferramenta de descoberta de requisitos.
Vantagens
- Melhora a percepcao do usuario sobre o software
- Desenvolvedor constrói algo imediatamente
- Feedback concreto desde o inicio
O risco classico
- Prototipo que nunca vira produto
- Cliente aprova, time coloca em produção
- Rascunho vira fundação do sistema
Isso tem nome: vibe coding de 1985
RAD
Resposta à lentidão dos modelos formais. Componentes reutilizáveis, geração de código e ciclos curtos de entrega entre 60 e 90 dias.
Cuidados
- SW grande: número de pessoas cresce
- Mais caro para desenvolver
- Exige sinergia entre clientes e devs
Baseado em Componentes
Nem tudo precisa ser construído do zero. Se um componente já existe, foi testado e funciona, por que reescrevê-lo?
Biblioteca de componentes
Busca e extrai reutilizaveis
Constroi apenas o novo
Adiciona a biblioteca
Na prática moderna: frameworks, pacotes npm, bibliotecas Python e ate skills de agentes inteligentes seguem essa lógica. Você não reescreve o que já funciona, você compoe.
A Revolucao Ágil
Snowbird, Utah, fevereiro de 2001
Dezessete desenvolvedores num resort de ski redefiniram como o mundo pensa sobre desenvolvimento de software. O Manifesto Ágil não disse que processo e ruim. Disse que processos que impedem adaptação são ruins.
O que o Manifesto disse
Valorizar individuos, software funcionando, colaboração e resposta a mudancas.
O que o mercado leu
"Menos processo" (a parte conveniente, sem a disciplina técnica que sustenta).
Scrum
Ciclos curtos (sprints) de 2-4 semanas com entregas verificaveis.
- Sprint Planning
- Daily Standup
- Sprint Review
- Retrospectiva
XP
Praticas técnicas rigorosas. Define como o código deve ser escrito.
- Programação em par
- TDD
- Integração continua
- Refatoração constante
Kanban
Fluxo continuo com limite de trabalho em andamento. Sem ciclos fixos.
- Quadro visual
- Limite de WIP
- Fluxo continuo
- Metricas de vazao
Os mitos que nos perseguem
"Mais pessoas resolvem atrasos"
Lei de Brooks (1975): adicionar pessoas a um projeto atrasado o atrasa ainda mais. Cinquenta anos depois, a resposta mais comum para atrasos ainda é abrir vaga no LinkedIn.
"O cliente sabe o que quer"
O cliente sabe qual dor quer resolver. Raramente sabe como um sistema deve resolver essa dor. A elicitação de requisitos existe para navegar essa distancia.
"Documentação é perda de tempo"
Documentação excessiva e desatualizada é perda de tempo. Documentação que registra decisões de arquitetura e o "por quê" de cada escolha salva projetos.
"Ágil significa sem planejamento"
Ágil não é sem plano. É plano adaptável, revisado a cada iteração com base em evidências reais de progresso.
"IA elimina a necessidade de processo"
O mito de 2024. A mesma lógica de sempre: a nova ferramenta e tao poderosa que os problemas antigos não se aplicam mais. Se aplicam. Um agente sem requisitos implementa a coisa errada com velocidade impressionante.
IA dentro do processo
O que muda com agentes inteligentes não e a necessidade das fases: e a velocidade com que cada fase pode ser executada. A ferramenta ficou mais rápida. A necessidade de metodo não diminuiu. Aumentou.
Agente sem processo
Ferramenta de aceleração de debito tecnico.
Agente com processo
Ferramenta de produtividade genuina.
A dificuldade não some.
Software não é apenas código executável. É código, requisitos, arquitetura, testes, operação e manutenção organizados por um processo que permita ao sistema continuar útil quando o entusiasmo inicial já passou.
O que muda e a preparação
de quem enfrenta.
Engenharia de Software com Agentes Inteligentes
O guia definitivo para quem quer usar IA com metodo, não com fe.
- Processo: De requisitos ao deploy com agentes inteligentes
- Videos: Conteudo complementar no Canal Sandeco
- Comunidade: Grupo exclusivo de engenheiros que usam IA com metodo
Conteudo gratuito toda semana sobre IA e engenharia de software