Metodologia Waterfall: Uma nova visão

Salve jovem padawan, se es novo em desenvolvimento de softwares, esta metodologia poderá parecer arcaica, saída dos tempos das cavernas, obsoleta e sem nenhum atrativo para as novas gerações, porem neste artigo irei apresenta-la e tentar advogar em pro do seu uso, posso estar enganado, mas ao final deixo a ti esta decisão.

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

A primeira defesa que faço e deixo para pensares: estamos falando de uma metodologia de desenvolvimento informático, que surgiu há mais de 8 décadas, sim o Waterfall é usado para desenvolver software desde os longínquos anos 1940 com bilhões de hora de uso.

Podemos dizer sem modéstia ou exagero, todos os grandes softwares do passado, foram elaborados nesta metodologia ou em suas derivadas, a internet surgiu nela, os grandes mainframes foram codificados neles, linguagens de programação criadas embaixo deste processo.

Mas antes de avançarmos na história, vamos situar o jovem leitor numa rápida olhadela, sobre suas origens, definições, ferramentas e uso. Não se assuste, na informática não existe bala de prata, uma solução funciona bem para uns, falha redondamente para outros e na média atende a quase todos. Lembre-se trata-se de uma ciência humana, com pessoas e suas vaidades e orgulhos.

O que é Metodologia Waterfall, ou Modelo Cascata?

É uma metodologia que migrou da Engenhara, sendo adaptada para solucionar problemas da informática, ela funciona em degraus, sendo que cada atividade inicia-se após a conclusão do passo anterior. Classicamente esta dividida nos seguintes estágios: Concepção, Iniciação, Analise, Design, Codificação, Teste, Implantação e Manutenção; alguns analistas incluem passos intermédios outros removem, mas didaticamente manteremos 8 passos, no decorrer do texto, abordaremos com mais detalhes.

Utilizada na gerencia de projetos, para ajudar a quantificar o tempo em horas/homem, custos do projeto e necessidade de alocações de espaço físico e equipamentos no processo de Desenvolvimento de Software é de vital importância, para minimizar os Riscos do Projeto e controlar a evolução até a entrega.

Antes de avançarmos faço uma ressalva, sou um tiozão de mainframe, uma realidade que trabalhei ao longo de 3 décadas, por isso aviso aos navegantes, que sofro de um vies em pro Sistemas Mainframe e código legado, tendo pouca experiência em baixa plataforma por isso aos puristas deixo o alerta..

Para que serve a Metodologia Waterfall?

Na sua origem, o principal objetivo e diminuir as incertezas inerentes a gestão do projeto, ao criar um caminho logico, indicando as etapas necessárias e os documentos ideias para a boa conclusão do projeto.

A metodologia Cascata tem como serventia a correta alocação de recursos, a estimativa de prazos e esforços para a conclusão das atividades, os custos diversos decorrente da atividade de desenvolvimento.

Sendo indicada para projetos de grande duração necessita de equipes maduras e que conheçam o sistema, pois uma vez iniciado fica difícil retornar a pontos anteriores e modificar os requisitos.

Quem pode usar a metodologia Waterfall?

Esta metodologia devido a sua rigidez estrutural é indicada para projetos com Target bem delimitado, produtos que os Stakeholders saibam o que desejam, com poucas incertezas e equipes que conheçam o legado, com sua estrutura e documentação.

Exemplos típicos de boa aplicação, são modificações legais, migração de produto, ferramentas bem conhecidas, que necessitam de novas funcionalidades.

Evite utilizar em projetos com mudanças constantes e irritantes de escopo, equipe imaturas e que desconhecem o sistema legado, para essas atividades as metodologias agiles, são mais indicadas devido ao fator imprevisibilidade e necessidade de alterações constantes.

Quando usar a metodologia Waterfall?

Deve ser usada quando sabe-se bem o que se deseja, os requisitos sejam bem claros, necessita de bons analistas para desenhar bem as etapas iniciais, um bom trabalho de analise, indica qual a metodologia a ser usada. Devido ao desenho procedural, ela é indica para projetos em Mainframe e Sistemas Legado.

No próximo bloco iremos falar sobre as diversas fases, sendo importante notar, que o processo é indicado para fabricas de software, onde os Analistas de Sistemas criam as espeficaçoes usando fluxogramas para guiar a codificação.

No passado muitas empresas usavam equipes divididas em BA – Business Analyst e SD – System Developers, os primeiros tinham a função de desenhar e especificar os programas, enquanto os segundos codificavam e iniciavam os testes básicos.

Fases da Metodologia Waterfall

A seguir apresento as 8 etapas do processo Waterfall, segundo o artigo original de W.W.Royce e modificada ao longo dos anos em milhares de CPDs, lembrando que muitas empresas usam metodologia baseada, com alguma especificidade local, por exemplo, muitas empresas validam a Fase antes de seguir ao próximo passo, modificando e corrigindo em tempo de voo.

No Banco REAL onde trabalhei cada etapa para ser concluída, necessitava do aval de todas as áreas envolvidas, a saber: usuários, performance, banco de dados, produção, comitê de tela, auditoria e desenvolvimento. Era um trabalho burocrático, mas garantia que o usuário recebesse ao final aquilo que necessitava, inclusive incluindo funcionalidades em futuras releases, de acordo com o BackLog, que era negociado mensalmente na altura de cobrar pelos serviços.

Fase de concepção

Primeira fase, também conhecida como Estudo de Viabilidade do Projeto, onde a Área Usuária reunia-se com o Área de Informática para definir a necessidade, incluir os documentos preliminares e discutir o orçamento da fase inicial. Nesta analise delimitava-se o Escopo do Projeto e cria-se o documento de solicitação de estudo.

Fase de Inicialização

De posse do Estudo de Viabilidade, a área de informática inicia o trabalho de levantamento dos requisitos funcionais, técnicos e comerciais, para analisar e verificar o tipo de atividade e revalidar os escopos, garantindo as fronteiras do projeto e criando um orçamento da análise, marcando as equipes envolvidas e os sistemas afetados, com a documentação elaboração nova rodada de negociação é iniciada, para que os Stakeholders validem e deem o aceite para iniciar o projeto de Analise.

Fase de Analise

De posse dos documentos gerados na Fase de Concepção e Fase de Inicialização, a equipe técnica produzira os documentos de requisitos, será feito a cisão das atividades de acordo com os Sistemas Envolvidos e de acordo com a disponibilidade, será escolhida a tecnologia a ser utilizada, será determinado as prioridades, de modo a evitar colisões entre Projetos e estouros de prazos e é criado o orçamento final do Projeto.

Fase de Design

Nesta fase o projeto está todo documentado com os limites definidos, cabe a equipe técnica iniciar os processos de especificação de software, criação de ambientes de testes, aceite e validação. No passado quando o conceito de fábrica de software não era utilizado, a equipe de desenvolvimento interna começava a atividade de criar a equipe do Projeto.

A atividade principal é desenhar a navegação de telas e o workflow funcional, o tipo de base de dados necessário e outras atividade técnicas inerentes ao processo.

Fase de codificação.

Esta é a fase de mão na massa, onde as equipes técnicas codificam, etapa onde os programadores criam o código fonte, testam os programas em ambiente de desenvolvimento e garantem que o código gerado esta aderente as especificações.

Fase de Teste

O código fonte é enviado ao ambiente de aceite, onde são executados testes de gerais, testes de integração, garantindo que o programa está aderente e passou em todos os testes existentes no documento de aceite. Nesta fase o comitê de telas, comitê de performance, comitê de banco de dados, auditoria executam seus testes e emitem a aprovação.

Fase de Implantação

Com as etapas anteriores concluídas e com os devidos aceites OK, o código fonte passa a produção, num primeiro momento sendo acompanhado pelas equipes técnicas para garantirem a total integridade da implantação, passado a garantia o projeto esta encerrado.

Fase de Manutenção

Nesta fase as equipes de manutenção composta pela equipe de sustentação, garantem o dia a dia do projeto e caso necessite de eventuais manutenções, a mesma é classificada de acordo com o grau de gravidade, sendo as impactantes solucionadas imediatamente e as menos graves entrando no backlog do Sistema.

O meu testemunho sobre o Modelo Cascata

Em minha carreira profissional a maior parte dos projetos que trabalhei tiveram bom termino, sendo implantados no prazo acordado e orçamento prévio, houveram projetos que falharam, mas olhando para trás, a conclusão que chego, a culpa sempre foi da Fase Inicial, pois o cliente não sabia o que queria.

A parte mais importante é a análise e o estudo de viabilidade, pois definindo aquilo que se quer, fica fácil determinar o caminho a ser percorrido, se a cada reunir o usuário definir um novo pedido, realmente o projeto nunca ficara pronto.

Muitos consultores querem vender metodologias agiles como a panaceia de todos os males, não acredito muito nisso, pois baseando-se na Lei dos Grandes Números, quando mais projetos usarem determinada metodologia, maior será a probabilidade de ocorreram erros no caminho. Acredito que o Modelo Waterfall no futuro irá receber uma nova roupagem, e como tudo na vida voltaram a estar na moda.

Lembrando que esta metodologia está presente e em funcionamento em centenas de empresas e com certeza tem funcionado, garantindo as entregas e passagens a produção de softwares nas mais diversas tecnologias e linguagens de programação.

Conclusão

Caro padawan,o que achou? Espero que tenha alguma experiência na modelo cascata e possa comparar com outras metodologias, se foi sua primeira abordagem espero ter ajudado, caso não concorde com algo, deixe seu feedback, conte-me um pouco da sua experiência e juntos vamos mais longe.

Royce ao escrever seu artigo pontuou diversas críticas e elogios, sobre as críticas o pior e as equipes envolvidas não saberem o que exatamente querem, muitos projetos dão ruim devido a falhas das pessoas envolvidas, trocas de equipes em momentos críticos e em alguns casos corrupção, onde membros da empresa recebem bola das empresas de consultoria para incluírem funcionalidades não previstas, com o objetivo de incluir adendos ao contrato.

Outras vezes por vaidade pessoal, gestores incluem funcionalidades não previstas apenas para garantirem a verba do orçamento ou ganharem visibilidade ao administrarem grandes equipes e projetos.

Espero ter ajudado ate o próximo artigo.

 Mais momento jabá, em 21 de Fevereiro de 1945 os nossos pracinhas da FEB, tomaram o Monte Castello na Italia das tropas nazistas, ajudando os aliados a libertarem o povo italiano dos fascistas, em comemoração a este feito histórico em Campinas foi feita uma exposição com diversos itens e recriação deste combate na Academia dos Cadetes do Exercito, assista e veja que bacana, visite meu vídeo e veja para onde fui desta vez: https://www.youtube.com/watch?v=V7Zs_fk1MKk

Bom curso a todos.

 https://www.linkedin.com/in/vagnerbellacosa/

 https://github.com/VagnerBellacosa/

Pode me dar uma ajudinha no YouTube?

 https://www.youtube.com/user/vagnerbellacosa