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
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
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
3
Abordagens para a Detecção de Erros

Ad-hoc: Quando não se define nenhuma
orientação de como se proceder para encontrar
defeitos.



Uso de listas de verificação (checklists)



É a abordagem normalmente utilizada.
Muito dependente das habilidades e conhecimento dos
revisores.
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
4
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
5
Técnicas de Leitura de Software


Leitura Baseada em Perspectiva (PerspectiveBased 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
6
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
7
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
8
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
9
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
10
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
11
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
12
Técnicas para Leitura de Projeto
Orientado a Objetos (OORT)
Especificação
de requisitos
Descrição dos
requisitos
Projeto de
alto nível
Diagrama
de classes
Descrição
de classes
Casos
de uso
Diagrama
de estados
Diagrama
de interação
Tópicos Especiais - Qualidade de Software 2008/2
13
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
14
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
15
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
16
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
17
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
18
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
19
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
20
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
21
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
22
Técnicas de Leitura de Artefatos de
Análise e Projeto Orientados a Objetos
Levantamento de
Requisitos
Descrições de Casos
de Uso
H1
Diagrama de
Casos de Uso
V4
Análise
Dicionário de
Projeto
V1
H2
Diagrama de
Classes
V2
H3
V3
Diagrama de
Estados
Diagrama de
Seqüência
H4
Projeto
V6
Dicionário de
Projeto
V5
H5
Diagrama de Classes do
Domínio do Problema
Tópicos Especiais - Qualidade de Software 2008/2
23
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
24
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
25
Referências




McGregor, J.D., Sykes, D.A., A Practical Guide to
Testing Object-Oriented Software, AddisonWesley, 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
26