 |
| Bellacosa Mainframe e o que é a metodologia waterfall |
☕ Um Café no Bellacosa Mainframe
O que é a Metodologia Waterfall ?
Quando um Programador Descobre que Construir um Sistema Bancário é Mais Parecido com Construir uma Usina Hidrelétrica do que com Criar um Aplicativo de Celular
Existe uma cena clássica em praticamente todos os filmes sobre construção de grandes obras.
Antes de alguém colocar o primeiro tijolo, engenheiros passam meses desenhando plantas, calculando estruturas, especificando materiais e validando cada detalhe.
Ninguém começa construindo o telhado.
Ninguém instala os elevadores antes das fundações.
Tudo acontece em uma sequência lógica.
Curiosamente, durante décadas, foi exatamente assim que nasceram praticamente todos os grandes sistemas bancários, governamentais, seguradoras e companhias aéreas do planeta.
Essa forma de desenvolver software recebeu um nome que se tornou uma das metodologias mais famosas da Engenharia de Software:
Waterfall, ou Modelo em Cascata.
Se você trabalha ou pretende trabalhar com IBM Mainframe, COBOL, CICS ou Db2, entender Waterfall é quase uma viagem no tempo para compreender como surgiram alguns dos maiores sistemas corporativos ainda em produção.
Prepare seu café. Hoje vamos descobrir por que uma simples cachoeira acabou se tornando uma das metodologias mais importantes da história da computação.
O que é Waterfall?
Waterfall (Cascata) é um modelo de desenvolvimento de software linear e sequencial.
Cada etapa deve ser concluída antes da próxima começar.
Em outras palavras:
Requisitos ↓ Análise ↓ Projeto ↓ Desenvolvimento ↓ Testes ↓ Implantação ↓ Manutenção
É exatamente como uma cascata.
A água nunca sobe.
Ela sempre segue para o próximo nível.
Por que recebeu esse nome?
Imagine uma cachoeira.
████████████ ↓ ████████████ ↓ ████████████ ↓ ████████████
Depois que a água passa por uma etapa, ela não volta.
O mesmo acontece no Waterfall.
Terminou os requisitos?
Segue para análise.
Terminou análise?
Vai para projeto.
E assim sucessivamente.
Um pouco de história
Embora existam ideias semelhantes desde os anos 1960, o modelo ficou famoso em 1970, quando Winston W. Royce publicou um artigo sobre desenvolvimento de grandes sistemas.
Curiosamente, um dos maiores "mistérios" da Engenharia de Software é que Royce não defendia um Waterfall rígido. No próprio artigo ele alertava que executar todas as fases sem revisões trazia riscos e sugeria iterações e validações intermediárias.
Mesmo assim, a indústria adotou o modelo simplificado em cascata porque ele era fácil de entender, documentar e controlar.
Naquela época:
- computadores eram extremamente caros;
- alterar software custava muito;
- testes consumiam semanas;
- compilações demoravam;
- documentação era obrigatória.
O Waterfall fazia muito sentido.
Por que o Mainframe adotou Waterfall?
Porque o ambiente Mainframe era perfeito para esse modelo.
Imagine um banco em 1985.
Uma alteração simples podia envolver:
- dezenas de programas COBOL;
- centenas de JCLs;
- arquivos VSAM;
- tabelas Db2;
- transações CICS;
- equipes diferentes.
Nada podia falhar.
Um erro poderia impedir milhões de pagamentos.
Logo, planejar tudo antes de programar era a escolha natural.
As sete fases do Waterfall
1. Levantamento de Requisitos
Tudo começa entendendo o negócio.
Perguntas como:
- O que o cliente precisa?
- Quem utilizará o sistema?
- Quais regras devem ser atendidas?
- Existem exigências legais?
- Há integrações com outros sistemas?
Exemplo:
"Precisamos criar um sistema para pagamento de aposentadorias."
Ainda não existe código.
Existe apenas a necessidade.
2. Análise Funcional
Agora o analista transforma as necessidades em especificações.
São produzidos documentos como:
- regras de negócio;
- fluxogramas;
- casos de uso;
- modelos de dados;
- especificações funcionais.
Aqui nasce o projeto.
3. Projeto Técnico
É o momento de definir como o sistema será construído.
Exemplos:
- COBOL ou PL/I?
- CICS ou Batch?
- Db2 ou VSAM?
- MQ?
- APIs REST?
- Estrutura das tabelas?
- Layout dos arquivos?
É como desenhar a planta de um edifício antes de iniciar a obra.
4. Desenvolvimento
Agora os programadores entram em ação.
Escrevem:
- programas COBOL;
- JCLs;
- Stored Procedures;
- BMS Maps;
- SQL;
- REXX;
- CLIST;
- utilitários.
É a fase mais conhecida, mas não é a primeira nem a única.
5. Testes
Tudo precisa ser validado.
No Mainframe encontramos testes como:
- unitários;
- integração;
- regressão;
- desempenho;
- homologação.
Cada programa é executado em diversos cenários para garantir que o comportamento esperado foi atendido.
6. Implantação
Depois da homologação, chega a hora de colocar o sistema em produção.
Normalmente envolve:
- geração de pacotes;
- controle de versões;
- promoção entre ambientes;
- execução de jobs;
- validações finais.
É a passagem do ambiente de testes para o mundo real.
7. Manutenção
O software entra em produção, mas o trabalho continua.
A manutenção pode ser:
- corretiva;
- adaptativa;
- evolutiva;
- preventiva.
Muitos sistemas COBOL estão nessa fase há mais de 40 anos.
Exemplo prático
Imagine um novo módulo de PIX para um banco.
Cliente solicita PIX │ ▼ Levantamento dos requisitos │ ▼ Análise funcional │ ▼ Projeto técnico │ ▼ Programação COBOL │ ▼ Testes │ ▼ Produção
Cada fase depende da anterior.
Virtudes do Waterfall
O modelo ganhou popularidade por oferecer várias vantagens em projetos de grande porte:
- documentação completa;
- planejamento detalhado;
- cronograma previsível;
- fácil acompanhamento gerencial;
- responsabilidades bem definidas;
- excelente para ambientes regulados;
- facilita auditorias;
- reduz ambiguidades quando os requisitos são estáveis.
Em setores como bancos, seguradoras, telecomunicações e governo, essas características sempre foram muito valorizadas.
Defeitos do Waterfall
Apesar de suas qualidades, o modelo apresenta limitações importantes.
Entre elas:
- mudanças são caras depois que o projeto avança;
- o cliente demora para ver o sistema funcionando;
- erros nos requisitos podem ser descobertos tardiamente;
- excesso de documentação pode tornar o processo lento;
- pouca flexibilidade para projetos inovadores ou com requisitos em constante mudança.
Por isso, em muitos cenários modernos, metodologias iterativas e ágeis passaram a ganhar espaço.
Waterfall no Mainframe atual
Mesmo com a adoção de práticas como Scrum, Kanban e DevOps, o Waterfall não desapareceu.
Em muitos projetos de IBM Z ele ainda é utilizado, principalmente quando há:
- requisitos legais bem definidos;
- integração com sistemas críticos;
- necessidade de documentação formal;
- auditorias frequentes;
- mudanças de alto risco.
Na prática, muitas organizações utilizam um modelo híbrido: planejamento e governança inspirados no Waterfall, combinados com entregas incrementais, integração contínua e automação de testes.
Curiosidades
- Grande parte dos sistemas bancários criados entre as décadas de 1970 e 1990 foi desenvolvida seguindo o modelo Waterfall.
- O artigo de Winston Royce é frequentemente citado como a origem da metodologia, embora ele próprio recomendasse mecanismos de revisão e feedback para reduzir riscos.
- O sucesso do Waterfall ajudou a consolidar profissões como analista de sistemas, analista funcional, arquiteto de software e gerente de projetos em ambientes corporativos.
Dicas para quem está começando
- Aprenda primeiro a levantar requisitos.
- Desenvolva o hábito de documentar bem.
- Domine fluxogramas e modelagem de processos.
- Entenda a diferença entre análise funcional e projeto técnico.
- Estude também metodologias ágeis para compreender quando cada abordagem é mais adequada.
- Lembre-se de que, em Mainframe, planejamento continua sendo um dos maiores diferenciais de um bom profissional.
Conclusão
O Waterfall marcou a história da Engenharia de Software ao organizar o desenvolvimento em etapas claras e sequenciais. Em ambientes Mainframe, onde confiabilidade, rastreabilidade e estabilidade sempre foram prioridades, ele ajudou a construir sistemas que processam milhões de transações diariamente e permanecem em operação por décadas.
No universo do Bellacosa Mainframe, compreender o Waterfall é entender como nasceram os gigantes da computação corporativa. Mesmo que hoje convivamos com métodos ágeis e práticas DevOps, a disciplina de planejar, analisar, projetar, implementar, testar e documentar continua sendo um dos pilares que sustentam o sucesso de aplicações críticas no IBM Z.
Sem comentários:
Enviar um comentário