{"id":265,"date":"2022-01-25T10:30:49","date_gmt":"2022-01-25T10:30:49","guid":{"rendered":"https:\/\/www.cybermedian.com\/pt\/?p=265"},"modified":"2022-03-24T12:04:59","modified_gmt":"2022-03-24T04:04:59","slug":"what-is-the-problems-of-waterfall-model","status":"publish","type":"post","link":"https:\/\/www.cybermedian.com\/pt\/what-is-the-problems-of-waterfall-model\/","title":{"rendered":"Quais s\u00e3o os problemas do modelo em cascata?"},"content":{"rendered":"

O modelo em cascata \u00e9 uma abordagem de projeto sequencial relativamente linear para certas \u00e1reas do projeto de engenharia.<\/p>\n

No desenvolvimento de software, tende a estar entre as abordagens menos iterativas e flex\u00edveis, pois o progresso flui em grande parte em uma dire\u00e7\u00e3o descendente, como uma cascata, atrav\u00e9s das fases de concep\u00e7\u00e3o, inicia\u00e7\u00e3o, an\u00e1lise, projeto, constru\u00e7\u00e3o, teste, implanta\u00e7\u00e3o e manuten\u00e7\u00e3o.\u00a0Usadas em projetos de desenvolvimento de software, as fases geralmente se parecem com isso:<\/p>\n

Modelo cascata<\/figcaption><\/figure>\n

1. Requisitos<\/strong><\/p>\n

Se voc\u00ea gosta de desenvolvimento de software ou de qualquer tipo de equipe de cria\u00e7\u00e3o de projetos, gostaria de conhecer o contexto de neg\u00f3cios do que est\u00e1 tentando criar – deseja definir que tipo de problemas est\u00e1 tentando resolver e como as pessoas reagiriam ao seu produto final.\u00a0Depois de definir todos esses \u201crequisitos\u201d, voc\u00ea tem a entrada necess\u00e1ria para passar para a pr\u00f3xima etapa.<\/p>\n

2. Projeto<\/strong><\/p>\n

Esta etapa \u00e9 composta de todas as etapas necess\u00e1rias para atender a todos os requisitos determinados anteriormente.\u00a0No desenvolvimento de software, esta \u00e9 a parte onde voc\u00ea define toda a arquitetura de software e hardware, linguagem de programa\u00e7\u00e3o, armazenamento de dados, etc. Esta \u00e9 tamb\u00e9m a parte em que voc\u00ea determina como o projeto seria \u00fatil para seu usu\u00e1rio final.<\/p>\n

3. Implementa\u00e7\u00e3o<\/strong><\/p>\n

Nesta etapa, voc\u00ea come\u00e7a a construir o que projetou em seu plano.\u00a0Esta parte do m\u00e9todo Waterfall \u00e9 dedicada a atender aos padr\u00f5es que voc\u00ea estabeleceu nas etapas anteriores.\u00a0Esta \u00e9 a parte em que as pessoas da equipe de desenvolvimento entram e fazem acontecer todas as coisas discutidas nas etapas anteriores.<\/p>\n

4. Verifica\u00e7\u00e3o<\/strong><\/p>\n

Esta \u00e9 a parte do m\u00e9todo em que as pessoas de garantia de qualidade entram para garantir que a equipe de desenvolvimento n\u00e3o cometeu nenhum erro.\u00a0Essa tamb\u00e9m \u00e9 provavelmente a parte em que as pessoas percebem o que est\u00e1 funcionando ou n\u00e3o em seu plano.<\/p>\n

Observe que<\/strong><\/p>\n

Quando todas as coisas s\u00e3o satisfeitas pelos desenvolvedores do projeto, o cliente ou o usu\u00e1rio final entra e faz a chamada final se o projeto estiver pronto para ser lan\u00e7ado.<\/p>\n

O m\u00e9todo Waterfall faz quest\u00e3o de que, quando algo d\u00e1 errado em um est\u00e1gio espec\u00edfico, as pessoas podem voltar ao anterior para ver o que deu errado.\u00a0Por exemplo, se houver um problema na Implementa\u00e7\u00e3o do Plano e as pessoas souberem que simplesmente seguiram o projeto que lhes foi entregue, os gerentes analisam seu plano e fazem suas revis\u00f5es a partir da\u00ed.<\/p>\n

Qual \u00e9 o problema da cachoeira?<\/span><\/h3>\n
Problema de Requisitos Antecipados – Plano x Realidade<\/figcaption><\/figure>\n

Os clientes podem n\u00e3o saber exatamente quais s\u00e3o seus requisitos antes de verem o software funcionando e, assim, alterar seus requisitos, levando ao redesenho, redesenvolvimento e reteste, al\u00e9m de aumentar os custos.<\/p>\n

Os desenvolvedores podem n\u00e3o estar cientes de dificuldades futuras ao projetar um novo produto ou recurso de software; nesse caso, \u00e9 melhor revisar o projeto do que persistir em um projeto que n\u00e3o leve em conta quaisquer restri\u00e7\u00f5es, requisitos ou problemas rec\u00e9m-descobertos.<\/p>\n

Assim, n\u00e3o h\u00e1 garantia de que os requisitos que a organiza\u00e7\u00e3o pensou realmente funcionariam.\u00a0A partir daqui, voc\u00ea perceberia que o modelo Waterfall tem os seguintes problemas:<\/p>\n

1.\u00a0\u00a0As pessoas seguem cegamente os planos.<\/strong><\/p>\n

No m\u00e9todo tradicional, as pessoas prestam mais aten\u00e7\u00e3o em como as coisas v\u00e3o acontecer no momento certo, sem estar atentas se as coisas est\u00e3o realmente se encaixando.\u00a0Embora o planejamento seja importante, tamb\u00e9m \u00e9 importante que os desenvolvedores e verificadores de qualidade entendam como as coisas devem acontecer, especialmente com o cliente ou o usu\u00e1rio final.\u00a0Tamb\u00e9m \u00e9 importante que todas as pessoas envolvidas no projeto possam dizer imediatamente como uma etapa espec\u00edfica no cumprimento do projeto pode desmoronar sem ter que esperar pelo est\u00e1gio de teste.<\/p>\n

2.\u00a0\u00a0Processo sequencial e mudan\u00e7as tornam-se dispendiosas<\/strong><\/p>\n

Essa abordagem n\u00e3o permite a mudan\u00e7a de requisitos definidos \u00e0 medida que o projeto avan\u00e7a.\u00a0Assim, h\u00e1 um grande potencial de que o software n\u00e3o atenda totalmente o requisito do usu\u00e1rio, seja ineficiente e tenha pouca funcionalidade.<\/p>\n

\u00c9 inadequado, pois os desenvolvedores n\u00e3o podem simplesmente voltar e mudar algo em uma fase anterior \u00e0 medida que o requisito do consumidor muda, mas o desenvolvedor precisa voltar para onde o requisito precisa mudar e iniciar essa fase toda.\u00a0N\u00e3o at\u00e9 que essa fase esteja completa ele pode passar para a pr\u00f3xima fase.<\/p>\n

3.\u00a0\u00a0Os usu\u00e1rios finais n\u00e3o sabem o que querem.<\/strong><\/p>\n

Na maioria das vezes, a mente de um usu\u00e1rio final est\u00e1 em constante mudan\u00e7a e a maioria das pessoas tem uma vaga ideia de seus requisitos de software e \u00e9 \u00e0 medida que o software se desenvolve que eles especificam seus requisitos.<\/p>\n

Quando chega a hora de entregar o produto acabado a um cliente, \u00e9 prov\u00e1vel que ele n\u00e3o goste de como ficou, apesar de dizer deliberadamente o contr\u00e1rio durante os est\u00e1gios iniciais.\u00a0\u00c9 f\u00e1cil para clientes e usu\u00e1rios finais alterarem o que desejam ao longo do tempo.\u00a0O sistema Waterfall ainda n\u00e3o tem como resolver isso, sem ter que revisar os planos e refazer todo o projeto por completo.<\/p>\n

4.\u00a0\u00a0Os testes de qualidade podem sofrer.<\/strong><\/p>\n

\u00c9 imposs\u00edvel prever com precis\u00e3o os resultados de um projeto e, quando toda a equipe est\u00e1 pressionada pelo tempo, \u00e9 poss\u00edvel encurtar o est\u00e1gio de teste para cumprir o prazo.<\/p>\n

5.\u00a0\u00a0Voc\u00ea nunca saber\u00e1 em que palco voc\u00ea realmente est\u00e1.<\/strong><\/p>\n

Como o produto que voc\u00ea est\u00e1 tentando criar n\u00e3o ser\u00e1 produzido at\u00e9 o final, voc\u00ea n\u00e3o tem certeza se ainda est\u00e1 planejando ou se j\u00e1 est\u00e1 no est\u00e1gio de desenvolvimento.\u00a0Isso significa que tamb\u00e9m \u00e9 prov\u00e1vel que voc\u00ea passe mais tempo em um palco do que o esperado devido a essa baixa visibilidade.<\/p>\n

No final, o m\u00e9todo Waterfall pode ser muito arriscado, pois \u00e9 muito r\u00edgido.\u00a0Para que voc\u00ea produza um produto que funcione e seja flex\u00edvel o suficiente para ajud\u00e1-lo a descobrir o que est\u00e1 funcionando ou n\u00e3o.<\/p>\n

Recursos Relacionados<\/span><\/h3>\n