🚀 Engenharia de Software
Processos e Paradigmas (Aula Estendida)
👨🏫 Professor: Ricardo Pires
📚 Unidade I
🎯 Agenda da Nossa Aula (3 Horas)
- ⚙️ Fundamentos do Processo de Software: O esqueleto do desenvolvimento.
- 🚦 As 4 Atividades Cardinais: Sem elas, o caos se instaura.
- 🌊 Paradigma Clássico: O Modelo em Cascata.
- 🧱 Paradigma Iterativo: O Desenvolvimento Incremental.
- ♻️ Paradigma Composto: Engenharia Baseada em Reuso.
- 💻 Exemplos de Código (O Ciclo de Vida do MVP)
⚙️ O Paradoxo do Caos e o Processo
Por que ter um “Processo”? 🤔
Programar com fone de ouvido é fascinante. Mas quando a equipe tem 50 pessoas, o desenvolvedor A salva por cima do banco de dados do desenvolvedor B, e ambos descobrem no dia do lançamento que o Usuário queria um botão vermelho, e não azul.
O Processo de Software é uma coreografia corporativa rigorosa de atividades, que define: 📋 Quem faz o que, 🕰️ Em que momento a tarefa deve ser feita, 🛠️ E qual padrão seguir.
🚦 A Bússola: As 4 Atividades Básicas
Não importa se você usa Metodologias Ágeis Modernas ou o rígido formato do Pentágono, todo modelo obrigatoriamente passará por:
- 📝 Especificação de Software (Mapeando a mente humana).
- 💻 Projeto e Implementação (Traduzindo para a máquina).
- ✅ Validação de Software (Checagem e Quality Assurance).
- 🔄 Evolução de Software (O sistema vive depois de lançado).
🌊 O Dinossauro Fiel: Modelo em Cascata
O avô de todos os modelos. Baseado puramente na engenharia civil. Você não constrói o telhado antes da fundação, certo? Se a planta (Requisitos) não estiver 100% pronta e assinada, ninguém toca no teclado.
[ 📝 REQUISITOS ]
│
├──► [ 📐 PROJETO (ARQUITETURA) ]
│
├──► [ 💻 CODIFICAÇÃO ]
│
├──► [ 🧪 TESTES ]
│
└──► [ 🛠️ IMPLANTAÇÃO E MANUTENÇÃO ](O fluxo da água não sobe! Voltar nas fases é caro, doloroso e demorado).
🌊 Anatomia do Cascata na Prática
Aonde ele domina o mercado até hoje? Em Sistemas Críticos. Pense num projeto da Embraer para o controle do estabilizador de um jato comercial, ou o Módulo da Sonda Lunar da NASA.
Não faz sentido dizer: “Gente, vamos colocar o básico pro jato voar no primeiro mês e depois vemos os bugs nas asas na atualização da versão 1.2”. O sistema precisa de precisão cirúrgica de validação teórica (Arquitetura) antes do custo gigantesco de produção real. Requisitos fechados!
🧱 A Resposta Comercial: Modelo Incremental
Na StartUp moderna (Rappi, Uber, Nubank), os clientes não sabem tudo que vão querer daqui a um ano. O Cascata de demorar “12 meses” para entregar não servia para as Apps Stores!
O Modelo Incremental pega uma funcionalidade essencial, planeja, projeta, coda e disponibiliza para as pessoas. Depois pega a segunda, e avança em “Sprints” de tijolo em tijolo.
O usuário já sai rodando de fusca antes de exigirmos que espere mais dois anos até entregarmos uma Ferrari.
🧱 ASCII: Vendo o Incremento Bater na Tela
Enquanto o Cascata entrega 1 versão em 1 ano… O modelo Incremental entrega partes da esteira a cada Sexta-Feira:
[ENTREGA 1]: Login Simples => PROD 🟢
[ENTREGA 2]: Catálogo => Carrinho => PROD 🟢
[ENTREGA 3]: Meios de pgto => ChatBot => Dashboard => PROD 🟢- A “Mágica” do Feedback: Ao entregar a
[Entrega 1], o cliente usou na rua. Descobrimos que ele acessa tudo por impressão digital do iPhone. Na[Entrega 2], o desenvolvedor já descarta tarefas obsoletas e foca na nova urgência do mercado.
💻 Exemplo Prático: Evolução de Código Incremental
Aqui vemos como a “Dívida Técnica” ocorre quando incrementamos rápido demais:
# Incremento 1: (Versão 1.0 - Feito às pressas e entregue)
def checar_desconto(cliente):
if cliente.status == "VIP":
return 0.20 # 20%
return 0Tudo muito lindo… Até o Incremento 4 alterar tudo!
💻 Exemplo Prático: Evolução de Código Incremental
E meses depois, no Incremental…
# Incremento 4: (Versão 1.3 - Regras multiplicaram)
def checar_desconto(cliente):
if cliente.status == "VIP":
if cliente.compras_mes_atual > 5:
return 0.30
return 0.20
elif cliente.id_cupom == "BLACKFRIDAY":
# Opa, se ele esqueceu de validar a data aqui, Bug em Prod!
return 0.50
return 0Vantagem do Incremental: Faturamento hoje! Risco: Código “remendado” rapidamente (“Spaghetti Code” em Python).
🧠 QUIZ RÁPIDO! Cascata ou Incremental?
Leia as situações abaixo e indique em voz alta o “Porquê” e “Qual” modelo!
- 🏦 Banco Central / Pix Integrado (Lida com normas globais de segurança ISO e falha zera o sistema): ______________
- 📸 Nova Rede Social do Meta (Foco em testar stories e filtros coloridos experimentais): ______________
- 🏥 Software do Raio-X Linear de um Hospital de Câncer: ______________
✅ RESPOSTAS DO QUIZ
- Pix (Cascata com Variantes Seguras): As bases criptográficas e normativos do Banco Central não dão “sprint de 15 dias” para testar falhas. Requisitos fechados.
- Rede Social (Incremental/Ágil): Lança-se o filtro tosco. As métricas veem que adolescentes detestaram. Joga o código fora na mesma semana sem prejuízo.
- Máquinas de Radiação (Cascata Forte): Um erro de vírgula emite radiação letal ao paciente de oncologia (Ver o caso Therac-25 real na história).
♻️ 3. Software Baseado em Reuso e Integração (APIs)
Por que construir um componente de “Geolocalização” gigantesco, lendo satélites e renderizando ruas usando OpenGL de baixo nível, se você pode apenas chamar uma linha do Google Maps API?
A Terceira Família é o Reuso Sistêmico e Modular. É a essência da Engenharia Web em Microserviços de Hoje.
🔌 API’s na Prática: A Fabrica de Lego
Você foca as 8 horas do seu dia em arquitetar a “Regra de Negócio que dá Faturamento pro seu Chefe” e terceiriza o resto (“Cola de Software”).
[ 📱 SEU E-COMMERCE NO IPHONE ]
|
| (1) - Calcula Frete ----> [ 🚛 API CORREIOS (AWS) ]
| (2) - Cobra o Preço ----> [ 💳 API STRIPE/CIELO ]
| (3) - Envia Comprovante -> [ ✉️ API TWILIO/WHATSAPP ]
|
(Banco de Dados Só Seu)O Arquiteto pensa em fluxos invisíveis e não em fazer tudo na unha!
📝 Mergulhando: As Dores da Especificação
Já entendemos os Modelos de Fabrica. Agora vamos olhar pra atividade humana “Levantamentos”:
Entender o cliente é a tarefa humana mais letal para empresas de TI. O “Efeito Telefone Sem Fio”:
- O Gerente interpreta que o cliente quer um CRM com Inteligência.
- O Analista escreve um Trello gigante exigindo Dashboards.
- O Dev Backend acha a descrição “chata” e foca em otimizar queries SQL.
- O Dev Frontend ignora a lógica e desenha botões em roxo choque.
(Surge a dor da incompatibilidade! Por isso Diagramas UML salvam vidas).
💻 Mergulhando: Validação e Teste (Automatize)
(Destina-se a provar matematicamente/sistemicamente a conformidade do fluxo)
As empresas abandonaram os “Testadores Humanos apertando botão na sexta à noite”. A Engenharia obriga Testes em código!
@Test
public void naoDevePermitirSaldoNegativo() {
ContaCorrente conta = new ContaCorrente(100.00); // Dado 100 reais
conta.sacar(200.00); // Tiro 200
// Eu AFIRMO (Assert) q o sistema tem q falhar sem me obedecer.
assertTrue(conta.isOperacaoRejeitada());
}(O Código ganha consciência para testar código!)
📐 Matemática do Custo do Erro (Lei de Boehm)
A Engenharia de Software tem um teorema econômico brutal e comprovado empiricamente:
Onde é o índice da fase (Requisitos=1, Projeto=2, Código=3, Teste=4, Produção=5).
Traduzindo para reais:
- Corrigir um requisito errado custa C_1 = R\ 1$.
- O mesmo erro, descoberto em produção, custa C_5 = R\ 10.000$.
Invista em Especificação antes de tocar no teclado. A matemática é implacável.
🗣️ QUIZ FINAL: A Atividade Ignorada
Cenário: Uma consultoria recebeu o contrato para modernizar o sistema de folha de pagamento de um município. Entusiasmados, os devs foram direto ao código em Python, ignorando reuniões com o RH. Três meses depois, o sistema calculava o 13º salário de forma incorreta para servidores com mais de 20 anos de casa — um caso especial que o RH sabia, mas nunca foi perguntado.
Das 4 atividades básicas do processo de software, qual foi completamente suprimida e provocou o desastre? Qual seria a ferramenta correta para evitá-lo?
✅ RESPOSTA DO QUIZ FINAL
A Especificação de Software foi ignorada! 📝
Explicação: A equipe pulou direto para Projeto e Implementação sem executar o Levantamento de Requisitos com os stakeholders reais (o RH). A regra de negócio do 13º para servidores longevos era um Requisito de Domínio implícito — não documentado, mas existente. A ferramenta correta seria um ciclo de entrevistas e criação de um Documento de Requisitos (DRS), seguido de validação com o cliente antes de uma linha de código ser escrita. Pelo teorema de Boehm, descobrir isso em produção custou ~10.000x mais caro do que teria custado descobrir na reunião inicial.
🚀 Sintetizando o Panorama do Processo
Independentemente de você “abraçar a árvore” com Scrum e post-its coloridos, ou vestir paletó numa reunião de Cascata Governamental, a fundação imutável é a mesma:
Esforce-se em Entender o Humano (Requisitos), Modele o fluxo lógico, Encaixe o código como peças de relógio (Incremental/APIs) e blinde sua aplicação contra ela mesma (Testes!).
O resto é barulho de mercado e sopa de letrinhas (tecnologias que em 3 anos vão mudar)!