Modelo V
Modelo V - SDLC:
O modelo V, uma metodologia de ciclo de vida de desenvolvimento de software, descreve as atividades a serem realizadas e os resultados que devem ser produzidos durante o ciclo de vida do produto. É conhecido como modelo de verificação e validação. A validação responde à pergunta - "Estamos desenvolvendo o produto que atende a tudo o que o usuário precisa deste software?" e a Verificação responde à pergunta - "Estamos desenvolvendo este produto seguindo firmemente todas as especificações de design?"
Objetivos do V-Model:
Minimização de riscos do projeto
Qualidade garantida
Redução do custo total de todo o projeto
Melhor comunicação entre todas as partes envolvidas
Fases diferentes do modelo V:
The Requirements phase, um documento que descreve o que o software deve fazer depois que o software é coletado e analisado e a atividade de teste correspondente é user acceptance testing.
The Architectural Design phase, em que uma arquitetura de software é projetada e construindo os componentes dentro do software e estabelecendo os relacionamentos entre os componentes e a atividade de teste correspondente é o Teste do Sistema.
The High Level Design phase,dividir o sistema em subsistemas com interfaces identificadas; em seguida, é traduzido para um design mais detalhado e a atividade de teste correspondente é o teste de integração.
The Detailed Design phase,onde a implementação detalhada de cada componente é especificada. O projeto detalhado dividido em estruturas de dados, algoritmo usado e a atividade de teste correspondente é o teste de unidade.
Coding em que cada componente do software é codificado e testado para verificar se implementa fielmente o projeto detalhado.
Vantagens e limitações do V-Model:
Vantagens:
Enfatize para verificação e validação do produto nos estágios iniciais de desenvolvimento do produto.
Cada estágio é testável
O gerenciamento de projetos pode acompanhar o progresso por marcos
Fácil de entender, implementar e usar
Limitações:
Não lida facilmente com eventos simultaneamente.
Não lida com iterações ou fases
Não lida facilmente com mudanças dinâmicas nos requisitos
Não contém análise de risco ou atividades de mitigação