Revisões de Software Parte 1

Apresentação em tema: "Revisões de Software Parte 1"— Transcrição da apresentação:

1 Revisões de Software Parte 1
Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal do Espírito Santo

2 Tópicos Especiais - Qualidade de Software 2008/2
Agenda Verificação & Validação Revisões de Software Técnicas de Leitura de Software Técnicas de Leitura de Orientadas a Objetos Tópicos Especiais - Qualidade de Software 2008/2

3 Verificação e Validação
Documentação Gerência de Configuração de Software Qualidade de Software Verificação e Validação Tópicos Especiais - Qualidade de Software 2008/2

4 Tópicos Especiais - Qualidade de Software 2008/2
Verificação Visa assegurar que o produto de uma fase está de acordo com os requisitos especificados nas fases anteriores. Não busca assegurar que o produto está correto, mas averiguar se está de acordo com as especificações pré-estabelecidas. Em suma, a pergunta a ser feita é: Está-se desenvolvendo o produto corretamente? Tópicos Especiais - Qualidade de Software 2008/2

5 Tópicos Especiais - Qualidade de Software 2008/2
Validação Visa assegurar que o produto de uma fase é apropriado e consistente com as necessidades de clientes e usuários. A pergunta a ser feita é: Está-se desenvolvendo o produto correto? Tópicos Especiais - Qualidade de Software 2008/2

6 Terminologia - Padrão IEEE 610.12-1990
Defeito (fault): passo, processo ou definição de dados incorretos. Ex.: um comando incorreto. Engano (mistake): ação humana que produz um resultado incorreto. Ex.: ação incorreta tomada por um programador. Erro (error): diferença entre o valor obtido e o valor esperado. Qualquer estado intermediário incorreto ou resultado inesperado. Falha (failure): produção de uma saída incorreta com relação à especificação. Tópicos Especiais - Qualidade de Software 2008/2

7 Tópicos Especiais - Qualidade de Software 2008/2
Terminologia adotada Defeito: não faremos distinção entre os termos defeito, engano e erro. Todos serão tratados como defeito, que estará associado à causa de um comportamento incorreto. Falha: usaremos este termo para designar um comportamento incorreto, ou seja, a conseqüência. Tópicos Especiais - Qualidade de Software 2008/2

8 Análise Estática e Análise Dinâmica
Análise Estática: não envolve a execução propriamente dita do produto. Pode e deve ser aplicada em qualquer artefato intermediário. Ex.: Revisões técnicas, inspeção de código. Análise Dinâmica: envolve a execução do produto. Ex.: Testes. (Maldonado e Fabbri em (Rocha et al., 2001)). Tópicos Especiais - Qualidade de Software 2008/2

9 Tópicos Especiais - Qualidade de Software 2008/2
Revisão de Software Visa assegurar que o produto produzido em uma fase possui qualidade suficiente para ser usado em outra fase. Artefatos são revisados ao longo do processo de software garantir que a equipe está utilizando artefatos com a qualidade mínima especificada (Travassos in (Rocha et al., 2001)). Tópicos Especiais - Qualidade de Software 2008/2

10 Tópicos Especiais - Qualidade de Software 2008/2
Histórico Inicialmente, revisões de software foram aplicadas especificamente a código-fonte. Atualmente são aplicadas a diversos artefatos gerados ao longo do processo de software, com o intuito de encontrar defeitos. (Travassos in (Rocha et al., 2001)) Tópicos Especiais - Qualidade de Software 2008/2

11 Tipos de Defeitos Detectados em Revisões de Software
Omissão: informações relevantes sobre o sistema foram omitidas do artefato de software. Ex.: requisito não incluído, seções de documentos faltando, diagramas faltando, falta de descrições etc. Fato incorreto: informações no artefato contradizem informações presentes na especificação de requisitos (quando a mesma está correta) ou o conhecimento geral do domínio. Ex.: requisito incorreto, um diagrama de análise contendo uma representação incorreta de um conceito. (Travassos in (Rocha et al., 2001)) Tópicos Especiais - Qualidade de Software 2008/2

12 Tipos de Erros Detectados em Revisões de Software
Inconsistência: informações de uma parte do artefato estão inconsistentes com outras partes do mesmo artefato ou de outro artefato correlacionado. Ex.: requisitos conflitantes, diagramas inconsistentes. Ambigüidade: informações em um artefato podem ser interpretadas de diferentes maneiras. Ex.: descrição ambígua de requisitos, representação pouco expressiva em um diagrama. Informação estranha: informações desnecessárias e não utilizadas. Ex.: informações constantes em uma especificação de requisitos mas nunca usadas. (Travassos in (Rocha et al., 2001)) Tópicos Especiais - Qualidade de Software 2008/2

13 O Processo de Revisão de Software
Planejamento Definir quem vai revisar o artefato, quando, as técnicas de detecção a serem empregadas etc. Revisões individuais ou em equipe. Revisões em etapas. Preparação (opcional) O autor do artefato pode descrever o artefato e a perspectiva utilizada em sua construção para o(s) revisor(es). Revisão Individual Detecção de defeitos Registro de defeitos Tópicos Especiais - Qualidade de Software 2008/2

14 O Processo de Revisão de Software
Reunião (opcional) Produzir uma lista de defeitos. Pesquisas recentes revelam que reuniões de revisão não contribuem significativamente para aumentar o número de defeitos encontrados. Correção Com base na lista de defeitos, o autor do artefato deve corrigi-lo ou explicar os motivos que levam alguns deles a não representarem problemas reais. Tópicos Especiais - Qualidade de Software 2008/2

15 Abordagens para a Detecção de Defeitos
Ad-hoc: Quando não se define nenhuma orientação de como se proceder para encontrar defeitos. É a abordagem normalmente utilizada. Muito dependente das habilidades e conhecimento dos revisores. Uso de listas de verificação (checklists) Não provê uma abordagem sistemática para a detecção de defeitos, mas indica alguns defeitos recorrentes que devem ser verificados, normalmente identificados pela experiência da organização em revisões. Técnicas de Leitura de Software Tópicos Especiais - Qualidade de Software 2008/2