revisões de software parte 2 ricardo de almeida falbo tópicos especiais – qualidade de software...

Revisões de SoftwareParte 2

Ricardo de Almeida Falbo

Tópicos Especiais – Qualidade de Software 2008/2

Departamento de InformáticaUniversidade Federal do Espírito Santo

Tópicos Especiais - Qualidade de Software 2008/2 2

Agenda Revisões de Software Técnicas de Leitura de Software Técnicas de Leitura de Orientadas a Objetos


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


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é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é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).


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.



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.



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?



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.



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é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écnicas para Leitura de Projeto Orientado a Objetos (OORT)

Especificaçãode requisitos

Projeto dealto nível

Descrição dosrequisitos

Casos de uso

Diagramade classes

Descrição de classes

Diagramade estados

Diagramade interação


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


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.


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.


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.


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?


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é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


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


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é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

H2 H3

H4

H5

V1 V2 V3

V4

V5V6


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.


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.


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.

revisões de software parte 2 ricardo de almeida falbo tópicos especiais – qualidade de software...

Documents