Translate

segunda-feira, 30 de abril de 2007

Quais outras ferramentas um analista mainframe usa para desenhar e desenvolver software

Bellacosa Mainframe e as ferramentas de um programador mainframe

Quais outras ferramentas um analista mainframe usa para desenhar e desenvolver software

 Um Analista Mainframe utiliza muito mais do que fluxogramas. Ao longo do ciclo de vida de um sistema, ele emprega diferentes técnicas para analisar, modelar, documentar e comunicar soluções. Algumas são tradicionais e existem desde os anos 1970; outras vieram da Engenharia de Software moderna.


1. Fluxograma

É o mais conhecido.

Representa a sequência de execução de um processo.

Exemplo:

Início

↓

Ler Cliente

↓

Cliente Existe?

↓

Sim

↓

Consultar Db2

↓

Fim

É excelente para explicar algoritmos.


2. BPMN (Business Process Model and Notation)

Muito usado por bancos.

Mostra processos completos do negócio.

Exemplo:

Cliente

↓

Solicita Empréstimo

↓

Análise de Crédito

↓

Aprovado?

↓

Sim

↓

Liberação

Enquanto o fluxograma mostra um algoritmo, o BPMN mostra o processo de negócio inteiro.


3. UML (Unified Modeling Language)

A UML possui diversos diagramas.

É uma das ferramentas mais importantes da Engenharia de Software.


Diagrama de Casos de Uso

Mostra quem utiliza o sistema.

Cliente

↓

Consultar Saldo

↓

Transferir PIX

↓

Pagar Conta

Diagrama de Classes

Muito usado em Java e C#.

No Mainframe também ajuda a entender modelos de dados.

Cliente

Nome

CPF

Saldo

↓

Conta

Diagrama de Sequência

Mostra quem conversa com quem.

Exemplo:

Cliente

↓

API

↓

CICS

↓

COBOL

↓

Db2

↓

Resposta

Hoje é um dos diagramas mais utilizados em integrações REST.


Diagrama de Atividades

É semelhante ao fluxograma, porém mais poderoso.

Permite representar:

  • paralelismo;

  • sincronização;

  • múltiplos caminhos;

  • exceções.


Diagrama de Estados

Mostra a vida de um objeto.

Exemplo:

Novo Pedido

↓

Pago

↓

Separado

↓

Enviado

↓

Entregue

4. DFD (Data Flow Diagram)

Muito popular nas décadas de 1980 e 1990.

Mostra como os dados circulam.

Cliente

↓

Sistema

↓

Arquivo VSAM

↓

Relatório

Ainda é encontrado em documentação antiga de Mainframe.


5. DER (Diagrama Entidade-Relacionamento)

Fundamental para Db2.

Mostra as tabelas e seus relacionamentos.

CLIENTE

↓

CONTA

↓

MOVIMENTO

↓

CARTÃO

É praticamente obrigatório para quem trabalha com banco de dados.


6. Matriz CRUD

CRUD significa:

  • Create

  • Read

  • Update

  • Delete

Ela responde:

Quem cria?

Quem consulta?

Quem altera?

Quem exclui?

Exemplo:

ProgramaClienteContaMovimento
COB001CRC
COB002RUR

Muito utilizada em sistemas bancários.


7. Árvore de Decisão

Excelente para regras complexas.

Exemplo:

Cliente Premium?

├── Sim

│     ↓

│ Limite Especial

└── Não

      ↓

Analisar Score

Muito usada em seguros.


8. Tabela de Decisão

Quando existem dezenas de regras.

Exemplo:

SalárioScoreAprovação
AltoAltoSim
AltoBaixoRevisão
BaixoAltoRevisão
BaixoBaixoNão

Muito comum em crédito bancário.


9. Wireframe

Antes da tela existir.

Desenha a interface.

+---------------------+

Conta: __________

Senha: _________

[ Entrar ]

+---------------------+

Muito usado por UX.


10. Protótipo

Vai além do Wireframe.

Já possui aparência próxima da tela final.

Ferramentas:

  • Figma

  • Adobe XD

  • Balsamiq


11. Story Mapping

Muito usado em Scrum.

Cliente

↓

Login

↓

Consultar

↓

Transferir

↓

Pagar

↓

Investir

Ajuda a organizar entregas.


12. User Story

Em vez de documentos enormes.

Exemplo:

Como cliente,

desejo consultar meu saldo,

para saber quanto dinheiro tenho disponível.

Hoje praticamente todo projeto ágil utiliza User Stories.


13. Jornada do Usuário (User Journey)

Mostra toda a experiência.

Aplicativo

↓

Login

↓

PIX

↓

Comprovante

↓

Logout

Ajuda a descobrir dificuldades.


14. Arquitetura de Sistemas

Mostra a visão macro.

Aplicativo

↓

API Gateway

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

Db2

↓

MQ

Muito usada em arquiteturas híbridas.


15. Arquitetura Física

Mostra servidores.

Internet

↓

Firewall

↓

API

↓

IBM Z

↓

Storage

Utilizada pela infraestrutura.


16. Mapa de Integrações

Mostra quem conversa com quem.

SAP

↓

MQ

↓

COBOL

↓

Db2

↓

CRM

↓

PIX

Muito comum em grandes bancos.


17. Diagrama de Deploy

Mostra onde cada aplicação será executada.

LPAR A

↓

CICS

↓

COBOL

↓

Db2

↓

MQ

18. Modelo C4

Uma abordagem moderna para arquitetura de software, dividida em quatro níveis:

  • Contexto: como o sistema se relaciona com usuários e outros sistemas.

  • Contêineres: aplicações, bancos de dados, APIs e serviços.

  • Componentes: módulos internos de cada aplicação.

  • Código: classes, programas ou componentes específicos.

É muito útil para documentar ambientes híbridos envolvendo IBM Z, microsserviços e nuvem.


Ferramentas utilizadas

Um analista normalmente utiliza:

  • Microsoft Visio

  • diagrams.net (Draw.io)

  • Lucidchart

  • IBM Blueworks Live

  • Enterprise Architect (Sparx Systems)

  • Visual Paradigm

  • Figma

  • Balsamiq

  • Bizagi Modeler

  • Microsoft PowerPoint

  • Microsoft Word

  • Confluence

  • Jira

  • Mermaid

  • PlantUML


O que um Analista Mainframe usa no dia a dia?

Em um banco de grande porte, é comum encontrar esta combinação:

  • Levantamento de requisitos → User Stories, Casos de Uso e entrevistas.

  • Modelagem do processo → BPMN.

  • Regras de negócio → Tabelas de Decisão e Árvores de Decisão.

  • Modelagem de dados → DER.

  • Integrações → Diagramas de Sequência e Mapas de Integração.

  • Arquitetura → Modelo C4 e Diagramas de Arquitetura.

  • Lógica dos programas COBOL → Fluxogramas e Diagramas de Atividades.

  • Documentação → Confluence, Word ou ferramentas corporativas.

Uma sugestão de roteiro de estudos

Para quem deseja se tornar um Analista Mainframe completo, uma boa sequência é:

  1. Fluxogramas

  2. Algoritmos e Pseudocódigo

  3. BPMN

  4. UML (Casos de Uso, Atividades e Sequência)

  5. DER e modelagem de dados

  6. Tabelas e Árvores de Decisão

  7. Arquitetura de Software (C4)

  8. COBOL, CICS, Db2, JCL e MQ

  9. APIs REST, z/OS Connect e integrações

  10. Métodos Ágeis (Scrum, User Stories e Story Mapping)

Essa combinação permite conversar com usuários de negócio, desenvolvedores COBOL, DBAs, arquitetos e equipes de infraestrutura, cobrindo praticamente todo o ciclo de desenvolvimento de software em ambientes IBM Mainframe modernos.

domingo, 29 de abril de 2007

O que é Fluxograma?

 

Bellacosa Mainframe o que é um fluxograma

O que é Fluxograma?

Imagine que um banco deseja explicar como funciona a aprovação de um empréstimo.

Em vez de escrever dezenas de páginas de texto, ele desenha um diagrama mostrando cada etapa do processo.

Esse desenho é chamado de fluxograma.

No ambiente Mainframe, o fluxograma é uma das ferramentas mais importantes para documentar sistemas, compreender programas COBOL, analisar regras de negócio e planejar novos projetos.

Ele permite visualizar o funcionamento de um sistema antes mesmo de escrever a primeira linha de código.


Definição simples

Um fluxograma é um diagrama que representa graficamente a sequência de passos de um processo, algoritmo ou sistema.

Ele utiliza símbolos padronizados ligados por setas para mostrar:

  • início;

  • atividades;

  • decisões;

  • entradas;

  • saídas;

  • término.

Em outras palavras:

O fluxograma é o mapa visual do funcionamento de um sistema.


Uma analogia simples

Imagine um mapa de metrô.

Você consegue visualizar:

  • onde começa a viagem;

  • quais estações serão percorridas;

  • onde trocar de linha;

  • onde termina o percurso.

O fluxograma faz exatamente isso com um programa ou processo.


Para que serve?

No Mainframe ele ajuda a:

  • entender programas COBOL;

  • documentar sistemas;

  • analisar processos;

  • descobrir erros;

  • explicar regras de negócio;

  • facilitar manutenção;

  • treinar novos funcionários;

  • planejar alterações.


Como funciona?

Imagine um sistema simples de consulta de saldo.

O fluxo pode ser:

Início

↓

Informar Conta

↓

Conta Existe?

↓

Sim → Consulta Db2

↓

Exibe Saldo

↓

Fim

↓

Não

↓

Mensagem de Erro

↓

Fim

Mesmo sem conhecer COBOL, é possível compreender o funcionamento.


Símbolos principais

Oval

Representa:

  • início;

  • fim.

(Início)

(Fim)

Retângulo

Representa uma atividade.

Exemplo:

Consultar Cliente

Losango

Representa uma decisão.

Exemplo:

Saldo suficiente?

Possui normalmente duas saídas:

  • Sim

  • Não


Paralelogramo

Representa:

  • entrada;

  • saída.

Exemplo:

Informar CPF

Exibir Mensagem

Setas

Mostram a direção do fluxo.

↓

→

←

Exemplo completo

Imagine um saque em caixa eletrônico.

Início

↓

Inserir Cartão

↓

Digitar Senha

↓

Senha Correta?

↓

Não

↓

Mensagem

↓

Fim

↓

Sim

↓

Escolher Valor

↓

Saldo Disponível?

↓

Não

↓

Saldo Insuficiente

↓

Fim

↓

Sim

↓

Debitar Conta

↓

Liberar Dinheiro

↓

Emitir Comprovante

↓

Fim

Fluxograma e COBOL

Antes da programação:

Fluxograma

↓

Especificação

↓

Programa COBOL

↓

Testes

O fluxograma ajuda o programador a entender toda a lógica antes de escrever o código.


Fluxograma e Mainframe

É comum utilizá-lo para representar:

  • programas COBOL;

  • transações CICS;

  • Jobs Batch;

  • fluxos JCL;

  • integrações MQ;

  • APIs REST;

  • processos bancários;

  • regras de negócio.


Exemplo em um banco

Pagamento PIX

Cliente

↓

Aplicativo

↓

API

↓

CICS

↓

Programa COBOL

↓

Db2

↓

Resposta

↓

Cliente

Esse fluxo mostra toda a integração entre sistemas.


Benefícios

Um bom fluxograma permite:

  • compreender sistemas rapidamente;

  • reduzir erros;

  • facilitar documentação;

  • melhorar comunicação;

  • acelerar treinamento;

  • simplificar manutenção;

  • apoiar testes.


Ferramentas utilizadas

Diversas ferramentas permitem criar fluxogramas.

Entre elas:

  • Microsoft Visio;

  • Draw.io (diagrams.net);

  • Lucidchart;

  • IBM Blueworks Live;

  • Microsoft PowerPoint;

  • Mermaid;

  • PlantUML.


Curiosidades

1. Fluxogramas existem há mais de 100 anos

Eles começaram a ser utilizados na engenharia industrial muito antes do surgimento dos computadores e depois foram adotados pela área de informática para representar algoritmos e processos.


2. Muitos programas COBOL antigos foram projetados com fluxogramas

Antes do desenvolvimento, era comum desenhar toda a lógica em papel utilizando símbolos padronizados.


3. O fluxograma continua atual

Mesmo com metodologias ágeis, UML e BPMN, o fluxograma continua sendo uma das formas mais simples de explicar um processo.


4. IA pode gerar fluxogramas

Ferramentas de Inteligência Artificial já conseguem criar fluxogramas automaticamente a partir de documentos, código COBOL ou descrições em linguagem natural.


Erros comuns de iniciantes

"Fluxograma é apenas um desenho"

Não.

Ele representa formalmente a lógica de um processo e ajuda a identificar falhas antes da programação.


"Só analistas usam fluxogramas"

Não.

Programadores, arquitetos, testadores, analistas de negócio e gestores utilizam fluxogramas para compreender sistemas.


"Fluxograma substitui a documentação"

Não.

Ele complementa a documentação, oferecendo uma visão visual do funcionamento do sistema.


Quando estudar fluxogramas?

Logo no início da carreira.

Uma boa sequência é:

  1. Lógica de Programação.

  2. Algoritmos.

  3. Fluxogramas.

  4. Pseudocódigo.

  5. COBOL.

  6. JCL.

  7. CICS.

  8. Db2.

Esse conhecimento facilitará o aprendizado de programação e permitirá compreender sistemas Mainframe de forma muito mais rápida.


Conclusão

O fluxograma é uma representação gráfica que descreve a sequência de atividades, decisões e caminhos de um processo ou sistema. No ambiente Mainframe, ele é amplamente utilizado para documentar programas COBOL, modelar processos bancários, representar transações CICS, integrar sistemas e facilitar a comunicação entre analistas, desenvolvedores e usuários.

Mais do que um simples desenho, o fluxograma é uma ferramenta de análise, planejamento e documentação que reduz erros, melhora o entendimento das regras de negócio e torna o desenvolvimento de aplicações IBM Z mais organizado e eficiente. Para qualquer profissional que esteja iniciando no universo Mainframe, aprender a criar e interpretar fluxogramas é um passo fundamental para evoluir em programação, análise de sistemas e arquitetura de software.

sábado, 28 de abril de 2007

O que é Análise Funcional?

 

Bellacosa Mainframe o que é analise funcional

O que é Análise Funcional?

Imagine que um banco deseja lançar uma nova funcionalidade:

"O cliente poderá parcelar automaticamente uma compra realizada no cartão de crédito."

Antes que qualquer programador COBOL altere um programa ou um analista técnico pense em tabelas Db2, CICS ou APIs, alguém precisa responder uma pergunta fundamental:

Como essa funcionalidade deve funcionar para o usuário e para o negócio?

Essa resposta é construída durante a Análise Funcional.

Ela descreve o comportamento esperado do sistema, as regras de negócio e os resultados desejados, sem entrar em detalhes de programação.


Definição simples

A Análise Funcional é a atividade que transforma uma necessidade do negócio em uma especificação clara sobre o que o sistema deve fazer.

Seu foco está no funcionamento da solução e nas regras de negócio, não em como ela será programada.

Em outras palavras:

A Análise Funcional explica o "o quê"; a Análise Técnica explica o "como".


Uma analogia simples

Imagine a construção de um elevador.

O cliente diz:

"Quero um elevador que leve pessoas do térreo ao décimo andar."

A Análise Funcional define:

  • capacidade para 10 pessoas;

  • velocidade;

  • número de andares;

  • botões;

  • sistema de emergência;

  • acessibilidade.

Já o engenheiro decidirá:

  • tipo de motor;

  • cabos;

  • circuitos;

  • materiais.

No Mainframe ocorre exatamente a mesma separação.


Como funciona?

O fluxo normalmente é:

Necessidade do Negócio

↓

Análise Funcional

↓

Especificação Funcional

↓

Análise Técnica

↓

Desenvolvimento COBOL

↓

Testes

↓

Produção

Objetivos da Análise Funcional

Ela busca responder perguntas como:

  • O que o usuário deseja?

  • Como será o funcionamento?

  • Quais regras de negócio existem?

  • Quais validações serão feitas?

  • O que acontece em caso de erro?

  • Quais informações serão apresentadas?

  • Quem poderá utilizar a funcionalidade?


Quem realiza a Análise Funcional?

Dependendo da empresa:

  • Analista Funcional;

  • Analista de Sistemas;

  • Product Owner;

  • Especialista de Negócio;

  • Consultor Funcional;

  • Arquiteto de Soluções.

Normalmente essas pessoas trabalham em conjunto.


O que um Analista Funcional faz?

Entre suas atividades estão:

  • entrevistar usuários;

  • levantar requisitos;

  • entender processos;

  • documentar regras de negócio;

  • desenhar fluxos;

  • validar soluções;

  • acompanhar testes;

  • apoiar a homologação.


Exemplo prático

Imagine um banco criando um PIX Agendado.

A Análise Funcional responderá perguntas como:

  • O cliente poderá cancelar?

  • Até que horário?

  • Haverá cobrança de tarifa?

  • O agendamento poderá ser recorrente?

  • O que acontece se não houver saldo?

  • Como o cliente será avisado?

Somente depois dessas respostas a equipe técnica começará a implementação.


O documento funcional

Normalmente contém:

  • objetivo;

  • descrição da funcionalidade;

  • regras de negócio;

  • fluxos;

  • exceções;

  • mensagens;

  • telas;

  • validações;

  • critérios de aceitação;

  • impactos para o usuário.

Ele evita ambiguidades e serve como referência para desenvolvimento e testes.


Diferença entre Análise Funcional e Técnica

Análise Funcional

Responde:

  • O que fazer?

  • Por quê?

  • Para quem?

  • Em quais situações?

  • Quais regras devem ser respeitadas?


Análise Técnica

Responde:

  • Como implementar?

  • Quais programas COBOL mudar?

  • Quais tabelas Db2 alterar?

  • Quais transações CICS serão utilizadas?

  • Haverá novas APIs?

  • Como será o deploy?


Tecnologias envolvidas

Embora o foco seja o negócio, um analista funcional costuma conhecer:

  • COBOL;

  • CICS;

  • Db2;

  • JCL;

  • VSAM;

  • MQ;

  • APIs REST;

  • z/OS Connect;

  • Git;

  • DevOps.

Esse conhecimento ajuda a avaliar impactos e conversar com a equipe técnica.


Exemplo completo

Imagine uma alteração no limite do cartão.

A análise funcional define:

Cliente solicita aumento

↓

Sistema verifica elegibilidade

↓

Consulta score

↓

Calcula novo limite

↓

Exibe resultado

↓

Registra auditoria

A análise técnica transformará esse fluxo em programas, tabelas e integrações.


Benefícios

Uma boa análise funcional:

  • reduz retrabalho;

  • melhora a comunicação;

  • evita interpretações diferentes;

  • facilita os testes;

  • aumenta a qualidade;

  • reduz custos do projeto.


Curiosidades

1. A maioria dos problemas começa na fase funcional

Diversos projetos falham porque a necessidade do negócio foi mal compreendida, e não porque o código foi mal escrito.


2. Um bom Analista Funcional entende mais de negócio do que de programação

Ele precisa conhecer profundamente produtos como contas correntes, cartões, PIX, empréstimos, seguros e investimentos.


3. A documentação funcional pode durar décadas

Em sistemas Mainframe, documentos funcionais servem de referência para aplicações que permanecem em produção por muitos anos.


4. IA está auxiliando a Análise Funcional

Ferramentas de Inteligência Artificial já conseguem resumir documentos, identificar inconsistências, sugerir regras e gerar casos de teste, mas a validação com o negócio continua sendo responsabilidade humana.


Erros comuns de iniciantes

"Análise Funcional é programação"

Não.

Ela define o comportamento esperado do sistema, enquanto a programação implementa esse comportamento.


"Somente o analista funcional precisa conhecer as regras"

Não.

Programadores, testadores e arquitetos também precisam compreender as regras para desenvolver e validar corretamente a solução.


"Análise Funcional e levantamento de requisitos são a mesma coisa"

Não exatamente.

O levantamento de requisitos coleta as necessidades do negócio. A Análise Funcional organiza, detalha, valida e transforma essas necessidades em uma especificação clara e implementável.


Quando estudar Análise Funcional?

Depois de aprender:

  1. Lógica de Programação.

  2. COBOL.

  3. JCL.

  4. CICS.

  5. Db2.

  6. Requisitos.

  7. Processos de Negócio.

  8. Engenharia de Software.

Esse conhecimento permitirá compreender não apenas como desenvolver programas, mas por que eles existem e quais problemas do negócio resolvem.


Conclusão

A Análise Funcional é uma das etapas mais importantes do desenvolvimento de sistemas Mainframe. Ela conecta as necessidades do negócio às soluções tecnológicas, definindo regras, fluxos e comportamentos que serão implementados posteriormente pela equipe técnica.

No ambiente IBM Z, onde aplicações movimentam bilhões de transações diariamente, uma análise funcional bem executada reduz riscos, evita retrabalho e garante que programas COBOL, transações CICS, bancos Db2 e integrações via APIs atendam exatamente às expectativas do negócio. Para quem deseja evoluir de programador para analista ou arquiteto, dominar Análise Funcional é um passo essencial na carreira.

sexta-feira, 27 de abril de 2007

O que são Requisitos de Sistema no Mainframe?

 

Bellacosa Mainframe o que são requisitos no mainframe

O que são Requisitos de Sistemas no Mainframe?

Imagine que um banco deseja criar uma nova funcionalidade:

"Permitir que clientes aumentem temporariamente o limite do cartão de crédito pelo aplicativo."

Antes que qualquer programador escreva uma única linha de COBOL, diversas perguntas precisam ser respondidas.

  • Quem poderá usar essa função?

  • Qual será o limite máximo?

  • Quanto tempo o aumento ficará válido?

  • Como será feita a validação?

  • Quais programas serão alterados?

  • Haverá mudanças no Db2?

  • Será necessário alterar APIs?

  • Como ficará a segurança?

Todas essas respostas fazem parte dos requisitos.

Sem requisitos bem definidos, um projeto dificilmente será desenvolvido corretamente.


Definição simples

Os requisitos são as necessidades, regras e expectativas que um sistema deve atender.

Eles descrevem o que o sistema deve fazer, como deve funcionar e quais restrições devem ser respeitadas.

Em outras palavras:

Os requisitos são o projeto da solução antes do desenvolvimento começar.


Uma analogia simples

Imagine a construção de uma casa.

Antes do pedreiro começar a obra é necessário definir:

  • número de quartos;

  • tamanho da cozinha;

  • localização das portas;

  • quantidade de banheiros;

  • tipo do telhado.

Sem essas definições, ninguém consegue construir corretamente.

No desenvolvimento Mainframe acontece exatamente o mesmo.


Como funciona?

O processo normalmente segue este fluxo:

Necessidade do Negócio

↓

Levantamento de Requisitos

↓

Análise

↓

Especificação

↓

Desenvolvimento COBOL

↓

Testes

↓

Produção

Quem define os requisitos?

Normalmente participam:

  • usuários;

  • especialistas do negócio;

  • Product Owner;

  • Analistas de Sistemas;

  • Arquitetos;

  • Desenvolvedores;

  • equipes de Qualidade;

  • gestores.


Tipos de requisitos

Requisitos Funcionais

Descrevem o que o sistema deve fazer.

Exemplos:

  • emitir boleto;

  • calcular juros;

  • gerar fatura;

  • autorizar cartão;

  • consultar saldo;

  • registrar pagamento PIX.

São as funcionalidades do sistema.


Requisitos Não Funcionais

Descrevem como o sistema deve funcionar.

Exemplos:

  • responder em até 2 segundos;

  • funcionar 24x7;

  • suportar 10.000 usuários simultâneos;

  • utilizar criptografia;

  • manter disponibilidade de 99,99%.

Esses requisitos tratam de qualidade, desempenho e segurança.


Regras de Negócio

São decisões da empresa.

Exemplo:

"O cliente somente poderá solicitar empréstimo se possuir renda mínima."

Outro exemplo:

"O limite do PIX noturno será diferente do diurno."

Essas regras normalmente são implementadas em programas COBOL.


Requisitos Técnicos

Definem aspectos da implementação.

Exemplo:

  • utilizar Db2;

  • utilizar CICS;

  • criar nova API REST;

  • atualizar MQ;

  • criar nova tabela;

  • alterar Copybook.


Exemplo prático

Imagine uma nova funcionalidade para cartão.

Os requisitos podem ser:

Cliente poderá bloquear o cartão pelo aplicativo.

↓

Alterar programa COBOL.

↓

Criar API REST.

↓

Atualizar Db2.

↓

Registrar auditoria.

↓

Enviar mensagem MQ.

Somente depois disso começa o desenvolvimento.


Documentação de requisitos

Normalmente contém:

  • objetivo;

  • descrição funcional;

  • regras de negócio;

  • telas;

  • mensagens;

  • validações;

  • campos;

  • arquivos;

  • tabelas;

  • APIs;

  • impactos.


Tecnologias envolvidas

Dependendo da demanda podem aparecer:

  • COBOL;

  • CICS;

  • JCL;

  • Db2;

  • VSAM;

  • MQ;

  • z/OS Connect;

  • APIs REST;

  • Git;

  • DevOps.


Benefícios

Requisitos bem definidos permitem:

  • reduzir erros;

  • evitar retrabalho;

  • facilitar testes;

  • melhorar documentação;

  • acelerar desenvolvimento;

  • reduzir custos.


Exemplo completo

Imagine que um banco queira implantar um novo PIX internacional.

Os requisitos podem determinar:

Novo serviço

↓

Nova API

↓

Alteração COBOL

↓

Nova tabela Db2

↓

Integração MQ

↓

Testes

↓

Produção

Cada etapa depende dos requisitos definidos inicialmente.


Curiosidades

1. A maioria dos erros nasce antes da programação

Diversos estudos de engenharia de software mostram que muitos defeitos têm origem em requisitos incompletos, incorretos ou ambíguos.


2. O COBOL apenas implementa os requisitos

O programa não decide sozinho as regras do negócio.

Ele executa exatamente o que foi especificado.


3. Um pequeno requisito pode impactar dezenas de programas

Alterar uma única regra bancária pode exigir mudanças em programas COBOL, tabelas Db2, transações CICS, APIs, mensagens MQ e processos batch.


4. Requisitos mudam durante o projeto

É comum que novas leis, mudanças de mercado ou decisões do negócio levem à revisão dos requisitos antes da entrega final.


Erros comuns de iniciantes

"Requisito é o programa COBOL"

Não.

O requisito existe antes do código e orienta sua implementação.


"Somente o Analista conhece os requisitos"

Não.

Desenvolvedores, testadores, arquitetos e usuários também precisam entendê-los.


"Depois de aprovado o requisito nunca muda"

Na prática, mudanças de prioridade, legislação ou estratégia podem exigir ajustes ao longo do projeto.


Quando estudar requisitos?

Logo no início da carreira.

Mesmo um programador COBOL júnior deve aprender a interpretar documentos de requisitos, pois é a partir deles que o código será desenvolvido.

Esse conhecimento também facilita a comunicação com analistas, usuários e equipes de testes.


Conclusão

Os requisitos no Mainframe representam a base de qualquer projeto de software. Eles definem as funcionalidades, regras de negócio, restrições técnicas e critérios de qualidade que orientam o desenvolvimento de aplicações em IBM Z.

Dominar a leitura, interpretação e análise de requisitos é uma habilidade essencial para programadores COBOL, analistas de sistemas, arquitetos e líderes técnicos. Quanto mais claros e completos forem os requisitos, maior será a qualidade do sistema entregue e menor será o risco de retrabalho, falhas e custos adicionais durante o ciclo de vida da aplicação.

quinta-feira, 26 de abril de 2007

O que é Backlog no Mainframe?

 

Bellacosa Mainframe o que é backlog no mainframe

O que é Backlog no Mainframe?

Quem está começando no IBM Mainframe frequentemente ouve frases como:

  • "Essa demanda entrou no backlog."

  • "O backlog da fábrica aumentou."

  • "Vamos priorizar o backlog."

  • "Esse projeto ainda está aguardando no backlog."

Mas afinal, o que significa isso?

A resposta é simples:

Backlog é a lista organizada de trabalhos, solicitações, correções e melhorias que ainda precisam ser desenvolvidas.

Ele não é exclusivo do Mainframe. É um conceito utilizado em praticamente todas as metodologias de desenvolvimento de software, especialmente em equipes ágeis.


Uma analogia simples

Imagine uma oficina mecânica.

Todos os dias chegam carros para:

  • trocar óleo;

  • consertar o motor;

  • revisar os freios;

  • trocar pneus.

O mecânico não consegue atender todos ao mesmo tempo.

Então ele cria uma fila.

Essa fila é o backlog.

No Mainframe acontece exatamente a mesma coisa.


Definição simples

No ambiente Mainframe, o backlog é uma lista priorizada contendo todas as atividades que deverão ser executadas pela equipe.

Pode incluir:

  • novos programas COBOL;

  • alterações em programas existentes;

  • correções de bugs;

  • mudanças em JCL;

  • novas tabelas Db2;

  • ajustes em CICS;

  • APIs REST;

  • melhorias de desempenho;

  • modernização de aplicações;

  • demandas regulatórias.


Como funciona?

Imagine um banco.

Durante a semana surgem diversas solicitações.

Nova funcionalidade PIX

↓

Correção da Fatura

↓

Mudança no Cartão

↓

Nova API

↓

Correção COBOL

↓

Atualização Db2

Tudo isso entra no backlog.


O ciclo do backlog

Normalmente o fluxo é:

Solicitação

↓

Análise

↓

Priorização

↓

Backlog

↓

Desenvolvimento

↓

Testes

↓

Produção

Quem cria o backlog?

Dependendo da empresa:

  • Product Owner (PO);

  • Gerente de Projetos;

  • Analista de Sistemas;

  • Líder Técnico;

  • Gestor de Produtos;

  • Comitês de negócio.


O que pode existir em um backlog Mainframe?

Novas funcionalidades

Exemplo:

  • PIX Parcelado;

  • novo boleto;

  • integração Open Finance.


Correções

Exemplo:

  • erro em programa COBOL;

  • ABEND;

  • cálculo incorreto.


Melhorias

Exemplo:

  • reduzir consumo de CPU;

  • otimizar SQL;

  • melhorar desempenho do CICS.


Atualizações técnicas

Como:

  • migração COBOL 6.5;

  • atualização Db2;

  • upgrade CICS;

  • adoção de Git;

  • DevOps.


Demandas legais

Por exemplo:

  • Banco Central;

  • Receita Federal;

  • LGPD;

  • normas contábeis.


Priorização

Nem tudo pode ser desenvolvido imediatamente.

As equipes normalmente classificam as demandas.

Por exemplo:

Alta prioridade

  • fraude bancária;

  • indisponibilidade;

  • falha crítica.

Média prioridade

  • melhorias;

  • novos relatórios.

Baixa prioridade

  • pequenas otimizações;

  • melhorias visuais.


Exemplo prático

Imagine um backlog de um banco.

1 - Corrigir erro no PIX

2 - Nova regra de cartão

3 - API Open Finance

4 - Otimizar Db2

5 - Atualizar JCL

6 - Modernizar COBOL

A equipe trabalha seguindo essa prioridade.


Ferramentas utilizadas

É comum utilizar:

  • Jira;

  • Azure DevOps;

  • IBM Engineering Workflow Management (antigo Rational Team Concert);

  • ServiceNow;

  • GitHub Issues;

  • GitLab Issues.


Relação com o DevOps

O backlog é o ponto de partida do fluxo DevOps.

Backlog

↓

Desenvolvimento

↓

Git

↓

Pipeline

↓

Testes

↓

Deploy

↓

Produção

Benefícios

Um backlog bem organizado permite:

  • melhor planejamento;

  • maior transparência;

  • definição clara de prioridades;

  • redução de retrabalho;

  • melhor comunicação entre negócio e tecnologia;

  • entregas contínuas.


Curiosidades

1. O backlog nunca fica vazio

Em grandes bancos e seguradoras, novas demandas surgem diariamente. O backlog é um processo contínuo.


2. Nem tudo que entra será desenvolvido

Algumas solicitações podem perder prioridade, ser canceladas ou substituídas por soluções diferentes.


3. Um backlog pode conter milhares de itens

Grandes instituições financeiras mantêm carteiras com milhares de demandas distribuídas entre dezenas de equipes.


4. O backlog representa o futuro do sistema

Ele mostra quais funcionalidades, correções e melhorias serão implementadas ao longo do tempo.


Erros comuns de iniciantes

"Backlog é apenas uma lista de bugs"

Não.

Ele inclui novas funcionalidades, melhorias, projetos, atualizações técnicas e demandas regulatórias.


"Tudo que entra no backlog será feito"

Não necessariamente.

Cada item será analisado, priorizado e poderá até ser descartado.


"Backlog é responsabilidade apenas do gerente"

Não.

Analistas, arquitetos, desenvolvedores, Product Owners e representantes do negócio participam da construção e priorização do backlog.


Quando aprender sobre backlog?

Logo no início da carreira.

Mesmo um programador COBOL iniciante participa de reuniões para entender quais demandas serão desenvolvidas e como elas serão priorizadas.

Compreender o backlog ajuda a enxergar como o trabalho técnico se conecta às necessidades do negócio.


Conclusão

O backlog no Mainframe é a lista organizada de demandas que orienta a evolução das aplicações IBM Z. Ele reúne correções, novas funcionalidades, melhorias técnicas, modernizações e requisitos legais, funcionando como um mapa do trabalho futuro da equipe.

Em ambientes corporativos, especialmente em bancos, seguradoras e grandes empresas, um backlog bem gerenciado é essencial para garantir que os recursos sejam direcionados às demandas mais importantes, mantendo sistemas críticos evoluindo de forma planejada, segura e alinhada aos objetivos do negócio.

terça-feira, 24 de abril de 2007

O que é o VisionPLUS?

 

Bellacosa Mainframe o que é o visionplus

O que é o VisionPLUS?

Para quem trabalha em bancos, administradoras de cartões ou empresas de meios de pagamento, VisionPLUS é um dos sistemas mais importantes já criados para o ambiente Mainframe.

Ele é uma plataforma completa para emissão, administração e processamento de cartões de crédito, débito, pré-pagos, private label e outros produtos financeiros. Hoje pertence à Fiserv (após aquisições ao longo dos anos) e é utilizado por instituições financeiras em diversos países. (Fiserv)

Em outras palavras:

Se o COBOL é o motor, o VisionPLUS é a fábrica inteira que administra a vida de um cartão bancário.


Uma analogia simples

Imagine um banco emitindo um cartão Visa.

O cliente faz o pedido.

O banco precisa:

  • aprovar o crédito;

  • criar a conta;

  • emitir o cartão;

  • definir o limite;

  • autorizar compras;

  • calcular juros;

  • gerar faturas;

  • receber pagamentos;

  • controlar parcelamentos;

  • bloquear cartões roubados;

  • controlar programas de fidelidade.

Tudo isso pode ser gerenciado pelo VisionPLUS.


O que ele faz?

O VisionPLUS administra praticamente todo o ciclo de vida de um cartão.

Cliente

↓

Solicitação

↓

Análise de Crédito

↓

Emissão

↓

Compras

↓

Autorizações

↓

Fatura

↓

Pagamento

↓

Histórico

Onde ele roda?

Historicamente, o VisionPLUS foi desenvolvido para ambientes IBM Mainframe, utilizando tecnologias como:

  • COBOL;

  • CICS;

  • JCL;

  • Db2;

  • VSAM;

  • IMS (em alguns ambientes);

  • z/OS.

Hoje também existem versões e arquiteturas modernizadas com APIs e suporte a ambientes híbridos e em nuvem, mantendo integração com IBM Z. (Fiserv)


Principais funções

Entre suas responsabilidades estão:

Cadastro de clientes

Mantém informações como:

  • CPF;

  • endereço;

  • renda;

  • limite;

  • perfil de crédito.


Administração das contas

Controla:

  • saldo;

  • limite disponível;

  • juros;

  • financiamentos;

  • parcelamentos.


Autorização de compras

Quando você passa o cartão:

Maquininha

↓

Bandeira

↓

VisionPLUS

↓

Banco

↓

Resposta

Em poucos segundos o sistema decide se a compra será aprovada.


Geração da fatura

Mensalmente o sistema calcula:

  • compras;

  • juros;

  • encargos;

  • IOF;

  • pagamentos;

  • saldo devedor.


Controle de cartões

Permite:

  • bloquear;

  • desbloquear;

  • cancelar;

  • reemitir;

  • renovar cartões.


Programas de fidelidade

Gerencia:

  • pontos;

  • cashback;

  • milhas;

  • promoções.


Arquitetura modular

O VisionPLUS é dividido em módulos especializados. Entre os mais conhecidos estão:

  • CMS (Credit Management System) – núcleo do processamento das contas de cartão.

  • FAS (Financial Authorization System) – responsável pelas autorizações em tempo real.

  • ASM (Account Services Management) – serviços e atendimento das contas.

  • CTA (Collections Tracking Analysis) – cobrança e acompanhamento de inadimplência.

  • LMS (Loyalty Management System) – programas de fidelidade.

  • ITS (Interchange Tracking System) – disputas e intercâmbio entre bandeiras.

  • KMS (Key Management System) – gerenciamento de chaves criptográficas para cartões. (Wikipedia)


Exemplo prático

Você compra um café usando cartão de crédito.

Em poucos segundos:

POS

↓

Visa/Mastercard

↓

VisionPLUS

↓

Banco Emissor

↓

Autorização

↓

Resposta ao POS

Todo esse processo costuma ocorrer em menos de dois segundos.


Tecnologias utilizadas

Em ambientes Mainframe é comum encontrar:

  • COBOL;

  • CICS;

  • JCL;

  • Db2;

  • MQ;

  • APIs REST;

  • z/OS Connect;

  • Git;

  • DevOps.

Muitas instituições modernizaram o VisionPLUS sem substituir seu núcleo de processamento.


Benefícios

  • Altíssima disponibilidade.

  • Processamento de milhões de transações por dia.

  • Grande capacidade de customização.

  • Escalabilidade.

  • Integração com Visa, Mastercard, Elo, Amex e outras bandeiras.

  • Suporte a diversos produtos financeiros. (Fiserv)


Curiosidades

1. Um dos sistemas de cartões mais difundidos do mundo

O VisionPLUS é utilizado por bancos, processadoras e instituições financeiras em dezenas de países e serve de base para centenas de milhões de cartões. (Fiserv)

2. É altamente modular

Cada banco pode utilizar apenas os módulos de que precisa ou personalizar funcionalidades conforme suas regras de negócio. (Wikipedia)

3. Continua evoluindo

A Fiserv vem modernizando a plataforma com APIs, arquitetura modular e soluções como Vision Next, mantendo compatibilidade com ambientes IBM LinuxONE e IBM Z. (Fiserv)


Para um programador COBOL

Trabalhar com VisionPLUS normalmente significa desenvolver ou manter:

  • programas COBOL;

  • transações CICS;

  • rotinas batch;

  • interfaces MQ;

  • acesso ao Db2;

  • processamento de cartões;

  • cálculo de juros;

  • geração de faturas;

  • regras de crédito.

É uma das especializações mais valorizadas no mercado financeiro, pois combina conhecimento de Mainframe com regras de negócio complexas de cartões e meios de pagamento.

segunda-feira, 23 de abril de 2007

O que é a IA aplicada ao desenvolvimento Maifnrame

Bellacosa Mainframe e a ia aplicada ao desenvolvimento mainframe

O que é a IA aplicada ao desenvolvimento Maifnrame


1. IA para desenvolvimento COBOL

É provavelmente a área que mais cresce. 

Ferramentas baseadas em IA podem:

  • sugerir código COBOL;

  • completar instruções automaticamente;

  • explicar programas antigos;

  • gerar documentação;

  • criar casos de teste;

  • identificar bugs;

  • sugerir refatorações.

Exemplo:

Um programa COBOL com 8.000 linhas pode ser resumido em poucos segundos, indicando:

  • objetivo do programa;

  • arquivos utilizados;

  • tabelas Db2 acessadas;

  • regras de negócio;

  • fluxos principais.

Isso reduz drasticamente o tempo de entendimento de sistemas legados.


2. IA para documentação

Em muitas empresas existem aplicações escritas há 30 ou 40 anos sem documentação.

A IA consegue gerar:

  • documentação técnica;

  • diagramas de fluxo;

  • dependências;

  • descrição de campos;

  • explicação de COPYBOOKs;

  • comentários no código.

Isso acelera a manutenção e a transferência de conhecimento.


3. IA para modernização

Em vez de reescrever um sistema inteiro, a IA pode identificar:

  • módulos mais críticos;

  • código duplicado;

  • dependências ocultas;

  • oportunidades de modularização;

  • chamadas CICS;

  • comandos SQL;

  • integrações MQ;

  • APIs candidatas ao z/OS Connect.

Ela ajuda a planejar a modernização com menos riscos.


4. IA para testes

A IA pode criar automaticamente:

  • casos de teste;

  • dados de teste;

  • cenários extremos;

  • testes de regressão;

  • testes unitários.

Também consegue comparar versões diferentes de um programa COBOL e indicar onde uma alteração pode afetar outras partes do sistema.


5. IA para DevOps

Os pipelines modernos podem usar IA para:

  • revisar código;

  • verificar padrões;

  • detectar vulnerabilidades;

  • sugerir melhorias;

  • prever falhas no build;

  • analisar cobertura de testes.

Isso reduz o tempo entre o desenvolvimento e a produção.


6. IA para operações (AIOps)

Uma das aplicações mais valiosas.

A IA monitora continuamente:

  • CPU;

  • memória;

  • canais;

  • discos;

  • workloads;

  • regiões CICS;

  • filas MQ;

  • jobs;

  • logs;

  • eventos SMF e RMF.

Ela consegue prever problemas antes que eles aconteçam.

Exemplo:

"A utilização de CPU sugere que a LPAR poderá atingir saturação em aproximadamente duas horas."

Isso permite agir antes do impacto no negócio.


7. IA para segurança

A IA aprende o comportamento normal dos usuários.

Quando algo foge do padrão, pode detectar:

  • acessos incomuns;

  • tentativas de fraude;

  • comandos suspeitos;

  • movimentações anormais de dados;

  • possíveis ataques.

Integrada ao RACF e a ferramentas de monitoramento, ela fortalece a segurança do ambiente.


8. IA para bancos de dados

No Db2, a IA auxilia em tarefas como:

  • sugerir índices;

  • otimizar consultas SQL;

  • identificar gargalos;

  • prever crescimento das tabelas;

  • recomendar ajustes de configuração.

Isso melhora o desempenho sem depender apenas de análises manuais.


9. IA para automação

A IA pode automatizar atividades repetitivas, como:

  • análise de ABENDs;

  • abertura de chamados;

  • classificação de incidentes;

  • geração de relatórios;

  • execução de procedimentos operacionais;

  • resposta inicial a alertas.

Ela reduz o tempo gasto com tarefas rotineiras.


10. IA Generativa no IBM Z

É a área mais recente.

Modelos generativos podem:

  • explicar JCLs;

  • criar documentação;

  • gerar exemplos COBOL;

  • converter especificações em código inicial;

  • resumir programas antigos;

  • responder perguntas sobre aplicações corporativas.

Esses recursos funcionam como assistentes para desenvolvedores e analistas.


Tecnologias da IBM relacionadas à IA

Algumas soluções importantes incluem:

  • watsonx.ai – criação e uso de modelos de IA.

  • watsonx Code Assistant for Z – assistência ao desenvolvimento e modernização de aplicações no Mainframe.

  • watsonx Assistant – construção de assistentes conversacionais.

  • IBM Z Anomaly Analytics – detecção inteligente de anomalias operacionais.

  • IBM Z IntelliMagic Vision – análise de desempenho com recursos de IA.

  • IBM Spyre Accelerator (em plataformas IBM Z mais recentes) – aceleração de cargas de trabalho de IA diretamente no ecossistema IBM Z.


O que um iniciante deve estudar?

Uma boa sequência é:

  1. COBOL

  2. JCL

  3. z/OS

  4. CICS

  5. Db2

  6. Git

  7. DevOps

  8. APIs REST

  9. z/OS Connect

  10. Fundamentos de Inteligência Artificial

  11. IA aplicada ao Mainframe

  12. AIOps

  13. Engenharia de Prompts

  14. Modelos de Linguagem (LLMs)


Habilidades que a IA não substitui

Mesmo com toda a evolução da IA, algumas competências continuam sendo essencialmente humanas:

  • compreender regras de negócio;

  • projetar arquiteturas;

  • decidir estratégias de modernização;

  • validar requisitos críticos;

  • interpretar normas legais e regulatórias;

  • comunicar-se com usuários e equipes.

A IA acelera o trabalho, mas a responsabilidade pelas decisões permanece com os profissionais.


Curiosidades

  • Grandes bancos utilizam IA para detectar fraudes em transações processadas pelo Mainframe em tempo real.

  • Ferramentas modernas conseguem explicar programas COBOL escritos há décadas sem necessidade de documentação original.

  • A IBM vem incorporando recursos de IA ao ecossistema IBM Z para apoiar desenvolvimento, operações e modernização, reduzindo o esforço manual em diversas atividades.

  • A tendência atual não é substituir aplicações COBOL, mas aumentar sua capacidade por meio de APIs, automação e IA.

Conclusão

Estudar IA no Mainframe significa aprender como aplicar inteligência artificial em todas as fases do ciclo de vida das aplicações IBM Z: desenvolvimento, testes, documentação, segurança, operações, modernização e integração com sistemas modernos. O profissional que combina sólidos conhecimentos de COBOL, z/OS, CICS, Db2 e DevOps com habilidades em IA, automação e engenharia de prompts estará especialmente preparado para atuar na próxima geração de sistemas corporativos, onde confiabilidade e inteligência caminham lado a lado.

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