Verificação e Validação. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 1

Transcrição

1 Verificação e Validação Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 1

2 Objetivos Apresentar a verificação e validação de software e discutir a distinção entre elas Descrever o processo de inspeção de programa e seu papel em V & V Explicar a análise estática como uma técnica de verificação Descrever o processo de desenvolvimento Cleanroom Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 2

3 Tópicos abordados Planejamento de verificação e validação Inspeções de software Análise estática automatizada Verificação e métodos formais Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 3

4 Verificação vs validação Verificação: Estamos construindo o produto correto? O software deve estar de acordo com sua especificação. Validação: Estamos construindo o produto corretamente?. O software deve fazer o que o usuário realmente deseja. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 4

5 O processo V & V É um processo de ciclo de vida completo V & V deve ser aplicado a cada estágio do processo de software. Tem dois objetivos principais: Descobrir defeitos em um sistema; Avaliar se o sistema é útil e usável ou não em uma situação operacional. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 5

6 Objetos de V& V Verificação e validação devem estabelecer confiança de que o software está adequado ao seu propósito. Isto NÃO significa completamente livre de defeitos. Ao invés disso, deve ser bom o suficiente para seu uso pretendido e o tipo de uso determinará o grau de confiança necessário. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 6

7 Confiança de V & V Depende do propósito do sistema, das expectativas dos usuários e do ambiente de mercado. Função de software O nível de confiança depende de quão crítico é o software para uma organização. Expectativas do usuário Os usuários podem ter baixas expectativas de certos tipos de software. Ambiente de mercado Colocação de um produto para o mercado mais cedo pode ser mais importante que descobrir defeitos no programa. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 7

8 Verificação estática e dinâmica Inspeções de software. Relacionado à análise de representações estáticas de sistema para descobrir problemas (verificação estática) Pode ser suplementado por um documento baseado em ferramenta e análise de código. Teste de software. Relacionado ao exercício e à observação do comportamento do produto (verificação dinâmica) O sistema é executado com dados de teste e seu comportamento operacional é observado. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 8

9 V&V estática e dinâmica Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 9

10 Pode revelar a presença de defeitos, NÃO a ausência. Teste de programa É a principal técnica de validação para requisitos não funcionais, visto que o software é executado para ver como se comporta. Deve ser usado em conjunto com a verificação estática para fornecer cobertura completa de V&V. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 10

11 Tipos de teste Teste de validação Pretende mostrar que o software atende aos seus requisitos; Um teste bem sucedido é aquele que mostra que um requisito foi adequadamente implementado. Teste de defeitos Testes projetados para descobrir defeitos de sistema; Um teste de defeitos bem sucedido é aquele que revela a presença de defeitos em um sistema; Abordado no Capítulo 23. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 11

12 Teste e debugging Teste e debugging e de defeitos são processos distintos. Verificação e validação está relacionada ao estabelecimento da existência de defeitos em um programa. Debugging está relacionado à localização e repararação desses defeitos. O debugging envolve a formulação de uma hipótese sobre o comportamento do programa e o teste dessas hipóteses para encontrar o defeito de sistema. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 12

13 O processo de debugging Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 13

14 Planejamento de V & V É necessário um planejamento cuidadoso para se obter o máximo dos processos de teste e de inspeção. O planejamento de V & V deve ser iniciado antecipadamente no projeto de desenvolvimento. O plano deve identificar o balanço entre a verificação estática e o teste. Planejamento de teste se ocupa em definir padrões para o processo de teste, não apenas em descrever testes de produtos. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 14

15 O modelo V de desenvolvimento Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 15

16 A estrutura de um plano de teste de software Processo de teste. Rastreabilidade de requisitos. Itens testados. Cronograma de testes. Procedimentos de registro de testes. Requisitos de hardware e de software. Restrições. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 16

17 O plano de teste de software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 17

18 Inspeções de software Envolvem pessoas que examinam uma representação original com o objetivo de descobrir anomalias e defeitos. Inspeções não requerem a execução de um sistema, por isso, podem ser usadas antes da implementação. Podem ser aplicadas em qualquer representação do sistema (requisitos, projeto, dados de configuração, dados de teste, etc.). Têm se mostrado uma técnica efetiva para descobrir erros de programa. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 18

19 Sucesso das inspeções Muitos defeitos diferentes podem ser descobertos em uma única inspeção. Em teste, um defeito pode mascarar um outro, por isso, várias execuções são necessárias. Domínio de reuso e conhecimento de programação de modo que os revisores têm maior probabilidade de já terem visto os tipos de erros que normalmente surgem. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 19

20 Inspeções e testes Inspeções e testes são complementares, e não técnicas de verificação opostas. Ambos devem ser usados durante o processo de V & V. Ass inspeções podem verificar a conformidade com uma especificação, mas não a conformidade com os requisitos reais do cliente. As inspeções não podem verificar características não funcionais, tais como desempenho, usabilidade, etc. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 20

21 Inspeções de programa Abordagem formalizada para revisões de documentos. Voltadas explicitamente para detecção de defeitos (não correção). Defeitos podem ser erros lógicos, anomalias no código que poderiam indicar uma condição errônea (por exemplo, uma variável não iniciada) ou não conformidade com padrões. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 21

22 Pré-condições para inspeção Uma especificação precisa deve estar disponível. Os membros da equipe devem estar familiarizados como os padrões organizacionais. O código sintaticamente correto ou outras representações de sistema devem estar disponíveis. Um checklist de erros deve ser preparado. A gerência deve aceitar que a inspeção aumentará os custos no início do processo de software. A gerência não deve usar inspeções para avaliar pessoal, isto é, descobrir quem cometeu erros. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 22

23 O processo de inspeção Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 23

24 Procedimento de inspeção Visão geral do sistema apresentado para a equipe de inspeção. Código e documentos associados são previamente distribuídos para a equipe de inspeção. A inspeção ocorre e os erros descobertos são anotados. Modificações são feitas para reparar os erros descobertos. Uma nova inspeção pode ou não ser necessária. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 24

25 Papéis da inspeção Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 25

26 Checklists de inspeção Um checklist de erros comuns deve ser usado para direcionar a inspeção. Checklists de erros são dependentes de linguagem de programação e refletem os erros característicos com maior probabilidade de surgimento na linguagem. Em geral, a verificação de tipo fraco é a maior parte do checklist. Exemplos: Iniciação, denominação de constantes, terminação de loops, limites de vetores, etc. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 26

27 Verificações de inspeção Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 27

28 Taxa de inspeção 500 declarações de código-fonte por hora durante a visão geral. 125 declarações de código fonte por hora durante a preparação individual. De 90 a 125 declarações por hora podem ser inspecionados durante a reunião de inspeção. A inspeção é, portanto, um processo dispendioso. A inspeção de 500 linhas custa aproximadamente 40 homem-hora de esforço 2800 em valores da Grã-Bretanha (UK). Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 28

29 Análise estática automatizada Analisadores estáticos são ferramentas de software para processamento de texto fonte. Eles varrem o texto do programa e tentam descobrir condições potencialmente errôneas e chamam a atenção da equipe de V & V. Eles são muito efetivos como um auxílio para as inspeções são um suplemento, mas não um substituto para as inspeções. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 29

30 Verificações de análise estática Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 30

31 Estágios da análise estática Análise de fluxo de controle. Verifica loops com múltiplos pontos de saídas ou de entrada, encontra código inacessível, etc. Análise de uso de dados. Detecta variáveis não iniciadas, variáveis escritas duas vezes sem uma tarefa de impedimento, variáveis que são declaradas mas nunca usadas, etc. Análise de interface. Verifica a consistência das declarações de rotina e procedimentos e seus usos. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 31

32 Estágios da análise estática Análise de fluxo de informação. Identifica as dependências das variáveis de entrada e de saída. Não detecta anomalias em si, mas destaca as informações para inspeção ou revisão de códigos. Análise de caminho. Identifica caminhos através do programa e estabelece as declarações executadas naquele caminho. Novamente, é potencialmente útil no processo de revisão. Ambos os estágios geram uma grande quantidade de informações, por isso, devem ser usados com cuidado. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 32

33 Análise estática com o Lint Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 33

34 Uso de análise estática Particularmente valiosa quando uma linguagem tal como C, que tem tipagem fraca, é usada e, por isso, muitos erros não são detectados pelo compilador. Menos adequado em custo para linguagens como Java, que têm verificação tipo forte e que pode, portanto, detectar muitos erros durante a compilação. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 34

35 Verificação e métodos formais Métodos formais podem ser usados quando uma especificação matemática do sistema é produzida. Eles são a técnica fundamental de verificação estática. Envolvem análise matemática detalhada da especificação, e podem desenvolver argumentos formais que um programa está em conformidade com a sua especificação matemática. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 35

36 Argumentos a favor dos métodos formais A produção de uma especificação matemática requer uma análise detalhada dos requisitos, por isso, a descoberta de erros é mais provável. Podem detectar erros de implementação antes do teste quando o programa é analisado em paralelo com a especificação. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 36

37 Argumentos contra os métodos formais Requerem notações especializadas que não podem ser compreendidas por especialistas de domínio. Desenvolver uma especificação é muito dispendioso, mas é mais dispendioso mostrar que um programa atende à essa especificação. Pode ser possível atingir o mesmo nível de confiança em um programa mais barato usando outras técnicas de V & V. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 37

38 Desenvolvimento de software Cleanroom O nome é derivado do processo Cleanroom na fabricação de semicondutores. A filosofia é prevenção ao invés de remoção de defeitos. Esse processo de desenvolvimento de software é baseado em: Desenvolvimento incremental; Especificação formal; Programação estruturada; Verificação estática usando argumentos de correção; Testes estatísticos para determinar a confiabilidade de programa. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 38

39 O processo Cleanroom Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 39

40 Características do processo Cleanroom Especificação formal usando um modelo de transição de estados. Desenvolvimento incremental onde o cliente prioriza os incrementos. Programação estruturada controle limitado e construções abstratas são usadas no programa. Verificação estática usando inspeções rigorosas. Testes estatísticos do sistema (abordados no Capítulo 24). Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 40

41 Especificação e inspeções formais O modelo de estado é uma especificação de sistema e o processo de inspeção verifica o programa em oposição a esse modelo. A abordagem de programação é definida de tal maneira que a correspondência entre o modelo e o sistema seja clara. Argumentos matemáticos (não provas) são usados para aumentar a confiança no processo de inspeção. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 41

42 Equipes de processo Cleanroom Equipe de especificação. É responsável pelo desenvolvimento e pela manutenção da especificação de sistema. Equipe de desenvolvimento. É responsável pelo desenvolvimento e pela verificação do software. O software NÃO é executado nem mesmo compilado 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 desenvolvimento. São modelos de crescimento de confiabilidade usados para determinar quando a confiabilidade é aceitável. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 42

43 Avaliação de processo Cleanroom Os resultados de uso do processo Cleanroom têm sido muito importantes, com poucos defeitos descobertos em sistemas entregues. Uma avaliação independente mostra que o processo não é mais dispendioso que outras abordagens. Havia menos erros do que em um processo tradicional de desenvolvimento. Contudo, o processo não é amplamente usado. Não está claro como essa abordagem pode ser transferida para um ambiente com engenheiros de software menos habilidosos ou menos motivados. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 43

44 Pontos-chave Verificação e validação não são a mesma coisa. A verificação mostra a conformidade com a especificação; já a validação mostra que o programa atende às necessidades do cliente. Planos de teste devem ser definidos para guiar o processo de teste. Técnicas de verificação estática envolvem o exame e a análise do programa para detecção de erros. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 44

45 Pontos-chave Inspeções de programa são eficientes para encontrar erros. Em inspeções, o código de programa é sistematicamente verificado por uma equipe pequena para localizar defeitos de software. Ferramentas de análise estática podem descobrir anomalias de programa que podem ser uma indicação de defeitos no código. O processo de desenvolvimento Cleanroom depende do desenvolvimento incremental, da verificação estática e dos testes estatísticos. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 45