O documento descreve o modelo V para engenharia de software, que enfatiza testes durante todo o ciclo de desenvolvimento para melhorar a qualidade. O modelo introduz testes de unidade, integração, sistema e aceitação em cada fase e é superior aos modelos cascata e espiral. Um caso de aplicação descreve como o modelo V foi usado em um projeto para fornecer diretrizes de teste e garantia de qualidade.

1. Engenharia da Programação
Descrição do modelo V
A estrutura do modelo V é uma aproximação estruturada de testes que pode ser
usada com toda a metodologia do desenvolvimento da gerência ou do sistema de projecto.
A estrutura enfatiza a qualidade da fase inicial das exigências através da fase de teste final.
Focaliza–se em testar durante todo o ciclo de desenvolvimento para conseguir uma
detecção adiantada dos erros.
Cada derivado principal no processo de desenvolvimento é avaliado, verificado,
validado e testado. Os derivados de cada fase necessitam ser verificados e validados para
se assegurar que estão completos e correctos. O trabalho prossegue para a fase seguinte
quando todos os derivados do projecto duma fase se encontram conforme as exigências de
verificação e validação. O processo de verificação e de validação é uma tentativa de travar
tantos erros quanto possível dentro do ciclo de desenvolvimento.
Este modelo introduz a criação de testes de dados e cenários de teste durante o ciclo
de desenvolvimento do software, ao contrário de outros que só fazem testes no fim do
ciclo. Este modelo disponibiliza diferentes estados de teste : “unit testing”, “integration
testing”, “system testing” e “acceptance testing".
Cada fase de testes é suportada pela documentação, conhecida como “ test plans”.
O modelo V retracta a importância do teste do software no início do
desenvolvimento do ciclo e garante a qualidade do software, porque este é testado várias
vezes ao longo do ciclo.
Em geral, reforça a ideia de que o teste não é uma fase, mas uma parte integrante do
ciclo de desenvolvimento do software.
Basicamente o ciclo de desenvolvimento do modelo segue a seguinte sequência:
especificação, requisitos, desenho, código, testes unitários, integração, testes, sistema,
testes, aceitação, testes, especificação/desenho de código, testes unitários, requisitos,
revisão, aceitação do sistema, testes de revisão, especificação/ desenho de código, testes de
aceitação do sistema, desenho e revisão.
Estas fases estão representadas no esquema a seguir apresentado:
1

2. Engenharia da Programação
2

3. Engenharia da Programação
Vantagens e desvantagens
Vantagens do modelo V:
8A fase de teste começa no início do ciclo.
8A segunda fase de testes é extremamente reduzida.
8Os “test plans” detalhados em cada fase do ciclo ajudam compreender melhor
qual a origem do problema.
8 O modelo V é um standard internacional para o desenvolvimento de sistemas IT,
sendo superior ao modelo cascata e ao modelo espiral no endereçamento de grandes
projectos IT.
Desvantagens:
8Continua a não ser suficientemente flexível;
8É necessário maior feedback entre todas as fases do ciclo.
8
3

4. Engenharia da Programação
Caso de Aplicação
Projecto EQUIPE do ISG
O ISG decidiu aplicar como base para o projecto EQUIPE os regulamentos do
modelo V, porque estes descrevem actividades internacionalmente conhecidas para o
desenvolvimento de software. A estrutura do modelo V divide o desenvolvimento do
sistema em sub-modelos: a gerência de projecto, a gerência da configuração e a garantia de
qualidade na qual o ISG deve compartilhar as actividades e responsabilidades. A
subdivisão dos sub-modelos individuais em actividades diferentes faz com que o modelo V
seja manejável e desobstruído. É possível adaptar exactamente os regulamentos do modelo
V às exigências reais do ISG.
Um argumento adicional para o uso do modelo V no projecto EQUIPE é a
experiência positiva que o ISG teve com o projecto InCoMM, executado como um
projecto da ESSI-PIE. Neste projecto o ISG introduziu um modelo do CM (configuration
management) ao software do ISG NC que segue os regulamentos do modelo V.
A escolha do modelo V foi feita porque contem regulamentos para actividades
analíticas do QA (quality assurance) bem como as actividades de construção do QA. Uma
execução melhorada do teste não melhoraria a qualidade do software no ISG sem um uso
eficaz dela. Da mesma maneira uma gerência melhorada do teste seria ineficaz sem
métodos apropriados de teste. Além disso o ISG procurava um tipo de guideline para a
melhoria das suas actividades do QA. O submodelo do QA do modelo v pode ser usado
como um guideline, porque o modelo V está estabelecido como um modelo do processo do
ciclo de desenvolvimento.
4