O objetivo da Validação e da Verificação é assegurar que o SW seja adequado e se atende às necessidades, ou seja, a confirmação de que este cumpra suas especificações.

A Verificação é uma atividade, a qual envolve a análise de um sistema para certificar se este atende aos requisitos funcionais e não funcionais. Já a Validação, é a certificação de que o sistema atende as necessidades e expectativas do cliente. O processo de Validação e Verificação, não são processos separados e independentes.

Durante este processo, podem ser utilizadas outras técnicas em conjunto, como a Inspeção de SW. A Inspeção de um SW é o ato de analisar as representações do sistema, analisar os documentos de requisitos, diagramas e código-fonte. É recomendável a utilização da Inspeção em todas as etapas do processo. Análise automatizada é uma técnica estática, a qual não se torna necessária à execução do SW. Testes de SW executam o sistema utilizando uma massa de dados. Os dados são inseridos no sistema e sua saída é analisada. Esses testes servem para verificar se o desempenho do sistema está correto. O Processo de V&V liga todo o cliclo de vida do sistema. A Técnica V&V, deve estabelecer a confiança de que o Sistema é adequado ao seu propósito. Deve atender as necessidades dos seus usuarios e que seja util para a tarefa pretendida.

O Teste de SW é uma técnica Dinâmica, a qual torna-se necessária a sua execução. Só é possível testar um SW quando um protótipo ou uma versão executável do SW está disponível. Esta é uma das vantagens do desenvolvimento Incremental, a funcionalidade de cada parte do sistema pode ser testada, antes de serem acopladas as demais partes. Testar significa exercitar o programa, fazendo uso de dados reais. Estes serão processados pelo programa, e através da saída, poderão ser descobertos os defeitos, saídas incorretas e anomalias.

Inspeção de SW é uma verificação Estática, utilizada na descoberta de problemas. É uma revisão que pode ser aplicada a todos os artefatos de SW. É um processo de detecção de defeitos bem definido. Após um defeito ser descoberto, é necessário corrigir o sistema e revalidá-lo. A partir daí, será necessário novas Inspeções no sistema, testes de regressões e análises. Para sistemas menores, um plano de testes com menos formalidade pode ser utilizado. Localizar e detectar defeitos em um programa, não é um processo simples. Às vezes é necessário projetar testes adicionais, os quais possam reproduzir os defeitos e localizarem estes. Ferramentas de debugging também ajudam na detecção de um problema.

Abaixo, um processo de Inspeção de Programa:


O moderador planeja a inspeção, alocando as pessoas envolvidas e os recursos que serão necessários; Uma visão geral do processo é explicada; Cada membro da equipe de inspeção estuda o programa os erros; Os erros são mostrados pelo leitor e registrados pelo relator; São corrigidos os problemas que foram identificados; O moderador decide se é necessário ou não outra inspeção.

OBS: Durante uma Inspeção, pode ser necessário o uso de um CheckList para melhor organizaçao.

As classes que serão verificadas no processo de Inspeção, são: Defeito de Dados, Defeito de Controle, Defeito de Entrada e Saída, Defeito de Interface, Defeito do Gerenciamento de Armazenamento e Defeito de Gerenciamento de Excessões.

Desenvolvimento de Software Cleanroom tem a finalidade de evitar defeitos pelo processo de Inspeções. Seu objetivo é o desenvolvimento de um Sistema sem defeitos. Seu processo de desenvolvimento tem as seguintes etapas:

  • Especificar Formalmente o Sistema;
  • Desenvolver Perfil Operacional;
  • Definir Incremento de SW;
  • Projetar Testes Estáticos;
  • Contruir Programa Estruturado;
  • Verificar Codigo;
  • Integrar Incremento;
  • Testar Sistemas Integrados.

Beneficios:


  • Avaliações mostram que o processo Cleanroom não é mais caro que outras abordagens;
  • Menos erros que um processo de desenvolvimento tradicional;
  • Os Softwares possuem menos erros.

Este processo é uma abordagem de desenvolvimento de SW que se apoia no desenvolvimento Incremental e nos outros testes estaticos e dinamicos.

REFERENCIAS BIBLIOGRÁFICAS

- Sommerville, Ian. Engenharia de Software - 8ª Edição 2007;

- Pressman, Roger s. Engenharia de Software – 1995;

- BOEHM, B.W., ABTS, C., BROWN, A.W., CHULANI, S., CLARK, B.K., HOROWITZ, E., MADACHY, R., REIFER, D., STEECE, B., 2000, Software Cost Estimation with COCOMO II, Prentice Hall;

- SPÍNOLA, R.O., ÁVILA, A.L., 2008. Introdução à Engenharia de Requisitos. Engenharia de Software Magazine, Edição 1;

- KALINOWSKI, M., 2008. Introdução à Inspeção de Software. Engenharia de Software Magazine, Edição 1. Artigo de Capa.