A metodologia de desenvolvimento de software da Waterfall ainda é viável?

14

Na minha experiência, parece que o modelo Waterfall provou ser muito inflexível e não responde aos requisitos mudanças para ser considerado um método viável no mundo moderno de desenvolvimento de software. O crescimento e o histórico comprovado de métodos iterativos mais ágeis parecem indicar que não há razão para que alguém esteja seguindo um processo de blocos rígidos que assume pouca ou nenhuma alteração desde o início do projeto até a entrega do produto.

É a metodologia de desenvolvimento em cascata ainda viável para entregar sistemas de software, com relação a tempo, custo e qualidade?

    
por CFL_Jeff 09.03.2012 / 21:27
fonte

6 respostas

18

O modelo em cascata ao qual você está se referindo nunca foi destinado a ser um modelo de processo usado em um projeto real. Em vez disso, é um palhaço. Ele identifica as principais fases e atividades que existem em projetos de software e o fluxo mais básico entre elas. Essa simplificação excessiva de como desenvolver software é falho e até mesmo apresentada dessa forma.

Do artigo da Wikipédia:

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, though Royce did not use the term "waterfall" in this article. Royce presented this model as an example of a flawed, non-working model.

O artigo discutido é intitulado Gerenciando o desenvolvimento de grandes sistemas de software . Nele, Royce apresenta esse modelo na segunda página. No entanto, o texto imediatamente abaixo da representação pictórica continua:

I believe in this concept, but the implementation described above is risky and invites failure.

Ele segue isso com uma discussão dos problemas com testes após a "conclusão" da fase de desenvolvimento e como as falhas aqui podem levar a grandes reformulações e alterações de código, e como elas podem levar a grandes excessos de custo e cronograma. Ao longo do artigo, ele refina o modelo original para um que é de fato viável em um projeto. No final, ele acaba com um modelo que introduz protótipos, interação com o cliente e refinamento de artefatos - idéias que acabariam sendo críticas para o movimento ágil que começou no final dos anos 90 e início dos anos 2000.

Para responder à sua pergunta: A Waterfall sobre a qual você está perguntando não é, e nunca foi, um método viável para entregar projetos de software com uma quantidade razoável de qualidade em tempo e orçamento. No entanto, existem outras metodologias orientadas por planos que se opõem à agilidade que podem e funcionam em projetos.

    
por 10.03.2012 / 15:35
fonte
8

O processo mítico em cascata que é mais frequentemente comparado com ágil nunca existiu e, portanto, não pode ser considerado morto. Processos em cascata reais ainda estão vivos e bem, e se destacam em entregar dentro do prazo um software de orçamento que atenda às expectativas do usuário.

    
por 09.03.2012 / 21:37
fonte
7

As pessoas não usam o modelo em cascata do livro de texto e provavelmente nunca o usam.

É um construto teórico idealizado cuja finalidade é levá-lo a pensar sobre os passos no desenvolvimento de sistemas. O ponto principal é que você quer que as mudanças maiores aconteçam o mais cedo possível, porque você nunca terá tempo ou dinheiro para fazer uma grande mudança, já que há muito código construído.

Apesar de ser mais um modo de pensar do que um processo, ainda é assim que muitos - provavelmente a maioria das organizações, constrói software (ou casas, ou submarinos, ou qualquer outra coisa ...) .

No mundo real, você não tem cortes totalmente rígidos entre as fases, e às vezes você retorna às fases anteriores para pequenos subprojetos. O que a metodologia diz não é que "essas coisas não são permitidas". O que ele diz é "essas coisas lhe custam dinheiro e / ou tempo" - então tente evitar isso no futuro.

Está tudo bem para os Agile Snobs (TM) olharem com desprezo para os desenvolvedores "antiquados" e para sua peculiar e instável metodologia em cascata, mas o fato é que o Agile também não é uma panacéia. Alguns projetos não podem ser criados usando o Agile e muitas equipes que acham que o Agile são na verdade desleixadas e desorganizadas.

A metodologia não é o ponto. O ponto é pensar sobre o que você está fazendo e por que você está fazendo dessa maneira - e obter o máximo de valor para o cliente no menor tempo razoável.

    
por 10.03.2012 / 14:54
fonte
4

Talvez a melhor maneira de perguntar em que você está se metendo é "quando é menos interativa e mais formal melhor?"

Existem situações em que este é o caso:

  • Quando os requisitos não mudam.

  • Quando atender novos requisitos é menos importante do que atingir 100% dos originais.

  • Quando todos os componentes de tecnologia estão maduros e são bem compreendidos.

De certa forma, você pode fazer o oposto do que pode levá-lo a ser ágil.

Muito poucas técnicas são aplicáveis em todos os lugares. Muito poucos não têm uso.

    
por 10.03.2012 / 20:32
fonte
2

Sim, está muito vivo, embora hoje seja o mais comum " modelo V " que é usado.

Em ambos os casos, o problema que o Agile tem é que a solução quase nunca termina, o cliente pode continuar a solicitar mudanças e o desenvolvimento continuará a resolvê-las iterativamente. Para um projeto baseado em tempo e custo de materiais, isso funciona muito bem. Para um projeto que tenha um custo fixo, isso não acontece.

Para esses projetos de custo fixo, o cliente quase sempre espera que marcos pré-definidos demonstrem progresso, no entanto, esses são mais da variedade escrita formal do que do código de trabalho. Para clientes como este, as especificações escritas tornam-se o projeto, em que o desenvolvimento de software é uma consideração secundária (como eles supõem, se você tiver um projeto bem definido, o software deve ser fácil de desenvolver). Essas empresas também são as que fazem uso pesado de recursos de desenvolvimento terceirizados baratos.

Portanto, se você tiver um pote fixo de dinheiro ou tempo, não espere que os requisitos mudem ou não tenha permissão para alterar nenhum requisito, e espera-se que eles forneçam um conjunto strong de documentação por escrito, então os modelos em cascata são os apenas aqueles que fazem sentido.

O Agile pode ser introduzido no meio desses projetos para fazer o desenvolvimento, mas você ainda tem uma fase de inicialização onde as especificações são criadas a partir de requisitos e uma fase de desaceleração onde o software é instalado e testado in situ. Ágil não responde bem a esses casos.

    
por 11.03.2012 / 00:25
fonte
1

Para quem? A maioria dos gerentes com quem lidei ainda usa o processo de desenvolvimento de software em cascata para o agendamento, e os níveis mais altos parecem ser de fácil agendamento.

Praticamente, muito poucos desenvolvedores que eu conheço acreditam que funcionam ou são válidos.

    
por 09.03.2012 / 21:30
fonte