Qualidade de software e garantia

(48) 3285 5615 / 9645 5506
contato@qualister.com.br

•  Terceirização de profissionais
•  Consultoria de teste Revisão
e
inspeção
de

•  Avaliação de usabilidade artefatos
(veriﬁcação)

•  Automação de testes
•  Testes de performance
•  Treinamentos

www.qualister.com.br

Quer saber mais?

Estes
são
apenas
alguns
slides
do
curso
de

revisão
e
inspeção
de
artefatos
(veriﬁcação)

oferecido
pela
Qualister.

Para
maiores
informações
visite
nosso
site:

h@p://www.qualister.com.br/cursos


Direitos autorais

Importante er
produção de qualqu
proibida a cópia e re
–  É resentação incluindo,
parte do conteúdo desta ap
, imagens, gráficos e
mas não limitado a, textos
é protegida pelas leis
tabela s. Esta apresentação no
opriedade de Cristia
de Copyright e são pr e Treinamento
Caetano e Qualister Consultoria
LTDA.

r, copiar, guardar em
–  Não é permitido modifica
ugar, vender ou
banco de dados público, al
apresentação,
republicar qualquer parte desta
o explícita do autor.
sem prévia permissã

o deste material,
–  Quando ho uver permissão de us e
bibliográfica conform
é ob rigatória a referência
as normas vigentes.


Instrutor

Cristiano Caetano
Email: cristiano.caetano@qualister.com.br
Apresentações: slideshare.net/cristianocaetano
Blog: cristianocaetano.wordpress.com
É certificado CBTS pela ALATS. Diretor técnico da Qualister com mais de 10 anos de experiência, já
trabalhou na área de qualidade e teste de software para grandes empresas como Zero G, DELL e HP
Invent. É colunista na área de Teste e Qualidade de software do site linhadecodigo.com.br e autor dos
livros "CVS: Controle de Versões e Desenvolvimento Colaborativo de Software" e "Automação e
Gerenciamento de Testes: Aumentando a Produtividade com as Principais Soluções Open Source e
Gratuitas". Participante ativo da comunidade de teste de software brasileira, é o criador e mantenedor
do portal TestExpert: A sua comunidade gratuita de teste e qualidade de software
(www.testexpert.com.br).


Twitter

twitter.com/c_caetano


Sobre a Qualister

•  Fundação: 2007.
•  Sobre a Qualister: A Qualister é uma empresa nacional, constituída a partir da união
de profissionais qualificados e certificados na área de testes e qualidade de software,
com o objetivo de integrar, implementar e implantar soluções com base nas melhores
práticas do mercado e normas internacionais.
•  Colaboradores: A Qualister é composta por colaboradores pós-graduados e
certificados na área de testes (CBTS, CSTE) com larga experiência na indústria de
Tecnologia da Informação.
•  Área de atuação: A Qualister é uma empresa especializada em serviços de
qualidade e teste de software. Tem como linhas de atuação consultoria em teste/
qualidade de software, outsourcing (terceirização dos serviços através da alocação
de profissionais) e treinamentos.


Parcerias internacionais

Soluções para automação, profilling e gestão de testes

Soluções para testes de performance

Soluções de apoio a avaliação de usabilidade


Tópico

• Introdução


Introdução

•  Qualidade de software
–  Q qualidade de software é a conformidade a requisitos funcionais e de desempenho
explicitamente declarados, a padrões de desenvolvimento claramente documentados e a
características implícitas que são esperadas de todo software profissionalmente desenvolvido
(PRESSMAN).

–  Esta definição enfatiza, três pontos chave: os requisitos de software, padrões especificados e
um conjunto de requisitos implícitos. Os requisitos de software são a base a partir da qual a
qualidade é medida. A falta de conformidade aos requisitos significa falta de qualidade. Em
resumo, a visão de Pressman pode ser enumerada da seguinte forma:

•  1. Os requisitos de software são a base a partir da qual a qualidade é medida. A falta de
conformidade aos requisitos significa falta de qualidade;
•  2. Padrões especificados definem um conjunto de critérios de desenvolvimento que
orientam a maneira segundo o qual o software passa pelo trabalho de engenharia. Se os
critérios não forem seguidos, o resultado quase que seguramente será a falta de
qualidade;
•  3. Há um conjunto de características implícitas que freqüentemente não são mencionadas
(usabilidade, manutebilidade, testabilidade, etc). Se o software se adequar a seus
requisitos explícitos, mas deixar de cumprir as suas características implícitas, a qualidade
do software será suspeita.


Introdução

•  Garantia de qualidade: (Qualidade do processo X Qualidade do produto)

Qualidade
do
processo
Qualidade
do
produto

• 
Foco:
garanFr
que
o
projeto
empresa
todos
os
• 
Foco:
descobrir
defeitos
em
produtos
de

processos
e
padrões
necessários
para
atender

trabalho
gerados
ao
longo
do
projeto
e
eliminar

aos
requisitos
suas
causas

• 
Forma
mais
usual:
auditorias
de
processo
e
de
• 
Forma
mais
usual:
testes
diversos
e
revisões

produto,
orientadas
por
checklists
por
pares
(simples,
inspeção,
walkthrough)

• 
UFliza
métodos,
procedimentos
e
padrões
• 
UFliza
casos
de
teste,
checklists
e
revisões

para
comparar
preciso
com
realizado
para
comparar
o
esperado
com
o
obFdo

• 
Assegurar
que
o
processo
empregado
é
• 
Assegurar
que
os
produtos
de
trabalho

deﬁnido
e
apropriado
gerados
estão
consistentes
e
alinhados

• 
É
orientada
a
processo,
visando
à
prevenção
• 
É
orientado
a
produto,
visando
à
detecção
e

de
defeitos
correção
de
defeitos

• 
Cuida
da
monitoração
e
melhoria
dos
• Cuida
da
monitoração
e
da
consistência
dos

processos
e
padrões
empregados
produtos
em
relação
aos
requisitos
e
à

• 
Assegura
que
se
faz
da
maneira
correta
(diz
o
uFlização

que
faz
e
faz
que
diz)
• 
Assegurar
que
se
faz
as
coisas
certas
(faz
certo

o
que
atende
a
necessidade
e
uso
pretendido)


Introdução

•  Garantia de qualidade: (Qualidade do processo X Qualidade do produto)

Qualidade
do
processo
Qualidade
do
produto

• ISO/IEC
12207
• ISO/IEC
9126

• CMMI
• ISO/IEC
14598

• MPS.BR
• Etc

• Etc


Introdução

•  Verificação X Validação

•  Verificação: avalia se o software desenvolvido é aderente
aos padrões previamente estabelecidos e está em
conformidade com os seus requisitos.
–  Estamos construindo o produto de maneira correta?

•  Validação: avalia se o software desenvolvido atende às
expectativas do cliente quando colocado no ambiente para
qual foi desenvolvido.
–  Estamos construindo o produto certo?


Introdução

•  Análise estática X Análise dinâmica

–  Análise estática, é uma técnica de verificação onde os artefatos são examinados
estaticamente, ou seja, o programa não é executado. Por este motivo podem ser
utilizadas em todas as fases do desenvolvimento do software. Porém essa técnica
não demonstra que o software é útil operacionalmente, já que não pode testar
algumas características do software como desempenho, confiabilidade, etc. Dentre
as técnicas de verificação existentes, as revisões são as técnicas mais conhecidas.

–  Análise dinâmica é uma técnica de validação que consiste em exercitar o
programa usando dados reais de entrada e avaliar se as saídas obtidas estão de
acordo com as saídas esperadas. Uma técnica dinâmica muito utilizada são os
testes de software que são essenciais para descoberta de defeitos que só podem
ser obtidas com a execução do programa.


Introdução

•  Propagação de defeitos entre as fases do ciclo de vida de
desenvolvimento
–  A partir dos diferentes modelos de ciclo de vida do software como
o cascata, o iterativo, o incremental, entre outros, é importante
entender a transição de uma atividade para outra, pois todos os
ambientes produzem um documento ao final de cada fase,
caracterizando o final de uma fase e o início da próxima. Cada
um desses documentos produzidos em cada fase representa o
software em um nível de abstração mais baixo, incluindo mais
e mais detalhes, até alcançar a representação do código fonte
na linguagem utilizada.


Introdução

•  Propagação de defeitos entre as fases do ciclo de vida de
desenvolvimento
–  Informação perdida durante a transformação
–  Informação transformada incorretamente
–  Informação estranha introduzida
–  Ocorrência de múltiplas transformações inconsistentes a partir de
uma mesma fonte de informação


Introdução

•  Retrabalho em projetos de desenvolvimento de software
–  O esforço gasto por organizações de software com retrabalho pode variar
em média entre 40% e 50% do esforço total do desenvolvimento de um
projeto. Uma estimativa da distribuição do retrabalho pelas atividades de
desenvolvimento de software está ilustrada na figura abaixo:

Distribuição do retrabalho pelas atividades de desenvolvimento de software.
Adaptado de (WHEELER et al., 1996).

Introdução

•  Custo relativo para a correção de um defeito
–  o custo do retrabalho para correção de defeitos aumenta na medida em que o processo de
desenvolvimento progride. Desta forma, iniciativas devem ser realizadas no sentido de
encontrar e corrigir defeitos tão logo sejam introduzidos. Uma abordagem que tem se mostrado
eficiente e de baixo custo para encontrar defeitos, reduzindo o retrabalho e melhorando a
qualidade dos produtos é a revisão dos artefatos produzidos ao longo do processo de
desenvolvimento de software.


Introdução

•  Revisões são filtros aplicados ao processo para evitar a propagação de
defeitos
–  Revisões e inspeções constituem “filtros” aplicados ao processo,
detectando erros e evitando sua propagação. À primeira vista, eles
podem parecer retardar o fluxo de desenvolvimento, porém na realidade
eles removem problemas que precisam ser tratados, que só seriam
evidenciados mais adiante e poderiam ser amplificados.


Introdução

•  O que é revisão?

–  São técnicas empregadas durante o processo de desenvolvimento de um
software.

–  Visam detectar antecipadamente falhas nos vários artefatos produzidos
durante o processo de desenvolvimento.

–  Segundo Wiegers, a implantação de processos de inspeção agregados
aos processos de desenvolvimento de software podem consumir de 5 a
15% do orçamento do projeto.

WIEGERS, Karl E., “Improve Quality Through Software Inspections”, 1999.

Introdução

•  Por que é necessário revisar um software?

–  Errar é humano.

–  É preciso garantir que os erros serão eliminados nas iniciais do ciclo de
vida de desenvolvimento de software

–  Aumentar a qualidade do produto.

–  Quando uma pessoa revisa o trabalho da outra a identificação das falhas
é muito maior.


Introdução

•  Distribuição das revisões nas fases do ciclo de vida de desenvolvimento
–  LAITENBERGER e DEBAUD demonstram que, conforme representado na
imagem abaixo, inspeções em código são as mais comuns. No entanto,
sabe-se que os benefícios de inspeções são maiores para os artefatos
produzidos no início do ciclo de desenvolvimento.

Laitenberger and J. Debaud, An encompassing life cycle-centric survey of software inspection,
Journal of Systems Software 50 (2000)

Introdução

•  O que pode ser revisado?

–  Muitos profissionais pensam que somente o código pode ser revisado. Na
verdade vários outros artefatos do processo de desenvolvimento devem
ser revisados

–  Por exemplo:
•  Especificações de Requisitos.
•  Modelos da Análise.
•  Modelos de Processos.
•  Regras de Negócio.
•  Casos de Teste
•  Códigos
•  Documentos do Projeto e Arquitetura


Introdução

•  Tipos de defeitos encontrados nos artefatos
Defeito
Descrição

Fato
incorreto
Algumas
informações
no
artefato
de
soaware

contradizem
as

informações
presentes
na
especiﬁcação
de
requisitos
ou
o

conhecimento
geral
do
domínio

Omissão
As
informações
necessárias
sobre
o
sistema
foram
omiFdos
do

artefato
de
soaware.

Inconsistência

As
informações
em
uma
parte
do
artefato
de
soaware
estão

inconsistentes
com
outras
partes
no
artefato
de
soawares.

Ambigüidade

As
informações
no
artefato
de
soaware
são
ambíguas,
isto
é,
é

possível
ao
desenvolvedor
interpretar
as
informações
de
diferentes

maneiras,
podendo
não
levar
a
uma
implementação
correta.

Informação
estranha
As
informações
são
fornecidas,
mas
não
são
necessárias
ou
mesmo

usadas.

Adaptado de IEEE (IEEE 830, 1998)

Introdução

•  Benefícios da revisão
–  A revisão auxilia a detectar os problemas do produto no início do ciclo de
desenvolvimento do software, evitando o alto custo de retrabalho na
manutenção do sistema (BOEHM, 2001).
–  Visão antecipada e melhor dos riscos e questões de qualidade do projeto.
–  Os inspetores identificam a causa dos defeitos detectados na raiz,
propondo modificações no processo de desenvolvimento do software e
prevenindo a ocorrência de defeitos similares em projetos futuros
(DOOLAN, 1992).
–  Certeza que os requisitos corretos estão sendo implementados.


Introdução

•  Resultados diretos de uma revisão
–  Uma revisão tem o objetivo de assegurar que:
•  O artefato satisfaz as especificações funcionais e atributos de
qualidade;
•  O artefato atende às necessidades do cliente;
•  O artefato está dentro dos padrões especificados;
•  O artefato cumpre com as regulamentações, regras, políticas,
planejamentos e procedimentos, identificando os possíveis
desvios.

WIEGERS, Karl E., “Improve Quality Through Software Inspections”, 1999.

Introdução

•  Revisão X Inspeção

•  Inspeções são um tipo de revisão.

•  Uma revisão (também chamada de revisão técnica (Technical review))
é uma leitura crítica de um artefato, onde:
–  Nem sempre é necessário um plano formal
–  Nem sempre e necessário o uso de regras de leitura pré-definidas
–  Nem sempre é necessário uma pequena equipe com papéis pré-definidos
–  Nem sempre os defeitos, dúvidas e melhorias são formalmente registrados

•  Uma inspeção é uma leitura crítica formal de um artefato, onde:
–  É realizada de acordo com um plano formal
–  A inspeção obedece regras de leitura pré-definidas
–  Envolve uma pequena equipe com papéis pré-definidos
–  Os defeitos, dúvidas e melhorias são formalmente registrados
–  Os registros de defeitos geram métricas e indicadores para a melhoria do produto e processo


Introdução

•  Eficiência das revisões

Técnica
Eﬁciência
(%
defeitos
detectados)

Revisões
informais
de
arquitetura
25%
a
40%

Inspeções
formais
de
arquitetura
45%
a
65%

Revisões
informais
de
código
20%
a
35%

Inspeções
formais
de
código
45%
a
70%

Caper Jones, Software Defect-Removal Efficiency. IEEE Computer, march 1996

Introdução

•  Contras
–  Freqüentemente a qualidade da revisão depende da
habilidade e comprometimento dos revisores

–  Em alguns casos a qualidade dos Checklists determina
a qualidade da revisão


Introdução

•  Modelos de maturidade

Nível
2:
GaranFa
de
qualidade
Nível
F:
GaranFa
de
qualidade

Nível
3:
Validação
e
Veriﬁcação
Nível
D:
Validação
e
Veriﬁcação


Introdução

•  MPS.BR: Processo de Verificação
–  Resultados esperados
•  VER1 - Produtos de trabalho a serem verificados são identificados
•  VER2 - Uma estratégia de verificação é desenvolvida e implementada,
estabelecendo cronograma, revisores envolvidos, métodos para
verificação e qualquer material a ser utilizado na verificação
•  VER3 - Critérios e procedimentos para verificação dos produtos de
trabalho a serem verificados são identificados e um ambiente para
verificação é estabelecido
•  VER4 - Atividades de verificação, incluindo inspeções e revisões por
pares, são executadas
•  VER5 - Defeitos são identificados e registrados
•  VER6 - Resultados de atividades de verificação são analisados e
disponibilizados para as partes interessadas


Tópico

• Tipos de revisão


Tipos de revisão

•  Aspectos usados para classificar e caracterizar os
tipos de revisão:
–  Formalidade
•  Técnicas sistemáticas (formal): o avaliador recebe um
treinamento de como ler o artefato que será avaliado, definindo
um procedimento formal no processo de revisão.
•  Técnicas não sistemáticas (informal): o avaliador não
recebe nenhum treinamento ou diretriz sobre como ler o
artefato a ser inspecionado, não possuindo um procedimento
claro a ser seguido na revisão.


Tipos de revisão

tipos de revisão:
–  Foco
•  Técnicas específicas: os avaliadores procuram tipos
específicos de defeitos.
•  Técnicas gerais: os avaliadores procuram por qualquer tipo de
defeitos.


Tipos de revisão

tipos de revisão:
–  Responsabilidade
•  Técnicas distintas: cada avaliador tem a sua
responsabilidade, sendo que a sobreposição de
responsabilidades é pouca ou nula.
•  Técnicas idênticas: não há divisão das responsabilidades
entre os avaliadores que participam da revisão, todos têm as
mesmas responsabilidades.


Tipos de revisão

•  Classificação das tipos de revisões
–  Dependendo da formalidade da revisão podemos classificar as
principais técnicas de revisão segundo a figura a abaixo (Wiegers,
2002).

Mais Menos
Formal Formal

Inspeção Revisão Walkthrough Pair Deskcheck Revisão Ad hoc
em Time Programming


Tipos de revisão

•  Inspeção
–  Inspeção é uma técnica desenvolvida por Fagan em 1972, enquanto
desenvolvia seu trabalho na IBM, e foi criada visando aumentar a
qualidade de software e aumentar a produtividade dos programadores.
Esta técnica inicialmente centrou foco na localização de defeitos na
estrutura e no código de programas.

–  Posteriormente ampliada para aplicação em outros artefatos de
software (como requisitos, especificações, arquitetura, planos de teste), A
literatura aponta que o processo de inspeção pode detectar de 30% a
90% dos erros existentes nos artefatos gerados num processo de
desenvolvimento de software

–  O processo de inspeção caracteriza-se pela utilização de uma técnica
de leitura aplicável a um artefato, buscando a localização de erros ou
defeitos no mesmo, segundo um critério pré-estabelecido.


Tipos de revisão

•  Inspeção
–  É realizado em seis etapas consecutivas: Planejamento, Visão
Geral, Preparação, Reunião de Inspeção, Retrabalho e Revisão;

–  Compreende a definição de uma equipe de inspeção para verificar
o artefato, que é composta pelo moderador, relator, inspetor e
autor, etc;

–  Os participantes que irão inspecionar o produto têm suas funções
bem definidas durante o processo, cada qual cumprindo a sua
tarefa;

–  O resultado final é gerar um documento do que foi obtido na
inspeção individual e nas discussões das reuniões das equipes.


Tipos de revisão

•  Inspeção
–  O processo de inspeção compreende várias etapas, iniciando pela coleta dos artefatos a serem utilizados e/ou
analisados, passando pela inspeção propriamente dita e chegando ao acompanhamento da correção dos defeitos
encontrados. Os participantes desempenham diferentes papéis, dependendo da etapa em desenvolvimento, e também
do grau de conhecimento e envolvimento no projeto.

Planeja
Apresen Prepara
Reunião
Retrabalho
Revisão

mento
tação
ção

•  Organizador

•  Moderador
Processo •  A serem
inspecionados
•  Autor de Artefato
Papéis Inspeção
Artefatos •  Para
•  Inspetor conduzirem a
inspeção
•  Secretário/Relator Técnicas de Leitura
•  Leitura Ad-hoc
•  Leitura Baseada em Checklists
•  Leituras baseadas em defeitos (DBR - Defect-Based Reading)
•  Leituras Baseadas em Perspectivas (PBR - Perspective-Based Reading)
•  Leituras baseadas em orientação a objetos (OORT’s -Object-Oriented Reading
Techniques)

Laitenberger, Oliver e DeBaud, Jean-Marc. An Encompassing Life Cycle Centric Survey of Software
www.qualister.com.br Inspection. The Journal of Systems and Software, vol 50, 2000

Tipos de revisão

•  Inspeção (processo)


Tipos de revisão

•  Inspeção (processo)
–  FAGAN (1976) desenvolveu o processo tradicional de inspeção de software, uma forma
detalhada de se realizar uma revisão. Neste processo, existem seis atividades principais:
•  Planejamento. Um usuário, desempenhando o papel de organizador da inspeção, define o contexto da
inspeção (descrição da inspeção, técnica a ser utilizada na detecção de defeitos, artefato a ser
inspecionado, autor do documento, entre outros), seleciona os inspetores e distribui o material a ser
inspecionado.
•  Apresentação (Visão geral). Os autores dos artefatos a serem inspecionados apresentam as
características destes. Esta fase pode ser omitida se os inspetores possuem conhecimento sobre o
projeto e os artefatos que devem ser inspecionados.
•  Preparação. Os inspetores estudam os artefatos individualmente, e eventualmente fazem anotações
sobre estes produzindo uma lista de discrepâncias. O uso de técnicas de leitura pode facilitar a execução
desta tarefa.
•  Reunião de inspeção. Uma reunião em equipe ocorre, envolvendo o moderador, os inspetores e os
autores do artefato. Discrepâncias são discutidas, e classificadas como defeito ou falso positivos. A
decisão final sobre a classificação de uma discrepância sendo discutida é do moderador. A solução dos
defeitos não é discutida durante a reunião, que não deve exceder duas horas, uma vez que após este
tempo a concentração e a capacidade de análise dos inspetores costuma reduzir drasticamente.
•  Retrabalho. Nesta etapa, os defeitos detectados, devidamente documentados, são encaminhados ao
autor do produto que foi inspecionado, para que seja providenciada a remoção destes defeitos.
•  Revisão. O material corrigido pelos autores é repassado para o moderador, que faz uma análise da
inspeção como um todo e re-avalia a qualidade do artefato inspecionado. Ele tem a liberdade de decidir
se uma nova inspeção deve ocorrer ou não.


Tipos de revisão

•  Inspeção (papéis)
–  No processo de inspeção existem diferentes papéis a serem
desempenhados pelos participantes:
•  O organizador é aquele que se responsabiliza pela organização e
condução do processo como um todo, coletando documentos e
informações necessárias, selecionando os participantes de acordo com
seu perfil, distribuindo os papéis, agendando encontros e acompanhando
a correção dos defeitos.
•  O moderador conduz a reunião de inspeção, e deve ter experiência na
condução de trabalhos em equipe e mediar e resolver eventuais conflitos.
•  O autor do artefato apresenta uma visão global do mesmo, antes da
inspeção ser efetuada.
•  O inspetor analisa os artefatos, seguindo uma técnica de leitura pré-
definida, anotando os defeitos encontrados e repassando-os ao secretário.
•  O secretário/relator reúne os defeitos encontrados pelos vários
inspetores, consolida-os num documento e os repassa ao moderador.


Tipos de revisão

•  Inspeção (artefatos)
–  Artefatos para serem inspecionados
•  Qualquer artefato (produto de trabalho) produzido ao longo do ciclo de
vida de desenvolvimento de software

–  Artefatos para conduzir a inspeção
•  Checklists de apoio a leitura
•  Padrões, políticas, diretrizes e procedimentos aplicáveis
•  Relatórios contendo o relato dos defeitos e divergências encontradas


Tipos de revisão

•  Inspeção (técnicas de leitura)
–  As técnicas de leitura, são um conjunto concreto de instruções dadas ao
leitor de como ler e o que olhar em um produto de software.

–  Os inspetores aplicam as técnicas ao ler o documento, como por exemplo,
no documento de requisitos ou de código, com o propósito de encontrar
defeitos. Essas técnicas, o termo “leitura” é usado para enfatizar as
semelhanças com os processos mentais, para tentar entender
suficientemente qualquer texto.

–  O objetivo das técnicas de leitura é criar um procedimento formal (ou um
guia) a ser seguido pelo revisor auxiliando o processo de revisão.

–  Técnicas de leitura em documentos foram elaboradas de forma a
maximizar a descoberta de defeitos.


Tipos de revisão

–  Tipos de técnicas de leitura
•  Leitura Ad-hoc
•  Leitura Baseada em Checklists
•  Leitura Baseada em Cenários
–  Leituras Baseadas em Defeitos (DBR - Defect-Based Reading)
–  Leituras Baseadas em Perspectivas (PBR - Perspective-Based Reading)
•  Leituras baseadas em Orientação a objetos (OORT’s -Object-
Oriented Reading Techniques)


Tipos de revisão

–  Leitura Ad-hoc
•  Leitura Ad Hoc é amplamente usada na prática. Os inspetores não
são orientados e assim, a descoberta de defeitos depende da sorte e/
ou da experiência/esforço do inspetor.

•  A leitura Ad Hoc é classificada como não sistemática (os inspetores
não recebem nenhuma orientação), geral (os inspetores devem
conferir todos os aspectos do documento) e idêntica (não existe
divisão de responsabilidades).


Tipos de revisão

•  As qualidades a serem satisfeitas num documento de requisitos e que podem
ser verificadas por esta técnica de leitura são:
–  Clareza (os requisitos estão bem determinados?)
–  Completude (estão presentes todos os requisitos necessários à
especificação do sistema?)
–  Consistência (os requisitos são consistentes com a visão geral do
sistema?)
–  Corretude (os requisitos descrevem as funcionalidades de maneira
correta?)
–  Funcionalidade (as funcionalidades descritas são necessárias e
suficientes para atingir os objetivos do sistema?)
–  Testabilidade (as funcionalidades permitem a verificação ou teste de
forma a mostrar que os requisitos são satisfeitos?)
–  Detalhamento (o nível de detalhe nos requisitos é suficiente para
fornecer uma base adequada ao desenho do sistema?)


Tipos de revisão

•  Desvantagens:
–  O número de defeitos encontrados fica dependente
exclusivamente da habilidade e experiência do inspetor
–  O resultado da inspeção pode variar bastante entre os inspetores
–  Os revisores não aprendem uns com os outros
–  O procedimento não é documentado, nenhum conhecimento é
transferido entre os inspetores e nem de uma inspeção para outra


Tipos de revisão

–  Leitura Baseada em Checklists
•  Na técnica de leitura baseada em checklists, já consolidada na
indústria, o conjunto de inspetores utiliza uma mesma lista para a
leitura e análise do artefato. Esta lista relaciona os itens a serem
verificados e o que deve ser entendido como defeito. Para cada
tipo de artefato há uma lista específica (Documento de Requisitos,
Cenários, Plano de Testes, Casos de Teste, Código, ...).

•  Essas listas são adaptáveis, e podem levar em consideração os
defeitos de maior ocorrência nos sistemas desenvolvidos
naquele ambiente. Um dos efeitos colaterais desta abordagem é que,
com o uso freqüente de inspeções,defeitos de tipos não
caracterizados no checklist não serão detectados.


Tipos de revisão

•  Esta técnica de inspeção, quando aplicada a artefatos de requisitos, pode
detectar os seguintes tipos de defeitos:
–  sintaxe incorreta nos artefatos (as sentenças/termos não seguem a
sintaxe estabelecida)
–  informação inconsistente entre artefatos (símbolos definidos num artefato
e não referido em outros; símbolos utilizados mas não definidos;
descrição não condizente com o símbolo; sinônimos incorretos)
–  requisitos não funcionais não explicitados
–  informação ambígua (símbolos, termos ou sentenças que possam
provocar diferentes interpretações)
–  informação desnecessária (atores e/ou recursos em excesso nos
cenários)
–  ausência de informação (pré-condições, atores e recursos necessários
nos cenários)
–  exceções não previstas


Tipos de revisão

•  Desvantagens:
–  Para que o checklist não seja muito específico, as perguntas
devem ser muito genéricas o que acaba abrindo margem para
interpretações

–  Os checklists tendem a ser muito longos o que torna o processo
tedioso e demorado

–  Todos os integrantes da equipe usam o mesmo checklist.


Tipos de revisão

–  Tipos de técnicas de leitura
•  Leitura Baseada em Cenários
–  Leituras Baseadas em Defeitos (DBR - Defect-Based
Reading)
–  Leituras Baseadas em Perspectivas (PBR - Perspective-
Based Reading)


Tipos de revisão

–  Leituras baseadas em defeitos (DBR - Defect-Based
Reading)

•  A leitura baseada em defeitos concentra-se em detectar classes
específicas de defeitos. A principal idéia da leitura baseada em defeito
é que diferentes revisores focalizam diferentes classes de defeito
enquanto examinam o mesmo artefato.

•  Para cada classe de defeito, há um cenário que consiste em um
conjunto de perguntas que um revisor deve responder enquanto lê. Ao
responder as perguntas, o revisor deve estar detectando defeitos
daquela classe em particular.


Tipos de revisão

–  Leituras Baseadas em Perspectivas (PBR - Perspective-Based
Reading)
•  A técnica de leitura baseada em perspectiva foi elaborada para a detecção de
defeitos em documentos de requisitos escritos em linguagem natural (existem
variações que permitem a revisão de código fonte).

•  Um documento de requisitos bem escrito deve ser capaz de apoiar os
diferentes usos que este pode ter: servir de base para o desenvolvimento
do projeto do sistema, permitir a criação de casos de teste apropriados
às funcionalidades envolvidas e garantir que o sistema como um todo
tenha as funcionalidades esperadas pelos clientes e usuários. Assim,
identificaríamos três diferentes “consumidores” deste artefato: projetistas,
testadores e usuários do sistema.

Requisitos
Projeto
Código
Testes
Uso

Documento
de

Requisitos


Tipos de revisão

Reading)
•  Nesse sentido, a técnica de leitura baseada em perspectivas assegura que
cada revisor avaliará o requisito segundo uma dessas perspectivas ao criar
um modelo físico com base nos requisitos.

•  A combinação de diferentes perspectivas resulta em uma melhor cobertura do
documento, sendo que uma inspeção baseada em perspectivas permite
certificar que os requisitos tenham qualidade suficiente para apoiar todos os
estágios posteriores necessários do desenvolvimento do software

•  O objetivo não é duplicar o trabalho realizado em outros pontos do ciclo de
desenvolvimento do software, mas 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
seguintes.


Tipos de revisão

Reading)
•  A versão atual da técnica de leitura baseada em perspectivas
para documentos de requisitos define três perspectivas:
–  a) a perspectiva do usuário que exige que o inspetor desenvolva
casos de uso para representar a utilização do sistema;
–  b) a perspectiva do projetista que exige que o inspetor construa
um diagramas de projeto;
–  c) a perspectiva do testador que exige que o inspetor construa
casos de teste.

–  Pode-se classificar a técnica de leitura baseada em perspectivas como sistemática
(porque uma perspectiva orienta o inspetor com respeito a como e onde procurar
defeitos), específica (porque o inspetor concentra-se em certos tipos de defeitos) e
distinta (porque os inspetores com a equipe de inspeção têm responsabilidades
distintas).


Tipos de revisão

Reading)
•  A técnica de leitura baseada em perspectivas consiste em três partes
principais: introdução, instruções e perguntas:
–  A introdução é um resumo que explica como o inspetor deverá usar a
técnica de leitura.
–  As instruções informam o inspetor como ele deve extrair a informação do
documento de requisitos. O inspetor deve construir um modelo físico do
sistema. Por exemplo, a perspectiva do testador orienta o inspetor na
criação de casos de testes para o documento de requisitos. Dessa forma,
os inspetores ganham um entendimento mais profundo do sistema e,
além disso, asseguram que eles estão bem preparados para as próximas
atividades.
–  As perguntas representam um questionário altamente especializado. O
questionário focaliza a atenção do inspetor para aspectos específicos do
seu trabalho, auxiliando a descobrir os defeitos.


Tipos de revisão

Reading)
•  Exemplos de perguntas usadas na perspectiva do usuário:
–  Todas as funções necessárias para escrever os cenários estão
especificadas no documento de requisitos ou na especificação funcional?
–  As condições para inicializar os cenários estão claras e corretas?
–  As interfaces entre as funções estão bem definidas e compatíveis (por ex.,
as entradas de uma função) têm ligação com as saídas da função
anterior?
–  Você consegue chegar num estado do sistema que deve ser evitado (por
ex., por razões de segurança)?
–  Os cenários podem fornecer diferentes respostas dependendo de como a
especificação é interpretada?
–  A especificação funcional faz sentido de acordo com o que você conhece
sobre essa aplicação ou sobre o que foi especificado em uma descrição
geral?


Tipos de revisão

Reading)
•  Exemplos de perguntas usadas na perspectiva do testador:
–  Você tem toda informação necessária para identificar o item a ser testado
e o critério de teste?
–  Você pode gerar um bom caso de teste para cada item, baseando-se no
critério?
–  Você tem certeza de que os testes gerados fornecerão os valores corretos
nas unidades corretas?
–  Existe outra interpretação dos requisitos de forma que o programador
possa estar se baseando nela?
–  Existe outro requisito para o qual você poderia gerar um caso de teste
similar, mas que poderia levar a um resultado contraditório?
–  A especificação funcional ou de requisitos faz sentido de acordo com
aquilo que você conhece sobre a aplicação ou a partir daquilo que está
descrito na especificação geral?


Tipos de revisão

Reading)
•  Exemplos de perguntas usadas na perspectiva do projetista/desenvolvedor:
–  O requisito foi adequadamente traduzido em diagramas de projeto?
–  O modelo de dados reflete adequadamente os requisitos, seus atributos e relações?
–  A manutenibilidade foi levada em consideração?
–  São definidas interfaces para os módulos e para os elementos de sistema externos?
–  O projeto foi adequadamente traduzido em código?
–  Há erros de ortografia ou tipográficos no código?
–  As convenções da linguagem foram adequadamente utilizadas?
–  Existe concordância em relação aos padrões de codificação quanto ao estilo da
linguagem, comentários e cabeçalho de cada código fonte?
–  Há comentários incorretos ou ambíguos?
–  Os tipos de dados das variáveis são apropriados?
–  As constantes estão corretas?


Tipos de revisão

–  Leituras baseadas em orientação a objetos (OORT’s -Object-
Oriented Reading Techniques)
•  As leituras baseadas em orientação a objetos representa uma
família de técnicas de leitura que fornecem um procedimento
para as revisões individuais dos diferentes diagramas e
documentos de projetos OO.

•  O processo de leitura baseada em orientação a objetos é
realizado em duas dimensões: leitura horizontal e vertical.
Na leitura horizontal, diferentes diagramas de arquitetura são
revisados para assegurar que estejam consistentes entre si. Na
leitura vertical, é necessária a revisão dos documentos de
especificação de requisitos em relação aos diagramas de
arquitetura para assegurar que estejam consistentes entre si.


Tipos de revisão

–  Leitura Vertical:
•  Quando lemos de um documento de mais alto nível como referência e o
comparamos com um documento de mais baixo nível. Artefatos de níveis de
abstração diferentes devem descrever o mesmo sistema


Tipos de revisão

–  Leitura Horizontal:
•  Quando lemos de um documento do mesmo nível como referência e o
comparamos com um documento também do mesmo nível. Assegurar que os
artefatos de um mesmo nível de abstração representem o mesmo sistema e
são consistentes entre si.


Tipos de revisão

–  Leitura vertical e horizontal
Artefatos
inspecionados
Tipo
ObjeAvo

Verificar
se
um
diagrama
de
classes
para
um
sistema
descreve
as
classes
e
seus

relacionamentos
de
forma
que
is
comportamentos
especificados
no
diagramas
de

seqüência
estão
capturados
corretamente.

Diagramas

de
Seqüência
x
Classe
Horizontal
Para
fazer
isso,
primeiramente
deve-‐se
verificar
se
as
classes
e
objetos
especificados
no

diagrama
de
seqüência
aparecem
no
diagrama
de
classe.
Assim,
será
verificado
se
o

diagrama
de
classes
descreve
os
relacionamentos,
comportamentos
e
condições
que

capturam
a
dinâmica
dos
serviços
como
estão
descritos
no
diagrama
de
seqüência.

Diagramas
de
Estado
x
Descrição
de
Classes
Horizontal
Verificar
se
as
classes
estão
descritas
de
forma
a
capturar
a
funcionalidade
especifica

pelo
diagrama
de
estados.

Diagrama
de
Seqüência
x
Estados
Horizontal
Verificar
se
toda
transcrição
de
estado
para
um
objeto
pode
ser
realizada
pelas

mensagens
enviadas
e
recebidas
pelo
objeto.

Diagrama
de
Classes
x
Descrição
de
Classe
Horizontal
Verificar
se
as
descrição
detalhadas
das
classes
contêm
toda
a
informação
necessária
de

acordo
com
o
diagrama
de
classes
e
se
a
descrição

da
classe
possui
um
senFdo

semânFco.

Descrições
de
Classe
x
Descrições
de
Requisitos
VerFcal

Verificar
de
os
conceitos
e
serviços
descritos
pelos
requisitos
funcionais
estão

capturadas
apropriadamente
pela
descrições
das
classes.

Diagramas
de
Seqüência
x
Casos
de
Uso

VerFcal

Verificar
se
os
diagramas
de
seqüência
descrevem
uma
combinação
apropriada
de

objetos
e
mensagens
que
trabalham
em
conjunto
para
capturar
a
funcionalidade

descrita
pelo
caso
de
uso.

Diagrama
de
Estado
x
Descrição
de
Requisitos
e
VerFcal
Verificar
se
os
diagramas
de
estado
descrevem
apropriadamente
os
estados
dos
objetos

Casos
de
Uso
e
eventos
que
disparam
as
trocas
de
estado
conforme
descritos
nos
requisitos
e
casos

de
uso.


Tipos de revisão

–  Este tipo de técnica de inspeção, pode detectar os
seguintes tipos de defeitos:
•  ausência de informação (definição de termos, unidades de medida,...)
•  informação ambígua (vários significados possíveis para um único
termo)
•  informação inconsistente (quando existem requisitos em conflito)
•  fatos incorretos (fato que não pode ser verdadeiro nas condições
especificadas para o sistema)
•  informação desnecessária (excesso de informação pode confundir os
usuários)
•  outros tipos de defeitos (defeitos não classificados em nenhum dos
tipos anteriores, como por exemplo requisito em seção incorreta)


Tipos de revisão

–  Dificuldades relatadas na literatura
•  O moderador que lidera o processo de inspeção não foi bem treinado;
•  As pessoas que compõem a equipe de inspeção não assumem as suas
tarefas;
•  Dificuldade dos participantes entenderem o uso das técnicas de inspeção
durante o treinamento;
•  O tempo disponível para detectar os defeitos é insuficiente, acarretando um
projeto mal inspecionado;
•  Falta de conhecimento por parte dos participantes com relação ao domínio do
projeto;
•  Para a maioria das organizações a produtividade ainda é vista e medida em
termos de linhas de código, sendo que as inspeções requerem esforço sem
produzir qualquer linha de código, não sendo vista como um benefício tangível;
•  Para os desenvolvedores, é constrangedor avaliar o seu trabalho e deixá-lo ser
avaliado por outros, pois pode comprometer a sua reputação profissional;


Tipos de revisão

•  Inspeção (workshop)
–  Exercícios Práticos


Tópico

• Ferramentas


Ferramentas

•  Ferramentas de revisão em software são extremante
complexas de serem construídas.

•  Normalmente usadas para gestão, apoio e
armazenamento do resultado da revisão e gerar métricas
e estatísticas.

•  Algumas ferramentas são usadas para a execução de
análise estática automatizada do código.

•  Nos próximos slides apresentaremos e conheceremos
diversos exemplos de ferramentas


Dúvidas?

•  Contato:
–  Email: cristiano.caetano@qualister.com.br


Qualidade de software e garantia

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Qualidade de software e garantia

Semelhante a Qualidade de software e garantia (20)

Mais de Qualister

Mais de Qualister (20)

Qualidade de software e garantia