Revisões de Software Parte 2

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

Agenda • 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

Revisão de Software • Visa assegurar que o produto produzido em uma fase possui qualidade suficiente para ser usado em outra fase. • Processo de Revisão: • Planejamento da Revisão • Detecção e Registro de Defeitos • Correção de Defeitos Tópicos Especiais - Qualidade de Software 2008/2

Abordagens para a Detecção de Erros • 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 • Inspeções Guiadas:”teste” de modelos de análise e projeto OO (McGregor e Sykes, 2001). Tópicos Especiais - Qualidade de Software 2008/2

Técnicas de Leitura de Software • Uma técnica de leitura de software é uma série de etapas ou heurísticas preparada para a análise individual de um artefato (ou conjunto de artefatos) que permite alcançar a compreensão necessária para uma determinada tarefa. • Técnicas de leitura aumentam a eficiência dos revisores individuais por fornecerem diretrizes a serem utilizadas durante a fase de detecção de defeitos. • Agregam melhores práticas para detecção de defeitos em um procedimento que pode ser seguido e repetido. (Travassos in (Rocha et al., 2001)) Tópicos Especiais - Qualidade de Software 2008/2

Técnicas de Leitura de Software • Leitura Baseada em Perspectiva (Perspective-Based Reading – PBR): revisão de requisitos (Shull et al., 2000). • Técnicas para Leitura de Projetos Orientados a Objetos (Object-Oriented Reading Techniques – OORT): projeto orientado a objetos, incluindo requisitos e diagramas da orientação a objetos (Travassos et al., 1999). Tópicos Especiais - Qualidade de Software 2008/2

Leitura Baseada em Perspectiva (PBR) • Revisão de Requisitos • Explora a observação da importância das informações nos requisitos para diferentes formas de utilização (perspectivas), tais como analistas, projetistas e testadores. • Cada um desses “usuários” da especificação de requisitos considera diferentes aspectos dos requisitos como importantes para seu trabalho. Tópicos Especiais - Qualidade de Software 2008/2

Leitura Baseada em Perspectiva (PBR) • Solicita-se a cada revisor o emprego de uma perspectiva distinta, relacionada a um dos potenciais usuários da especificação. • Usos principais de uma especificação de requisitos: • Como descrição das necessidades do cliente • Como base para o projeto do sistema • Como base para o projeto de casos de teste do sistema • Além de encontrar defeitos, visa criar representações que possam ser usadas como base para a criação futura de artefatos mais específicos e que possam revelar quão bem os requisitos conseguem apoiar as tarefas subseqüentes. Tópicos Especiais - Qualidade de Software 2008/2

Leitura Baseada em Perspectiva (PBR) • Para apoiar a detecção de defeitos, a PBR fornece um conjunto de questões para diferentes tipos de erros (omissão, fato incorreto, inconsistência, etc). Ex.: Questões sob ponto de vista do testador: • O requisito faz sentido levando em consideração o que você sabe sobre a aplicação ou o que está especificado na descrição geral? • Você tem todas as informações necessárias para identificar as entradas para o requisito? • Alguma entrada necessária foi omitida? • Há alguma entrada especificada que não é necessária para esse requisito? • O requisito está na seção apropriada do documento? Tópicos Especiais - Qualidade de Software 2008/2

Leitura Baseada em Perspectiva (PBR) • Quando a especificação de requisitos não provê informações suficientes para responder às questões, então ela também não é suficiente para apoiar os usuários de requisitos em suas tarefas e essa situação deve levar à criação de uma lista de defeitos. Tópicos Especiais - Qualidade de Software 2008/2

Leitura Baseada em Perspectiva (PBR) • Problemas com a PBR (Travassos in (Rocha et al., 2001)): • Não são oferecidos meios efetivos que facilitem a identificação da informação importante e a detecção de defeitos pelo revisor, propriamente dita. • Em um projeto OO, as abstrações das informações importantes já existem, sendo descritas por meio de diagramas e documentos (p. ex., diagramas de classes e dicionário de dados) Tópicos Especiais - Qualidade de Software 2008/2

Técnicas para Leitura de Projeto Orientado a Objetos (OORT) • OORT: Uma família de técnicas de leitura de projetos OO, destinada à identificação de defeitos. • Foco: verificação • Sete técnicas, organizadas em duas formas leitura, cada uma delas definidas para um conjunto de diagramas de projeto. • Leitura horizontal: verificação da consistência de artefatos produzidos em uma mesma fase. • Leitura vertical: verificação da consistência de artefatos produzidos em fases diferentes. Tópicos Especiais - Qualidade de Software 2008/2

Técnicas para Leitura de Projeto Orientado a Objetos (OORT) Especificação de requisitos Descrição dos requisitos Casos de uso Projeto de alto nível Diagrama de classes Descrição de classes Diagrama de estados Diagrama de interação Tópicos Especiais - Qualidade de Software 2008/2

Inspeções Guiadas • Equipe: desenvolvedores autores dos modelos, testadores e um membro do grupo de processo para atuar como moderador. • Moderador : responsável pelo planejamento, mediação da reunião e complementação do relatório final. • Planejamento: • Definição do escopo (conjunto de casos de uso) • Planejamento de tempo (cronograma) • Distribuição de materiais Tópicos Especiais - Qualidade de Software 2008/2

Inspeções Guiadas • Testadores: desenvolvem conjuntos de casos de teste a partir dos casos de uso que estão no escopo da inspeção. • Revisões são tratadas como uma sessão de testes, incluindo: • projeto de casos de teste, • estabelecimento de critérios de cobertura de testes, • “execução” (análise estática simulando a execução) de casos de teste e • avaliação da efetividade em relação à cobertura. Tópicos Especiais - Qualidade de Software 2008/2

Inspeções Guiadas • Um caso de teste consiste de: • Um conjunto de pré-condições • Entradas • Resposta esperada • Casos de teste construídos a partir de cenários de um caso de uso, estabelecendo valores para todos os atributos e objetos. • Cenários podem dar origem a múltiplos casos de uso, atribuindo-se diferentes valores para os objetos usados no caso de uso. • Considerar cursos normais, alternativos e de exceção. Tópicos Especiais - Qualidade de Software 2008/2

Inspeções Guiadas • Checklist: antes da sessão de inspeção interativa, os inspetores examinam os modelos para avaliar certas informações sintáticas, usando um checklist definido pela técnica. • Esta porção da técnica não tem foco no conteúdo, mas apenas na forma do modelo. Tópicos Especiais - Qualidade de Software 2008/2

Inspeções Guiadas • Algumas questões do checklist: • Todas as classes do modelo de análise que não estão no modelo de projeto estão fora do escopo da aplicação? • Todas as associações do modelo de projeto têm informação de navegabilidade? • Todo diagrama de seqüência é um subconjunto de um diagrama de atividades? • Todas as mensagens enviadas em um diagrama de interação aparecem como um método na interface pública da classe do objeto que recebe a mensagem? • Todas as transições de saída de um diagrama de estados são mutuamente exclusivas? Tópicos Especiais - Qualidade de Software 2008/2

Inspeções Guiadas • Realização de Sessão de Inspeção Interativa, envolvendo testadores e desenvolvedores. • Desenvolvedores cooperam para realizar uma execução simbólica que simula o processamento que ocorreria se um código real estivesse disponível. • Moderador controla a sessão, mantendo a sessão dentro de seu escopo e sem permitir a depuração. • Usualmente, um testador fica responsável por anotar os defeitos. Tópicos Especiais - Qualidade de Software 2008/2

Técnicas de Leitura de Artefatos de Análise e Projeto Orientados a Objetos • Técnicas para leitura de artefatos de análise e projeto orientados a objetos, tomando por base uma especificação de requisitos usando modelos de casos de uso. • Cinco técnicas de Leitura Horizontal • Seis técnicas de Leitura Vertical Tópicos Especiais - Qualidade de Software 2008/2

Documentação Necessária • Levantamento de Requisitos  Documento de Especificação de Requisitos, contendo: • Diagrama de Pacotes (opcional) • Diagramas de Casos de Uso • Descrições de Casos de Uso • Análise de Requisitos  Documento de Especificação de Análise, contendo: • Diagramas de Classes • Diagramas de Estados (opcional) • Diagramas de Seqüência (opcional) • Dicionário de Projeto descrevendo classes, atributos e operações Tópicos Especiais - Qualidade de Software 2008/2

Documentação Necessária • Projeto  Documento de Especificação de Análise, contendo: • Diagramas de Classes • Dicionário de Projeto descrevendo classes, atributos e operações Tópicos Especiais - Qualidade de Software 2008/2

Levantamento de Requisitos Descrições de Casos de Uso H1 Diagrama de Casos de Uso V4 Análise V1 V2 V3 H2 H3 Diagrama de Estados Diagrama de Seqüência Dicionário de Projeto Diagrama de Classes H4 V6 V5 Projeto Dicionário de Projeto Diagrama de Classes do Domínio do Problema H5 Técnicas de Leitura de Artefatos de Análise e Projeto Orientados a Objetos Tópicos Especiais - Qualidade de Software 2008/2

H1 – Descrições de Casos de Uso x Diagrama de Casos de Usos • Para cada caso de uso identificado em um diagrama de casos de uso deve haver uma descrição de caso de uso associada. • Os nomes dos casos de uso nos dois artefatos devem ser os mesmos. • As descrições dos casos de uso devem fazer menção aos atores envolvidos nos casos de uso e os atores identificados nos dois artefatos devem ser consistentes. • Quando um diagrama de casos de uso apontar uma associação entre casos de uso (inclusão, extensão etc), a descrição correspondente deve fazer menção explicitamente à realização do caso de uso associado. Tópicos Especiais - Qualidade de Software 2008/2

V1 – Descrições de Casos de Uso x Diagrama de Classes • As classes, associações, atributos e operações modelados no diagrama de classes devem ser necessários e suficientes para realizar cada um dos fluxos de eventos apontados em uma descrição de casos de uso. • Quando uma descrição de caso de uso fizer menção a dados claramente relacionados a uma classe no diagrama de classes, então a descrição do caso de uso deve ser consistente com os atributos modelados na correspondente classe do diagrama de classes. Tópicos Especiais - Qualidade de Software 2008/2

Referências • McGregor, J.D., Sykes, D.A., A Practical Guide to Testing Object-Oriented Software, Addison-Wesley, 2001. • Rocha, A.R.C., Maldonado, J.C., Weber, K.C., Qualidade de Software: Teoria e Prática, Prentice Hall, 2001. • Shull, F., Rus, I., Basili, V., How perspective based reading can improve requirements reading, IEEE Computer Society, 2000. • Travassos, G.H., Shull, F., Carver, J., Basili, V., Reading techniques for OO design inspections, 24th Annual Software Engineering Workshop, NASA/SEL, USA, 1999. Tópicos Especiais - Qualidade de Software 2008/2

Revisões de Software Parte 2