Inspeo de software

Silvana M. Melo1
1

Instituto de Computao e Matemtica Computacional Universidade de So Paulo

(USP)
Caixa Postal 668 13560-970 So Carlos SP Brazil

morita@icmc.usp.br

Abstract. This article describes the methods and techniques used in the search
for quality of software artifacts during all stages of its development, methods
of verification and validation, verification and other static and dynamic,
emphasizing the process of software inspection.
Resumo. Este artigo descreve os mtodos e tcnicas utilizadas na busca de
qualidade dos artefatos de software, durante todas as fases de seu
desenvolvimento, mtodos de verificao e validao, verificao esttica e
dinmica entre outros, dando nfase ao processo de inspeo de software.

1. Introduo
Dada a popularizao de sistemas de software, e o fato deles se tornarem cada vez
maiores e mais complexos, a garantia de qualidade nesses sistemas um grande desafio.
Uma forma de garantir a qualidade do produto tratar de problemas o mais cedo
possvel, ou seja, assim que eles aparecem e no adiando at o final do desenvolvimento,
pois quanto mais tarde o problema descoberto maior custo de sua correo.
Na tentativa de diminuir o retrabalho e melhorar a qualidade dos produtos, uma
abordagem que tem se mostrado eficiente e de baixo custo para encontrar defeitos,
reduzindo o retrabalho e melhorando a qualidade dos produtos a reviso dos artefatos
produzidos ao longo do processo de desenvolvimento de software. Inspeo de software
um tipo particular de reviso que pode ser aplicado a todos os artefatos de software e
possui um processo de deteco de defeitos rigoroso e bem definido. A figura a seguir
ilustra a possibilidade de realizar inspees nos diferentes artefatos de software
[Kalinowski 2004].

Figura 1. Inspeo em diferentes artefatos (adaptado de [Kalinowski 2004])

2. Qualidade de software
Qualidade de Software um processo sistemtico que focaliza todas as etapas e artefatos
produzidos com o objetivo de garantir a conformidade de processos e produtos,
prevenindo e eliminando defeitos. Defeitos so encontrados em todas as fases do
desenvolvimento, porm comprovado que a maioria encontra-se nas fases iniciais do
processo de desenvolvimento. Isso gera prejuzos enormes para as empresas
desenvolvedoras de software, pois o preo para corrigir um erro cresce muito com o
passar do tempo. Com isso, fica clara a importncia de um processo de Garantia da
Qualidade que atue em todas as fases do processo de desenvolvimento [Barti 2002].
Para isso, o processo de Garantia da Qualidade utiliza-se de atividades de
verificao, validao com o intuito de encontrar erros em todas as etapas do
desenvolvimento. Essas atividades so muito importantes, pois cuidam de analisar
diversos pontos do processo de desenvolvimento, impedindo que um erro se propague
para as fases posteriores do projeto.
2.1 Verificao e Validao
Tcnicas de verificao e validao so aplicadas aos softwares durante e depois de seu
desenvolvimento para garantir que ele atente sua especificao e fornece as
funcionalidades esperadas pelos clientes.
Essas atividades ocorrem durante todo o ciclo de vida do software comeando
com revises de requisitos e continua ao longo das revises de projeto e das inspees
de cdigo at o teste do produto.
2.1.1 Anlise dinmica
Anlise dinmica de software uma tcnica de verificao e validao muito usada, que
consiste em exercitar o programa usando dados reais processados pelo programa e
verificar se as sadas obtidas esto de acordo com as sadas esperadas.
Uma tcnica esttica muito utilizada so os testes de software que so essenciais
para descoberta de defeitos e garantia de qualidade e confiabilidade que s podem ser
obtidas com a execuo do programa.

2.1.2 Anlise esttica

So mtodos usados para garantir a qualidade do software que no necessita de uma
verso executvel do programa. Por este motivo podem ser utilizadas em todas as fases
do desenvolvimento do software, pode verificar tanto o produto quanto o processo de
software.
Porm essa tcnica oferece garantia somente a correspondncia entre um
programa e sua especificao (verificao), no demonstra que o software til
operacionalmente, no pode testar propriedades emergentes do software como
desempenho e confiabilidade [Sommerville 2007].
Dentre as tcnicas de verificao, revises so tcnicas amplamente difundidas e
que podem ser usadas tanto na anlise esttica quanto dinmica.

3. Revises
Revises fazem parte do conjunto de atividades de garantia de qualidade de software.
Essas atividades constituem um padro sistemtico e planejado de aes que so exigidas
para garantia de qualidade do software e que devem ser aplicadas ao longo de todo
processo de engenharia de software [Pressman 2000].
Nesse contexto a reviso de software um filtro para o processo de engenharia
de software. Pois revises so aplicadas em vrios pontos durante o ciclo de vida do
desenvolvimento de software eliminando defeitos em cada fase antes de passar para a
fase seguinte [Pressman 2000].
As revises podem ser classificadas em:

Discusso informal: realizada pelos grupos de desenvolvedores para resolver

problemas tcnicos.

Apresentao: exposio do projeto de software pelo autor, para os clientes,

administradores e pessoal tcnico.

Revises Tcnicas Formais (RTF): avaliaes tcnicas do software, realizadas em

pequenos grupos, fornecendo informaes confiveis sobre as atividades que so
realizadas.
As revises tcnicas formais tm como objetivos principais:

Descobrir erros de funo, lgica ou implementao, em qualquer produto de

software;

Verificar se o software que se encontra sob reviso atende a seus requisitos;

Garantir que o software tenha sido representado de acordo com padres

predefinidos;

Obter um software que seja desenvolvido uniformemente;

Tornar os projetos mais administrveis.

Dentre os principais mtodos de reviso tcnica formal esto: Walkthrough,

Peer-review e Inspeo.

3.1.1 Walkthrough
Nesta tcnica a reviso feita atravs de uma execuo passo a passo de um
procedimento ou programa (no papel), com o objetivo de encontrar erros. Dura em
mdia uma a duas horas. Envolve equipes pequenas de trs a cinco pessoas, onde feita
uma simulao da execuo por cada revisor, controlada um testador que durante a
reunio disponibiliza um conjunto de casos de teste e monitora os resultados obtidos de
cada revisor.
3.1.2 Peer-Review
uma tcnica formal de inspeo de cdigo realizada em pares de programadores com
mesmo nvel de conhecimento, o objetivo desta tcnica obter pontos de vista diferentes
do desenvolvedor e revisar o material, a fim de encontrar problemas de qualidade, apenas
um programa ou algumas funcionalidades so revisados de cada vez. Os resultados
obtidos vo para um relatrio para a reviso e se forem pertinentes passam para o
relatrio final oficial. O problema desta tcnica so as disputas pessoais. Por esse motivo
deve ser analisado o produto no o desenvolvedor.

3.1.3 Inspeo
A inspeo um processo de reviso formal de software e corresponde a uma das mais
importantes atividades de Garantia de Qualidade de Software, sendo que o principal
objetivo descoberta antecipada de falhas (produo de uma sada incorreta em relao
especificao), de modo que eles no se propaguem para o passo seguinte do processo
de software. Assim, a Engenharia de software tem utilizado a inspeo como um dos
mtodos mais eficientes e efetivos na busca por um produto de melhor qualidade.
[Felizardo 2004].
A inspeo visa encontrar erros lendo, entendendo o que o documento descreve e
checando atravs de um checklist as propriedades de qualidade requeridas, composto
por seis fases, que so: Planejamento, Apresentao, Preparao, Reunio de Inspeo,
Retrabalho e Acompanhamento [Fagan 1986].
No Planejamento os inspetores so selecionados e os materiais a serem revisados so
preparados; na Apresentao, o grupo recebe instrues essenciais sobre o material a ser
inspecionado, especialmente sobre o que deve ser inspecionado; na Preparao,
integrantes do time de inspeo se preparam para desempenhar o papel designado a cada
um; no momento da Reunio de Inspeo os defeitos so encontrados, discutidos e
categorizados; no Retrabalho o autor do documento corrige os defeitos encontrados pelo
time de inspeo e na etapa de Acompanhamento, o time de inspeo responsvel por
assegurar que todos os defeitos encontrados foram corrigidos e nenhum outro tipo de
defeito foi introduzido na fase de Retrabalho. O Acompanhamento tambm pode ser
realizado somente pelo moderador [MacDonald 1995] [Fagan 1986].
A figura a seguir ilustra as etapas e papis envolvidos no processo de inspeo de
software.

Figura 2. Etapas da inspeo de software [Porto 2009].

3.1.3.1 Etapas
O processo de inspeo realizado por uma equipe composta por desenvolvedores e
tambm por mais participantes, que realizam os seguintes papis [Fagan 1986]:

Autor: o prprio desenvolvedor do artefato que ser inspecionado;

Moderador: quem lidera a inspeo e as reunies;

Redator: quem relata os defeitos encontrados e as solues sugeridas durante a

inspeo;

Inspetor: membros da equipe que tentam encontrar erros no produto.

3.1.3.2 Aspectos abordados

A inspeo pode ser feita tanto em produtos de software com projetos de software,
depende do aspecto que ser analisado durante a reviso. Podemos classificar dois tipos
bsicos de reviso de acordo com os aspectos analisados:

Inspeo de documentos de requisitos: analisa documentos de requisitos

encontrando erros enquanto eles so mais fceis e baratos de serem corrigidos.

Inspeo de cdigo-fonte: Visa a encontrar defeitos no cdigo-fonte, realizando

uma anlise esttica do cdigo. Tornam os programas menos complexos, pois os
subprogramas so escritos em um estilo consistente e obedecem padres
estabelecidos, alm disso o desenvolvimento de sistemas torna-se transparente, a
estimativa e o planejamento tornam-se mais confiveis e facilita a
manuteno,com o desenvolvimento de sistemas mais compreensveis e bem
documentados.

3.1.3.2.1 Tipos de defeitos encontrados em cada aspecto

A inspeo em documentos de requisitos pode revelar inmeros defeitos,
podemos classific-los como segue:

Defeito de omisso: informaes necessrias ao sistema so omitidas, como

exemplo a omisso de uma funcionalidade ou da capacidade de desempenho do
sistema.

Defeito de fato incorreto: h informaes nos artefatos do sistema que so

contraditrios com o domnio da aplicao.

Defeito de inconsistncia: a informao aparece mais de uma vez no artefato e de

forma diferente em cada apario causando incoerncia.

Defeito de ambigidade: a informao leva a mltiplas interpretaes.

Defeito de informao estranha: uma informao que aparece no artefato e

embora esteja relacionada ao domnio, no necessria para o sistema em
questo.
Os defeitos encontrados no cdigo fonte podem ser classificados em:

Defeitos de Omisso: causado pelo esquecimento de algum elemento no

programa, como um comando que atribui valor a uma varivel por exemplo.

Defeitos de Comisso: um segmento de cdigo incorreto, quando, por exemplo,

um operador aritmtico errado usado em uma expresso.

Defeito de inicializao: inicializao incorreta de uma estrutura de dados.

Defeitos de computao: qualquer computao incorreta para a gerao do valor

de uma varivel.

Defeito de controle: causa a execuo de um caminho de controle errado para

um valor de entrada.

Defeito de interface: quando um mdulo usa ou faz suposies sobre dados que
no fazem parte de seu escopo.

Defeitos de dados: uso incorreto de uma estrutura de dados.

Defeitos de cosmtico: erros de ortografia e gramtica.

3.2 Tcnicas de leitura de artefato de software

A inspeo uma tcnica de reviso baseada na leitura e entendimento de um documento
a fim de encontrar defeitos. Porm um dos problemas enfrentados pelos desenvolvedores
que eles aprendem a escrever documentos de requisitos, cdigo, projeto, mas no
aprendem a fazer a leitura adequada dos mesmos.
A soluo empregar tcnicas de leitura, que so um conjunto concreto de
instrues dadas ao leitor de como ler e o que olhar em um produto de software. Leitura
de software uma anlise individual de um produto textual de software que pode ser
uma especificao de requisitos, cdigo fonte planos de teste, com objetivo de obter
entendimento necessrio para realizar uma tarefa como detectar defeitos por exemplo.
Existem diversas tcnicas de leitura, aqui trataremos das essenciais, so elas: Ad-hoc,
Check-list e Leitura Baseada em Perspectiva (PBR).

3.2.1 Tcnica de leitura Ad-Hoc

Essa tcnica no utiliza nenhuma tcnica formal de leitura, cada leitor l o documento do
seu modo, por este motivo ela torna-se dependente da experincia do leitor, e apresenta
um grande defeito que o fato de no ser repetvel nem passvel de melhoria, pois no
existe um procedimento a ser seguido.
3.2.2 Tcnica de leitura Check-list
Similar tcnica Ad-Hoc, porm cada revisor recebe um checklist, onde os itens desse
checklist capturam importantes lies aprendidas em revises anteriores. Itens
individuais de um checklist podem enumerar defeitos caractersticos, priorizar diferentes
defeitos ou propor questes para ajudar o revisor a descobrir defeitos.
3.2.3 Tcnica de leitura baseada em perspectiva
A tcnica de leitura baseada em perspectiva aplicada em inspeo de documentos de
requisitos em linguagem natural. Ela prev um conjunto de instrues especficas para os
trs papis envolvidos diretamente com o documento de requisitos: o testador, o
projetista e o usurio [Travassos 2004]. A figura a seguir ilustra a utilizao de PBR no
desenvolvimento do produto de software.

Figura 3. Tcnica de leitura baseada em Perspectiva

A PBR define responsabilidades especficas para cada revisor, desse modo cada
indivduo responsvel por criar uma abstrao do produto e ento responder questes
baseadas na anlise da abstrao a partir de uma perspectiva (ponto de vista) diferente. O
indivduo pode revisar o documento de software da perspectiva do desenvolvedor, do
testador e do usurio final. Em cada perspectiva definido um cenrio o e um conjunto
de questes e atividades que dizem ao indivduo o que ele deve fazer e como ele deve ler
o documento, essas questes auxiliam o indivduo a descobrir defeitos. Os cenrios
descrevem as atividades que devem ser executadas pelo indivduo no momento da leitura
a fim de descobrir defeitos em suma um cenrio uma coleo de procedimentos que
permitem operacionalizar estratgias para detectar defeitos. A seguir, apresentam-se os
cenrios e questes, sob as perspectivas de leitura do usurio e do testador [Dria 2009]:
3.2.3.1 Perspectiva do usurio
Espera-se que o revisor execute as seguintes tarefas: defina o conjunto de funes que
um usurio esteja apto a executar; defina um conjunto de entrada necessrio para
executar cada funo e o conjunto de sada gerado pela funo. Isto pode ser visto como
escrever todos os cenrios operacionais ou subconjuntos de cenrios operacionais que o

sistema deveria executar. Iniciando com os cenrios mais convencionais e prosseguindo

para os cenrios menos comuns ou condies especiais. Enquanto os cenrios esto
sendo gerados, o revisor faz a si mesmo as seguintes perguntas:

Todas as funes necessrias para escrever os cenrios esto especificadas no

documento de requisitos ou na especificao funcional?

As condies 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?

3.2.3.2 Perspectiva do testador

Tendo como perspectiva a viso de um testador, o revisor deve assegurar que para cada
especificao funcional ou requisito gere um conjunto de casos de teste que assegure de
que a implementao do sistema satisfaz a especificao funcional ou o requisito.
recomendvel que ele use a sua abordagem de teste formal e critrios de teste. Aps a
construo do cenrio ele deve fazer a si mesmo as perguntas a seguir para cada teste:

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 testes gerados fornecero os valores corretos nas
unidades corretas?

Existe outra interpretao 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 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?

4. Ferramentas de apoio
Em geral revises so trabalhosas, muitas vezes executadas manualmente e por isso
lentas podendo levar a erros. A automatizao de algumas tarefas pode auxiliar os
revisores a compreenderem melhor o processo e diminuir o esforo, alm de diminuir o
custo e aumentar o desempenho desta atividade. Muitos esforos tm sido empregados
no desenvolvimento de ferramentas para apoiar a inspeo de software, existem hoje
ferramentas que apiam a inspeo de cdigo fonte, como tambm ferramentas de

inspeo de artefatos de software, at mesmo ferramentas que oferecem suporte a todas

as etapas do desenvolvimento. Dentre as ferramentas desenvolvidas e usadas pelas
indstrias de software, aqui apresentamos duas, dentre tantas outras de relevncia no
mercado:

CRISTA [Porto 2009]. Uma ferramenta que apia o processo de inspeo

baseado na tcnica Stepwise Abstraction, facilita a navegao pelo cdigo e
possui vrios recursos que ajudam na compreenso do cdigo e em sua
documentao. Ela prov a gerao de diferentes relatrios que auxiliam o
processo de inspeo, por meio de uma interao constante do usurio com a
ferramenta, solicitando relatrios que possam transferir abstraes realizadas para
o cdigo em forma de comentrio, gerando uma redocumentao para o mesmo.
A ferramenta oferece um sistema de wizards, que guia o usurio na realizao de
vrias tarefas. Alm disso, a CRISTA disponibiliza para o inspetor uma seo de
ajuda, na qual existem informaes a respeito do processo de inspeo com a
tcnica Stepwise Abstraction. uma ferramenta muito til no contexto de
inspees de cdigo.

IBIS [Lanubile 2003]. Utiliza a web em conjunto com notificaes por e-mail
para apoiar inspees assncronas com equipes geograficamente distribudas.
IBIS visa explicitamente apoiar a reorganizao do processo de inspeo e
permitir a sua realizao de forma sistematizada. IBIS no limita o tipo de
artefato a ser inspecionado e na deteco de defeitos atualmente permite apenas a
utilizao das tcnicas ad-hoc e de checklists. IBIS no fornece apoio aos pontos
de tomada de deciso do processo de inspeo, sendo as atividades de
planejamento e de continuao do processo tratadas como simples cadastros, sem
apoio para a realizao de suas tarefas. IBIS tem sido utilizada em estudos
experimentais recentes para obter conhecimento na rea de inspees de software
e para avaliar aspectos da reorganizao do processo de inspeo.

5. Concluso
Inspees no requerem necessariamente a execuo do sistema e assim podem ser
usadas antes da implementao estar concluda. Podem ser aplicadas em qualquer
representao (artefato) do sistema. Por detectar defeitos assim que eles aparecem,
quando um erro encontrado, conhecida tambm sua natureza e localizao,
facilitando sua correo. Isso no ocorre com o Teste de Software.
Inspeo e Teste so tcnicas de V&V complementares. Elas devem ser usadas
em conjunto para garantir maior cobertura e confiabilidade.
Inspees podem checar a conformidade com especificao, mas no a
conformidade com os requisitos reais do cliente, ou seja, uma tcnica de verificao e
no de validao por isso no podem ser utilizadas para checar caractersticas no
funcionais como desempenho, usabilidade, estas atividades ficam a cargo dos Testes de
software.

Referncias
FAGAN, M. (1986) "Advances in Software Inspection", IEEE Transactions on Software
Engineering, Vol. SE-12, NO. 7.
MACDONALD, F; MILLER, J; Brooks, A.; Roper, M; Wood, M. (1995) "Automating
the Software Inspection Process", Empirical Foundations of Computer Science
(EfoCS), Departament of Computer Science, University of Stranthclyde.
PRESSMAN, R. S. (2000) Software Engineering A Practitioners Approach. 5th
edition McGraw Hill.
DRIA, E. S. (2001) Replicao de estudos empricos em engenharia de software.
Dissertao (Mestrado em Computao) Instituto de Cincias Matemticas e de
Computao (ICMC) Universidade de So Paulo, So Carlos.
BARTI, A. (2002) Garantia de Qualidade de Software. Edio: 2002, Campus.
LANUBILE, F., MALLARDO, T., CALEFATO, F., (2003). Tool support for
Geographically Dispersed Inspection Teams, Software Process Improvement and
Practice, 2003, 8: 217-231 (DOI: 10.1002/spip.184).
FELIZARDO, K. R. (2004). Apoio computacional para inspeo de software.
INFOCOMP: R evista de Cincia da Computao, v.3, n.2. Lavras, MG.
KALINOWSKI, M., SPNOLA, R.O., TRAVASSOS, G. H., (2004). Infra-Estrutura
Computacional para Apoio ao Processo de Inspeo de Software. No: Simpsio
Brasileiro de Qualidade de Software, Braslia.
SOMMERVILLE, (2007). Engenharia de Software. 8a edio, Addison Wesley.
PORTO, D. P. (2009) CRISTA: um apoio computacional para atividades de inspeo e
compreenso de cdigo. Dissertao (Mestrado em Computao) Universidade
Federal de So Carlos, So Carlos.