09 Requisitos

Prévia do material em texto

Engenharia de Software 
Verificação e Validação 
Aula 9 
Verificação e validação 
l  Asseguram que o software cumpra com 
suas especificações e atenda às 
necessidades dos usuários 
Objetivos 
l  Introduzir verificação e validação de 
software. 
l  Descrever o processo de inspeção de 
programa 
l  Explicar análise estática. 
l  Introduzir o processo de 
desenvolvimento de software Cleanroom 
Verificação vs validação 
l  Verificação: 
”Estamos construindo certo o produto?" 
O software cumpre com suas especificações 
l  Validação: 
”Estamos construindo o produto certo?" 
lO software deve estar de acordo com o que o 
usuário deseja. 
O processo V & V 
l  É um processo que engloba todo o ciclo de 
vida 
l  - V & V deve ser aplicado em cada estágio no 
processo de desenvolvimento. 
Tem dois objetivos principais: 
l  a descoberta de defeitos no sistema 
l  Assegurar se o sistema é ou não utilizável em 
uma situação operacional. 
Verificação estática e dinâmica 
l  Inspeções de software - preocupadas com a análise 
estática das representações do sistema para descobrir 
problemas (verificação estática)) 
l  pode ser complementadas por alguma análise automática do 
texto de origem de um sistema ou dos documentos associados. 
l  Teste de software - preocupado com a execução e 
observação do comportamento do produto (verificação 
dinâmica). 
l  • O sistema é executado com dados de teste e o seu 
comportamento operacional é observado. 
Teste de programas 
l  Pode revelar a presença de erros e NÃO a 
ausência 
l  Um teste bem sucedido é um teste que 
descobre um ou mais erros. 
l  É a única técnica de validação para requisitos 
não funcionais (desempenho, confiabilidade) 
l  Deve ser usado em conjunto com a verificação 
estática para uma cobertura total das 
atividades de V&V 
Tipos de teste 
Os testes de defeito 
l  Testes projetados para descobrir defeitos no sistema. 
l  Um teste bem sucedido é aquele que revela a presença 
de defeitos em um sistema. 
Testes estatísticos 
l  Usado para testar o desempenho e a confiabilidade do 
programa. 
l  Confiabilidade: número de falhas no sistema, etc 
l  Desempenho Tempo de execução, tempo de resposta, 
etc. 
Metas de V& V 
l  Verificação e validação deve estabelecer a 
confiança de que o software é “adequado a 
seu propósito”. 
l  Isso NÃO significa que o programa tenha que 
ser livre de defeitos. 
l  Ao invés disso, significa que o sistema deve 
ser suficientemente bom para o uso 
pretendido. O tipo de uso irá determinar o grau 
de confiança que será necessário. 
Confiança de V & V 
l  Depende do propósito do sistema, as expectativas do 
usuário e o ambiente de mercado. 
Função do software 
l  » O nível de confiança depende do tipo de sistema e o 
quanto é importante para a organização. 
Expectativas do usuário 
l  » Usuários podem ter poucas expectativas de certos tipos 
de software 
Ambiente de mercado 
l  » Colocar um produto no mercado pode ser mais 
importante do que encontrar todos os defeitos no 
programa. 
Testes e depuração 
l  Testar e depurar um programa são atividades 
distintas. 
l  Verificação e validação e teste estão 
preocupados em estabelecer a existência de 
defeitos em um programa. 
l  Depuração está preocupada com a localização 
e remoção desses defeitos. 
l  Depuração envolve a formulação de uma 
hipótese sobre o comportamento do programa 
e testar essa hipótese para encontrar o erro no 
sistema. 
O processo de depuração 
Planejamento de V & V 
l  Planejamento cuidadoso é necessário para 
obter sucesso nos processos de inspeção e 
teste. 
l  O planejamento deve iniciar no começo do 
processo de desenvolvimento. 
l  O processo de planejamento deve decidir 
sobre o equilíbrio entre as abordagens 
estáticas e dinâmicas. 
l  O planejamento de testes se ocupa em 
estabelecer os padrões para o processo de 
testes. 
A estrutura de um plano de 
teste 
l  O processo de teste 
l  Facilidade de rastreamento dos requisitos 
l  Itens a serem testados 
l  Cronograma de testes 
l  Procedimentos de registros de testes 
l  Requisitos de hardware e de software 
l  Restrições 
Inspeções de software 
l  Envolve pessoas examinando uma 
representação de software para descobrir 
anomalias e defeitos. 
l  Não há a necessidade de execução do 
sistema, assim pode ser usada antes da 
implementação. 
l  Pode ser aplicada a qualquer representação 
do sistema (requisitos, projeto, dados de teste, 
etc.) 
l  Técnica muito eficaz para a descoberta de 
erros. 
Sucessos da inspeção 
l  Muitos defeitos diferentes podem ser 
descobertos em uma única inspeção. No teste, 
um defeito pode mascarar outros, assim várias 
execuções são necessárias. 
l  A reutilização do conhecimento do domínio e 
da programação é benéfica, uma vez que 
revisores provavelmente já viram os tipos de 
erros que ocorrem com freqüência em 
linguagens de programação específicas e em 
determinados tipos de aplicações. 
Inspeções e testes 
l  Inspeções e testes são técnicas de verificação 
complementares. 
l  Ambas devem ser utilizadas no processo de 
V&V. 
l  Inspeções podem verificar a conformidade 
com uma especificação mas não a 
conformidade com os reais requisitos do 
usuário. 
l  Inspeções não podem verificar as 
características não funcionais tais como 
desempenho, usabilidade, etc. 
Inspeções de programa 
l  Revisão cuidadosa, linha por linha, do código 
fonte do programa. 
l  Objetivo é a DETECÇÃO de defeitos (não 
correção) 
l  Defeitos podem ser erros lógicos, anomalias 
no código que podem indicar uma condição 
errônea (por ex. uma variável não inicializada) 
ou a não conformidade com padrões 
organizacionais. 
Pré-condições para a inspeção 
de programa 
l  Uma especificação precisa deve estar 
disponível. 
l  Os membros da equipe de inspeção devem 
estar familiarizados com os padrões 
organizacionais. 
l  Código sintaticamente correto deve estar 
disponível. 
l  Uma lista de erros deve ser preparada 
l  Gerente deve aceitar que a inspeção 
aumentara os custos no começo do processo 
de software. 
Processo de inspeção de 
programa 
Planejamento e introdução 
l  Visão geral do sistema, apresentado à equipe de inspeção. 
Preparação Individual 
l  Cada membro da equipe estuda a especificação e procura 
defeitos no código. 
Reunião de Inspeção 
l  Durante a inspeção, os erros descobertos são anotados. 
Retrabalho 
l  Modificações são feitas para corrigir os erros descobertos. 
Acompanhamento 
l  Uma nova inspeção pode ser ou não necessária. 
Checklist para inspeção de 
programas 
l  Lista de erros comuns deve ser usada para 
dirigir a inspeção. 
l  Lista de erros são dependentes da linguagem 
de programação 
l  Quanto mais “fraca” é a checagem de tipos 
pela linguagem, maior é a lista de erros mais 
comuns. 
l  Exemplos: inicialização, nomeação de 
constantes, término de laços, limites de 
vetores, etc. 
Taxa de inspeção (IBM) 
l  Cerca de 500 declarações/hora durante 
revisão geral 
l  125 declarações/hora durante preparação 
individual 
l  90-125 declarações/hora podem ser 
inspecionadas durante a reunião 
l  Inspeção é portanto um processo caro 
l  Contudo, o esforço requerido para a inspeção 
é menor do que a metade o esforço de teste 
exigido para defeitos equivalentes. 
Análise estática automatizada 
l  Analisadores estáticos são ferramentas de 
software para o processamento do código 
fonte. 
l  Percorrem o texto do programa e tentam 
descobrir potenciais condições erradas e 
chamar a atenção da equipe de v&v. 
l  São bastanteeficaz como um auxílio às 
inspeções de programas. É um complemento, 
porém não substitui as inspeções. 
Checagem da análise estática 
Uso da Análise Estática 
l  Útil quando a linguagem não faz 
checagem adequada de tipos e, por 
isso, muitos erros não são detectados 
pelo compilador (C ) 
l  Menos eficaz para linguagens que 
possui forte checagem de tipos e 
podem, portanto, detectar muitos erros 
durante a compilação (Java). 
Desenvolvimento de software 
Cleanroon 
l  Filosofia de desenvolvimento que tem como base 
evitar defeitos pelo uso de um rigoroso processo de 
inspeção. 
l  Objetivo: Conseguir um software sem nenhum defeito. 
Processo de desenvolvimento baseado em: 
l  Especificação formal 
l  Desenvolvimento incremental 
l  Programação estruturada. 
l  Verificação estática usando rigorosas inspeções de 
software 
l  Teste estatístico do sistema. 
O processo Cleanroon 
Desenvolvimento Incremental 
Especificação formal e 
inspeções 
l  O modelo baseado em estados é a 
especificação e o processo de inspeção checa 
o programa com relação a esse modelo. 
l  A abordagem utilizada para o desenvolvimento 
tem como base transformações bem definidas, 
que tentam preservar a exatidão em cada 
transformação, para uma representação mais 
detalhada. 
l  Argumentos matemáticos (não provas) são 
usados para aumentar a confiança no 
processo de inspeção. 
Equipes no processo Cleanroom 
Equipe de especificação. Responsável pelo 
desenvolvimento e pela manutenção da 
especificação do sistema. 
Equipe de desenvolvimento. Responsável por 
desenvolver e verificar o software. O software 
não é executado durante esse processo. 
Equipe de certificação. Responsável pelo 
desenvolvimento de um conjunto de testes 
estatísticos para exercitar o software após o 
seu desenvolvimento (certificação da 
confiabilidade do software). 
Avaliação do processo 
Cleanroom 
l  Resultados na IBM tem mostrado que os 
softwares possuem bem menos erros, 
l  Avaliação mostra que o processo não é mais 
caro do que outras abordagens. 
l  Menos erros do que em um processo de 
desenvolvimento tradicional. 
l  Uso do processo tem sido restrito a 
organizações tecnologicamente avançadas. 
Pontos chave 
l  Verificação certifica a conformidade com a 
especificação; Validação certifica que 
programa faz o que o usuário precisa. 
l  Planos de teste descrevem os itens a serem 
testados. 
l  Inspeção de programas é o processo de 
analisar o código fonte, sem executá-lo. 
l  • O código do programa é sistematicamente checado 
por uma pequena equipe, para localizar defeitos. 
Pontos chave. 
l  Ferramentas de análise estática pode 
revelar anomalias no programa 
(possíveis defeitos). 
l  Processo de desenvolvimento 
cleanroom é uma abordagem de 
desenvolvimento de software que se 
apóia em desenvolvimento incremental, 
verificação estática e teste estatístico. 
REFERÊNCIAS 
l  PRESSMAN, Roger S. - Engenharia de 
Software - Uma Abordagem Profissional 
- 7º Edição 
l  SOMMERVILLE , Ian - Engenharia de 
Software