ES 13 - Verificação e Validação

(1)

Régis Simão 1/41

Verificação e Validação

(2)

Régis Simão 2/41

Verificação e Validação

Agenda

 _Introdução

 _{Planejamento de verificação e validação}  _{Inspeções de software}

 _{Análise estática automatizada}

 _{Desenvolvimento de software Cleanroom}  _Bibliografia

(3)

Régis Simão 3/41

Verificação e Validação

Introdução

 _Objetivos

 Explicar as diferenças entre verificação e validação de software

 _{Descrever as inspeções de programa como um método para descobrir}

defeitos em programas

 _{Explicar por que a análise estática de programas é uma importante}

técnica de verificação

 _{Explicar o método Cleanroom para o desenvolvimento de programas e}

(4)

Régis Simão 4/41

Verificação e Validação

Introdução

 _{São atividades que objetivam assegurar que o software atende as} necessidades dos usuários

 _{Verificação}

 Nós estamos construindo corretamente o produto?

 O software está em conformidade com a sua especificação?

 _Validação

 _{Nós estamos construindo o produto correto?}

(5)

Régis Simão 5/41

Verificação e Validação

Introdução

 _{Verificação e Validação (V&V) são os nomes dados aos processos de} verificação e análise que asseguram que o software cumpra suas

especificações e atenda às necessidades dos clientes que estão pagando por ele

 _{Os dois principais objetivos são:}

 _{A descoberta de defeitos no sistema}

 A avaliação de que o sistemas é ou não usável em uma situação

(6)

Régis Simão 6/41

Verificação e Validação

Introdução

 _{Objetivos da V&V}

 Verificação e Validação deveriam garantir que o software atende ao seu

propósito

 Isto NÃO significa completamente livre de defeitos

 _{Embora, seja bom o suficiente para uso pretendido e tipo de uso}

(7)

Régis Simão 7/41

Verificação e Validação

Introdução

 _{Confiabilidade V&V}

 Depende da proposta do sistema, expectativas do usuário e ambiente de

marketing

 Função do Software

 O nível de confiabilidade depende de quanto crítico o software é para uma organização

 _{Expectativas do usuário}

 Usuários podem ter baixas expectativas sobre certos tipos de software

 _{Ambiente de Mercado}

 Colocar um produto no mercado o mais rápido possível pode ser mais importante que encontrar defeitos no programa

(8)

Régis Simão 8/41

Verificação e Validação

Introdução

 _{Verificação Dinâmica X Verificação Estática}

 Inspeção de software

 Compreende a análise da representação estática do sistema para descobrir problemas (verificação estática)

 Pode ser acompanhada pelos análise automática de textos e diagramas  _{Teste de Software}

 Compreende o uso e a observação do comportamento do produto (verificação dinâmica)

 O sistema é executado com dados de testes e seu comportamento operacional é observado

(9)

Régis Simão 9/41

Verificação e Validação

Introdução

(10)

Régis Simão 10/41

Verificação e Validação

Introdução

 _{Teste de Programas}

 Podem revelar a presença de erros e NÃO a ausência de erros

 _{Um teste que obteve sucesso é um teste que descobriu um ou mais erros}  É a única técnica de validação para requisitos não funcionais

 _{Deve ser usado em conjunto com a verificação estática para provê uma}

(11)

Régis Simão 11/41

Verificação e Validação

Introdução

 _{Tipos de Teste}

 Teste de Defeito

 Testes projetados para descobrir defeitos no sistema

 Um testes de defeito de sucesso é aquele que revela a presença de defeitos no sistema

 _{Teste Estatístico}

 Teste projetado para refletir a freqüência de entradas de usuários. Usado para a estimativa de confiabilidade

(12)

Régis Simão 12/41

Verificação e Validação

Introdução

 _{Teste e Depuração (Debugging)}

 Testar e Depurar são processos distintos

 _{V&V compreende descobrir se um programa tem defeitos}  Depuração compreende localizar e corrigir os erros

 _{Depurar envolve formulação de hipóteses sobre o comportamento de}

programa, então testa-se estas hipóteses no programa para encontrar erros no sistema

(13)

Régis Simão 13/41

Verificação e Validação

Introdução

(14)

Régis Simão 14/41

Verificação e Validação

Planejamento de V&V

 _Projeto

 Planejamento cuidadoso é necessário para se obter o máximo possível

dos processos de teste e inspeção

 O planejamento de V&V deve ser iniciado cedo no processo de

desenvolvimento

 O plano deveria identificar o balanceamento entre a verificação estática e

os testes

 O planejamento dos testes compreende a definição de padrões de testes

(15)

Régis Simão 15/41

Verificação e Validação

Planejamento de V&V

(16)

Régis Simão 16/41

Verificação e Validação

Planejamento de V&V

(17)

Régis Simão 17/41

Verificação e Validação

Inspeções de Software

 _{Consiste de pessoas examinando os artefatos de projeto e código fonte} com o objetivo de descobrir anomalias e defeitos

 _{Não requer execução do sistema, logo pode ser feita antes da} implementação

 _{Pode ser realizada sobre qualquer artefato do sistema: requisitos, projeto,} dados de testes, etc.

 _{É uma técnica muito efetiva para descobrir erros}

 _{Muitos defeitos diferentes podem ser descobertos em uma única} inspeção. Em testes, um defeito pode mascará outros defeitos, logo várias execuções são necessárias

(18)

Régis Simão 18/41

Verificação e Validação

Inspeções de Software

 _{Inspeções e Testes}

 Inspeções e testes são complementares e não técnicas de verificação de

uso exclusivo. As duas técnicas devem ser usadas em um processo V&V

 Inspeções podem checar a conformidade entre as especificações, mas

não a conformidade com os requisitos reais do cliente

 Inspeções não podem checar requisitos não funcionais tais como

(19)

Régis Simão 19/41

Verificação e Validação

Inspeções de Software

 _{Inspeções de programas}

 Técnica formal para revisar documentos

 _{Explicitamente pretendido para detecção de defeitos e não a correção}  Defeitos podem ser :

 erros lógicos,

 anomalias no código que pode ser indicadas por uma condição errada (variável não inicializada) ou

(20)

Régis Simão 20/41

Verificação e Validação

Inspeções de Software

 _{Pré-condições de Inspeção}

 Uma especificação precisa deve estar disponível

 _{Membros de times devem ser conhecer os padrões organizacionais}

 Código deve estar sintaticamente correto  _{Um checklist deve estar disponível}

 _{O gerenciamento deve aceitar que a inspeção aumente os custos iniciais}

do processo de software

 _{O gerenciamento não deve usar inspeções para avaliação dos}

(21)

Régis Simão 21/41

Verificação e Validação

Inspeções de Software

(22)

Régis Simão 22/41

Verificação e Validação

Inspeções de Software

 _{Procedimento de Inspeção}

 Uma visão geral do sistema é apresentada para o time de inspeção

 _{Código e a documentação associada são distribuídos antecipadamente}

para o time de inspeção

 _{Inspeções são realizadas e erros descobertos são anotados}  Modificações são feitas para reparar erros descobertos

(23)

Régis Simão 23/41

Verificação e Validação

Inspeções de Software

(24)

Régis Simão 24/41

Verificação e Validação

Inspeções de Software

 _{Checklists de Inspeção}

 Checklist de erros comuns devem ser usados para guiar a inspeção  _{Checklist de erros é dependente da linguagem de programação}

 Exemplos: Inicialização de variáveis, nomenclatura de constantes,

(25)

Régis Simão 25/41

Verificação e Validação

Inspeções de Software

(26)

Régis Simão 26/41

Verificação e Validação

Inspeções de Software

 _{Valores sobre Inspeção}

 500 linhas/hora durante a apresentação

 _{125 linhas de código-fonte/hora durante a preparação individual}  90-124 linhas/hora podem ser inspecionada

 _{Inspeção é portanto um processo caro}

(27)

Régis Simão 27/41

Verificação e Validação

Análise Estática Automatizada

 _{Analisadores estáticos são ferramentas para o processamento de códigos} fontes

 _{Eles percorrem o texto do programa e tentam descobrir condições} potenciais de erro e mostram estas condições para o time de V&V  _{Muito efetivo quando utilizado juntamente com a inspeção. Deve ser}

(28)

Régis Simão 28/41

Verificação e Validação

Análise Estática Automatizada

(29)

Régis Simão 29/41

Verificação e Validação

Análise Estática Automatizada

 _{Estágios da Análise Estática}  _{Análise do Fluxo de Controle}

 _{Procura por laços com pontos de entrada e saída múltiplos, por códigos}

não alcançáveis, etc.

 _{Análise da Utilização de Dados}

 Detecta variáveis não inicializadas, variáveis que foram declaradas e

nunca foram utilizadas, etc.

 _{Análise de Interface}

(30)

Régis Simão 30/41

Verificação e Validação

Análise Estática Automatizada

 _{Estágios da Análise Estática}

 _{Análise de Fluxo de Informações}

 _{Identifica as dependências das variáveis de saída. Não detectam}

anomalias, mas destacam a informação para inspeção ou revisão de código

 _{Análise de Caminho}

 _{Identificam os caminhos através dos programas e listam os comandos}

executados no caminho. Novamente, são potencialmente úteis no processo de revisão

 _{Todos os estágios geram grande quantidade de informação. Mas devem} ser usados com cautela

(31)

Régis Simão 31/41

Verificação e Validação

Análise Estática Automatizada

 _{Análise Estática do LINT}

138% more lint_ex.c #include <stdio.h> printarray (Anarray) int Anarray; { printf(“%d”,Anarray); } main () {

int Anarray[5]; int i; char c; printarray (Anarray, i, c); printarray (Anarray) ; }

139% cc lint_ex.c 140% lint lint_ex.c

lint_ex.c(10): warning: c may be used before set lint_ex.c(10): warning: i may be used before set

printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10)

printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(11) printf returns value which is always ignored

(32)

Régis Simão 32/41

Verificação e Validação

Análise Estática Automatizada

 _{Uso da Análise Estática}

 Particularmente útil quando uma linguagem como C é usada, ela possui

uma tipagem fraca e portanto muitos erros não são detectadas pelo compilador

 Baixa efetividade para linguagens como Java que tem verificação de

tipagem forte e podem portanto detectar muitos erros durante a compilação

(33)

Régis Simão 33/41

Verificação e Validação

Desenvolvimento de Software Cleanroom

 _{O nome é derivado do processo “Cleanroom” de fabricação de} semicondutores. A filosofia é evitar erros ao invés de removê-los  _{Processo de desenvolvimento de software baseado em}

 Desenvolvimento incremental

 Especificação formal

 _{Programação estruturada}

 Verificação estática

(34)

Régis Simão 34/41

Verificação e Validação

Desenvolvimento de Software Cleanroom

(35)

Régis Simão 35/41

Verificação e Validação

Desenvolvimento de Software Cleanroom

 _{Características do Processo Cleanroom}

 Especificação formal usando um modelo de transição de estados

 _{Desenvolvimento incremental}

 Programação estruturada – construções de abstrações e controles

limitados são usados

 Verificação estática usando inspeções rigorosas  _{Testes estatísticos do sistema}

(36)

Régis Simão 36/41

Verificação e Validação

Desenvolvimento de Software Cleanroom

(37)

Régis Simão 37/41

Verificação e Validação

Desenvolvimento de Software Cleanroom

 _{Especificação e Inspeções Formais}

 Um modelo baseado em estado é uma especificação do sistema e o

processo de inspeção verifica o programa contra o modelo

 A técnica de programação é definida de forma que exista uma

correspondência clara entre o modelo e o sistema implementado

 Argumentos matemáticos (não provas matemáticas) são usados para

(38)

Régis Simão 38/41

Verificação e Validação

Desenvolvimento de Software Cleanroom

 _{Equipes envolvidos no Processo de Desenvolvimento Cleanroom}

 Equipe de Especificação

 Responsável pelo desenvolvimento e manutenção da especificação do sistema

 Equipe de Desenvolvimento

 Responsável pelo desenvolvimento e verificação do software. O software não é executado ou mesmo compilado durante o processo

 _{Equipe de Certificação}

 Responsável pelo desenvolvimento de um conjunto de testes estatísticos para

testar o software depois do desenvolvimento. Modelos de aumento de

confiabilidade são usados para determinar quando a confiabilidade está no nível aceitável

(39)

Régis Simão 39/41

Verificação e Validação

Desenvolvimento de Software Cleanroom

 _{Avaliações independentes mostram que o processo não é mais caro que} outras técnicas

 _{O processo gera menos erros que o desenvolvimento tradicional}  _{Funciona bem quando executado por engenheiros habilitados e}

(40)

Régis Simão 40/41

Verificação e Validação

Bibliografia

 _{Sommerville, Ian. Engenharia de Software, 6a. edição. Addison Wesley,} 2004

(41)

Régis Simão 41/41