 |
| Bellacosa Mainframe e a engenharia de software sem misterios parte I |
☕ Um Café no Bellacosa Mainframe
Da Ideia ao Código: A Engenharia de Software Sem Mistérios
O Guia Definitivo do Programador COBOL Padawan para Entender Como Nascem os Sistemas que Movem o Mundo — Inspirado no Universo de Star Trek
"A lógica é o começo da sabedoria, não o fim."
— Sr. Spock
Introdução — A Ponte de Comando da USS Enterprise e o IBM Z
Existe uma cena recorrente em praticamente toda série de Star Trek.
O Capitão Kirk recebe uma missão.
Antes de simplesmente sair acelerando rumo ao desconhecido, uma sequência acontece quase sempre da mesma forma:
Uhura recebe as comunicações;
Sulu calcula a rota;
Chekov verifica a navegação;
Scotty analisa os motores;
Dr. McCoy avalia a tripulação;
Spock analisa os riscos.
Somente depois disso...
Warp Factor!
Curiosamente...
É exatamente assim que funciona um projeto de software.
O programador iniciante costuma imaginar que um sistema nasce quando alguém abre o Visual Studio Code, o IDz ou o ISPF e começa a escrever COBOL.
Na realidade...
O código representa apenas a ponta do iceberg.
Antes de existir uma única linha de código, dezenas de profissionais trabalharam durante semanas — ou meses — planejando tudo.
Foi justamente essa percepção que criou uma nova ciência chamada:
Engenharia de Software
E é exatamente essa jornada que faremos hoje.
Pegue sua caneca de café.
Ajuste o brilho do terminal 3270.
Ative os sensores de longo alcance.
Nossa missão começa agora.
Diário de Bordo — Stardate 2026
Imagine que a Federação precisa desenvolver um novo sistema para controlar toda a logística das naves da Frota Estelar.
Esse sistema deverá controlar:
combustível (Dilithium)
tripulação
armamentos
manutenção
suprimentos
teletransporte
missões
Parece simples.
Mas...
Como garantir que um erro nunca destrua uma nave inteira?
É exatamente para isso que existe a Engenharia de Software.
Capítulo 1 — A Grande Crise do Software
Nos anos 50 e início dos anos 60, programar era relativamente simples.
Os programas eram pequenos.
Poucas pessoas trabalhavam neles.
Mas os computadores ficaram cada vez maiores.
Surgiram:
bancos
companhias aéreas
governos
seguradoras
sistemas militares
De repente surgiram programas com:
Resultado?
Uma verdadeira catástrofe.
Projetos atrasavam anos.
Custavam dezenas de vezes mais.
Nunca terminavam.
Essa situação ficou conhecida como:
Software Crisis
Foi ela que deu origem à Engenharia de Software.
O verdadeiro significado de Software
As apostilas mostram:
Software = Programas + Dados + Documentação
Na prática moderna...
Software significa muito mais.
Um sistema corporativo normalmente inclui:
código COBOL
programas Java
APIs REST
filas MQ
banco Db2
VSAM
IMS
documentação
monitoramento
pipelines CI/CD
segurança
backups
auditoria
logs
scripts
automação
Ou seja...
O código é apenas uma pequena parte.
Easter Egg nº 1 ☕
No universo Star Trek, o computador da Enterprise nunca mostra apenas "o programa".
Ele conhece:
estado da nave
sensores
mapas
comunicações
banco de dados
diagnósticos
Isso é exatamente o conceito moderno de software.
Engenharia de Requisitos
Antes de escrever código existe uma pergunta extremamente difícil.
"O que exatamente devemos construir?"
Curiosamente...
Essa costuma ser a pergunta mais complicada de todo projeto.
Imagine um banco dizendo:
"Queremos um sistema PIX."
Pronto?
Claro que não.
Agora começam centenas de perguntas.
Quem pode transferir?
Existe limite?
Qual horário?
Pessoa física?
Pessoa jurídica?
Existe auditoria?
Existe rollback?
Existe LGPD?
Existe dupla autenticação?
Existe assinatura digital?
Existe timeout?
Existe integração com BACEN?
Perceba.
Nenhuma dessas perguntas envolve COBOL.
O Analista é um Investigador Vulcano
Spock nunca tira conclusões precipitadas.
Ele primeiro coleta evidências.
Depois formula hipóteses.
Depois valida.
Um bom analista faz exatamente isso.
Ele investiga.
Questiona.
Confirma.
Documenta.
Engenharia de Requisitos é Engenharia de Perguntas
Quanto melhor forem as perguntas...
Melhor será o software.
Existe um velho ditado da IBM:
Um requisito mal entendido custa centenas de horas de retrabalho.
Requisitos Funcionais
São aqueles que respondem:
"O sistema faz o quê?"
Exemplos:
Consultar saldo
Transferir PIX
Emitir boleto
Gerar extrato
Cadastrar cliente
Calcular juros
Tudo isso é comportamento.
Requisitos Não Funcionais
Agora entra uma categoria que muitos iniciantes ignoram.
Ela responde:
"Como o sistema deve funcionar?"
Por exemplo.
Consultar saldo.
↓
Em menos de 300 milissegundos.
Transferir dinheiro.
↓
Disponibilidade de 99,999%.
Cadastrar cliente.
↓
Suportar 50 mil usuários simultâneos.
Esses requisitos normalmente definem se o projeto será aprovado ou não.
O Segredo do Mainframe
Por que um IBM Z consegue processar bilhões de transações?
Porque praticamente todos os seus requisitos importantes são...
Não funcionais.
Disponibilidade.
Escalabilidade.
Confiabilidade.
Segurança.
Performance.
Curiosidade ☕
A famosa meta de 99,999% de disponibilidade ("cinco noves") significa apenas alguns minutos de indisponibilidade por ano. Esse nível é perseguido por plataformas de missão crítica como o IBM Z porque uma interrupção pode afetar milhões de clientes e transações.
Como levantar requisitos
Existem diversas técnicas.
As mais usadas são:
Entrevistas
Observação
Questionários
Brainstorming
Protótipos
Workshops
O poder da observação
Imagine automatizar um caixa bancário.
Você pergunta:
"Como você trabalha?"
Ele responde.
Mas...
Quando você o observa...
Descobre atalhos.
Planilhas escondidas.
Papéis.
Post-its.
Macetes.
Fluxos nunca documentados.
Isso acontece diariamente nas empresas.
O Documento Mais Importante do Projeto
Depois de semanas de entrevistas nasce um documento.
O famoso:
SRS
Software Requirement Specification
Ele é praticamente a Constituição do projeto.
Tudo nasce dele.
Tudo termina nele.
O que existe em um SRS?
Escopo.
Objetivos.
Glossário.
Casos de uso.
Regras de negócio.
Integrações.
Restrições.
Mensagens.
Fluxos.
Requisitos funcionais.
Requisitos não funcionais.
Critérios de aceitação.
No mundo IBM Z, muitas organizações utilizam documentos equivalentes, às vezes com outros nomes, mas a função é a mesma: registrar claramente o que será construído.
A Validação
Agora acontece algo extremamente importante.
Antes de programar...
Pergunta-se:
"Está correto?"
É muito mais barato descobrir um erro aqui do que meses depois.
A Regra dos Custos
Existe um princípio amplamente aceito na Engenharia de Software:
Quanto mais tarde um defeito é encontrado, maior tende a ser o custo para corrigi-lo.
Encontrar uma falha durante a análise geralmente é muito mais barato do que descobri-la após a implantação em produção.
Arquitetura
Agora começa outra etapa.
Imagine construir a USS Enterprise.
Você começaria instalando os motores?
Claro que não.
Primeiro existe um projeto.
Com software acontece igual.
Arquitetura responde perguntas gigantes
Será:
Monolito?
Microserviços?
Mainframe?
Cloud?
MQ?
REST?
Kafka?
Db2?
VSAM?
IMS?
CICS?
Nada disso envolve código ainda.
Um exemplo IBM Z
Imagine uma compra pela Internet.
O fluxo pode ser:
Cliente
↓
API
↓
z/OS Connect
↓
CICS
↓
Programa COBOL
↓
Db2
↓
MQ
↓
Sistema de Estoque
Isso é arquitetura.
Arquitetura em Camadas
As apostilas mostram:
Presentation
Business
Data
Database
Curiosamente...
Muitos sistemas COBOL já utilizavam esse conceito décadas antes da popularização dos frameworks modernos.
Tela BMS.
↓
Programa COBOL.
↓
Db2.
É uma separação de responsabilidades.
Microserviços
Hoje muito se fala em Microservices.
A ideia é dividir um sistema enorme em pequenos serviços independentes.
Exemplo:
PIX
Cartões
Empréstimos
Investimentos
Clientes
Cada um evolui de forma independente.
Mas isso não significa que seja sempre a melhor escolha. Em muitos cenários, um monólito bem projetado é mais simples de desenvolver e manter.
HLD — High Level Design
Agora a arquitetura vira documento.
O HLD mostra:
Grandes módulos.
Integrações.
Banco.
Protocolos.
Fluxo de dados.
Não entra nos detalhes.
É o mapa da cidade.
LLD — Low Level Design
Agora sim.
Entramos no nível do desenvolvedor.
O LLD explica:
Algoritmos.
Tabelas.
Campos.
Índices.
Funções.
Pseudocódigo.
Fluxogramas.
Entradas.
Saídas.
Mensagens.
Agora o programador consegue escrever código.
Exemplo COBOL
Imagine um programa chamado:
COBPIX01
O LLD pode dizer:
Entrada:
Processamento:
validar conta
consultar saldo
verificar limite
debitar
registrar auditoria
gravar MQ
atualizar Db2
executar COMMIT
Saída:
código de retorno
novo saldo
mensagem ao usuário
Perceba.
O código praticamente nasce desse documento.
O Pseudocódigo
Uma das ferramentas mais antigas da Engenharia.
Ele permite pensar antes de programar.
Receber conta
↓
Conta existe?
↓
Não
Erro
↓
Sim
Saldo suficiente?
↓
Não
Saldo insuficiente
↓
Sim
Debitar
↓
Registrar log
↓
Atualizar Db2
↓
Commit
↓
Retornar sucesso
Quando esse fluxo está correto...
Programar fica muito mais simples.
SDLC na prática
Todo projeto percorre algo semelhante a:
Ideia
↓
Requisitos
↓
Validação
↓
Arquitetura
↓
HLD
↓
LLD
↓
Codificação
↓
Testes
↓
Implantação
↓
Manutenção
↓
Nova evolução
Perceba que a programação aparece apenas na metade da jornada.
Modelos de Desenvolvimento
A Engenharia criou diversos modelos para organizar esse fluxo.
Waterfall
Segue uma sequência rígida.
Requisitos.
↓
Projeto.
↓
Código.
↓
Testes.
↓
Produção.
Ainda é muito usado em projetos com requisitos estáveis, como diversos sistemas governamentais e aplicações de missão crítica.
Modelo V
Cada etapa de desenvolvimento possui uma etapa correspondente de teste.
Requisitos
⇔ Testes de Aceitação
Projeto
⇔ Testes de Sistema
Arquitetura
⇔ Testes de Integração
Módulos
⇔ Testes Unitários
É excelente para ambientes onde rastreabilidade e qualidade são fundamentais.
Modelo Incremental
Em vez de entregar tudo de uma vez, o sistema cresce por partes.
Primeiro:
Login.
Depois:
Cadastro.
Depois:
Relatórios.
Depois:
Integrações.
Cada incremento entrega valor ao usuário.
Modelo Espiral
Muito usado em projetos grandes e de alto risco.
Cada volta da espiral passa por:
Planejamento.
↓
Análise de riscos.
↓
Desenvolvimento.
↓
Avaliação do cliente.
↓
Nova volta.
É um modelo que combina evolução contínua com gestão de riscos.
Os Atributos da Qualidade
Um software não é considerado bom apenas porque "funciona".
Ele precisa ser:
✔ Correto
✔ Confiável
✔ Eficiente
✔ Seguro
✔ Escalável
✔ Portável
✔ Fácil de manter
✔ Disponível
✔ Fácil de usar
Esses atributos influenciam diretamente o sucesso de um sistema em produção.
A Engenharia Invisível
Quando um cliente faz um PIX em dois segundos...
Ele nunca imagina que por trás daquela simplicidade existiram:
Meses de análise.
Centenas de reuniões.
Documentos.
Diagramas.
Arquitetura.
Revisões.
Testes.
Validações.
Planejamento.
Essa é a parte invisível da Engenharia de Software.
Easter Egg nº 2 — A Diretriz Principal
Em Star Trek existe a famosa Prime Directive, um conjunto de regras criado para evitar consequências desastrosas.
Na Engenharia de Software existe um princípio parecido:
Nunca comece a codificar antes de compreender completamente o problema que precisa ser resolvido.
Escrever código sem requisitos claros costuma produzir sistemas que funcionam tecnicamente, mas não atendem ao negócio.
Lições do Sr. Spock para o Programador COBOL Padawan
Se Spock fosse um arquiteto de software no IBM Z, provavelmente deixaria estas recomendações:
A lógica deve vir antes do código.
Requisitos mal definidos geram defeitos bem implementados.
Um bom design reduz a complexidade futura.
Documentação não substitui conhecimento, mas preserva conhecimento.
Teste não cria qualidade; ele revela a qualidade do que foi construído.
O programa termina de ser escrito, mas o software continua evoluindo durante anos.
Conclusão — A Verdadeira Missão da Engenharia de Software
Muitos iniciantes acreditam que o objetivo de um desenvolvedor é escrever muitas linhas de código.
Com o tempo, descobrem que acontece justamente o contrário.
Os melhores engenheiros escrevem o código certo, no momento certo, apoiado por requisitos claros, uma arquitetura consistente e um projeto bem elaborado.
É exatamente por isso que sistemas COBOL executados em IBM Z continuam sustentando bancos, seguradoras, governos e bolsas de valores após décadas de evolução. Eles não sobreviveram apenas por causa da linguagem ou do hardware, mas porque foram construídos sobre fundamentos sólidos de Engenharia de Software: análise cuidadosa, documentação, arquitetura, testes e manutenção disciplinada.
Assim como a USS Enterprise não parte para uma missão sem planejamento, análise de riscos e coordenação entre toda a tripulação, um grande sistema corporativo também não nasce de improviso. Cada documento, cada diagrama, cada revisão e cada teste representa um membro da "tripulação" trabalhando para que, quando chegar o momento da implantação, tudo funcione de forma segura, previsível e confiável.
No fim da jornada, o verdadeiro Padawan COBOL percebe que programar é uma habilidade importante, mas compreender a Engenharia de Software é o que transforma um programador em um engenheiro capaz de construir sistemas que resistem ao tempo — exatamente como os grandes sistemas do IBM Z e as lendárias naves da Frota Estelar. Vida longa e próspera! 🖖
