Modelo V

No artigo de hoje vamos nos aprofundar em Modelo V, um tema relevante que tem chamado a atenção de muita gente nos últimos tempos. Ao longo deste texto analisaremos diferentes aspectos de Modelo V, desde suas origens até seu impacto na sociedade atual. Iremos mergulhar na sua história, explorar as suas implicações em diferentes áreas e refletir sobre a sua importância no contexto atual. Modelo V é um tema interessante que merece ser abordado sob diferentes perspectivas, por isso neste artigo pretendemos oferecer uma visão ampla e enriquecedora deste assunto. Junte-se a nós nesta exploração fascinante!

The V-model of the Systems Engineering Process.[1]

O Modelo V [2]é um modelo conceitual de Engenharia de Sistemas/Desenvolvimento de Produto visto como melhoria ao problema de reatividade do modelo em cascata. Ele permite que, durante a integração de um sistema em seus diversos níveis, os testes sejam feitos contra os próprios requisitos do componente/interface que está sendo testado(a), em contraste com modelos anteriores onde o componente era testado contra a especificação do componente/interface. Notar a diferença entre requisito e especificação.

O Modelo V virou um padrão da indústria de software depois de 1980 e, após o surgimento da Engenharia de Sistemas, tornou-se um conceito padrão em todos os domínios da indústria. O mundo do software tinha feito poucos avanços em termos de maturidade, em achar na bibliografia corrente as referências que poderiam se aplicar ao sistema.

Características

  • Os testes têm resultados de maior efetividade, uma vez que são testados contra requisitos e não contra especificações;
  • Este modelo possibilita que se encontrem erros durante os processos de se derivar especificações de requisitos;
  • Ajuda a desenvolver novos requisitos;
  • Melhora a qualidade do produto resultante, uma vez que valida o processo de engenharia de sistemas durante a integração do sistema.

Desvantagens

  • Não considera o paralelismo que geralmente ocorre em projetos de maior complexidade;
  • Não considera as diversas dimensões do projeto;
  • Há ciclos de revisão em etapas tardias do processo, quando se encontra erros, sua correção é onerosa.

Etapas

  • Análise das necessidades e viabilidade;
  • Especificação do software;
  • Concepção: arquitetura;
  • Concepção: detalhamento;
  • Codificação;
  • Teste individual;
  • Teste de integração;
  • Teste de validação;
  • Receita.

Referências

  1. ↑ Clarus Concept of Operations. Arquivado em 5 de julho de 2009, no Wayback Machine. Publication No. FHWA-JPO-05-072, Federal Highway Administration (FHWA), 2005
  2. ↑ Franco, Ricardo. «Steps for requirements writing» (PDF). Product: Management & Development