A metodologia Waterfall é excelente, em situações que os requisitos são bem definidos e não se precisa ficar revisistando e mudando o que já foi alinhado. Porém, no desenvolvimento de software, tudo é tão dinâmico e constante a mudança que tal metodologia irá mais atrapalahar do que ajudar. Nisso, um dos princípais empecilhos que vejo é o feedback tardio, afinal, o cliente alinhou tudo, mas só ficará sabendo como de fato ficou o projeto, no final, ou seja, pode acontecer uma sensação de frustração por parte do cliente. A partir de outras metodologias mais flexíveis e abertas a mudanças a todo momento, esse problema é solucionado. :D

Boa tarde.

Concordo com ambos. A metodologia Waterfall é uma ótima metodologia mas não pode ser aplicada sempre. Em geral para desenvolvimento de software essa metodologia é muito engessada como mencionou a colega, e o custo de cada alteração do projeto original nessa metodologia é altíssimo. A agilidade e dinamismo são fatores de ordem em desenvolvimento de software, nessa metodologia a implementação e teste são as últimas fases do processo, o que promove um feedback muito tardio, e qualquer alteração necessária acaba tendo um curso muito alto pois muitas horas já foram gastas no projeto, sem contar que a satisfação dos clientes pode ser muito prejudicada nessa metodologia.

Oi Marília, Deivid e Paula.

Tudo bom?

Agradeço pela contribuição de vocês e por enriquecerem o tópico com suas visões, isso é muito legal!

Qualquer coisa, estamos à disposição.

Ótima jornada de estudo.

Abraços.

O método Warefall não é indicado na Engenharia de Software, uma vez que que esse segmento possui alteracões regulamentais, necessidade de validações do cliente final e constantes alterações de acordo com as aualização de processos que o mercado em constante movimento necessita.

Assim como em uma construção, onde o método Warefall é utilizado, fica inviável derrubar paredes depois do prédio construído, porque não era o que o cliente queria. No método ágil as entregas são feitas e validadas por partes, economizando recursos

Por mais ferramentas e processos que se utilize para o levantamento dos requisitos, sempre tem algo que não é identificado, ou que na prática poderia ficar melhor e com isso o modelo tradicional acaba engessando, visto que o foco é a documentação do requisito e não a melhor experiência de uso.

Esse método não se torna eficaz desde o processo da análise, visto que a qualquer mudança é necessário analisar tudo de novo. O método Waterfall funciona apenas para segmentos que não são dinâmicos.

É um método que não possibilita atualizações constantes, como no exemplo dado da nova lei de proteção de dados.

Acredito que ele não proporciona a flexibilidade que os projetos atuais exigem, pois as exigências e os valores dos clientes mudaram.

Por ser baseado num mundo físico, onde ainda assim pessoas querem continuamente alterar o que foi proposto (quem nunca fez ou conhece alguém que ao realizar alguma obra em casa pensada de um jeito e que acabou terminando de outro?), o waterfall serve quando se conhece de forma antecipada e imutável o início, meio e fim de um projeto.

Para um projeto envolvendo software, onde se tem apenas uma idéia do objetivo final, sem pleno conhecimento do que irá aparecer no caminho, uma metodologia ágil, que permita a realização de rollbacks e stepbacks para uma análise situacional se torna mais efetiva e acaba trazendo um nível maior de satisfação em todos os envolvidos.

A grande questão do waterfall é que nem todos os projeto podem congelar os requisitos até que ele esteja pronto. Estruturas dinâmicas dependem de ferramentas dinâmicas.

Sabemos que por mais que um software seja bem planejado e os pré requisitos tentam ser definidos ao máximo, ao começar a desenvolver aparecem várias questões e melhorias. Com o waterfall essas melhorias acabam sendo travadas pois o modelo não se permite retornar a fases já concluídas.

O grande problema seria não poder voltar nas etapas anteriores, o que gera um impasse tendo em vista que a criação de software precisa estar alinhando com o cliente, que pode mudar de opinião facilmente ou pode ter que alterar suas ideias por questões legais, por exemplo.

A grande diferença entre o Waterfall x Agilidade está no grau de "incerteza" e velocidade, conforme foi colocado pelo Mario. Waterfall (Preditivo): Quando tenho requisitos claros e definidos, com processos e técnicas bem dominadas. Ágil: Não tenho clareza dos requisitos detalhados e a tecnologia não é totalmente dominada.

Tipos de Ciclo de Vida - Sequencial - Cascata / Waterfall

Neste ciclo ocorre uma abordagem sequencial ao decorrer do projeto, ou seja, as fases do ciclo de desenvolvimento são executadas em uma sequência ordenada. Desta forma, a passagem para determinada atividade exige como critério a finalização da atividade imediatamente anterior. Um dos pontos fortes do modelo sequencial está na ênfase dada a uma abordagem disciplinada e na recomendação de que todos os produtos de cada fase sejam formalmente revisados.

Cascata / Waterfall - Características:

• Modelo tradicional.
• Tendência na progressão sequencial entre uma fase e a seguinte.
• Assume que é possível declarar detalhadamente todos os requisitos antes do início das demais fases do desenvolvimento.

Cascata / Waterfall - Problemas:

• Mudança de requisitos (retornar a fases anteriores)
• Sistemas grandes (entrega única levaria muito tempo)
• Detecção tardia de erros (maior impacto e custo de correção).
• Propagação de erros pelas as fases do processo.
• Uma versão de produção do sistema não estará pronta até que o ciclo do projeto de desenvolvimento chegue ao final.
• Projetos reais raramente seguem um fluxo sequencial.
• Todo o sistema é entregue de uma só vez.