A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Revisões de Software Parte 2 Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal.

Apresentações semelhantes


Apresentação em tema: "Revisões de Software Parte 2 Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal."— Transcrição da apresentação:

1 Revisões de Software Parte 2 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/22 Agenda Revisões de Software Técnicas de Leitura de Software Técnicas de Leitura de Orientadas a Objetos

3 Tópicos Especiais - Qualidade de Software 2008/23 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

4 Tópicos Especiais - Qualidade de Software 2008/24 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).

5 Tópicos Especiais - Qualidade de Software 2008/25 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))

6 Tópicos Especiais - Qualidade de Software 2008/26 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).

7 Tópicos Especiais - Qualidade de Software 2008/27 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.

8 Tópicos Especiais - Qualidade de Software 2008/28 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.

9 Tópicos Especiais - Qualidade de Software 2008/29 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?

10 Tópicos Especiais - Qualidade de Software 2008/210 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.

11 Tópicos Especiais - Qualidade de Software 2008/211 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)

12 Tópicos Especiais - Qualidade de Software 2008/212 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.

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

14 Tópicos Especiais - Qualidade de Software 2008/214 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

15 Tópicos Especiais - Qualidade de Software 2008/215 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.

16 Tópicos Especiais - Qualidade de Software 2008/216 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.

17 Tópicos Especiais - Qualidade de Software 2008/217 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.

18 Tópicos Especiais - Qualidade de Software 2008/218 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?

19 Tópicos Especiais - Qualidade de Software 2008/219 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.

20 Tópicos Especiais - Qualidade de Software 2008/220 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

21 Tópicos Especiais - Qualidade de Software 2008/221 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

22 Tópicos Especiais - Qualidade de Software 2008/222 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

23 Tópicos Especiais - Qualidade de Software 2008/223 Técnicas de Leitura de Artefatos de Análise e Projeto Orientados a Objetos Diagrama de Casos de Uso Descrições de Casos de Uso Levantamento de Requisitos Análise Diagrama de Classes Dicionário de Projeto Diagrama de Seqüência Diagrama de Estados Projeto Diagrama de Classes do Domínio do Problema Dicionário de Projeto H1 H2H3 H4 H5 V1V2V3 V4 V5V6

24 Tópicos Especiais - Qualidade de Software 2008/224 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.

25 Tópicos Especiais - Qualidade de Software 2008/225 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.

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


Carregar ppt "Revisões de Software Parte 2 Ricardo de Almeida Falbo Tópicos Especiais – Qualidade de Software 2008/2 Departamento de Informática Universidade Federal."

Apresentações semelhantes


Anúncios Google