Introdução ao modelo em cascata
Originado das indústrias de construção e manufatura, é um ambiente físico altamente estruturado destinado a processos de design e desenvolvimento. O modelo em cascata também é conhecido como modelo de ciclo de vida de desenvolvimento de software. Foi o primeiro modelo de processo introduzido como o modelo de ciclo de vida linear-seqüencial. O modelo em cascata simplesmente diz ao fenômeno como concluir completamente uma fase antes de iniciar a nova fase de desenvolvimento, para que não haja sobreposição de fases. No campo de desenvolvimento de software, o modelo em cascata foi usado pela primeira vez como a abordagem SDLC. Para trabalhar no modelo em cascata, precisamos entender sua abordagem de aplicação com base em fatores internos e externos, que podem ser os seguintes:
- Não há requisitos ambíguos no aplicativo.
- Estabilidade da definição do produto
- É tecnologia entendida
- Não é dinâmico
- Grandes recursos com conhecimento adequado estão disponíveis para dar suporte ao produto
- Projeto Vey de curta duração
- O bom documento, requisitos claros e fixos.
Para começar com a história do modelo em cascata, gostaria de dizer que a primeira amostra do modelo em cascata foi introduzida no ano de 1970 por Winston w Royce em um artigo. Desde então, o modelo em cascata afirma que só se deve mudar para outra fase quando as fases anteriores forem completamente testadas, revisadas e verificadas. Ele enfatiza a progressão lógica das etapas da fase. Sua funcionalidade é semelhante à água que flui sobre a beira do penhasco. Essa abordagem de desenvolvimento de software recebeu o nome de cascata, porque se desenvolve sistematicamente de uma fase para outra de maneira descendente. Desde que foi publicado pela primeira vez por Winston W. Royce, em 1970, o modelo em cascata tem sido amplamente utilizado no campo do desenvolvimento de software. No ciclo do processo de desenvolvimento de software, modelos de programação são usados para planejar os vários estágios do desenvolvimento de um aplicativo. Um desses modelos é o modelo em cascata.
Modelo de fases da cachoeira
Agora vamos falar sobre as fases do modelo em cascata, que podem ser explicadas claramente através deste infográfico de demonstração.
Com os infográficos acima, podemos entender que o modelo em cascata possui um total de 7 fases do ciclo de software de design e desenvolvimento, que são as seguintes:
- Exigências
- Análise
- Projeto
- Codificação / implementação
- Teste
- Operação / implantação
- Manutenção
Assim, podemos ver que o modelo em cascata trabalha a hierarquia de cima para baixo, com uma fase concluída com verificações completas, passando para outra fase, incluindo processos de fase como concepção, iniciação, análise, projeto, construção, teste, produção / implementação e manutenção. Para obter um conhecimento mais breve sobre o modelo em cascata, precisamos entender profundamente todos os seus processos com seu modelo de trabalho. Há uma fase básica de pré-requisito que precisa ser entendida antes de iniciar as fases profundas do conhecimento. Trata-se do estudo de viabilidade para o produto de software. Ele lida com os aspectos financeiros e técnicos dos requisitos do projeto. Esta fase trata da correção das medidas com base nos benefícios e desvantagens analisados. Assim, a melhor solução é escolhida.
- Requisitos: Como específico por palavras, precisamos saber e entender o que temos que projetar, o que temos que desenvolver, seus processos, qual será sua funcionalidade etc. Ele fornece material de entrada para o produto que está sendo produzido e, portanto, o produto que está por vir. é estudado, finalizado e marcado. Também nos fornece a extensão para decidir os requisitos de hardware ou software do produto que serão projetados, desenvolvidos e capturados em todas as fases.
- Análise: resulta na criação de modelos, esquemas e regras de negócios. Não apenas esse requisito é dividido em duas partes:
- Coleta e análise de requisitos: Primeiro, todas as informações e requisitos para o desenvolvimento do produto são coletadas do cliente e depois processadas para análise. O principal papel desta parte é erradicar a incompletude e as inconsistências relacionadas ao desenvolvimento de produtos de software.
- Especificação de requisitos: Em seguida, os requisitos acima analisados são documentados em um documento SRS (especificação de requisitos de software). Ele serve como um caminho entre o cliente e a equipe de desenvolvimento do SRS. Quaisquer disputas no futuro são gerenciadas e resolvidas somente através desta documentação do SRS.
- Projeto: Depois que a primeira fase é concluída e verificada, é a próxima fase mais importante a ser estudada, pois é usada no projeto do sistema. Ajuda na especificação de requisitos de software e hardware para o design do produto. Também ajuda na arquitetura geral do design do sistema. Portanto, a especificação de requisitos é principalmente estudada e verificada nesta fase. Também é útil na transformação do documento SRS em design funcional e desenvolvimento do produto de software. Então, podemos dizer que, na fase de design, está sendo feita a arquitetura geral do projeto de desenvolvimento de software.
- Implementação: com o design do sistema totalmente verificado, a fase de implementação ocorre na linha. Nesta fase, as entradas do design do sistema são obtidas e são desenvolvidas primeiro em pequenos programas conhecidos como unidades, que são testados e implementados na próxima fase. Cada unidade na fase de implementação passa por desenvolvimento e sua funcionalidade completa é testada, também conhecida como teste de unidade. Portanto, nesta fase, o design do sistema é convertido em código-fonte com módulos de programas totalmente funcionais. Inclui desenvolvimento, comprovação e integração do software.
- Integração e testes: Cada projeto de unidade e desenvolvido nas fases anteriores é incorporado a partir da fase de implementação, que é integrada a um módulo ou sistema para vários testes, como teste de carga, teste de chumbo, etc., após o teste de cada unidade. O ambiente de teste passa por uma constante verificação de software para descobrir se há algum fluxo ou erro no design ou no código. Os testes são feitos para manter a estabilidade e a viabilidade do software, para que o cliente não enfrente nenhum distúrbio ou bugs durante sua produção. Portanto, nesta fase após a implementação, todo o sistema é testado minuciosamente quanto a falhas e falhas. Os testes do sistema consistem em três tipos diferentes de atividades que podem ser explicadas como abaixo:
- Teste Alfa (α): É o teste realizado pela equipe de desenvolvimento.
- Teste beta (β): é o teste realizado pela equipe amigável de clientes e usuários.
- Teste de aceitação: é realizado após os testes alfa e beta. Basicamente, esse teste é feito após a entrega pelos clientes. Após o teste realizado pelo cliente, é tomada a decisão de aceitá-lo ou rejeitá-lo. Então, nesta fase, basicamente a depuração de bugs é feita.
- Implantação do sistema / Operações: uma vez concluídos os testes não funcionais, funcionais, alfa e beta, o produto do software é implantado no sistema do usuário ou cliente ou lançado no mercado. A fase de implantação inclui instalação, migração e suporte do sistema completo para o ambiente do usuário ou cliente.
- Manutenção: É a última, mas a fase mais importante no modelo de fluxo de trabalho em cascata. Esta etapa ocorre logo após a instalação e inclui a modificação apropriada no produto ou sistema, ou para aprimorar, alterar ou modificar atributos relacionados ao problema de desempenho relacionado ao sistema. seu principal papel é melhorar o desempenho do sistema com o resultado máximo de precisão da saída do software. Essas alterações levantadas durante a fase de manutenção estão relacionadas principalmente às alterações iniciadas pelo cliente ou pelos usuários após a fase de instalação e teste, que inclui bugs, como defeitos descobertos durante os usos ao vivo do sistema ou solicitações levantadas pelos clientes. Portanto, o cliente recebe manutenção e suporte pontuais e programados para o produto desenvolvido. Você ficará realmente surpreso ao saber que o esforço realizado na fase de design e desenvolvimento do produto de software é apenas o esforço de 60% em comparação aos esforços realizados na fase de manutenção. Existem basicamente três tipos de manutenção, explicados abaixo:
- Manutenção corretiva: Durante a fase de design e desenvolvimento, alguns erros não são descobertos, eles só levam em consideração quando o cliente usa. Isso é apenas manutenção corretiva, o que significa correção de problemas ou erros que não foram descobertos na fase de desenvolvimento.
- Manutenção perfeita: esse tipo de manutenção é realizada mediante solicitação do cliente para aumentar e aprimorar as funcionalidades do sistema ou software.
- Manutenção adaptativa: é a manutenção necessária para alternar o ambiente do sistema. Geralmente necessário para transportar o sistema existente para um novo ambiente ou novo computador ou sistema ou talvez com um novo sistema operacional. Essa fase é muito importante, pois leva a um melhor desempenho do sistema.
Portanto, na discussão acima, conhecemos profundamente cada fase do modelo em cascata com especificações completas. Assim, podemos dizer que o modelo em cascata é muito importante no campo do software, também em comparação com as indústrias mecânicas, pois cada fase tem sua própria importância, pois gera um software mais produtivo e estável.
Vantagens
Não apenas esse modelo em cascata também possui muitas outras vantagens no ciclo de vida de desenvolvimento de software, que podem ser discutidas abaixo:
- Permite departamentalização e controle.
- É possível definir um cronograma com prazos para cada estágio de desenvolvimento e um produto pode prosseguir pelas fases do modelo de processo de desenvolvimento, uma por uma.
- Como passa por fases facilmente compreensíveis e explicáveis, supera muitos problemas e, portanto, é muito fácil de usar.
- Devido à rigidez do modelo de fluxo de trabalho, é muito fácil gerenciar, pois cada fase do modelo em cascata possui processos específicos de revisão e entregas.
- O modelo em cascata funciona bem para projetos menores, onde os requisitos são muito bem compreendidos.
- O cronograma pode ser definido com prazos para cada estágio de desenvolvimento e um produto pode prosseguir pelas fases do modelo de processo de desenvolvimento, uma por uma.
- Estágios claramente definidos.
- Marcos bem compreendidos.
- Fácil de organizar tarefas.
- Processo e resultados estão bem documentados.
- Reforça os bons hábitos: definir antes do design,
- Design antes do código.
- O modelo funciona bem para projetos menores e onde os requisitos são bem compreendidos.
Desvantagem
Como sabemos que cada moeda tem duas faces, portanto, com o amplo acesso às vantagens do modelo em cascata, o modelo em cascata também apresenta algumas desvantagens ou pode-se dizer as desvantagens discutidas abaixo:
- Não é um bom modelo para projetos complexos e orientados a objetos.
- Não é adequado para projetos em que os requisitos correm um risco moderado a alto de alteração.
- É difícil estimar tempo e custo para cada fase do processo de desenvolvimento.
- Não é um bom modelo para projetos complexos e orientados a objetos.
- Nenhum software de trabalho é produzido até tarde durante o ciclo de vida.
- Não pode acomodar requisitos variáveis.
- É difícil medir o progresso em etapas.
- Altas quantidades de risco e incerteza.
- Mau modelo para projetos longos e em andamento.
- O ajuste do escopo durante o ciclo de vida pode encerrar um projeto.
- Nenhum caminho de feedback
- Sem sobreposição de fases
- Difícil de acomodar solicitações de mudança.
- risco e incerteza são altos com este modelo de processo.
Onde usar o modelo em cascata
Agora, depois de envolver todos os cenários, chegamos a um ponto em que queremos saber onde usar o modelo em cascata.
- Principalmente o modelo em cascata é usado em um projeto de defesa, pois o requisito é claro, porque antes de passar para a fase de desenvolvimento eles o analisam bem.
- Isso também pode ser usado em projetos de migração em que os requisitos serão os mesmos, apenas a plataforma ou os idiomas poderão variar / mudar.
Conclusão
Portanto, como um todo, posso dizer que o modelo em cascata é mais adequado para pequenos projetos de desenvolvimento de software, em comparação com grandes projetos, porque o design, o desenvolvimento e a implementação são mais fáceis no pequeno projeto quando se trabalha no modelo em cascata, porque nesse modelo todas as fases anteriores precisam a ser concluído ao passar para as próximas fases. Portanto, no grande projeto, os problemas e erros ocorrem com freqüência, pois possui um modelo grande; portanto, toda vez que a fase de teste será continuada se implementada pelo modelo em cascata, o que levará a menos otimização e precisão do software.
Artigos recomendados
Este foi um guia para o modelo Waterfall. Aqui discutimos as fases, vantagens e desvantagens do modelo em cascata. Você também pode consultar nossos outros artigos sugeridos para saber mais -
- O que é a AWS?
- O que é o Bootstrap?
- O que é uma colméia?
- O que é o Unix?
- Scrum vs Cachoeira | Comparação