Modelo em cascata - Waterfall model

Desenvolvimento de software
Principais atividades
Paradigmas e modelos
Metodologias e frameworks
Disciplinas de apoio
Práticas
Ferramentas
Padrões e Corpos de Conhecimento
Glossários
Contornos
O "modelo em cascata" não modificado. O progresso flui de cima para baixo, como uma cachoeira em cascata.

O modelo em cascata é uma divisão das atividades do projeto em fases sequenciais lineares , onde cada fase depende das entregas da anterior e corresponde a uma especialização de tarefas. A abordagem é típica para certas áreas do projeto de engenharia . No desenvolvimento de software , tende a estar entre as abordagens menos iterativas e flexíveis, já que 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 , design , construção , teste , implantação e manutenção .

O modelo de desenvolvimento em cascata originou-se nas indústrias de manufatura e construção ; onde os ambientes físicos altamente estruturados significavam que as alterações de design se tornavam proibitivamente caras muito mais cedo no processo de desenvolvimento. Quando adotado pela primeira vez para o desenvolvimento de software, não havia alternativas reconhecidas para o trabalho criativo baseado no conhecimento.

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 Avançados de Programação para Computadores Digitais em 29 de junho de 1956. 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 foram organizadas propositalmente de acordo com a especialização das tarefas e apontando que o processo não era de fato executado de forma estritamente top-down, mas dependia de um protótipo .

Embora o termo "cachoeira" não seja usado no artigo, o primeiro diagrama formal detalhado do processo, mais tarde conhecido como "modelo em cascata", é freqüentemente citado como um artigo de 1970 de Winston W. Royce . No entanto, ele também sentiu que tinha grandes falhas decorrentes do fato de que os testes só aconteceram no final do processo, que ele descreveu como "arriscado e convida ao fracasso". O restante de seu artigo introduziu cinco etapas que ele considerou necessárias para "eliminar a maioria dos riscos de desenvolvimento" associados à abordagem em cascata inalterada.

As cinco etapas adicionais de Royce (que incluíam escrever a documentação completa em vários estágios de desenvolvimento) nunca foram dominadas, mas seu diagrama do que ele considerava um processo falho se tornou o ponto de partida ao descrever uma abordagem em "cascata".

O uso mais antigo do termo "cachoeira" pode ter sido em um artigo de 1976 de Bell e Thayer.

Em 1985, o Departamento de Defesa dos Estados Unidos capturou essa abordagem no DOD-STD-2167A , seus padrões para trabalhar com empreiteiros de desenvolvimento de software, que afirmavam que "o empreiteiro deve implementar um ciclo de desenvolvimento de software que inclui as seguintes seis fases: Análise de Requisitos de Software , Projeto Preliminar, Projeto Detalhado, Codificação e Teste de Unidade, Integração e Teste ".

Modelo

No modelo em cascata original de Royce, 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 , provando , 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 afirma que só se deve passar para uma fase quando sua fase anterior for revisada e verificada.

Vários modelos em cascata modificados (incluindo o modelo final de Royce), no entanto, podem incluir variações ligeiras ou importantes neste processo. Essas variações incluíam retornar ao ciclo anterior após as falhas serem encontradas a jusante, ou retornar totalmente à 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 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).

Na prática comum, as metodologias em cascata resultam em um cronograma de projeto com 20–40% do tempo investido nas duas primeiras fases, 30–40% do tempo para codificação e o restante dedicado ao teste e implementação. A organização do projeto real 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.

Um outro argumento 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 . Em metodologias menos elaboradas e documentadas, o conhecimento é perdido se os membros da equipe saem antes da conclusão do projeto, 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 até mesmo equipes totalmente novas devem ser capazes de se familiarizar lendo os documentos.

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 é usado como um exemplo inicial de um modelo de desenvolvimento em muitos textos e cursos de engenharia de software.

Crítica

Os clientes podem não saber exatamente quais são seus requisitos antes de ver o software em funcionamento e, portanto, alterá-los, levando a um redesenho, redesenvolvimento e reteste, além de aumento de custos.

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

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 manter uma separação estrita entre análise de sistemas e programação. 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), Cachoeira com subprojetos e Cachoeira com redução de risco".

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 .

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

As fases do Rational Unified Process (RUP) reconhecem a necessidade programática de marcos, para manter um projeto sob controle, mas encorajam iterações (especialmente dentro das Disciplinas) dentro das Fases. As fases do RUP são freqüentemente chamadas de "tipo cachoeira".

Modelos de 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 em cascata "puro".

Isso inclui os modelos de desenvolvimento rápido que Steve McConnell chama de "cachoeiras modificadas": o "modelo sashimi" de Peter DeGrace (cachoeira com fases sobrepostas), cachoeira com subprojetos e cachoeira com redução de risco. Outras combinações de modelos de desenvolvimento de software , como "modelo em cascata incremental", também existem.

Modelo final de Royce

Modelo final de Royce

O modelo final de Winston W. Royce , sua pretendida melhoria em seu "modelo em cascata" inicial, ilustrou que o feedback poderia (deveria, e muitas vezes levaria) do teste de código ao design (como teste de código descoberto falhas no design) e de design de volta à especificação de requisitos (já que os problemas de design podem exigir a remoção de requisitos conflitantes ou de outra forma insatisfatórios / indesejáveis). No mesmo jornal, Royce também defendeu grandes quantidades de documentação, fazendo o trabalho "duas vezes se possível" (um sentimento semelhante ao de Fred Brooks , famoso por escrever o Mythical Man Month, um livro influente em gerenciamento de projetos de software , que defendia o planejamento para "jogue fora") e envolva o cliente o máximo possível (um sentimento semelhante ao da Extreme Programming ).

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

  1. Projeto completo do programa antes da análise e codificação começar
  2. A documentação deve estar atualizada e completa
  3. Faça o trabalho duas vezes, se possível
  4. O teste deve ser planejado, controlado e monitorado
  5. Envolva o cliente

Veja também

Referências

links externos