Translate

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

quarta-feira, 17 de abril de 2024

RAD (Rapid Application Development) - A Metodologia que Mudou a Engenharia de Software e Continua Transformando o IBM Mainframe

 

Bellacosa Mainframe e RAD rapid application development

☕ Um Café no Bellacosa Mainframe

RAD (Rapid Application Development)

A Metodologia que Mudou a Engenharia de Software e Continua Transformando o IBM Mainframe

Você não está estudando apenas uma metodologia criada nos anos 90. Está entendendo a origem de grande parte das práticas modernas de desenvolvimento de software.

"O Mainframe nunca foi lento. Lento sempre foi o processo de desenvolvimento ao seu redor."

Introdução

Quando alguém fala em desenvolvimento ágil, Scrum, DevOps, Low-Code, No-Code ou Inteligência Artificial, normalmente imagina que essas tecnologias surgiram praticamente do nada.

Na realidade, muitas dessas ideias nasceram décadas antes.

Entre elas está o RAD (Rapid Application Development), metodologia criada para reduzir o tempo entre uma necessidade do negócio e a entrega de software funcionando.

Seu princípio continua extremamente atual.

Não desenvolver mais rápido.

Aprender mais rápido.

Para quem trabalha com COBOL e IBM Mainframe, compreender o RAD significa entender que velocidade nunca dependeu apenas da linguagem de programação. Ela depende principalmente da organização do trabalho, da automação, da participação do usuário e da capacidade de evoluir continuamente.

Esta série apresenta o RAD sob a ótica do profissional IBM Z, mostrando que seus princípios continuam mais vivos do que nunca.

O que você aprenderá nesta série

Ao longo dos três capítulos veremos:

  • a origem do RAD;

  • por que ele revolucionou a Engenharia de Software;

  • como implementar RAD na prática;

  • metodologias derivadas;

  • ferramentas clássicas e modernas;

  • integração com Low-Code, DevOps e IA;

  • aplicação em COBOL, CICS, DB2, IMS e IBM Z;

  • oportunidades profissionais para desenvolvedores Mainframe.

Capítulo 1 — O que é RAD e por que ele revolucionou o desenvolvimento de software

Resumo

O primeiro capítulo apresenta a história do Rapid Application Development, criado por James Martin em 1991.

Mostra o cenário da época, dominado pelo modelo Cascata (Waterfall), em que projetos levavam anos para serem concluídos e frequentemente chegavam ao usuário já desatualizados.

Também explica os quatro pilares do RAD:

  • desenvolvimento iterativo;

  • prototipação;

  • participação constante do usuário;

  • equipes pequenas e multidisciplinares.

O capítulo compara RAD com Waterfall e demonstra como suas ideias influenciaram praticamente todas as metodologias modernas.

Leia o capítulo completo:

👉 RAD (Rapid Application Development) – Parte 1: O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia que Ensinou o Mundo a Desenvolver Software Rapidamente

https://eljefemidnightlunch.blogspot.com/2024/01/rad-rapid-application-development-o-que.html

Capítulo 2 — Como implementar RAD na prática

Resumo

Depois de entender os conceitos fundamentais, chega o momento de colocar o RAD em funcionamento.

Este capítulo apresenta um roteiro completo de implementação.

Você aprenderá:

  • como dividir projetos em pequenas entregas;

  • como montar equipes enxutas;

  • como construir protótipos;

  • como utilizar MVP (Minimum Viable Product);

  • como medir resultados;

  • indicadores de sucesso;

  • governança;

  • segurança;

  • documentação enxuta.

Também apresenta as metodologias influenciadas pelo RAD:

  • Scrum;

  • Extreme Programming (XP);

  • Lean Software Development;

  • DevOps;

  • Agile.

Além disso, faz um panorama das principais ferramentas RAD da história, como PowerBuilder, Delphi, Oracle Forms e GeneXus, chegando às plataformas atuais como Mendix, OutSystems, Power Apps, Oracle APEX e soluções baseadas em Inteligência Artificial.

Leia o capítulo completo:

👉 RAD (Rapid Application Development) – Parte 2: Como Implementar RAD na Prática, Principais Metodologias, Ferramentas e o Papel da Inteligência Artificial

https://eljefemidnightlunch.blogspot.com/2024/02/rad-rapid-application-development-como.html

Capítulo 3 — RAD no IBM Mainframe

Resumo

O terceiro capítulo aproxima definitivamente o RAD do universo IBM Z.

Mostra que o Mainframe nunca foi incompatível com desenvolvimento rápido.

Na verdade, muitos bancos já aplicavam práticas semelhantes ao RAD antes mesmo da popularização do Agile.

Entre os assuntos abordados estão:

  • RAD aplicado ao COBOL;

  • modularização;

  • COPYBOOKs;

  • reutilização;

  • APIs REST;

  • z/OS Connect;

  • CICS;

  • DB2;

  • IMS;

  • VSAM;

  • Git;

  • DevOps;

  • CI/CD;

  • testes automatizados;

  • observabilidade;

  • Inteligência Artificial aplicada ao código legado.

O capítulo também discute o futuro do desenvolvimento Mainframe e mostra como a combinação entre COBOL, IA e automação cria novas oportunidades para profissionais especializados em IBM Z.

Leia o capítulo completo:

👉 RAD (Rapid Application Development) – Parte 3: RAD no IBM Mainframe: Como Aplicar Desenvolvimento Rápido em COBOL sem Perder a Confiabilidade do IBM Z

https://eljefemidnightlunch.blogspot.com/2024/03/rad-rapid-application-development-rad.html

As principais lições da série

Ao final da leitura, fica evidente que o RAD nunca foi apenas uma metodologia para acelerar projetos.

Ele representa uma mudança de mentalidade.

Seus princípios continuam presentes em praticamente todas as práticas modernas de Engenharia de Software:

  • entregas incrementais;

  • feedback contínuo;

  • automação;

  • integração contínua;

  • testes automatizados;

  • prototipação;

  • foco no usuário;

  • redução de desperdícios;

  • melhoria contínua.

No ambiente IBM Mainframe, esses conceitos tornaram-se ainda mais relevantes graças à integração com APIs, Git, DevOps, z/OS Connect e Inteligência Artificial.

O desenvolvedor COBOL moderno não precisa abandonar décadas de conhecimento.

Precisa ampliar sua caixa de ferramentas.

Quanto mais automatizado for o processo, menor será o tempo entre uma ideia de negócio e sua implementação.

Esse sempre foi o verdadeiro objetivo do RAD.

Trinta anos depois, continua sendo uma das maiores lições da Engenharia de Software.

Próximas leituras recomendadas

Se você gostou desta série, acompanhe também os artigos do ☕ Um Café no Bellacosa Mainframe sobre:

  • DevOps para IBM Mainframe;

  • Low-Code para Programadores COBOL;

  • No-Code e Modernização;

  • Arquitetura Transformer para Mainframe;

  • Engenharia de Dados para Desenvolvedores COBOL;

  • CASE Tools;

  • APIs REST no IBM Z;

  • Inteligência Artificial aplicada ao COBOL;

  • Git e CI/CD no z/OS;

  • Modernização de aplicações IBM Z.

Esse artigo funciona como uma página pilar (Pillar Page) para SEO, concentrando a autoridade do tema RAD e distribuindo links para os três capítulos da série.


Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , ,

quinta-feira, 28 de março de 2024

RAD (Rapid Application Development) — RAD no IBM Mainframe - Parte III

 

Bellacosa Mainframe apresenta a parte III do RAD

☕ Um Café no Bellacosa Mainframe

RAD (Rapid Application Development)

Parte III — RAD no IBM Mainframe: Como Aplicar Desenvolvimento Rápido em COBOL sem Perder a Confiabilidade do IBM Z

"O Mainframe nunca foi lento. Lento sempre foi o processo de desenvolvimento ao seu redor."

Introdução

Existe uma frase que acompanha o IBM Mainframe há décadas.

"Mainframe é lento."

Quase sempre essa frase vem de alguém que nunca trabalhou em um ambiente bancário de alta disponibilidade.

Porque, na prática, o IBM Z executa milhões de transações por segundo, movimenta trilhões de dólares diariamente e mantém índices de disponibilidade que chegam próximos dos famosos cinco noves (99,999%).

Então de onde surgiu essa fama?

A resposta é simples.

As pessoas confundiram velocidade de processamento com velocidade de desenvolvimento.

São coisas completamente diferentes.

Durante muitos anos, alterar um sistema COBOL exigia:

  • abrir uma solicitação;

  • elaborar documentação;

  • aprovar análise;

  • atualizar especificações;

  • codificar;

  • compilar;

  • testar;

  • homologar;

  • agendar implantação;

  • executar mudança.

Em muitos casos, uma alteração simples levava semanas.

Não porque COBOL fosse lento.

Mas porque o processo era.

É justamente nesse ponto que o RAD mostra sua força.

O maior mito sobre COBOL

Quando ouvimos falar em RAD, muitas pessoas imaginam aplicações Web.

JavaScript.

Python.

Java.

.NET.

Poucos lembram do COBOL.

Entretanto, existe uma curiosidade interessante.

Muitos grandes bancos já utilizavam práticas extremamente parecidas com RAD muito antes da popularização do Agile.

Como?

Através de pequenas entregas.

Versionamento interno.

Reuniões constantes com usuários.

Protótipos em CICS.

Homologações frequentes.

Reutilização de módulos.

Na prática...

Faziam RAD sem chamar de RAD.

O que muda no Mainframe?

A resposta curta é:

Muito menos do que as pessoas imaginam.

Os princípios continuam exatamente iguais.

Continuamos buscando:

  • reduzir desperdícios;

  • validar rapidamente;

  • automatizar tarefas;

  • envolver usuários;

  • diminuir retrabalho.

O que muda é a plataforma.

O ciclo RAD dentro do IBM Z

Imagine uma nova funcionalidade para um sistema bancário.

Em vez de esperar seis meses para entregar tudo, o projeto pode seguir este fluxo.

Semana 1

Levantamento com usuários.

Protótipo.

Modelagem das regras.

Semana 2

Alterações em programas COBOL.

Novas tabelas DB2.

Novas transações CICS.

Semana 3

Testes automatizados.

Integração.

Homologação.

Semana 4

Produção.

Feedback.

Nova versão.

Perceba que o ciclo é praticamente o mesmo visto nas partes anteriores.

RAD e COBOL

O COBOL possui características que favorecem bastante o desenvolvimento iterativo.

Entre elas:

Grande legibilidade.

Regras de negócio bem separadas.

Excelente estabilidade.

Código altamente reutilizável.

Processamento previsível.

Programas pequenos podem ser alterados rapidamente.

Especialmente quando a arquitetura foi bem construída.

O problema normalmente não está no COBOL.

Está na forma como o sistema foi organizado.

A importância da modularização

Um dos princípios mais importantes do RAD é dividir problemas grandes em pequenos módulos.

Curiosamente...

Esse também é um dos princípios clássicos do COBOL.

Imagine um programa com cinquenta mil linhas.

Alterar qualquer coisa nele gera medo.

Agora imagine cinquenta programas com mil linhas cada.

A manutenção muda completamente.

Módulos menores significam:

  • menor risco;

  • testes menores;

  • menor impacto;

  • entregas mais rápidas.

COPYBOOKs e reutilização

Muito antes dos frameworks modernos, COBOL já utilizava reutilização.

COPYBOOKs são um excelente exemplo.

Campos.

Layouts.

Constantes.

Mensagens.

Estruturas.

Tudo compartilhado entre centenas de programas.

Isso reduz erros.

Padroniza interfaces.

Facilita manutenção.

RAD valoriza exatamente esse tipo de reutilização.

APIs mudaram completamente o jogo

Durante décadas, sistemas Mainframe conversavam principalmente através de:

Arquivos.

MQ.

CICS.

IMS.

Hoje a realidade é diferente.

Programas COBOL podem ser expostos como APIs REST utilizando:

  • z/OS Connect

  • CICS Web Services

  • IMS Connect

  • API Gateway

  • IBM API Connect

Isso aproxima enormemente o Mainframe das práticas RAD.

Uma equipe pode construir rapidamente um serviço.

Publicar.

Receber feedback.

Melhorar.

Publicar novamente.

RAD e CICS

Talvez nenhum componente do Mainframe combine tanto com RAD quanto o CICS.

Ele nasceu para processamento online.

Pequenas transações.

Respostas rápidas.

Atualizações imediatas.

Cada transação pode evoluir independentemente.

Novas telas podem ser adicionadas.

Novas regras podem ser implantadas.

Novos serviços podem ser publicados.

Tudo isso reduzindo o tempo de entrega.

RAD e DB2

Outro grande aliado.

DB2 permite evolução incremental.

Novas tabelas.

Novas views.

Novos índices.

Stored Procedures.

Funções SQL.

Muitas melhorias podem ser entregues sem alterar profundamente toda a aplicação.

Essa capacidade favorece ciclos curtos.

VSAM continua importante

Mesmo na era das APIs, VSAM continua extremamente presente.

Especialmente em sistemas críticos.

O RAD não exige abandonar tecnologias antigas.

Exige apenas desenvolver melhor.

Um arquivo KSDS bem projetado continua extremamente eficiente.

IMS também participa

Quem trabalha com IMS DB ou IMS TM sabe que estabilidade é prioridade.

Mas isso não impede evolução rápida.

Novos programas.

Novas transações.

Novos PSBs.

Novos DBDs.

Tudo pode seguir ciclos iterativos.

DevOps aproximou RAD do Mainframe

Durante muitos anos parecia impossível falar em DevOps dentro do IBM Z.

Hoje isso mudou completamente.

Ferramentas modernas permitem:

Git.

Pipeline.

Build automático.

Deploy automatizado.

Testes automatizados.

Análise de qualidade.

Code Review.

Integração Contínua.

Entrega Contínua.

Tudo isso acelerou o desenvolvimento COBOL.

Git no Mainframe

Outro paradigma foi quebrado.

Hoje programas COBOL podem ser versionados utilizando Git.

Isso traz inúmeras vantagens.

Histórico.

Branches.

Merge.

Pull Requests.

Auditoria.

Integração com pipelines.

RAD ganha enorme velocidade quando combinado com versionamento moderno.

Testes automatizados

Talvez o maior diferencial do desenvolvimento moderno.

Antes.

Cada alteração exigia dias de testes manuais.

Hoje podemos utilizar:

  • IBM ZUnit;

  • COBOL Unit Test;

  • testes de APIs;

  • testes de integração;

  • testes automatizados em pipelines.

Quanto menor o tempo de teste...

Mais ciclos RAD podemos executar.

Integração Contínua

Sempre que um desenvolvedor altera um programa:

Compila.

Executa testes.

Analisa qualidade.

Publica artefatos.

Tudo automaticamente.

Esse processo praticamente elimina erros humanos repetitivos.

Entrega Contínua

Depois da Integração Contínua vem outro passo.

Deploy automatizado.

Naturalmente ambientes bancários continuam exigindo aprovações.

Mas boa parte das tarefas repetitivas desaparece.

Inteligência Artificial no Mainframe

Estamos vivendo talvez a maior transformação desde o surgimento do COBOL.

Hoje a IA consegue:

Explicar programas legados.

Gerar documentação.

Produzir diagramas.

Encontrar dependências.

Criar casos de teste.

Gerar SQL.

Explicar ABENDs.

Documentar COPYBOOKs.

Converter documentação antiga.

Criar APIs.

Sugerir melhorias.

Isso reduz drasticamente o tempo entre entender um sistema e modificá-lo.

Mas a IA substitui o programador COBOL?

Não.

Na verdade, ela muda seu papel.

O desenvolvedor deixa de gastar horas procurando variáveis.

Passa a dedicar mais tempo às decisões arquiteturais.

Ao negócio.

À integração.

À qualidade.

À segurança.

A produtividade aumenta.

A responsabilidade também.

Governança continua indispensável

RAD nunca significou ausência de controle.

No Mainframe isso é ainda mais importante.

Boas práticas incluem:

  • RACF;

  • segregação de ambientes;

  • aprovação de mudanças;

  • auditoria;

  • versionamento;

  • rastreabilidade;

  • documentação mínima;

  • revisão técnica.

Velocidade sem governança gera incidentes.

Segurança

O IBM Z continua sendo referência mundial.

Entretanto...

Novas APIs significam novos riscos.

Autenticação.

OAuth.

JWT.

TLS.

MFA.

LGPD.

Logs.

Monitoramento.

Tudo deve ser considerado desde o início.

Observabilidade

Outra tendência recente.

Não basta colocar em produção.

É preciso observar.

SMF.

RMF.

OMEGAMON.

Grafana.

OpenTelemetry.

Logs.

Métricas.

Alertas.

Quanto antes identificarmos problemas...

Mais rapidamente corrigimos.

Oportunidades profissionais

Existe um aspecto extremamente interessante.

Empresas procuram profissionais que conheçam:

COBOL.

CICS.

DB2.

Mas também procuram pessoas que compreendam:

DevOps.

Git.

APIs.

Cloud.

Containers.

Integração.

CI/CD.

IA.

RAD aproxima esses dois mundos.

O profissional deixa de ser apenas um programador.

Passa a ser um engenheiro de soluções.

O futuro do RAD no IBM Z

O futuro parece bastante claro.

Veremos cada vez mais:

Assistentes baseados em IA.

Documentação automática.

Conversão de código.

Testes gerados automaticamente.

APIs criadas por IA.

Observabilidade inteligente.

Pipelines autônomos.

Análise preditiva.

Low-Code integrado ao Mainframe.

Agentes de IA especializados em COBOL.

Nada disso elimina o IBM Z.

Na verdade...

Tudo isso aumenta sua importância.

Porque o Mainframe continuará sendo o sistema de registro das maiores organizações do mundo.

O RAD morreu?

Definitivamente não.

Ele apenas mudou de nome várias vezes.

Quando ouvimos falar em:

Agile.

Sprint.

Lean.

XP.

DevOps.

CI/CD.

Low-Code.

No-Code.

IA Generativa.

Estamos observando diferentes evoluções da mesma ideia.

Reduzir o tempo entre uma necessidade do negócio e a entrega de valor.

Essa continua sendo a essência do RAD.

Conclusão

Ao longo desta série vimos que o Rapid Application Development nunca foi apenas uma metodologia para acelerar projetos.

Foi uma mudança de mentalidade.

James Martin percebeu, ainda no início da década de 1990, que o maior desperdício no desenvolvimento de software não era escrever código lentamente. Era construir soluções que não atendiam às necessidades reais do negócio.

Três décadas depois, essa percepção continua atual.

Scrum, DevOps, Low-Code, No-Code e Inteligência Artificial ampliaram as possibilidades, mas preservaram o mesmo princípio: aprender cedo, corrigir cedo e entregar valor continuamente.

No universo IBM Mainframe, essa filosofia encontra um terreno fértil. COBOL, CICS, DB2, IMS e z/OS permanecem como pilares das aplicações mais críticas do planeta, enquanto APIs, Git, pipelines CI/CD, testes automatizados e IA transformam a forma como essas soluções evoluem.

O verdadeiro ganho não está em substituir tecnologias consolidadas, mas em modernizar processos, reduzir desperdícios e aproximar continuamente a TI das necessidades do negócio.

Para o programador COBOL, a mensagem é clara: dominar RAD não significa abandonar décadas de experiência. Significa potencializá-las com práticas modernas, mantendo a confiabilidade que fez do IBM Z uma referência mundial.

No fim das contas, a velocidade nunca esteve na linguagem de programação.

Ela sempre esteve na capacidade da equipe de aprender, adaptar-se e entregar soluções que realmente fazem diferença.

E essa continua sendo uma das maiores lições da Engenharia de Software.


Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , , ,

sexta-feira, 23 de fevereiro de 2024

RAD (Rapid Application Development) — Como Implementar RAD na Prática, Principais Metodologias, Ferramentas - Parte II

 

Bellacosa Mainframe apresenta o rad parte ii

☕ Um Café no Bellacosa Mainframe

RAD (Rapid Application Development)

Parte II — Como Implementar RAD na Prática, Principais Metodologias, Ferramentas e o Papel da Inteligência Artificial

"Desenvolver rapidamente nunca significou programar rapidamente. Significou aprender rapidamente."

Recapitulando

Na primeira parte desta série vimos que o RAD nasceu como resposta a um problema que ainda existe.

Empresas mudam rapidamente.

Os negócios mudam rapidamente.

Os clientes mudam rapidamente.

O software precisa acompanhar esse ritmo.

James Martin percebeu isso no início dos anos 90, muito antes de ouvirmos falar de Scrum, DevOps, Cloud Computing ou Inteligência Artificial.

Mas existe uma pergunta ainda mais importante.

Como colocar RAD em prática?

É exatamente isso que veremos agora.

Porque conhecer a teoria é relativamente simples.

O verdadeiro desafio está em transformar uma equipe tradicional em uma equipe capaz de entregar software continuamente.

A filosofia do RAD

Antes de falar de ferramentas precisamos compreender uma característica importante.

RAD não é uma ferramenta.

RAD não é uma linguagem.

RAD não é um framework.

RAD é uma filosofia de desenvolvimento.

Essa diferença muda tudo.

Uma empresa pode utilizar Java.

Outra COBOL.

Outra Python.

Outra C#.

Outra JavaScript.

Todas podem aplicar RAD.

O que muda não é a tecnologia.

É a maneira como ela é utilizada.

O primeiro passo: definir um problema pequeno

O maior erro cometido por equipes iniciantes é querer desenvolver todo o sistema de uma única vez.

RAD faz exatamente o contrário.

Começa pequeno.

Muito pequeno.

Imagine um banco.

Ao invés de desenvolver todo o Internet Banking...

Começa apenas pela consulta de saldo.

Depois extrato.

Depois PIX.

Depois investimentos.

Depois cartões.

Cada funcionalidade nasce praticamente como um pequeno projeto.

Essa abordagem reduz riscos.

Se algo der errado...

O prejuízo é pequeno.

Segundo passo: montar uma equipe enxuta

RAD funciona melhor quando existe pouca burocracia.

Normalmente encontramos equipes compostas por:

  • Analista de Negócios

  • Usuário-chave

  • Desenvolvedor

  • Especialista em Banco de Dados

  • Testador

  • Arquiteto

Não significa que grandes empresas trabalhem apenas com seis pessoas.

Significa que cada módulo possui autonomia.

Quanto menor a cadeia de aprovação...

Maior a velocidade.

Terceiro passo: envolver o usuário desde o primeiro dia

Este talvez seja o segredo mais importante.

No desenvolvimento tradicional o usuário aparece em três momentos.

Levantamento.

Homologação.

Produção.

No RAD ele participa praticamente todos os dias.

Imagine um gerente de crédito.

Na segunda-feira ele vê uma tela.

Na terça sugere mudanças.

Na quarta recebe uma nova versão.

Na quinta encontra outro detalhe.

Na sexta aprova.

Foram cinco dias.

Não cinco meses.

Quarto passo: criar um protótipo

Muitos desenvolvedores acreditam que um protótipo precisa funcionar.

Nem sempre.

Às vezes basta desenhar as telas.

Hoje existem dezenas de ferramentas para isso.

Figma.

Balsamiq.

Adobe XD.

Draw.io.

PowerPoint.

Até papel e caneta funcionam.

O objetivo não é impressionar.

É descobrir rapidamente se a ideia faz sentido.

Quinto passo: construir um MVP

Outro conceito herdado pelo desenvolvimento moderno.

MVP significa:

Minimum Viable Product

Ou Produto Mínimo Viável.

É a menor versão possível capaz de gerar valor.

Não significa software incompleto.

Significa software focado.

Imagine um sistema de empréstimos.

Ao invés de desenvolver quarenta funcionalidades...

Construa apenas cinco.

Se resolverem o problema principal...

O MVP cumpriu seu papel.

Sexto passo: validar rapidamente

Depois do MVP vem o momento mais importante.

Mostrar ao usuário.

Sem apresentações longas.

Sem centenas de slides.

Sem documentos enormes.

Coloque o sistema na frente dele.

Observe.

Escute.

Anote.

Melhore.

Repita.

Esse ciclo acontece inúmeras vezes.

Sétimo passo: melhorar continuamente

RAD nunca considera o software terminado.

Sempre existe espaço para melhorias.

Esse conceito influenciou diretamente o DevOps.

A aplicação evolui continuamente.

Pequenas melhorias.

Pequenos ajustes.

Pequenas correções.

Pequenas entregas.

O resultado costuma ser muito superior a uma única entrega gigantesca.

Como medir se o RAD está funcionando?

Toda metodologia precisa de indicadores.

Caso contrário ela vira opinião.

Algumas métricas importantes são:

Tempo até a primeira entrega

Quanto tempo levou para o usuário ver algo funcionando?

Dias?

Semanas?

Meses?

Quanto menor esse tempo...

Melhor.

Tempo de resposta às mudanças

Quanto tempo leva para alterar uma regra?

Horas?

Dias?

Semanas?

Se pequenas alterações exigem meses...

O processo ainda é pesado.

Número de retrabalhos

Se o usuário rejeita constantemente o software...

Algo está errado.

RAD busca reduzir retrabalho através do feedback constante.

Satisfação do usuário

Talvez seja o indicador mais importante.

Software existe para resolver problemas.

Não para produzir documentação.

As metodologias que herdaram conceitos do RAD

Embora o RAD seja uma metodologia própria, diversos movimentos posteriores incorporaram suas ideias.

Scrum

Sprint.

Incrementos.

Revisões.

Backlog.

Todos esses conceitos possuem enorme afinidade com RAD.

A principal diferença é que Scrum adicionou uma estrutura mais formal para gerenciamento.

Extreme Programming (XP)

XP talvez seja a metodologia que mais herdou conceitos do RAD.

Ela enfatiza:

  • feedback constante;

  • integração contínua;

  • programação em pares;

  • testes automatizados;

  • pequenas entregas.

Na prática, XP leva o RAD para um nível técnico ainda maior.

Lean Software Development

O Lean nasceu inspirado no Sistema Toyota.

Seu foco é eliminar desperdícios.

Curiosamente...

RAD também fazia exatamente isso.

Ambos valorizam aquilo que gera valor ao cliente.

DevOps

Muitos imaginam que DevOps trata apenas de infraestrutura.

Não.

DevOps também reduz o tempo entre desenvolver e colocar em produção.

Essa busca pela velocidade é um dos princípios centrais do RAD.

Agile

Podemos dizer que o RAD foi um dos grandes precursores do movimento ágil.

Nem todos concordam com essa afirmação.

Mas basta observar os princípios.

Feedback rápido.

Cliente presente.

Entregas frequentes.

Iterações.

Tudo isso já aparecia no RAD.

Ferramentas clássicas do RAD

Nos anos 90 existia uma verdadeira explosão de ferramentas RAD.

Algumas desapareceram.

Outras evoluíram.

Outras continuam presentes.

Entre elas:

PowerBuilder

Uma das maiores referências da época.

Construía aplicações corporativas rapidamente.

Oracle Forms

Durante muitos anos dominou aplicações empresariais.

Principalmente no ambiente Oracle.

Visual Basic

Talvez o maior símbolo do RAD para plataformas Windows.

Arrastar componentes.

Criar telas.

Conectar banco.

Gerar aplicações em poucas horas.

Delphi

Um dos ambientes RAD mais famosos da história.

Compilação extremamente rápida.

Excelente desempenho.

Grande produtividade.

Até hoje possui uma comunidade fiel.

GeneXus

Muito conhecido na América Latina.

Gera aplicações automaticamente para diversas plataformas.

Utilizado inclusive em grandes instituições financeiras.

Magic xpa

Ferramenta RAD voltada ao ambiente corporativo.

Muito utilizada em integração de sistemas.

Ferramentas modernas

O conceito continua vivo.

Mudaram apenas os nomes.

Hoje encontramos:

Microsoft Power Apps

Google AppSheet

OutSystems

Mendix

ServiceNow App Engine

Salesforce Lightning

Oracle APEX

Retool

FlutterFlow

Bubble

Appian

Zoho Creator

Todas seguem praticamente a mesma ideia.

Construir rapidamente.

Validar rapidamente.

Entregar rapidamente.

RAD e Low-Code

É impossível falar de RAD sem mencionar Low-Code.

Na prática...

Low-Code tornou o RAD muito mais poderoso.

Imagine criar uma tela.

Conectar um banco.

Criar APIs.

Publicar na nuvem.

Tudo isso praticamente sem escrever código.

O RAD encontrou no Low-Code um parceiro natural.

RAD e No-Code

O No-Code leva esse conceito ainda mais longe.

Usuários de negócio conseguem construir soluções simples.

Sem depender completamente da TI.

Isso acelera protótipos.

Validações.

Experimentos.

Naturalmente, sistemas críticos ainda exigem desenvolvimento profissional.

Especialmente no Mainframe.

Inteligência Artificial e RAD

Talvez este seja o maior salto desde os anos 90.

Hoje a IA consegue:

Gerar código.

Criar documentação.

Escrever testes.

Produzir APIs.

Criar consultas SQL.

Explicar código legado.

Converter linguagens.

Criar protótipos.

Documentar regras de negócio.

Isso reduz drasticamente o tempo de desenvolvimento.

Mas existe um detalhe importante.

A IA acelera.

Ela não substitui engenharia.

Alguém continua precisando tomar decisões arquiteturais.

Performance no RAD

Existe outro mito bastante conhecido.

"Software desenvolvido rapidamente é lento."

Não necessariamente.

Performance depende muito mais da arquitetura.

Uma aplicação construída em RAD pode apresentar excelente desempenho quando possui:

  • arquitetura bem definida;

  • banco de dados otimizado;

  • índices corretos;

  • consultas eficientes;

  • cache adequado;

  • testes de carga;

  • monitoramento constante.

O problema não está na velocidade do desenvolvimento.

Está na ausência de engenharia.

Governança

Projetos RAD também precisam de controle.

Sem governança surge o caos.

Algumas práticas recomendadas:

Versionamento no Git.

Code Review.

Integração Contínua.

Pipeline automatizado.

Testes automatizados.

Documentação mínima.

Monitoramento.

Catálogo de APIs.

Padronização de componentes.

Segurança

Outro erro comum.

"Ainda é protótipo."

Quantos incidentes começaram exatamente assim?

Mesmo durante prototipação devemos considerar:

Autenticação.

Autorização.

Criptografia.

Proteção de dados.

LGPD.

Auditoria.

Logs.

Quanto antes a segurança entrar no projeto...

Menor o custo.

Quando RAD não é a melhor escolha?

Existem situações em que outras abordagens podem ser mais adequadas.

Por exemplo:

Projetos militares.

Sistemas embarcados extremamente críticos.

Software aeroespacial.

Equipamentos médicos.

Aplicações certificadas.

Ambientes altamente regulados.

Nesses casos o custo da documentação extensa pode ser menor que o risco de falhas.

Mesmo assim, muitos princípios do RAD continuam sendo utilizados durante prototipação e validação.

O erro mais comum

Muitos gestores acreditam que RAD significa fazer tudo mais rápido.

Na realidade significa aprender mais rápido.

Existe uma enorme diferença.

Velocidade sem aprendizado produz retrabalho.

Aprendizado contínuo produz velocidade.

Essa talvez seja a maior lição deixada por James Martin.

O que um programador COBOL pode aproveitar hoje?

Mesmo trabalhando exclusivamente com IBM Z, praticamente todos os conceitos desta parte podem ser aplicados.

Você pode criar protótipos de telas antes de desenvolver transações CICS.

Pode validar regras de negócio com usuários antes de alterar programas COBOL.

Pode utilizar APIs simuladas para testar integrações.

Pode automatizar builds, testes e deploys em pipelines DevOps.

Pode expor programas COBOL como serviços REST por meio do z/OS Connect e receber feedback em ciclos curtos.

Pode utilizar Inteligência Artificial para documentar código legado, sugerir refatorações e acelerar a criação de testes.

O ambiente mudou muito desde 1991, mas o objetivo continua exatamente o mesmo: reduzir a distância entre a necessidade do negócio e a entrega de uma solução funcional.

No próximo café entraremos definitivamente no universo IBM Mainframe. Veremos como aplicar RAD em aplicações COBOL, CICS, IMS, DB2, VSAM e z/OS, como integrar essa metodologia com DevOps, Git, APIs, z/OS Connect, testes automatizados e modernização, além de entender por que o RAD continua extremamente relevante na era do IBM Z e da Inteligência Artificial.


Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , , ,

quarta-feira, 24 de janeiro de 2024

RAD (Rapid Application Development) - O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia RAD Parte I

 

Bellacosa Mainframe apresenta a rapid application development parte i

☕ Um Café no Bellacosa Mainframe

RAD (Rapid Application Development)

O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia que Ensinou o Mundo a Desenvolver Software Rapidamente

Você Não Está Descobrindo uma Ideia Nova. Está Descobrindo uma Tecnologia que Influenciou Quase Tudo o Que Veio Depois.

"Toda geração acredita que inventou uma forma mais rápida de desenvolver software. Poucos percebem que muitas dessas ideias nasceram há mais de trinta anos. O RAD foi uma delas."

Introdução

Quem começou a trabalhar com desenvolvimento de software nos anos 80 e 90 certamente ouviu falar de uma promessa bastante ousada.

"Vamos desenvolver sistemas em poucos meses."

Naquela época isso parecia impossível.

O desenvolvimento tradicional era lento.

Primeiro vinha o levantamento de requisitos.

Depois a documentação.

Depois o projeto.

Depois a programação.

Depois os testes.

Depois a homologação.

E finalmente... meses ou anos depois... o usuário via o sistema funcionando.

Não era raro um projeto durar dois ou três anos.

O problema?

Quando finalmente ficava pronto, o negócio já havia mudado.

As regras eram outras.

As necessidades eram diferentes.

E boa parte do software já nascia desatualizada.

Foi justamente para resolver esse problema que surgiu o Rapid Application Development, mais conhecido como RAD.

Muitos desenvolvedores mais jovens imaginam que desenvolvimento rápido começou com Agile, Scrum, DevOps, Low-Code ou Inteligência Artificial.

Na verdade, todos esses movimentos herdaram conceitos que o RAD apresentou décadas antes.

Para quem trabalha com COBOL, isso é especialmente interessante.

Durante muito tempo criou-se o mito de que Mainframe significa desenvolvimento lento.

Na prática, diversos bancos brasileiros entregavam sistemas críticos em velocidade impressionante utilizando conceitos extremamente próximos do RAD, mesmo antes de adotarem oficialmente essa metodologia.

O segredo nunca foi apenas a linguagem.

O segredo sempre foi o processo.

O cenário antes do RAD

Para entender o RAD precisamos voltar aos anos 1980.

A informática corporativa vivia um momento curioso.

Os computadores estavam ficando mais poderosos.

As empresas dependiam cada vez mais dos sistemas.

Mas o desenvolvimento continuava extremamente burocrático.

O modelo dominante era o famoso Waterfall, ou Cascata.

Sua lógica era simples.

Primeiro termina uma fase.

Depois começa a próxima.

Jamais volte atrás.

Na teoria fazia sentido.

Na prática...

Nem tanto.

Imagine desenvolver um sistema bancário durante dezoito meses.

Durante esse período:

  • novas leis aparecem;

  • novos produtos financeiros surgem;

  • a inflação muda;

  • concorrentes inovam;

  • clientes mudam de comportamento.

Quando o software finalmente chega à produção...

Ele resolve um problema que talvez nem exista mais.

Era uma época em que modificar requisitos era quase um pecado.

Qualquer alteração significava:

  • alterar documentos;

  • alterar diagramas;

  • alterar especificações;

  • alterar programas;

  • alterar testes.

Tudo isso custava muito dinheiro.

Foi nesse ambiente que algumas pessoas começaram a fazer uma pergunta aparentemente simples.

"E se desenvolvêssemos junto com o usuário?"

Essa pergunta mudaria a história da Engenharia de Software.

O nascimento do RAD

O principal responsável pela popularização do RAD foi James Martin.

Image

Image

Image

James Martin era um dos maiores especialistas em Engenharia de Software da época.

Consultor.

Autor.

Pesquisador.

Visionário.

Em 1991 publicou um livro que se tornaria referência mundial:

Rapid Application Development.

Naquele momento ele propôs algo bastante diferente.

Ao invés de gastar meses planejando cada detalhe do sistema...

Construa uma primeira versão.

Mostre ao usuário.

Receba feedback.

Melhore.

Repita.

Hoje isso parece absolutamente normal.

Na época era revolucionário.

Martin defendia que o software não deveria nascer perfeito.

Deveria nascer útil.

Existe uma enorme diferença entre essas duas ideias.

O grande problema que o RAD resolveu

Imagine um gerente de banco.

Ele pede um sistema.

Durante meses responde entrevistas.

Participa de reuniões.

Assina documentos.

Depois desaparece.

Um ano depois recebe o software.

Ao abrir a aplicação percebe algo curioso.

"Não era exatamente isso que eu queria."

Essa frase custava milhões de dólares.

Não porque os programadores eram ruins.

Mas porque pessoas têm dificuldade em imaginar um sistema apenas olhando documentação.

Quando veem uma tela funcionando...

Tudo muda.

Elas descobrem novas necessidades.

Percebem erros.

Lembram regras esquecidas.

Propõem melhorias.

O RAD transformou essa descoberta em metodologia.

Em vez de lutar contra mudanças...

Passe a utilizá-las como parte natural do desenvolvimento.

O princípio mais importante do RAD

Se fosse necessário resumir o RAD em apenas uma frase, seria esta:

O usuário entende melhor um sistema funcionando do que um documento descrevendo esse sistema.

Esse conceito parece óbvio hoje.

Mas revolucionou a forma de desenvolver software.

Em vez de produzir centenas de páginas de documentação...

Construa rapidamente um protótipo.

Mesmo incompleto.

Mesmo simples.

Mesmo temporário.

Porque um protótipo gera discussões muito mais produtivas do que um documento.

É muito mais fácil dizer:

"Esse botão deveria estar aqui."

Do que imaginar onde ele deveria ficar lendo uma especificação técnica.

O que significa "Rapid"

Muita gente interpreta o nome errado.

Rapid não significa:

"Programar correndo."

Nem:

"Escrever código sem qualidade."

Nem:

"Ignorar documentação."

Nem:

"Fazer gambiarra."

Rapid significa reduzir desperdícios.

Eliminar atividades que não agregam valor.

Descobrir erros cedo.

Corrigir rapidamente.

Automatizar tarefas repetitivas.

Construir somente aquilo que realmente será utilizado.

Em outras palavras...

Ser rápido porque o processo ficou melhor.

Não porque os programadores trabalham mais horas.

Os quatro pilares do RAD

Embora existam diversas interpretações, praticamente todas compartilham quatro fundamentos.

1. Desenvolvimento iterativo

Ao invés de entregar tudo no final...

Entregue pequenas partes continuamente.

Cada versão adiciona funcionalidades.

Cada ciclo reduz riscos.

Cada entrega aproxima o produto da necessidade real.

Esse conceito mais tarde inspiraria boa parte do Agile.

2. Prototipação

O protótipo é talvez a característica mais conhecida do RAD.

Ele não precisa ser bonito.

Nem completo.

Seu objetivo é validar ideias.

Quanto antes o usuário interagir...

Melhor.

Hoje fazemos isso com wireframes.

Mockups.

Aplicações Low-Code.

Ferramentas de UX.

Nos anos 90 isso já existia, apenas com tecnologias diferentes.

3. Participação intensa do usuário

No RAD o cliente deixa de ser apenas aprovador.

Ele participa continuamente.

Isso reduz um problema clássico.

Desenvolver exatamente aquilo que ninguém precisava.

Quanto mais próximo estiver o usuário...

Maior a chance de sucesso.

4. Times pequenos e multidisciplinares

Equipes enormes costumam gerar burocracia.

RAD prefere grupos pequenos.

Com autonomia.

Decisão rápida.

Comunicação simples.

Responsabilidade compartilhada.

Décadas depois...

Scrum repetiria praticamente o mesmo conceito.

O ciclo de vida do RAD

Embora existam variações, normalmente encontramos quatro grandes fases.

Planejamento

Define objetivos.

Escopo inicial.

Equipe.

Restrições.

Não tenta prever absolutamente tudo.

Planeja apenas o suficiente para começar.

Design colaborativo

Usuários e desenvolvedores trabalham juntos.

Modelam processos.

Criam protótipos.

Validam telas.

Ajustam regras.

É uma fase extremamente dinâmica.

Construção rápida

Os desenvolvedores começam imediatamente.

Ferramentas de geração automática.

Componentes reutilizáveis.

Bibliotecas.

Frameworks.

Tudo é utilizado para acelerar o trabalho.

Transição

Depois das validações...

O sistema entra em produção.

Mas o ciclo continua.

Novas versões aparecem.

Novos ajustes são realizados.

O software evolui continuamente.

RAD e Engenharia de Software

Existe um mito curioso.

Algumas pessoas acreditam que RAD significa abandonar Engenharia de Software.

Na verdade ocorre exatamente o contrário.

O RAD depende fortemente de boas práticas.

Arquitetura.

Modelagem.

Reutilização.

Padronização.

Automação.

Sem isso...

O desenvolvimento rápido se transforma rapidamente em caos.

Quanto maior a velocidade...

Maior deve ser a disciplina.

RAD versus Waterfall

A comparação mais comum é entre RAD e Cascata.

WaterfallRAD
Planejamento extensoPlanejamento suficiente
Documentação pesadaProtótipos
Entrega únicaEntregas frequentes
Mudanças carasMudanças esperadas
Usuário distanteUsuário presente
Descobre erros tardeDescobre erros cedo

Nenhum modelo é perfeito.

Projetos extremamente regulados ainda utilizam Cascata.

Projetos inovadores normalmente preferem abordagens iterativas.

O RAD influenciou quase tudo

É curioso observar quantas metodologias modernas possuem DNA do RAD.

Scrum utiliza iterações.

Kanban utiliza fluxo contínuo.

Lean elimina desperdícios.

XP incentiva feedback constante.

DevOps aproxima desenvolvimento e operação.

Low-Code acelera construção.

No-Code reduz codificação.

IA Generativa cria protótipos em minutos.

Nenhuma dessas ideias nasceu isoladamente.

Todas beberam, em maior ou menor grau, da mesma fonte: a busca por ciclos curtos de entrega e validação.

Vantagens do RAD

Para o negócio, os benefícios são claros:

  • redução do tempo de entrega;

  • menor custo de mudanças;

  • maior participação do cliente;

  • melhor alinhamento com o negócio;

  • menor risco de desenvolver funcionalidades desnecessárias;

  • maior satisfação dos usuários;

  • retorno mais rápido do investimento;

  • possibilidade de corrigir erros antes que se tornem caros.

Para os desenvolvedores, o ganho também é significativo.

Ver o sistema funcionando cedo aumenta a motivação da equipe.

O feedback deixa de ser uma surpresa no final do projeto e passa a orientar o trabalho desde o primeiro ciclo.

Desvantagens e limitações

Nenhuma metodologia resolve todos os problemas.

O RAD também possui limitações.

Projetos gigantescos, envolvendo centenas de equipes e forte dependência regulatória, podem exigir maior formalismo.

Além disso, o sucesso depende da disponibilidade do usuário.

Se o cliente não participa, o principal benefício do RAD desaparece.

Outro ponto crítico é a arquitetura.

A pressa para entregar não pode comprometer a qualidade estrutural da solução.

Sem uma boa arquitetura, cada nova iteração aumenta a dívida técnica.

Mitos sobre o RAD

Ao longo dos anos, alguns equívocos se tornaram comuns.

"RAD é programar sem planejamento."
Não. O planejamento existe, mas é adaptativo.

"RAD elimina documentação."
Não. Ele elimina documentação desnecessária.

"RAD serve apenas para sistemas pequenos."
Não. Grandes organizações o utilizam, desde que combinado com boa governança.

"RAD gera software de baixa qualidade."
Também não. Quando bem aplicado, tende a produzir software mais aderente às necessidades do negócio justamente porque recebe feedback constante.

O que um programador COBOL deve aprender com o RAD?

Talvez a maior lição do RAD seja esta:

A velocidade de um projeto não depende apenas da linguagem.

COBOL continua processando bilhões de transações diariamente com confiabilidade incomparável.

O desafio moderno não é substituir COBOL, mas reduzir o tempo entre uma ideia de negócio e sua implementação em produção.

É aí que entram os princípios do RAD.

Prototipação.

Integração contínua.

Automação de testes.

Reutilização de componentes.

Participação ativa do usuário.

Entrega incremental.

Esses conceitos funcionam tão bem em aplicações web quanto em ambientes IBM Z.

Um programa COBOL que expõe serviços por meio do z/OS Connect, integra APIs REST, participa de pipelines DevOps e recebe feedback frequente do negócio está muito mais próximo do espírito do RAD do que muitos sistemas escritos com tecnologias consideradas "modernas".

No fim, o RAD nunca foi sobre velocidade pela velocidade.

Sempre foi sobre reduzir desperdícios, aprender mais cedo e entregar valor continuamente.

Essa ideia nasceu há mais de três décadas, atravessou gerações de linguagens, frameworks e plataformas, e continua moldando a forma como construímos software.

No próximo café, veremos como colocar o RAD em prática: metodologias, ferramentas clássicas e modernas, métricas, governança, performance, integração com Low-Code, IA e um passo a passo completo para implementar RAD com sucesso — inclusive em ambientes IBM Mainframe.


Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , ,
Subscrever: Mensagens (Atom)