Engenharia de Software - Verificação e Validação

Prévia do material em texto

Verificação e Validação
Idarlan Machado
Prof. Vander Alves
Supervisor
• The verification and validation costs 
for critical systems involves 
additional validation processes and 
analysis than for non-critical 
systems:
– The costs and consequences of failure 
are high so it is cheaper to find and 
remove faults than to pay for system 
failure;
– You may have to make a formal case 
to customers or to a regulator that the 
system meets its dependability 
requirements. This dependability case 
may require specific V & V activities to 
be carried out.
Em operação, o que não 
desejamos !!!
• The verification and validation costs 
for critical systems involves 
additional validation processes and 
analysis than for non-critical 
systems:
– The costs and consequences of failure 
are high so it is cheaper to find and 
remove faults than to pay for system 
failure;
– You may have to make a formal case 
to customers or to a regulator that the 
system meets its dependability 
requirements. This dependability case 
may require specific V & V activities to 
be carried out.
Ao usar o sistema, o que não 
desejamos !!!
 
Introdução
- Validação: "Estamos construindo o produto correto?" -> Software 
conforme sua especificação
- Verificação: "Estamos construindo o produto corretamente" -> O 
software deve fazer o que o usuário solicitou (registros das espeficações
● Dupla motivação: (i) Descobrir defeitos no sistema; (ii) Avaliar se 
sistema pode ser operado em ambiente real
● Aplicação V & V deve garantir que software faz o que se propôs a fazer
● Aplicação de V & V NÃO significa isenção total de defeitos
● O tipo de uso irá indicar a tolerância a defeitos
● Processo V & V
● Inspeções de software ou revisões por pares – técnica estática 
de rerificação e validação, não precisa de executar o sw
● Testes de software – técnica dinâmica
 
Verificação e validação dinâmica e 
estática
 
Processo de debugging (encontrar 
erro para corrigi-lo)
 
Planejamento de verificação e 
validação
● O processo Validação & Verificação deve ser aplicado em 
todo o ciclo de vida do processo de engenharia de 
software
● Deve ocorrer logo no início no processo de construção do 
sw
● Deve definir o equilíbrio entre abordagem estática e 
dinâmica
● Se concentra em estabelecer padrões para o processo de 
teste
● Deve gerar um plano de testes – exemplificado a seguir 
para grandes sistemas
● Planos de testes são documentos dinâmicos = evoluem 
durante o desenvolvimento do sw
 
Aplicar V & V em ciclo de vida do 
processo de construção do software 
 
Plano de testes com ligação entre o 
desenvolvimento e os testes
 
Estrutura de um plano de teste de 
software
● Processo de teste - Descrição das fases principais do processo de teste.
● Rastreabilidade de requisitos - Planejar os testes de modo que todos os 
requisitos do usuário sejam individualmente testados.
● Itens testados - Os produtos (artefatos) do processo de software a serem 
testados devem ser especificados.
● Cronograma de testes - Um cronograma global de testes e a alocação dos 
recursos. Deve estar alinhado com o cronograma do projeto global.
● Procedimentos de registro de testes - Os resultados dos devem ser 
sistematicamente registrados, pois deve serm possível auditar o processo 
de teste para verificar que foi conduzido corretamente.
● Requisitos de hardware e software - Estabelecer quais ferramentas de 
software serão e quais hardwares serão necessários para realização dos 
testes.
● Restrições - Antecipar aqui quais as restrições afetarão o processo de 
teste, exemplo: falta de pessoal, de máquinas, etc.
 
Inspeções de software
● Contexto: processo V&V estático
● Objetivo: descobrir anomalias e defeitos antes de 
executar o sistema
● Maneira: pessoas revisam os artefatos (requisitos, 
arquitetura-diagramas, modelo de dados-MER, etc)
● Resultados: segundo pesquisas, pode reduzir até 
90% dos defeitos de implementação
● Não checa: requisitos não-funcionais, já que o 
programa não está em funcionamento
● Foco: detectar antecipadamente defeitos, não corrigi-
los
 
Pré-condições para inspeção
● Uma precisa especificação deve estar 
disponível
● Equipe deve estar familiarizadas com os 
padrões da organização
● Um checklist de erros deve estar elaborado
● A gerência deve estar ciente de que inspeção 
aumenta os custos nas fases inicias do 
processo de software
● A gerência não deve utilizar a inspeção como 
identificação de falhas humanas
 
Processo de inspeção de programa
 
Análise estática automatizada
● É o uso de ferramentas de análise de 
processamento de texto
● Realiza o parse do texto do programa e tenta 
encontrar potenciais erros e detaca-os para a 
equipe de V & V
● É uma forma efetiva de auxiliar o processo de 
inspeção, mas não atende o processo inteiro
 
Verificação e métodos formais
● É a verificação baseada em especificações matemáticas
● É uma técnica de verificação estática definitiva, a mais rigorosa
● Pode desenvolver argumentos formais matemáticos para verificar se 
o programa está conforme ou atende tais argumentos
● Vantagens:
● Pode identificar erros/omissões de especificação já que exige 
uma análise detalhada dos requisitos
● Identificação de defeitos antes dos testes
● Desvantagens:
● Requer notações especiais que o especialista do domínio não 
domina = dificulta a comunicação
● Alto custo
● Pode ser alcançados os mesmos resultados com outras técnicas de 
V & V
	Slide 1
	Validation of critical systems
	Slide 3
	Slide 4
	Slide 5
	Slide 6
	Slide 7
	Slide 8
	Slide 9
	Slide 10
	Slide 11
	Slide 12
	Slide 13
	Slide 14
	Slide 15