Inspeo

Sandra Fabbri

Prof. Dra. Sandra Fabbri

sfabbri@dc.ufscar.br

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br

Inspeo de Software

Definio
um mtodo de anlise esttica para verificar
propriedades de qualidade de produtos de
software.
Caractersticas:
processo estruturado e bem definido.
a equipe de inspeo consiste, normalmente, de
pessoal tcnico.
os participantes possuem papis bem definidos.
os resultados da inspeo so registrados.

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 2 de 39

Inspeo de Software
Como conduzir uma inspeo?
Artefato
Software

- Ad-hoc
Tcnicas de - Checklist
1 Plano Leitura - Leitura Baseada em Perspectiva

organizador Planejamento

2 Relatrio
de
inspetor Deteco defeitos

moderador
3 Relatrio
inspetores
Coleta/ de
Papis Anlise defeitos
autor
Atividades

Produtos 4 Relatrio Artefato

Inspeo correo Software
de Software autor Correo defeitos corrigido

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 3 de 39

 Benefcios da Inspeo:
deteco de defeitos antecipada
As inspees melhoram a qualidade desde o incio do projeto
detectando mais defeitos desde a fase de requisitos.
Sem inspeo Com inspeo
90 90

80 80

70 70

15 45 45
60 60

45
50 50
30
40 30 40
15

30 30
25 35
50 30
20 20 10 20 10
Defeitos:
30 30 Requisitos
25
10
15 15
10 10
5
10 5 Projeto
10 10
0
5
0
5 4
5
1 Cdigo
Req

Des

Code

Mod Test

Sys Test

Use
Req

Des

Code

Mod Test

Sys Test

Use

Req Proj Cod Teste Teste Uso Req Proj Cod Teste Teste Uso
Mod Sist Mod Sist
Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 4 de 39
Benefcios da Inspeo:
produtividade e custo
As inspees melhoram a produtividade uma vez
que os defeitos so encontrados quando so mais
fceis e mais baratos para corrigir.
35

30
de deteco de defeito
Normalized Cost for Defect Detection and Removal

25

20
Requirements
Design
Code
15
custo

10
Defeitos:
Requisitos
5
Projeto
0
Cdigo
Analysis Phase Design Phase Coding Module Testing System Testing System Use
Req Proj Cod Teste Mod. Teste Sist. Uso

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 5 de 39

Benefcios Qualitativos da Inspeo

Aprende-se pela experincia

participantes aprendem os padres e o raciocnio utilizado
na deteco de defeitos.
participantes aprendem bons padres de desenvolvimento.
A longo prazo
a inspeo convence os participantes a desenvolver
produtos mais compreensveis e mais fceis de manter.

As inspees ajudam integrar o processo de

preveno de defeitos com o processo de deteco
de defeitos.
Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 6 de 39
 Defeitos do Software
Os defeitos surgem quando o desenvolvimento no est de
acordo com a especificao j desenvolvida ou quando podem
causar problemas daquele ponto em diante.
Fase de Situao ideal:
Previous
desenvolvimento
Development Fase
Current Prxima
Next
anterior
Phase atual
Phase Fase
Phase 1. A informao transformada corretamente.
1 Tipos de Erros:
2
2. A informao perdida durante a
3 ?
5 transformao.
6
4 ? 3. A informao transformada incorretamente.
4. Informao extranha introduzida.
5. A mesma informao transformada em
diversas ocorrncias inconsistentes.
6. A mesma informao possibilita diversas
transformaes inconsistentes.

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 7 de 39

Defeito

Interpretao de defeito
defeito: qualquer propriedade de
qualidade que no seja satisfeita.
deve-se evitar focar apenas na corretitude,
como se fosse a nica propriedade de
qualidade.

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 8 de 39

Taxonomia de Erros
Definio: so as classes de defeitos que sero usadas para
classificar os defeitos encontrados.

Classes:
Omisso (O): qualquer informao necessria que tenha sido omitida.
Fato Incorreto (FI): informao que consta do artefato mas que seja
contraditria com o conhecimento que se tem do domnio de aplicao.
Inconsistncia (I): informao que consta do artefato mais de uma vez e em
cada ocorrncia ela descrita de forma diferente.
Ambiguidade (A): quando a informao pode levar a mltiplas interpretaes.
Informao Estranha (IE): qualquer informao que, embora relacionada ao
domnio, no necessria para o sistema em questo.
Miscelnea (M): qualquer outro tipo de defeito que no se encaixe nas outras
categorias. Ex: declaraes em sees erradas.

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 9 de 39

Exemplo: Omisso

Omisso de Funcionalidade:
Informao que descreva algum comportamento desejado
do sistema foi omitida do Documento de Requisitos (DR).

Ex: considere um sistema de biblioteca e os seguintes requisitos

funcionais (RF):
....
RF2: o sistema deve solicitar a informao necessria para
inserir um item bibliogrfico: ttulo, autor, data, lugar, assunto,
resumo, nmero, editor, peridico, congresso.
RF3: o sistema deve dar uma mensagem de alerta quando o
usurio tentar inserir um item imcompleto. Essa mensagem
deve questionar o usurio se ele deseja cancelar a operao,
completar a informao ou concluir a insero como est.
.....
Qual informao necessria para possibilitar uma insero incompleta?
Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 10 de 39
Exemplo: Omisso

Omisso de Desempenho:
Informao que descreva um desempenho
desejado para o sistema foi omitida ou descrita
de uma forma no apropriada para que possa ser
verificada posteriormente no teste de aceitao.
Ex: considere o seguinte Requisito No Funcional (RNF):

RNF1: o sistema deve fornecer os resultados to rpido quanto possvel.

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 11 de 39

Exemplo: Omisso

Outros tipos de omisso:

Omisso de Interface:
Quando informao que descreva como sitema proposto
vai fazer interface e se comunicar com outros objetos fora
de seu escopo for omitida do DR.

Omisso de Recursos do Ambiente:

Quando informao que descreva o hardware, software,
base de dados ou detalhes do ambiente operacional no qual
o sistema vai rodar for omitida do DR.

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 12 de 39

 Exemplo: Fato Incorreto

Informao que consta do artefato mas que

seja contraditria com o conhecimento que
se tem do domnio da aplicao.
Ex: considere um Sistema de Emprstimo numa Biblioteca e o seguinte RF:
....
RF30: o sistema no deve aceitar devoluo de livros se o usurio
no tiver a carteirinha da bilbioteca no momento.
...

para devoluo de livros no necessrio apresentar a carteirinha

pois todas as informaes esto registradas no sistema !
Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 13 de 39
 Exemplo: Inconsistncia

Informao que consta do artefato mais

de uma vez e, em cada ocorrncia, ela
descrita de forma diferente.
Ex: considere um Sistema de Emprstimo numa Biblioteca e o seguinte RF:
....
FR5: o sistema no deve permitir perodos de emprstimo maiores
que 15 dias.
....
FR9: professores podem emprestar livros por um perodo de 3
semanas.
.....

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 14 de 39

 Exemplo: Ambiguidade

quando a informao pode levar a mltiplas

interpretaes.

Ex: considere um Sistema de Emprstimo numa Biblioteca e o seguinte RF:

....
FR20: se o nmero de dias que o usurio est em atraso menor
que uma semana, ele deve pagar uma taxa de R$1,00; se o
nmero maior que uma semana, a taxa de R$0,50 por dia.

qual a taxa a ser paga se o perodo for de uma semana?

no primeiro caso, a taxa deve ser calculada por dia?

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 15 de 39

 Exemplo: Informao Estranha

qualquer informao que, embora

relacionada ao domnio, no necessria
para o sistema em questo.
Ex: considere um Sistema de Emprstimo numa Biblioteca e o seguinte RF:
....
RF15: quando um novo livro adicionado ao acervo, ele
permanece em uma prateleira especial por um perodo de um
ms.
....

essa informao no necessria para o sistema

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 16 de 39

Tcnicas de Leitura para Inspeo

Questo: Como detectar defeitos?

Resposta:
lendo o documento
entendendo o que o documento descreve
verificando as propriedades de qualidade
requeridas

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 17 de 39

Tcnicas de Leitura para Inspeo

Problema:
em geral no se sabe como fazer a leitura de um documento !
Razo:
em geral, os desenvolvedores aprender a escrever
documento de requisitos, cdigo, projeto, mas no
aprendem fazer uma leitura adequada dos mesmos.
Soluo:
fornecer tcnicas de leitura bem definidas.
Benefcios:
aumenta a relao custo/benefcio das inspees.
fornece modelos para escrever documentos com maior
qualidade.
reduz a influncia humana nos resultados da inspeo.
Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 18 de 39
Tcnicas de Leitura para Inspeo

O que uma tcnica de leitura?

um conjunto de instrues fornecido ao revisor
dizendo como ler e o que procurar no produto de
software.

Tcnicas de leitura para deteco de defeitos

em Documentos de Requisitos:
Ad-hoc
Checklist
Leitura Baseada em Perspectiva

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 19 de 39

Ad-hoc

Os revisores no utilizam nenhuma tcnica

sistemtica de leitura.
Cada revisor adota sua maneira de ler o
Documento de Requisitos
Desvantagens:
depende da experincia do revisor
no repetvel
no passvel de melhoria pois no existe um
procedimento a ser seguido.

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 20 de 39

 Checklist

Prof. Dra. Sandra Fabbri

sfabbri@dc.ufscar.br

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br

Checklist
Definio: uma tcnica que fornece
diretrizes para ajudar o revisor alcanar os
objetivos de uma atividade de reviso formal
que so:

verificar se o software est de acordo com os

seus requisitos.
assegurar que o software est representado de
acordo com padres pr definidos.
cobrir erros de funo, de lgica, de
implementao em qualquer representao
(artefato) de software.
Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 22 de 39
 Checklist

similar ao ad-hoc, mas cada revisor

recebe um checklist.
Os itens do checklist capturam lies
importantes que foram aprendidas em
inspees anteriores no ambiente de
desenvolvimento.
Itens do checklist podem explorar defeitos
caractersticos, priorizar defeitos diferentes e
estabelecer questes que ajudam o revisor a
encontrar defeitos.

de 39 Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 23

Checklist

pode ser desenvolvido para

documentos de requisitos, anlise,
projeto, cdigo e mesmo documentos
de teste.
requisitos anlise projeto cdigo teste

O projeto foi traduzido de forma apropriada para o cdigo?

Exemplo de Checklist
A linguagem foi utilizada de forma correta? para a fase de cdigo
Existem comentrios incorretos ou ambguos?
As declaraes e os tipos de dados esto corretos?
...........

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 24 de 39

Checklist
Questes Gerais:
Os objetivos do sistema foram definidos?
Os requisitos esto claros e no ambguos?
Foi fornecida uma viso geral da funcionalidade do
sistema?
Foi fornecida uma viso geral das formas de operao do
sistema?
O software e o hardware necessrios foram especificados?
Se existe alguma suposio que afete a implementao ela
foi declarada?
Para cada funo, os requisitos foram especificados em
termos de entrada, processamento e sada?
Todas as funes, dispositivos e restries esto
relacionadas aos objetivos do sistema e vice-versa?

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 25 de 39

Checklist
Omisso
de Funcionalidade
As funes descritas so suficientes para alcanar os objetivos do
sistema?
As entradas declaradas para as funes so suficientes para que
elas sejam executadas?
Foram considerados os eventos indesejveis e as respostas a eles
foram especificadas?
Foram considerados o estado inicial e os estados especiais (por
ex. inicializao do sistema, trmino anormal)?
de Desempenho
O sistema pode ser testado, analisado ou inspecionado para
mostrar que ele satisfaz seus requisitos?
Os tipos de dados, unidades, limites e resoluo foram
especificados?
A freqncia e volume de entrada e sada foram especificados
para cada funo?
Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 26 de 39
Checklist
Omisso
de Interface
As entradas e sadas para todas as interfaces so suficientes?
Foram especificados os requisitos de interface entre hardware,
software, pessoas e procedimentos?
de Recursos do Ambiente
Foram especificadas de forma apropriada as funcionalidades de
interao entre hardware, software com o sistema?
Informao Estranha
Todas as funes especificadas so necessrias para alcanar os
objetivos do sistema?
As entradas das funes so necessrias para execut-las?
As entradas e sadas das interfaces so necessrias?
As sadas produzidas por uma funo so usadas por outra
funo ou transferidas para a interface externa?
Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 27 de 39
Checklist

Ambiguidade
Cada requisito foi especificado de forma discreta,
no ambgua e testvel?
Todas as transies do sistema foram
especificadas de forma determinstica?
Inconsistncia
Os requisitos esto consistentes entre si?
Fato Incorreto
As funes especificadas so coerentes com o
sistema e com os objetivos a serem alcanados?

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 28 de 39

Leitura Baseada em
Perspectiva

Prof. Dra. Sandra Fabbri

sfabbri@dc.ufscar.br

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br

Leitura Baseada em Perspectiva

Definio: um conjunto de tcnicas de leitura que

focam em determinados pontos de vista.

Fazem com que cada revisor se torne responsvel

por uma perspectiva em particular.
Possibilita que o revisor melhore sua experincia em
diferentes aspectos do documento de requisitos.
Assegura que perspectivas importantes sejam
contempladas.

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 30 de 39

Leitura Baseada em Perspectiva

Cada revisor possui um cenrio para guiar

seu trabalho de reviso.

Todo cenrioconsiste de duas partes:

Construir um modelo do documento que est sob
reviso a fim de aumentar o entendimento sobre o
mesmo.
Responder questes sobre o modelo, tendo como
foco itens e problemas de interesse da
organizao.

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 31 de 39

Leitura Baseada em Perspectiva

Como composto o cenrio

Perspectivas sobre Itens/defeitos

o documento importantes para a
requerem organizao
modelos que dem
suporte a elas

Procedimento consistindo da construo do

modelo e das perguntas.

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 32 de 39

Leitura Baseada em Perspectiva

Cada revisor vai ler o Documento de

Requisitos com olhos diferentes
Benefcios:
determina uma responsabilidade especfica para
cada revisor.
melhora a cobertura de defeitos.

cobertura ad-hoc cobertura baseada em perspectiva

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 33 de 39
Leitura Baseada em Perspectiva

Considerando o Documento de Requisitos (DR),

quais as leituras interessantes?

Requisitos Projeto Cdigo Teste Uso

Documento
de Requisitos

o projetista que usa o DR para gerar o projeto do sistema.

o testador que, com base no DR deve gerar casos de teste
para testar o sistema quando este estiver implementado.
o usurio para verificar se o DR est capturando toda
funcionalidade que ele deseja para o sistema.

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 34 de 39

Leitura Baseada em Perspectiva -
Viso do Usurio
definir um conjunto de funes que o usurio esteja apto
a executar.
definir o conjunto de entradas necessrias para executar
cada funo e o conjunto de sadas que so geradas por
cada funo.
isso pode ser feito escrevendo todos os cenrios
operacionais que o sistema deve executar.
iniciar com os cenrios mais bvios at chegar nos
menos comuns ou condies especiais.
ao fazer isso, faa a voc mesmo as seguintes
perguntas:

sugesto: usar como modelo Caso de Uso

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 35 de 39
Leitura Baseada em Perspectiva -
Viso do Usurio
Questes:
todas as funes necessrias para escrever os cenrios esto
especificadas no documento de requisitos ou na especificao
funcional?
as condies iniciais para inicializar os cenrios esto claras e
corretas?
as interfaces entre as funes esto bem definidas e compatveis
(por ex., as entradas de uma funo tm ligao com as sadas da
funo anterior?)
voc consegue chegar num estado do sistema que deve ser
evitado (por ex., por razes de segurana)?
os cenrios podem fornecer diferentes respostas dependendo de
como a especificao interpretada?
a especificao funcional faz sentido de acordo com o que voc
conhece sobre essa aplicao ou sobre o que foi especificado em
uma descrio geral?
Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 36 de 39
Leitura Baseada em Perspectiva -
Viso do Testador
para cada especificao funcional ou requisito gere um
ou um conjunto de casos de teste que faa com que
voc se assegure de que a implementao do sistema
satisfaz a especificao funcional ou o requisito .
use a sua abordagem de teste normal e adicione
critrios de teste.
ao fazer isso, faa a voc mesmo as seguintes
perguntas para cada teste:

sugesto: usar como critrios de teste

Particionamento de Equivalncia, Anlise do Valor
Limite

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 37 de 39

Leitura Baseada em Perspectiva -
Viso do Testador
Questes:
voc tem toda informao necessria para identificar o item
a ser testado e o critrio de teste? Voc pode gerar um bom
caso de teste para cada item, baseando-se no critrio?
voc tem certeza de que os teste gerados fornecero os
valores corretos nas unidades corretas?
existe uma outra interpretao dos requisitos de forma que
o implementador possa estar se baseando nela?
existe um outro requisito para o qual voc poderia gerar um
caso de teste similar, mas que poderia levar a um resultado
contraditrio?
a especificao funcional ou de requisitos faz sentido de
acordo com aquilo que voc conhece sobre a aplicao ou
a partir daquilo que est descrito na especificao geral?

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 38 de 39

Bibliografia
(Basili et. al., 86) Basili, V.; Selby, Richard W.; Hutchens, David H.
Experimentation in Software Engineering. IEEE Transactions on Software
Engineering. n. 7, vol. SE-12 (1986), 733-743.

(Basili & Selby, 87) Basili, V.; Selby, Richard W. Comparing the Effectiveness of
Software Testing Strategies. IEEE Transactions on Software Engineering. n. 12,
vol. SE-13 (1987), 1278-1296.

(Basili et. al., 96) Basili, V.; Green, S.; Laitenberger, 0.; Lanubile, F.; Shull, F.;
Sorumgard, S.; Zelkowitz, M. The Empirical Investigation of Perspective-Based
Reading. Empirical Software Engineering: An International Journal. n. 2, vol. 1
(1996), 133-164.

(Kamsties & Lott, 95) Kamsties, E.; Lott, C. M. An empirical evaluation of three
defect-detection techniques. Technical Report ISERN-95-02, Universitt
Kaiserslautern, Postfach 3049, D-67653 Kaiserslautern, 1995.
www.cs.umd.edu/~mvz/mswe609/shull.pdf

Prof. Dra. Sandra Fabbri - sfabbri@dc.ufscar.br 39 de 39