VERIFICAÇÃO E VALIDAÇÃO (V&V) de um Software?

VERIFICAÇÃO E VALIDAÇÃO (V&V)

 

     Logo após finalizar o processo de implementação, o programa deve ser verificado para termos a certeza de que ele atende a sua especificação e entrega a funcionalidade solicitada pelos clientes. O processo de Verificação e Validação (V&V) é o nome dado a esse processo de verificação e analise, onde as atividades de V&V ocorrem em cada fase do processo de software, iniciando com as revisões de requisitos , continuando com o projeto e das inspeções de código até os testes de produtos.

O processo de Verificação e Validação não são a mesma coisa, uma vez que a validação se preocupa se “estamos construindo o produto certo?” e a verificação tem o foco se “estamos construindo o produto da forma correta?”. Desta maneira o papel da verificação nos faz ver se o software esta de acordo com as especificações, se atende ou não os requisitos funcionais e não-funcionais. Já a validação é um processo mais amplo, cuja finalidade é garantir que o software atenda as expectativas do cliente. O maior objetivo do processo de V&V é estabelecer a confiança de que o software esteja adequado ao proposito ao qual foi desenvolvido, porém o nível de confiabilidade depende do fim a que se presta o software, das expectativas dos usuários do sistema e do atual ambiente de mercado.

Dentro do processo de V&V podemos verificar duas abordagens para a verificação e analise de sistema, onde a primeira seria a inspeção de software ou revisões por pares também chamado de técnica de V&V estática, onde analisam e verificam as representações do sistema como um documento de requisitos, diagramas de projeto, código-fonte do programas, etc. e a segunda abordagem seria a de testes de software também conhecida com técnica de V&V dinâmica, que envolvem a execução do software com dados de testes a fim de checar as saídas do software, o comportamento operacional no intuito de verificar se o seu desempenho está conforme o desejado.

As técnicas de inspeções incluem inspeções de programa e de analise de código-fonte, porem não podem demonstrar que o software é operacionalmente útil. Embora as inspeções de software sejam amplamente usadas, os testes de programas será sempre a técnica principal de V&V do software, uma vez que exercita o programa utilizando dados reais processados pelo programa, onde descobre erros e defeitos nos programas. Há dois tipos de testes que podem ser utilizados no processo de software o teste de validação que tem a finalidade de mostrar que o software é o que o cliente deseja e teste de defeitos que é destinado a revelar defeitos no sistema em vez de simular o seu uso operacional, tendo como objetivo encontrar inconsistências entre um programa e sua especificação.

Os processos de V&V e de depuração (debugging) geralmente são intercalados, na medida em que descobre os defeitos no programa, você deve alterar o programa para corrigir esses defeitos. Porem o teste e o debugging tem finalidades diferentes, onde os testes são dedicados a estabelecer a existência de defeitos no sistema e o debugging é um processo que localiza e corrige esses defeitos.

Planejar a verificação e validação é um processo caro, pois para alguns sistemas de tempo real com restrições não-funcionais complexas, boa parte do orçamento pode ser gasto em processos de V&V. Como parte do processo de planejamento de V&V há necessidade de decidir sobre o equilíbrio entre as abordagens estática e dinâmica para os processos de V&V, especificar os padrões e procedimentos para inspeções e testes de software e por fim estabelecer o checklists para direcionar as inspeções nos programas.

O planejamento de teste concentra-se no estabelecimento de padrões para o processo de teste e não apenas na descrição dos testes. Os principais componentes de um plano de teste são:

• Processo de teste
• Rastreabilidade de requisitos
• Itens testados
• Cronograma de testes
• Procedimentos de registro de testes
• Requisitos de hardware e software
• Restrições

Os planos de testes não são documentos estáticos, pois evoluem durante o processo de desenvolvimento, ou seja, mudam devido a atrasos em outros estágios do processo de desenvolvimento.

As inspeções de software é um processo de V&V estática, onde um sistema de software é revisto para encontrar erros, omissões e anomalias. Geralmente tem o foco no código-fonte, mas em qualquer representação legível do software pode ser inspecionado (requisitos, algoritmos, etc). Quando realizamos a inspeção de um sistema, nos usamos o conhecimento do sistema, seu domínio de aplicação, a linguagem de programação ou o modelo de projeto para descobrir erros.

Inspeções é uma ideias antiga, visto que as inspeções são mais eficientes para descobrir defeitos do que testes de programas. Dentre as vantagens dos processos de inspeção podemos citar:

• Durante os testes, os erros podem ocultar outros erros, pois, uma vez que um erro é descoberto não podemos ficar seguros de se outros erros descobertos são devidos a um novo erro ou se são efeitos colaterais dos erros descobertos originalmente. Por ser um processo estático, em uma única sessão de inspeção pode-se descobrir muitos erros de um sistema.
• Versões incompletas podem ser inspecionadas, se um programa esta incompleto é necessário desenvolver um conjunto de testes especializados para essas partes disponíveis, acrescentando assim os custos do projeto.
• A inspeção deve considerar atributos de qualidade mais abrangentes de um programa tais como a conformidade com padrões, portabilidade, facilidade de manutenção, etc.

Revisões e testes tem vantagens e desvantagens que devem ser usadas em conjunto no processo de V&V. Uma das aplicações mais eficientes das revisões é revisar os casos de testes para um sistema. As revisões podem descobrir problemas com esses testes e auxiliar a projetar caminhos mais eficientes para testar um sistema. Inicialmente o V&V do sistema deve começar inspeções no inicio do processo de desenvolvimento e se este for sistema integrado, é preciso testá-lo para verificar as propriedades emergentes e se a funcionalidade do sistema é a que o cliente realmente deseja.

Na há duvidas de que as inspeções que começam no inicio os custos de V&V do sistemas e resultam em economia de custos somente depois que as equipes de desenvolvedores se tornam experientes em seu uso. Além disso as inspeções levam tempo para serem organizadas e parecem diminuir a velocidade do processo de desenvolvimento, sendo difícil de convencer um gerente com projetos em atraso de que esse tempo pode ser recuperado mais tarde pelo fato de que menos tempo será dispendido no processo de debugging.