SDLC - Modelo V
O modelo V é um modelo SDLC onde a execução dos processos ocorre de forma sequencial em forma de V. Também é conhecido comoVerification and Validation model.
O V-Model é uma extensão do modelo em cascata e é baseado na associação de uma fase de teste para cada estágio de desenvolvimento correspondente. Isso significa que, para cada fase do ciclo de desenvolvimento, há uma fase de teste diretamente associada. Este é um modelo altamente disciplinado e a próxima fase começa somente após a conclusão da fase anterior.
V-Model - Design
No V-Model, a fase de teste correspondente da fase de desenvolvimento é planejada em paralelo. Portanto, há fases de verificação em um lado do 'V' e fases de validação no outro lado. A fase de codificação une os dois lados do V-Model.
A ilustração a seguir descreve as diferentes fases em um modelo V do SDLC.
Modelo V - Fases de verificação
Existem várias fases de verificação no V-Model, cada uma delas é explicada em detalhes abaixo.
Análise de Requisitos de Negócios
Esta é a primeira fase do ciclo de desenvolvimento em que os requisitos do produto são entendidos da perspectiva do cliente. Esta fase envolve uma comunicação detalhada com o cliente para entender suas expectativas e requisitos exatos. Esta é uma atividade muito importante e precisa ser bem administrada, pois a maioria dos clientes não tem certeza do que exatamente precisa. oacceptance test design planning é feito neste estágio, pois os requisitos de negócios podem ser usados como uma entrada para o teste de aceitação.
Projeto de sistema
Depois de ter os requisitos do produto claros e detalhados, é hora de projetar o sistema completo. O projeto do sistema terá a compreensão e detalhamento do hardware completo e configuração de comunicação para o produto em desenvolvimento. O plano de teste do sistema é desenvolvido com base no projeto do sistema. Fazer isso em um estágio anterior deixa mais tempo para a execução real do teste posteriormente.
Projeto arquitetônico
As especificações arquitetônicas são compreendidas e projetadas nesta fase. Normalmente, mais de uma abordagem técnica é proposta e com base na viabilidade técnica e financeira a decisão final é tomada. O design do sistema é subdividido em módulos que ocupam funções diferentes. Isso também é conhecido comoHigh Level Design (HLD).
A transferência de dados e a comunicação entre os módulos internos e com o mundo exterior (outros sistemas) é claramente entendida e definida nesta etapa. Com essas informações, os testes de integração podem ser projetados e documentados durante este estágio.
Projeto de Módulo
Nesta fase, o projeto interno detalhado para todos os módulos do sistema é especificado, referido como Low Level Design (LLD). É importante que o design seja compatível com os outros módulos da arquitetura do sistema e com os outros sistemas externos. Os testes de unidade são uma parte essencial de qualquer processo de desenvolvimento e ajudam a eliminar o máximo de falhas e erros em um estágio muito inicial. Esses testes de unidade podem ser projetados neste estágio com base nos designs dos módulos internos.
Fase de Codificação
A codificação real dos módulos do sistema projetados na fase de design é realizada na fase de codificação. A linguagem de programação mais adequada é decidida com base nos requisitos de sistema e arquitetura.
A codificação é realizada com base nas diretrizes e padrões de codificação. O código passa por várias revisões de código e é otimizado para melhor desempenho antes que a compilação final seja verificada no repositório.
Fases de Validação
As diferentes fases de validação em um modelo V são explicadas em detalhes abaixo.
Teste de Unidade
Os testes de unidade projetados na fase de design do módulo são executados no código durante esta fase de validação. O teste de unidade é o teste em nível de código e ajuda a eliminar bugs em um estágio inicial, embora todos os defeitos não possam ser descobertos pelo teste de unidade.
Teste de integração
O teste de integração está associado à fase de projeto arquitetônico. Os testes de integração são realizados para testar a coexistência e a comunicação dos módulos internos do sistema.
Teste de Sistema
O teste do sistema está diretamente associado à fase de design do sistema. Os testes de sistema verificam toda a funcionalidade do sistema e a comunicação do sistema em desenvolvimento com sistemas externos. A maioria dos problemas de compatibilidade de software e hardware podem ser descobertos durante a execução do teste do sistema.
Teste de aceitação
O teste de aceitação está associado à fase de análise de requisitos de negócios e envolve o teste do produto no ambiente do usuário. Os testes de aceitação revelam os problemas de compatibilidade com os outros sistemas disponíveis no ambiente do usuário. Ele também descobre os problemas não funcionais, como defeitos de carga e desempenho no ambiente real do usuário.
V- Modelo ─ Aplicação
A aplicação do modelo V é quase igual ao modelo em cascata, pois ambos os modelos são do tipo sequencial. Os requisitos devem ser muito claros antes do início do projeto, porque geralmente é caro voltar e fazer alterações. Este modelo é utilizado no campo do desenvolvimento médico, por ser um domínio estritamente disciplinado.
As dicas a seguir são alguns dos cenários mais adequados para usar o aplicativo V-Model.
Os requisitos são bem definidos, claramente documentados e fixos.
A definição do produto é estável.
A tecnologia não é dinâmica e é bem compreendida pela equipe do projeto.
Não há requisitos ambíguos ou indefinidos.
O projeto é curto.
V-Model - Prós e Contras
A vantagem do método V-Model é que ele é muito fácil de entender e aplicar. A simplicidade desse modelo também facilita o gerenciamento. A desvantagem é que o modelo não é flexível para mudanças e caso haja uma mudança de requisito, o que é muito comum no mundo dinâmico de hoje, torna-se muito caro fazer a mudança.
As vantagens do método V-Model são as seguintes -
Este é um modelo altamente disciplinado e as fases são concluídas uma de cada vez.
Funciona bem para projetos menores onde os requisitos são muito bem compreendidos.
Simples e fácil de entender e usar.
Fácil de gerenciar devido à rigidez do modelo. Cada fase tem resultados específicos e um processo de revisão.
As desvantagens do método V-Model são as seguintes -
Alto risco e incerteza.
Não é um bom modelo para projetos complexos e orientados a objetos.
Mau modelo para projetos longos e em andamento.
Não é adequado para projetos onde os requisitos têm um risco moderado a alto de alteração.
Quando um aplicativo está em estágio de teste, é difícil voltar e alterar uma funcionalidade.
Nenhum software funcional é produzido até o final do ciclo de vida.