☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta SDLC. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta SDLC. Mostrar todas as mensagens

domingo, 2 de agosto de 2026

IBM Bob : O Holocron do Padawan — Da Primeira Pergunta até os Agentes Inteligentes

 

Bellacosa Mainframe e o holocron do conhecimento do ibm bob

☕ Um Café no Bellacosa Mainframe

IBM Bob para Programadores COBOL

O Holocron do Padawan — Da Primeira Pergunta até os Agentes Inteligentes

"Quando um programador COBOL encontra uma IA pela primeira vez, a tendência é pensar que ela escreve código. Depois de alguns dias percebe que ela faz muito mais. Depois de alguns meses percebe que quem realmente mudou foi a forma de pensar sobre desenvolvimento."


Durante décadas nós aprendemos uma sequência relativamente estável.

Requisito
↓
Análise
↓
Codificação
↓
Compilação
↓
Teste
↓
Produção

O IBM Bob não muda esse fluxo.

Ele muda quem participa dele.

O desenvolvedor deixa de trabalhar sozinho e passa a trabalhar acompanhado por uma IA especializada.

Essa é exatamente a ideia por trás de praticamente todas as fases do treinamento.



Capítulo 1 — O que é o IBM Bob?

O erro mais comum é pensar:

"Bob é um ChatGPT."

Não.

Bob é um AI Software Engineer.

Ele foi construído para acompanhar todo o ciclo de vida do software (SDLC).

Ele entende:

  • código

  • arquitetura

  • documentação

  • Git

  • Pull Request

  • testes

  • APIs

  • banco de dados

  • DevOps

  • Cloud

  • Mainframe

Ele não responde apenas perguntas.

Ele participa do desenvolvimento.



Capítulo 2 — O verdadeiro SDLC

Praticamente em vários momentos do curso falam do SDLC.

A ordem correta é:

Planejamento

↓

Levantamento de requisitos

↓

Análise

↓

Design

↓

Implementação

↓

Testes

↓

Deploy

↓

Manutenção

Nunca confunda.

Os testes nunca vêm antes dos requisitos.


Planejamento

Aqui respondemos:

O que será construído?

Quem vai usar?

Qual problema resolve?


Requisitos

Aqui descobrimos:

  • regras de negócio

  • usuários

  • limitações

  • integrações

É exatamente como conversar com o cliente antes de escrever um COBOL.


Design

Aqui definimos

Arquitetura.

Tecnologias.

Banco.

API.

Cloud.

Infraestrutura.

É a planta da casa.


Implementação

Aqui escrevemos código.

COBOL.

Java.

Python.

TypeScript.

Não importa.

O design vira código.


Testes

Somente agora validamos.

Não antes.


Capítulo 3 — Contexto é Rei

Uma das maiores mensagens do curso.

IA sem contexto é praticamente inútil.

Imagine perguntar:

Melhore esse programa.

Qual programa?

Qual arquivo?

Qual função?

Qual objetivo?

Agora compare com:

Arquivo:

CLIENTE.CBL

Objetivo:

Melhorar performance da leitura VSAM.

Não alterar layout.

Não modificar regras fiscais.

Não instalar bibliotecas.

Agora Bob entende.

Toda IA funciona melhor quando recebe contexto.



Capítulo 4 — Janela de Contexto

Outro assunto recorrente.

A Janela de Contexto é simplesmente tudo aquilo que Bob conhece naquele momento.

Ela contém:

  • conversa

  • arquivos

  • regras

  • prompts

  • histórico

  • documentos

Quanto maior o contexto útil,

melhor a resposta.

Quanto maior o contexto inútil,

pior a resposta.


Context Poisoning

Uma expressão importante.

Imagine manter aberto:

Projeto Banco A.

Depois mudar para

Projeto Banco B.

Mas esquecer documentos antigos.

Bob pode misturar regras.

Isso chama-se

Context Poisoning.

A IA passa a raciocinar baseada em informações erradas.



Capítulo 5 — Human in the Loop

Talvez seja o conceito mais importante do treinamento.

Bob nunca substitui o desenvolvedor.

Ele trabalha junto.

Você continua responsável por:

✔ validar

✔ revisar

✔ aprovar

✔ decidir

A IA sugere.

Você decide.


Capítulo 6 — Auto Approve

Bob pode executar ações automaticamente.

Mas existem níveis.

Exemplo:

Leitura

Pode abrir arquivos.

Pode listar diretórios.

Sem perguntar.

Já comandos perigosos

como

git reset

rm

git push

normalmente pedem confirmação.

Por quê?

Porque alterar um repositório é diferente de apenas ler um arquivo.


Capítulo 7 — Checkpoints

O que faz um checkpoint? Muitas vezes usamos o conceito mas não paramos para analisar e fazer um mapa mental.

Checkpoint significa:

Criar um ponto seguro.

Igual snapshot.

Antes de uma grande mudança:

✔ cria checkpoint

✔ modifica

✔ testa

✔ aprova

É exatamente igual ao conceito de backup antes de um grande IPL.



Capítulo 8 — Bob Rules

Aqui está um conceito excelente.

Imagine um programador COBOL.

Toda vez você escreve:

Sempre documente.

Nunca use GO TO.

Explique em português.

Isso é repetitivo.

As Bob Rules resolvem isso.

São regras permanentes.

Exemplo:

Sempre gerar comentários.

Nunca instalar dependências.

Usar Clean Code.

Elas ficam válidas para o projeto inteiro.



Capítulo 9 — Slash Commands

Enquanto Rules são permanentes,

Slash Commands são ações.

Exemplo:

/review

Revisar código.

/document

Gerar documentação.

/performance

Analisar desempenho.

São pequenas automações.


Capítulo 10 — agent.md

Uma excelente ideia.

O arquivo

agent.md

é um manual para Bob.

Ele registra:

  • arquitetura

  • convenções

  • decisões

  • padrões

  • organização

É muito parecido com um grande README técnico.


Capítulo 11 — Git

O curso insiste bastante nisso.

Fluxo correto.

git checkout -b

↓

editar

↓

commit

↓

push

↓

Pull Request

↓

Review

↓

Merge

Jamais:

Editar diretamente a Main.


Pull Request

Não é apenas enviar código.

É pedir revisão.


Code Review

Serve para verificar

✔ qualidade

✔ documentação

✔ arquitetura

✔ padrões

✔ clareza

✔ links

✔ consistência

Não apenas bugs.



Capítulo 12 — MCP

Aqui começa o futuro.

Model Context Protocol.

Imagine um cabo USB.

Você conecta:

Bob

Git

SQLite

Appwrite

GitHub

Filesystem

Terminal

APIs

Tudo usando um padrão.

Esse padrão chama-se MCP.


MCP Local

Vale apenas para um projeto.


MCP Global

Vale para todos.


MCP Remoto

Permite conversar com serviços externos.

Exemplo:

Appwrite.


API Keys

Sem credenciais

Bob não entra.

Assim como RACF protege um dataset,

API Keys protegem serviços Cloud.



Capítulo 13 — LLM

Outra sequência cobrada.

LLM

↓

Chatbot

↓

Copilot

↓

Agente

LLM

Motor.


Chatbot

Conversa.


Copilot

Ajuda.


Agente

Executa.

Planeja.

Decide.

Corrige.



Capítulo 14 — Sistemas Agentic

Agente faz muito mais.

Ele consegue:

Planejar.

Executar.

Reavaliar.

Corrigir.

Continuar.

Esse conceito aparece sempre que usamos um chat bot, seria o nosso passo a passo na execução da tarefa.


Multistep

Executa várias etapas.

Não apenas uma.


Self Correction

Errou?

Corrige sozinho.


Human in the Loop

Mesmo assim,

o desenvolvedor continua aprovando.



Capítulo 15 — Analytics

Outro bloco do curso.

Bob Analytics mostra:

Consumo.

Bob Coins.

Plano.

Uso.

Métricas.


Bob Coins

Padronizam consumo.

Não importa qual modelo está por trás.


Trial

Temporário.


PRO

Renova Bob Coins mensalmente.


Overage

Uma pegadinha da prova.

No treinamento foi enfatizado que:

o overage precisa ser reativado manualmente a cada mês para continuar em uso.

Mesmo que essa característica possa variar entre serviços, essa é a resposta esperada no contexto da aula.



Capítulo 16 — O Grande Mapa Mental

Cliente

↓

Requisitos

↓

Design

↓

Bob entende contexto

↓

Rules

↓

Slash Commands

↓

agent.md

↓

Checkpoint

↓

Implementação

↓

Git

↓

Commit

↓

Push

↓

Pull Request

↓

Review

↓

Merge

↓

Deploy

↓

Analytics

↓

Melhoria Contínua


O Pensamento Bellacosa Mainframe

Quando comecei no mainframe, lá no final dos anos 1980, a inteligência estava concentrada em dois lugares: na cabeça do analista experiente e nos milhares de programas COBOL que sustentavam o negócio. Hoje, continuamos precisando dessa experiência, mas ganhamos um novo parceiro.

O IBM Bob não substitui o programador COBOL. Ele não conhece melhor o negócio do que quem mantém aquele sistema há anos. O que ele faz é acelerar tarefas repetitivas, organizar informações, sugerir melhorias e reduzir o tempo gasto com atividades mecânicas.

Pense nele como um novo integrante da equipe. Ele trabalha rápido, lê milhares de arquivos em segundos e nunca se cansa de revisar código. Porém, ainda depende do arquiteto, do analista e do desenvolvedor para definir o rumo correto.

No fim das contas, a principal lição de todo esse treinamento não é aprender comandos, MCPs ou Bob Rules. É compreender uma nova forma de desenvolver software:

A IA executa. O desenvolvedor direciona. A experiência humana continua sendo o verdadeiro sistema operacional por trás de qualquer projeto.

Esse é o verdadeiro espírito do Bellacosa Mainframe: combinar décadas de conhecimento em engenharia de software com as novas capacidades da Inteligência Artificial, formando um desenvolvedor que entende tanto o legado quanto o futuro.

sábado, 4 de outubro de 2025

☕💾🔥 ENGENHARIA DE SOFTWARE — O “SISTEMA OPERACIONAL INVISÍVEL” QUE SEPARA PROGRAMADORES COMUNS DE PROFISSIONAIS ENTERPRISE 🔥💾☕

 

Bellacosa Mainframe e a Engenharia de Software

☕💾🔥 ENGENHARIA DE SOFTWARE — O “SISTEMA OPERACIONAL INVISÍVEL” QUE SEPARA PROGRAMADORES COMUNS DE PROFISSIONAIS ENTERPRISE 🔥💾☕

Muita gente entrando no mundo COBOL/mainframe acredita que:

“Engenharia de software = aprender linguagem.”

☠️🔥

Mas aí acontece o primeiro trauma corporativo real:

  • ABEND em produção;
  • batch atrasado;
  • janela estourada;
  • rollback;
  • incidente crítico;
  • auditoria;
  • problema de performance DB2;
  • mudança quebrando outro sistema;
  • integração falhando às 3h da manhã.

E nesse momento o programador descobre:

Engenharia de software NÃO é apenas programar.

Ela é:

  • organização;
  • arquitetura;
  • previsibilidade;
  • qualidade;
  • processos;
  • sobrevivência operacional.

☕ O QUE É ENGENHARIA DE SOFTWARE DE VERDADE?

Engenharia de software é:

construir sistemas grandes, confiáveis, escaláveis e sustentáveis sem transformar a empresa num apocalipse tecnológico.

🔥💾☕


O ERRO MAIS COMUM DO PROGRAMADOR JÚNIOR

O iniciante normalmente pensa assim:

“Se compilou e rodou, está pronto.”

☠️☠️☠️

No mundo enterprise isso NÃO significa nada.

Porque um software corporativo precisa:

  • funcionar;
  • escalar;
  • ser seguro;
  • ser auditável;
  • ser documentado;
  • sobreviver anos;
  • suportar manutenção;
  • integrar com dezenas de sistemas;
  • não destruir produção.

☕💾 O MAINFRAME ENSINOU ISSO MUITO ANTES DA CLOUD

A ironia é fantástica.

Hoje o mercado fala:

  • DevOps;
  • SRE;
  • observabilidade;
  • resiliência;
  • alta disponibilidade;
  • governança.

Mas o mundo mainframe já fazia isso desde os anos 70.

🔥☕


UM PROGRAMADOR COBOL NÃO ESCREVE “APENAS PROGRAMAS”

Ele frequentemente participa de:

  • sistemas bancários;
  • processamento de folha;
  • cartões;
  • PIX;
  • compensação;
  • seguros;
  • governo;
  • telecom.

Ou seja:

software que movimenta bilhões.


☕ A DIFERENÇA ENTRE “CODAR” E “ENGENHARIA”

Programador comum

“Vou fazer funcionar.”

Engenheiro de software

“Como isso vai sobreviver 15 anos em produção?”

🔥💾


O SDLC — O CICLO DA SOBREVIVÊNCIA CORPORATIVA

Toda empresa séria usa algum tipo de SDLC.

Software Development Life Cycle


As etapas clássicas

Requirements

Design

Development

Testing

Deployment

Maintenance

☕ O QUE O JÚNIOR NORMALMENTE NÃO PERCEBE

O código é apenas UMA etapa pequena.

Grande parte do esforço real está em:

  • entender negócio;
  • validar regras;
  • testar;
  • homologar;
  • documentar;
  • subir produção;
  • monitorar;
  • manter.

☠️ O MAIOR CEMITÉRIO DA TI

Projetos falham mais por:

  • requisitos ruins;
  • arquitetura ruim;
  • falta de comunicação;
  • falta de testes;

do que por linguagem.


☕💾 REQUISITOS — O “BUG” QUE NASCE ANTES DO CÓDIGO

Muitos sistemas falham porque:

o time implementou corretamente…
o requisito errado.

☠️🔥


Exemplo COBOL clássico

Usuário diz:

“quero calcular juros.”

Mas ninguém definiu:

  • regra;
  • arredondamento;
  • calendário;
  • horário;
  • feriados;
  • timezone;
  • tratamento de exceção.

☠️☠️☠️

Resultado:

  • prejuízo;
  • auditoria;
  • incidente;
  • caos.

☕ TESTES — O SEGURO DE VIDA DO ENTERPRISE

Programador júnior frequentemente pensa:

“Mas na minha máquina funcionou.”

☠️🔥☠️🔥☠️🔥

Produção enterprise não perdoa isso.


Tipos de teste

Functional

A regra funciona?


Performance

Aguenta milhões de transações?


Regression

A correção quebrou outro sistema?


Security

Existe vulnerabilidade?


☕💾 MAINFRAME LEVA ISSO AO EXTREMO

Porque:

  • bancos não podem parar;
  • folha não pode falhar;
  • PIX não pode sumir;
  • cartão não pode duplicar;
  • batch não pode atrasar.

Então engenharia enterprise nasce da paranoia operacional.

🔥☕


VERSIONAMENTO — O “TIME MACHINE” CORPORATIVO

Sem versionamento:

  • ninguém sabe quem mudou;
  • ninguém sabe quando;
  • ninguém sabe por quê.

☠️🔥


Mundo moderno

  • Git
  • GitHub
  • GitLab

Mundo mainframe

  • Endevor
  • Changeman
  • Librarian

☕ O CONCEITO É O MESMO

Controlar:

  • mudanças;
  • histórico;
  • rollback;
  • rastreabilidade.

☕💾 ARQUITETURA — O CÉREBRO INVISÍVEL DO SISTEMA

Aqui o júnior normalmente desperta.

Porque descobre que:

sistemas grandes NÃO sobrevivem só com código.

Precisam:

  • organização;
  • integração;
  • escalabilidade;
  • segurança;
  • observabilidade.

Exemplo bancário

Frontend

API Gateway

Microservices

MQ

COBOL/CICS

DB2

Isso é engenharia enterprise.


☠️ MICROservices NÃO SÃO “MÁGICA”

Muita empresa cria:

400 APIs
+
500 containers
+
logs infinitos
+
monitoramento caótico

e chama isso de:

“transformação digital.”

☠️🔥☠️🔥☠️🔥


☕💾 O MAINFRAME ENSINOU ALGO IMPORTANTE

Centralização às vezes é:

  • mais segura;
  • mais simples;
  • mais eficiente.

Por isso muitos core bancários continuam no z/OS.


O GRANDE SEGREDO DA ENGENHARIA DE SOFTWARE

Ela NÃO é sobre tecnologia apenas.

Ela é sobre:

  • reduzir caos;
  • reduzir risco;
  • reduzir falhas;
  • organizar complexidade.

🔥☕


☕ O JÚNIOR QUE EVOLUI RÁPIDO ENTENDE ISSO

Linguagens mudam.

Ontem:

  • COBOL;
  • PL/I;
  • C.

Depois:

  • Java;
  • C#;
  • Python.

Agora:

  • IA assistida;
  • automação;
  • cloud native.

Mas:

  • lógica;
  • arquitetura;
  • qualidade;
  • engenharia;

continuam eternas.


☕💾 O FUTURO DO PROGRAMADOR COBOL

O mercado NÃO quer apenas:

“quem sabe COBOL.”

Quer:

  • APIs;
  • integração;
  • cloud;
  • automação;
  • observabilidade;
  • DevOps;
  • segurança;
  • engenharia moderna.

E AQUI ESTÁ A GRANDE VERDADE

Quem domina:

  • fundamentos enterprise;
  • processamento crítico;
  • arquitetura;
  • mentalidade operacional;

possui vantagem enorme no mercado moderno.

Porque MUITOS desenvolvedores atuais:

  • sabem framework;
  • sabem frontend;
  • sabem cloud;

mas nunca sustentaram:

  • processamento nacional;
  • batch crítico;
  • transações financeiras massivas.

☕💾🔥 CONCLUSÃO — ENGENHARIA DE SOFTWARE É A ARTE DE EVITAR O APOCALIPSE CORPORATIVO 🔥💾☕

Programar faz software funcionar.

Engenharia de software faz:

  • software sobreviver;
  • empresas continuarem operando;
  • sistemas escalarem;
  • produção não explodir às 2h da manhã.

E no fundo…

o mundo mainframe já sabia disso muito antes da internet virar moda. 💾☕🔥


quarta-feira, 21 de fevereiro de 2024

Metodologia Waterfall, o que é, para que serve, virtudes e defeitos

Bellacosa Mainframe apresenta a metodologia waterfall

Metodologia Waterfall: O Modelo Clássico que Ainda Sustenta os Maiores Sistemas do Mundo

Muito antes de termos Scrum, Kanban, DevOps, CI/CD e equipes ágeis entregando software em ciclos rápidos, existia uma metodologia que estabeleceu as bases da engenharia de software moderna: a Metodologia Waterfall, também conhecida como Modelo em Cascata. Criada para organizar projetos complexos de forma previsível e controlada, ela continua sendo amplamente utilizada em setores onde segurança, conformidade, documentação e rastreabilidade são essenciais, como bancos, seguradoras, governos, indústrias, telecomunicações, aeroespacial e, principalmente, no universo dos IBM Mainframes.

O princípio do Waterfall é simples e poderoso: cada fase do projeto deve ser concluída antes do início da próxima. Dessa forma, levantamento de requisitos, análise, projeto, desenvolvimento, testes, implantação e manutenção seguem uma sequência lógica, reduzindo ambiguidades e permitindo um rigoroso controle de qualidade.

Embora muitos considerem o Waterfall ultrapassado diante das metodologias ágeis, a realidade é bem diferente. Bilhões de transações financeiras executadas diariamente em sistemas COBOL, CICS, Db2 e IBM Z continuam sendo desenvolvidas e mantidas utilizando princípios herdados desse modelo. Em ambientes onde uma alteração incorreta pode causar prejuízos milionários, previsibilidade vale mais do que velocidade.

Neste artigo você entenderá o que é a Metodologia Waterfall, como ela surgiu, quais são suas etapas, vantagens, desvantagens, diferenças em relação ao Agile, Scrum e DevOps, quando ela ainda representa a melhor escolha e por que continua sendo um dos pilares da engenharia de software corporativa. Seja você um estudante, desenvolvedor, analista de sistemas ou profissional de Mainframe, conhecer o Waterfall é compreender as origens da disciplina que moldou praticamente toda a indústria de desenvolvimento de software moderna.

Bellacosa Mainframe e a metodologia de desenvolvimento waterfall

Muitas linhas foram escritas, defensores e detratores, propagandistas de outras metodologias, coachs e consultores tentando vender seu peixe, pintando um monstro, atacando uma metodologia, que como tudo na vida, ela tem seus pros e contras.
 

quarta-feira, 21 de julho de 2021

Da Ideia ao Código: A Engenharia de Software Sem Mistérios - Parte I

 

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:

  • milhões de linhas

  • milhares de tabelas

  • centenas de desenvolvedores

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:

  • Agência

  • Conta

  • Valor

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! 🖖


☕ Um Café no Bellacosa Mainframe

Engenharia de Software sem Mistérios — Parte 2

Da USS Enterprise ao IBM Z

Descubra como arquitetos pensam, como projetos evoluem e como um programador COBOL pode enxergar além do código, compreendendo SRS, HLD, LLD, modelos Incremental e Espiral, arquitetura, qualidade e desenvolvimento de sistemas no IBM Z.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...