Modelo cascata

Da Wikipédia, a enciclopédia livre
Ir para a navegação Saltar para pesquisar

O modelo em cascata é um desdobramento das atividades do projeto em fases sequenciais lineares , onde cada fase depende das entregas da anterior e corresponde a uma especialização de tarefas. [1] A abordagem é típica para certas áreas do projeto de engenharia . No desenvolvimento de software , [1] tende a estar entre as abordagens menos iterativas e flexíveis, pois o progresso flui em grande parte em uma direção ("para baixo" como uma cachoeira ) através das fases de concepção, iniciação, análise , projeto , construção , teste , desdobramento, desenvolvimentoe manutenção . [2]

O modelo de desenvolvimento em cascata originou-se nas indústrias de manufatura e construção [ carece de fontes ] ; onde os ambientes físicos altamente estruturados significavam que as mudanças de projeto se tornavam proibitivamente caras muito mais cedo no processo de desenvolvimento. [ citação necessária ] Quando adotado pela primeira vez para o desenvolvimento de software, não havia alternativas reconhecidas para o trabalho criativo baseado em conhecimento. [3] [ melhor fonte necessária ]

História

A primeira apresentação conhecida descrevendo o uso de tais fases na engenharia de software foi realizada por Herbert D. Benington no Simpósio sobre Métodos de Programação Avançados para Computadores Digitais em 29 de junho de 1956 [ carece de fontes ] . [4] Esta apresentação foi sobre o desenvolvimento de software para SAGE . Em 1983 o artigo foi republicado com um prefácio de Benington explicando que as fases eram propositadamente organizadas de acordo com a especialização das tarefas, e apontando que o processo não era de fato realizado de forma estritamente top-down, mas dependia de um protótipo . [3]

Embora o termo "cascata" não seja usado no artigo, o primeiro diagrama formal detalhado do processo mais tarde conhecido como "modelo em cascata" é frequentemente citado como um artigo de 1970 de Winston W. Royce . [5] [6] [7] No entanto, ele também sentiu que tinha grandes falhas decorrentes do fato de que os testes só aconteciam no final do processo, que ele descreveu como "arriscado e convida a falhas". [5] O resto de seu artigo apresentou cinco etapas que ele sentiu serem necessárias para "eliminar a maioria dos riscos de desenvolvimento" associados à abordagem em cascata inalterada. [5]

As cinco etapas adicionais de Royce (que incluíam escrever documentação completa em vários estágios de desenvolvimento) nunca se tornaram populares, mas seu diagrama do que ele considerava um processo falho tornou-se o ponto de partida ao descrever uma abordagem "cascata". [8] [ melhor fonte necessária ]

O primeiro uso do termo "cachoeira" pode ter sido em um artigo de 1976 de Bell e Thayer. [9] [ melhor fonte necessária ]

Em 1985, o Departamento de Defesa dos Estados Unidos capturou essa abordagem em DOD-STD-2167A [ carece de fontes ] , seus padrões para trabalhar com empreiteiros de desenvolvimento de software, que afirmou que "o empreiteiro deve implementar um ciclo de desenvolvimento de software que inclui as seis fases seguintes : Análise de Requisitos de Software, Projeto Preliminar, Projeto Detalhado, Codificação e Testes Unitários, Integração e Testes". [10]

Modelo

No modelo cascata original de Royce [ carece de fontes ] , as seguintes fases são seguidas em ordem:

  1. Requisitos de sistema e software : capturados em um documento de requisitos de produto
  2. Análise : resultando em modelos , esquema e regras de negócios
  3. Design : resultando na arquitetura de software
  4. Codificação : o desenvolvimento , comprovação e integração de software
  5. Teste : a descoberta sistemática e depuração de defeitos
  6. Operações : instalação , migração , suporte e manutenção de sistemas completos

Assim, o modelo em cascata sustenta que se deve passar para uma fase somente quando sua fase anterior for revisada e verificada.

Vários modelos de cascata modificados (incluindo o modelo final de Royce), no entanto, podem incluir pequenas ou grandes variações nesse processo. [5] Essas variações incluíam o retorno ao ciclo anterior após a descoberta de falhas a jusante, ou o retorno à fase de projeto se as fases a jusante fossem consideradas insuficientes.

Argumentos de apoio

O tempo gasto no início do ciclo de produção de software pode reduzir os custos em estágios posteriores. Por exemplo, um problema encontrado nos estágios iniciais (como especificação de requisitos) é mais barato de corrigir do que o mesmo bug encontrado posteriormente no processo (por um fator de 50 a 200). [11]

Na prática comum, as metodologias em cascata resultam em um cronograma de projeto com 20 a 40% do tempo investido nas duas primeiras fases, 30 a 40% do tempo na codificação e o restante dedicado a testes e implementação. A organização real do projeto precisa ser altamente estruturada. A maioria dos projetos de médio e grande porte incluirá um conjunto detalhado de procedimentos e controles, que regulam todos os processos do projeto. [12] [ falha na verificação ]

Um argumento adicional para o modelo em cascata é que ele enfatiza a documentação (como documentos de requisitos e documentos de design), bem como o código-fonte . [ citação necessária ] Em metodologias menos elaboradas e documentadas, o conhecimento é perdido se os membros da equipe saem antes que o projeto seja concluído, e pode ser difícil para um projeto se recuperar da perda. Se um documento de design totalmente funcional estiver presente (como é a intenção do Big Design Up Front e do modelo em cascata), novos membros da equipe ou mesmo equipes totalmente novas devem ser capazes de se familiarizar lendo os documentos. [13]

O modelo em cascata fornece uma abordagem estruturada; o próprio modelo progride linearmente por fases discretas, facilmente compreensíveis e explicáveis ​​e, portanto, é fácil de entender; ele também fornece marcos facilmente identificáveis ​​no processo de desenvolvimento. Talvez seja por essa razão que o modelo em cascata seja usado como exemplo inicial de um modelo de desenvolvimento em muitos textos e cursos de engenharia de software. [14]

Críticas

Os clientes podem não saber exatamente quais são seus requisitos antes de verem o software funcionando e, assim, alterar seus requisitos, levando ao redesenho, redesenvolvimento e reteste, além de aumentar os custos. [15]

Os designers podem não estar cientes das dificuldades futuras ao projetar um novo produto ou recurso de software; nesse caso, é melhor revisar o design do que persistir em um design que não leva em conta quaisquer restrições, requisitos ou problemas recém-descobertos. [16]

As organizações podem tentar lidar com a falta de requisitos concretos dos clientes empregando analistas de sistemas para examinar os sistemas manuais existentes e analisar o que eles fazem e como podem ser substituídos. No entanto, na prática, é difícil sustentar uma separação estrita entre análise de sistemas e programação. [17] Isso ocorre porque a implementação de qualquer sistema não trivial quase inevitavelmente exporá problemas e casos extremos que o analista de sistemas não considerou.

Em resposta aos problemas percebidos com o modelo em cascata puro , foram introduzidos modelos em cascata modificados, como "Sashimi (Cachoeira com Fases Sobrepostas), Cascata com Subprojetos e Cascata com Redução de Riscos". [11]

Algumas organizações, como o Departamento de Defesa dos Estados Unidos, agora têm uma preferência declarada contra metodologias do tipo cascata, começando com MIL-STD-498 , que incentiva a aquisição evolutiva e o Desenvolvimento Iterativo e Incremental . [18]

Enquanto os defensores do desenvolvimento ágil de software argumentam que o modelo cascata é um processo ineficaz para o desenvolvimento de software, alguns céticos sugerem que o modelo cascata é um argumento falso usado apenas para comercializar metodologias alternativas de desenvolvimento. [19]

As fases do Rational Unified Process (RUP) reconhecem a necessidade programática de marcos, para manter um projeto no caminho certo, mas incentivam as iterações (especialmente dentro das Disciplinas) dentro das Fases. As fases do RUP são frequentemente chamadas de "tipo cascata". [ citação necessária ]

Modelos em cascata modificados

Em resposta aos problemas percebidos com o modelo em cascata "puro", muitos modelos em cascata modificados foram introduzidos. Esses modelos podem abordar algumas ou todas as críticas ao modelo "puro" em cascata.

Estes incluem os modelos de Desenvolvimento Rápido que Steve McConnell chama de "cascatas modificadas": [11] o "modelo sashimi" de Peter DeGrace (cascata com fases sobrepostas), cascata com subprojetos e cascata com redução de risco. Outras combinações de modelos de desenvolvimento de software , como "modelo cascata incremental", também existem. [20]

Modelo final de Royce

Royce modelo final

O modelo final de Winston W. Royce , sua intenção de melhorar seu "modelo em cascata" inicial, ilustrou que o feedback poderia (deveria, e muitas vezes levaria) do teste de código ao design (como o teste de código descobriu falhas no design) e de projeto de volta à especificação de requisitos (uma vez que problemas de projeto podem exigir a remoção de requisitos conflitantes ou de outra forma insatisfeitos/não projetáveis). No mesmo artigo, Royce também defendia grandes quantidades de documentação, fazendo o trabalho "duas vezes se possível" (sentimento semelhante ao de Fred Brooks , famoso por escrever o Mês do Homem Mítico, livro influente em gerenciamento de projetos de software , que defendia o planejamento para "jogar fora"),programação extrema ).

As notas de Royce para o modelo final são:

  1. Projeto completo do programa antes do início da análise e codificação
  2. A documentação deve ser atual e completa
  3. Faça o trabalho duas vezes, se possível
  4. Os testes devem ser planejados, controlados e monitorados
  5. Envolva o cliente

Veja também

Referências

  1. ^ a b Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). Bomário, Frank; Oivo, Markku; Jaring, Päivi; Abrahamsson, Pekka (eds.). "O Modelo Cachoeira no Desenvolvimento em Grande Escala" . Melhoria de Processo de Software Focada no Produto . Notas de Aula em Processamento de Informações Empresariais. Berlim, Heidelberg: Springer: 386-400. doi : 10.1007/978-3-642-02152-7_29 . ISBN 978-3-642-02152-7.
  2. ^ "A Abordagem Cachoeira Tradicional" . www.umsl.edu . Recuperado 2022-02-23 .
  3. ^ a b Benington, Herbert D. (1 de outubro de 1983). "Produção de grandes programas de computador" (PDF) . IEEE Annals of the History of Computing . Departamento de Atividades Educacionais do IEEE. 5 (4): 350–361. doi : 10.1109/MAHC.1983.10102 . S2CID 8632276 . Recuperado em 21-03-2011 .   Arquivado em 18 de julho de 2011, no Wayback Machine
  4. Estados Unidos, Navy Mathematical Computing Advisory Panel (29 de junho de 1956), Simpósio sobre métodos avançados de programação para computadores digitais , [Washington, DC]: Office of Naval Research, Dept. of the Navy, OCLC 10794738 
  5. ^ a b c d Royce, Winston (1970), "Gerenciando o desenvolvimento de grandes sistemas de software" (PDF) , Proceedings of IEEE WESCON , 26 (agosto): 1–9
  6. ^ "Cachoeira" . Universidade de Bremen - Matemática e Ciência da Computação .
  7. ^ Abbas, Noura; Gravell, Andrew M.; Wills, Gary B. (2008). Abrahamsson, Pekka; Baskerville, Richard; Conboy, Kieran; Fitzgerald, Brian; Morgan, Lorena; Wang, Xiaofeng (eds.). "Raízes históricas dos métodos ágeis: de onde veio o "pensamento ágil"?" . Processos Ágeis em Engenharia de Software e Extreme Programming . Notas de Aula em Processamento de Informações Empresariais. Berlim, Heidelberg: Springer: 94-103. doi : 10.1007/978-3-540-68255-4_10 . ISBN 978-3-540-68255-4.
  8. ^ Conrad Weisert, Metodologia Waterfall: isso não existe!
  9. Bell, Thomas E. e TA Thayer. Requisitos de software: eles são realmente um problema? Anais do 2º Congresso Internacional de Engenharia de Software. IEEE Computer Society Press, 1976.
  10. ^ "Desenvolvimento de software do sistema de defesa padrão militar" (PDF) .
  11. ^ a b c McConnell, Steve (1996). Desenvolvimento Rápido: Domendo Programações de Software Selvagens . Imprensa da Microsoft. ISBN 1-55615-900-5.
  12. ^ "Modelo de desenvolvimento de software em cascata" . 5 de fevereiro de 2014 . Recuperado em 11 de agosto de 2014 .
  13. ^ Tecnologias do Arcisfério (2012). "Tutorial: O Ciclo de Vida de Desenvolvimento de Software (SDLC)" (PDF) . Recuperado 2012-11-13 .
  14. ^ Hughey, Douglas (2009). "Comparando Análise e Projeto de Sistemas Tradicionais com Metodologias Ágeis" . Universidade do Missouri – St. Louis . Recuperado em 11 de agosto de 2014 .
  15. ^ Parnas, David L.; Clements, Paul C. (1986). "Um processo de design racional: como e por que fingir" (PDF) . Transações IEEE em Engenharia de Software (2): 251–257. doi : 10.1109/TSE.1986.6312940 . S2CID 5838439 . Recuperado em 21-03-2011 .  
  16. ^ McConnell, Steve (2004). Código Completo, 2ª edição . Imprensa da Microsoft. ISBN 1-55615-484-4.
  17. ^ Ensmenger, Nathan (2010). Os meninos do computador assumem o controle . pág. 42 . ISBN 978-0-262-05093-7.
  18. ^ Larman, Craig; Basili, Victir (2003). "Desenvolvimento Iterativo e Incremental: Uma Breve História" . Computador IEEE (ed. de junho). 36 (6): 47–56. doi : 10.1109/MC.2003.1204375 . S2CID 9240477 . 
  19. ^ Uma metodologia do desenvolvimento de sistemas da cachoeira… Seriamente? por David Dischave. 2012. Arquivado em 2 de julho de 2014, no Wayback Machine
  20. ^ "Metodologia: métodos de design" .

Links externos