Apostila

Mtricas e Estimativas a-
plicadas a Teste de
Software


Professor MSc. Leoncio Regal
Dutra
leoncioregal@gmail.com

Maro 2009



Ps-Graduao MBA em Teste de Software
II

SUMRIO


INTRODUO A MTRICAS E ESTIMATIVAS APLICADAS A TESTE DE
SOFTWARE III

GQM GOAL QUESTIONS METRICS XXVI

CCMI MEDIES E ANLISES LI

GESTO E MEDIO SEGUNDO TMM LXXI


III




















Introduo a Mtricas e
Estimativas aplicadas a
Teste de Software
IV






INTRODUO A MTRICAS E ESTIMATIVAS
APLICADAS A TESTE DE SOFTWARE


Introduo


Imagine que voc faa parte de uma equipe de Rally, e que voc e sua
equipe tenham que atravessar um deserto enorme e cheio de obstculos e
que 50% dos fatores crticos de sucesso dependam do seu navegador para
estimar o tempo do percurso e a distncia. Agora imagine-se diante de um
projeto de Sistemas de Informao onde 50% dos fatores crticos de sucesso
esto nos prazos e custos. Certamente voc ter que fazer uma eficiente m-
trica e estimativa de software.
As mtricas e estimativas de software vem se tornando um dos princi-
pais tpicos na Engenharia da Informao com a crescente exigncia de seus
consumidores pela qualidade, rapidez, comodidade e baixo custo de implan-
tao e manuteno, impossvel no enxergar tais tcnicas como alavanca
para um produto de melhor qualidade, com custos adequados. Mas existem
ainda muitas barreiras que impedem os profissionais da rea de utilizarem tais
tcnicas ou de o fazerem de maneira errnea, embora a literatura disponvel
atualmente sobre engenharia da informao seja relativamente ampla e varia-
da, o que nos leva a questionar: Por que as mtricas e estimativas de softwa-
re propostas para o desenvolvimento de sistemas no so fiis realidade e
dimenso do problema? Tais tcnicas acompanharam a rpida evoluo do
setor?
V

Tais questes nos levam a crer que algumas mtricas e estimativas de
software ficaram obsoletas e outras ganharam vigor nas pocas atuais, quan-
do a busca da qualidade de software vem crescendo com grande rapidez.
Acredito que o ato de medir e estimar a parte mais importante de um
projeto de sistema bem-sucedido e alguns fatos como: a falta de maturidade,
o desinteresse das empresas de desenvolvimento de sistemas e a baixa po-
pularidade deste assunto entre os profissionais da rea de informtica so
algumas da principais causas para o insucesso e o alto custo dos sistemas de
informao.
O termo mtrica de software refere-se mensurao dos indicadores
quantitativos do tamanho e complexidade de um sistema. Estes indicadores
so, por sua vez, utilizados para correlatar contra os desempenhos observa-
dos no passado a fim de derivar previses de desempenho futuro.
A mtrica de software tem como princpios especificar as funes de co-
leta de dados de avaliao e desempenho, atribuir essas responsabilidades a
toda a equipe envolvida no projeto, reunir dados de desempenho pertencen-
tes complementao do software, analisar os histricos dos projetos anterio-
res para determinar o efeito desses fatores e utilizar esses efeitos para pesar
as previses futuras. Estes princpios nos permite prever o resto do processo,
avaliar o progresso e reduzir a complexidade, como numa prova de rally, onde
a cada corrida ficamos mais esclarecidos da condies e limites da equipe.


Conceitos: Mtricas


Por que Avaliamos?


Avaliamos principalmente para obter controle de um projeto e, portanto, poder
gerenci-lo. Avaliamos para estimar se estamos pertos ou longe dos objetivos defi-
VI

nidos no plano em termos de concluso, qualidade, compatibilidade com os requisi-
tos etc.
Avaliamos tambm para podermos estimar melhor o esforo de novos proje-
tos, o custo e a qualidade, com base na experincia passada. Por fim, avaliamos
para estimar como melhorar algum aspecto importante do desempenho do processo
ao longo do tempo, para examinar os efeitos das mudanas.
A avaliao de alguns aspectos importantes de um projeto adiciona um custo
significativo. Portanto, no fazemos uma avaliao s porque podemos. Devemos
definir metas muito precisas para esse esforo, e s coletar as mtricas que nos
permitiro satisfazer a essas metas.
H dois tipos de metas:
1. Metas de conhecimento: so expressas pelo uso de verbos como
avaliar, prever, monitorar. Voc deseja entender melhor o processo de desen-
volvimento. Por exemplo, talvez voc queira avaliar a qualidade do produto,
obter dados para prever o esforo do teste, monitorar a cobertura do teste ou
acompanhar as mudanas de requisitos.
2. Metas de mudana ou realizao: so expressas pelo uso de verbos
como aumentar, reduzir, melhorar ou realizar. Voc est realmente interessa-
do em examinar como as situaes mudam ou melhoram ao longo do tempo,
de uma iterao para outra, de um projeto para outro.

Exemplos
Monitorar o andamento relativo ao plano
Aumentar a satisfao do cliente
Melhorar a produtividade
Aperfeioar a previsibilidade
Aumentar a reutilizao

Essas metas gerais de gerenciamento no se transformam facilmente em m-
tricas. preciso transform-las em algumas submetas menores (ou metas de ao)
que identificam as aes que os participantes do projeto devem realizar para alcan-
ar a meta. preciso ter certeza de que as pessoas envolvidas entendem os benef-
cios.
VII


Exemplos
A meta para "aumentar a satisfao do cliente" seria decomposta em:
o Definir a satisfao do cliente
o Avaliar a satisfao do cliente em vrios releases
o Verificar se a satisfao aumenta
A meta para "melhorar a produtividade" seria decomposta em:
o Avaliar o esforo
o Avaliar o andamento
o Calcular a produtividade em vrias iteraes ou projetos.
o Comparar os resultados

Em seguida, algumas submetas (mas no todas) precisariam de alguma m-
trica para serem coletadas.

Exemplo
"Avaliar a satisfao do cliente" pode ser proveniente de
o Pesquisa do cliente (onde o cliente forneceria marcas para diferen-
tes aspectos)
o Nmero e gravidade das chamadas para uma linha de suporte ao
cliente.
Uma maneira til de categorizar essas metas por organizao, projeto e necessi-
dade tcnica. Esse procedimento fornece um framework para refinar o que foi discu-
tido acima.


Necessidades Organizacionais das Mtricas


Uma organizao precisa conhecer, e talvez melhorar, o custo por 'item', di-
minuir os tempos de construo (tempo de mercado), e ao mesmo tempo liberar o
produto de qualidade conhecida (objetiva e subjetiva) e as demandas de manuten-
o apropriadas. Uma organizao pode precisar melhorar de vez em quando (ou
at mesmo continuamente) o seu desempenho para permanecer competitiva. Para
VIII

reduzir os riscos, uma organizao precisa conhecer o nvel de habilidade e experi-
ncia da sua equipe, e garantir que h outros recursos e capacidades para competir
no setor escolhido. Uma organizao deve poder introduzir uma nova tecnologia e
determinar a relao custo-benefcio dessa tecnologia.
A tabela a seguir lista alguns exemplos dos tipos de mtricas relevantes para
as necessidades de uma organizao de desenvolvimento de software, relevantes
para as necessidades de uma organizao de desenvolvimento de software.

Questo Mtrica
Custo do Item Custo por linha de cdigo, custo por
ponto de funo, custo por caso de
uso. Esforo normalizado (atravs da
parte definida do ciclo de vida, da lin-
guagem de programao, do nvel da
equipe, etc.) por linha de cdigo, pon-
to de funo ou caso de uso. Obser-
ve que essas mtricas no so nor-
malmente nmeros simples - elas
dependem do tamanho do sistema
para serem apresentadas e de a pro-
gramao estar ou no compactada.
Tempo de Construo Tempo decorrido por linha de cdigo
ou por ponto de funo. Observe que
isso tambm depender do tamanho
do sistema. A programao tambm
pode ser diminuda adicionando a
equipe - mas apenas at um ponto. A
capacidade de gerenciamento de
uma organizao determinar exata-
mente onde o limite.
Densidade do Defeito no Produto Li- Defeitos (descobertos aps a libera-
IX

berado o) por linha de cdigo ou por ponto
de funo.
Qualidade Subjetiva Facilidade de uso, facilidade de ope-
rao, aceitao do cliente. Embora
sejam confusas, as maneiras de ten-
tar a quantificao foram planejadas.
Facilidade de Manuteno Custo por linha de cdigo ou ponto
de funo por ano.
Perfil das Habilidades, Perfil da Expe-
rincia
O grupo de Recursos Humanos man-
teria presumivelmente algum tipo de
banco de dados de habilidade e ex-
perincia.
Capacidade Tecnolgica Ferramentas uma organi-
zao deve saber quais so
mais usadas e o nvel de
conhecimento dos funcion-
rios sobre as que no so
to usadas.
Maturidade do Processo -
onde se encontra a taxa da
onde se encontra a taxa da
organizao na escala SEI
CMM, por exemplo?
Capacidade do Domnio
em que domnios do aplica-
tivo a organizao capaz
de atuar?
Medidas de Melhoria do Processo Tempo e esforo da execu-
o do processo.
Taxas de defeito, estatstica
X

de anlise causal, taxas fi-
xas, retalhamento e retraba-
lho.


Necessidades Organizacionais das Mtricas


Um projeto deve ser liberado normalmente:
com os recursos funcionais e no funcionais necessrios;
sob certas restries;
para um oramento e em um determinado momento;
liberao de um produto com certas caractersticas de transio (para o
cliente), operacionais e de manuteno.

O Gerente de Projeto deve poder verificar se est se dirigindo para essas me-
tas, expandidas na tabela a seguir para fornecer alguma idia do que ser conside-
rado no exame das medies do projeto:

Questo
Esforo e Oramento do Projeto
Como acompanhar o esforo e o custo do projeto em relao ao
plano?
Programao do Projeto
O projeto est alcanando os seus marcos?
Transio/Instalao
O esforo previsto, o custo e os requisitos de habilidade so aceit-
veis?
Operao
O esforo previsto e os requisitos de habilidade so suportveis pe-
lo cliente?
Manuteno/Suportabilidade
XI

O esforo previsto e os requisitos de habilidade so aceitveis para
o cliente?
Requisitos Funcionais
Os requisitos vlidos esto completos?
Os requisitos esto alocados para uma iterao?
Os requisitos esto sendo atendidos de acordo com o plano?
Requisitos No-Funcionais
Desempenho
O sistema est atendendo aos requisitos de receptividade, taxa de
transferncia de dados, tempo de recuperao?

Capacidade
O sistema comporta o nmero necessrio de usurios simultneos?
O site da web comporta o nmero necessrio de ocorrncias por
segundo? H armazenamento suficiente para o nmero necessrio
de registros de cliente?

Fatores de Qualidade
Confiabilidade: qual a freqncia permitida de falhas do sistema, e
o que constitui uma falha do sistema?
Usabilidade: o sistema fcil e agradvel de usar? Quanto tempo
preciso para aprender a us-lo e saber quais so as habilidades ne-
cessrias?
Tolerncia a falhas/robustez/flexibilidade/capacidade de sobrevivn-
cia: o sistema pode continuar a funcionar se ocorrerem falhas? O
sistema pode lidar com uma entrada invlida? O sistema capaz de
se recuperar automaticamente aps uma falha?

Requisitos de Especialidade da Engenharia
Segurana: o sistema pode ser executado sem risco vida ou
XII

propriedade (tangvel e intangvel)?
Segurana/privacidade: o sistema protege os dados confidenciais
contra acesso no autorizado? O sistema seguro contra acesso
malicioso?
Impacto ambiental: o sistema atende aos requisitos ambientais?

Outros Requisitos Reguladores ou Legais

Restries

Ambiente externo: o sistema capaz de funcionar no ambiente re-
comendado?
Recursos, host, destino: o sistema atende s restries de CPU,
memria, linguagem, ambiente de hardware/software?
Uso do commercial-off-the-shelf (COTS) ou outro software existente:
o sistema atende s restries de reutilizao?
Disponibilidade e habilidades da equipe: o sistema pode ser criado
com o nmero e o tipo da equipe disponveis?
Suporte de interface/compatibilidade: o sistema pode suportar o a-
cesso necessrio a outros sistemas e a partir deles?
Reusabilidade: que provises so criadas para que o sistema seja
reutilizvel?
Padres impostos: o sistema e o mtodo de desenvolvimento so
compatveis?
Outras restries de design (arquitetural, algortmica, por exemplo):
o sistema est usando o estilo arquitetural necessrio? Os algorit-
mos prescritos esto sendo usados?


Esta uma lista grande, mas no exaustiva, das questes do Gerente de Pro-
jeto. Muitas exigiro a coleta e a anlise das mtricas, e algumas tambm exigiro o
XIII

desenvolvimento de testes especficos (para gerar medies) a fim de responder s
questes propostas.



Necessidades Tcnicas das Mtricas

Muitas necessidades do projeto no precisaro ter medidas diretas, e mesmo
as que precisarem, talvez no seja bvio o que deve ser feito ou alterado para aper-
feio-las. Os atributos de qualidade de nvel inferior podem ser usados para criar a
qualidade em relao a vrios atributos de qualidade de nvel superior, como, por
exemplo, aqueles identificados no ISO Standard 9126 (Caractersticas e Mtricas da
Qualidade do Software) e aqueles mencionados acima nas Necessidades do Proje-
to. Essas medidas tcnicas so caractersticas e efeitos (cobrindo o processo e o
produto) da engenharia (estrutural e comportamental), que contribuem para as ne-
cessidades das mtricas do nvel do projeto. Os atributos na tabela a seguir foram
usados para gerar um conjunto de exemplo das mtricas dos artefatos e do proces-
so do Rational Unified Process.

Qualidade Atributos
Excelncia dos Requisitos Volatilidade: freqncia de
mudana, taxa de introdu-
o de novos requisitos
Validade: estes so os re-
quisitos certos?
Abrangncia: est faltando
algum requisito?
Correo da expresso: os
requisitos esto adequada-
mente estabelecidos?
Clareza: as descries es-
to compreensveis e no
XIV

contm compreensveis e
no contm ambigidades?
Excelncia de Design Acoplamento: qual a ex-
tenso das conexes entre
os elementos do sistema?
Coeso: cada componente
tem uma finalidade nica e
bem definida?
Originalidade: os mtodos
ou as operaes de uma
classe podem ser constru-
dos de outros mtodos ou
operaes da classe? Se
puderem, no so originais
(uma caracterstica desej-
vel).
Abrangncia: o design reali-
za completamente os requi-
sitos?
Volatilidade: freqncia da
alterao arquitetural.
Excelncia da Implementao Tamanho: qual a proximi-
dade da implementao em
relao ao tamanho mnimo
(para resolver o problema)?
A implementao atende s
restries?
Complexidade: o cdigo es-
t difcil ou intricado do pon-
to de vista do algoritmo?
XV

difcil de entender e modifi-
car?
Abrangncia: a implementa-
o executa com fidelidade
todo o design?
Excelncia de Teste Cobertura: o teste experi-
menta bem o software? To-
das as instrues so exe-
cutadas por um conjunto de
testes? O teste experimenta
muitos caminhos por meio
do cdigo?
Validade: os prprios testes
refletem corretamente os
requisitos?
Excelncia do Processo (no nvel
mais baixo)
Taxa de defeito, causa do
defeito: qual a incidncia e
defeitos em uma atividade,
e quais so as causas?
Esforo e durao: qual a
durao e quanto esforo
humano exige uma ativida-
de?
Produtividade: por unidade
de esforo humano, qual o
rendimento de uma ativida-
de?
Excelncia dos artefatos:
qual o nvel dos defeitos
nas sadas de uma ativida-
XVI

de?
Eficincia do Processo/Mudana de
Ferramenta
Taxa de defeito, causa do-
defeito
Esforo e durao
Produtividade
Excelncia dos artefatos


O que Mtrica?


H dois tipos de mtricas:

Uma mtrica um atributo de uma entidade que pode ser avaliado. Por
exemplo, o esforo do projeto uma avaliao (ou seja, mtrica) do tama-
nho do projeto. Para calcular essa mtrica, voc precisa somar todos os
registros do cronograma do projeto.
Uma mtrica original um item de dados bruto que usado para calcular
uma mtrica. No exemplo acima, os registros do cronograma so as mtri-
cas originais. Uma mtrica original normalmente uma mtrica que existe
em um banco de dados, mas no interpretada isoladamente.
Cada mtrica composta de uma ou mais mtricas coletadas. Conseqente-
mente, cada mtrica original deve ser claramente identificada e seu procedimento de
coleta definido.
As mtricas destinadas a suportar as metas de mudana ou realizao fre-
qentemente so "geradas primeiro" ao longo do tempo (ou iteraes ou projeto).
Estamos interessados em uma "geradas primeiro" ao longo do tempo (ou iteraes
ou projeto). Estamos interessados em uma tendncia, no em um valor absoluto.
Para "melhorar a qualidade" preciso verificar se o nvel residual de defeitos conhe-
cidos diminui ao longo do tempo.


Templates
XVII



Template de uma mtrica


Nome Nome da mtrica e qualquer
sinnimo conhecido.
Definio Os atributos das entidades que so
avaliadas usando essa mtrica, como
a mtrica calculada, e de qual m-
trica original ela calculada.
Metas Lista de metas e perguntas referentes
a essa mtrica. Tambm alguma ex-
plicao sobre por que a mtrica est
sendo coletada.
Procedimento de anlise Como se pretende usar a mtrica.
Precondies para a interpretao da
mtrica (por exemplo, conjunto vlido
de outras mtricas). Valores-alvo ou
tendncias. Modelos de tcnicas e
ferramentas de anlise para serem
usados. Suposies implcitas (por
exemplo, do ambiente ou modelos).
Procedimentos de Calibrao. Arma-
zenamento.
Responsabilidades Quem coletar e agregar os dados
da mtrica, preparar os relatrios e
analisar os dados.


Template de uma mtrica original

XVIII


Nome Nome da mtrica original
Definio Descrio sem ambigidade da m-
trica em termos do ambiente do pro-
jeto
Procedimento de coleta Descrio do procedimento de coleta.
Ferramenta e forma de coleta de da-
dos a serem usadas. Pontos no ciclo
de vida em que os dados so coleta-
dos. Procedimento de verificao a
ser usado. Onde os dados sero ar-
mazenados, formato e preciso.
Responsabilidades Quem o responsvel pela coleta de
dados. Quem o responsvel pela
verificao de dados.


Atividades das Mtricas


H duas atividades:

Definir o plano de mtricas
Coletar as medidas

A definio do plano de mtricas realizada uma vez por ciclo de desenvol-
vimento - na fase de iniciao, como parte da atividade de planejamento geral, ou s
vezes, como parte da configurao do processo no caso de desenvolvimento. O pla-
no de mtricas pode ser revisto como qualquer outra seo do plano de desenvolvi-
mento de software durante o curso do projeto.
XIX

A coleta das medidas realizada repetidamente, pelo menos uma vez por ite-
rao, e s vezes mais freqentemente; por exemplo, semanalmente, em uma itera-
o que dure muitos meses.
As mtricas coletadas fazem parte do documento Avaliao de Status, que
deve ser explorado na avaliao do andamento e da integridade do projeto. Elas
tambm podem ser acumuladas para uso futuro em estimativas do projeto e tendn-
cias sobre a organizao.


Como as Mtricas so Usadas?


Estimativa


O gerente do projeto especialmente se depara com a situao de ter de pla-
nejar - atribuir recursos a atividades com oramentos e programaes. Tanto o es-
foro quanto a programao so estimados com base em um julgamento do que de-
ve ser produzido, ou o inverso - h recursos fixos e programao, e necessria
uma estimativa do que pode ser produzido. A estimativa normalmente est relacio-
nada ao clculo dos recursos necessrios com base em outros fatores - normalmen-
te tamanho e produtividade - para fins de planejamento.


Previso


A previso um pouco diferente da estimativa e normalmente indica o clculo
do valor futuro de algum fator com base em seu valor atual, e outros fatores de influ-
ncia. Por exemplo, com um exemplo dos dados do desempenho, til saber (pre-
ver) como o sistema funcionar com carga total, ou em uma configurao de recur-
sos restritos ou degradados. Os modelos de previso de confiabilidade usam os da-
dos da taxa de defeito para prever quando o sistema alcanar certos nveis de con-
XX

fiabilidade. Com uma atividade planejada, o gerente de projeto precisar dos dados
sobre os quais prever as datas de concluso e o esforo na concluso


Avaliao


A avaliao usada para estabelecer a posio atual para comparar com um
limite ou identificao de tendncias, ou para comparao entre alternativas, ou co-
mo base da estimativa ou previso.


Tipos de Mtricas


As Mtricas Orientadas ao Tamanho


Mtricas de software orientadas ao tamanho so medidas diretas do
software e do processo por meio do qual ele desenvolvido. Se uma organi-
zao de software mantiver registros simples, uma tabela de dados orientada
ao tamanho poder ser criada. A tabela registros simples, uma tabela de da-
dos orientada ao tamanho poder ser criada. A tabela relaciona cada projeto
de desenvolvimento de software que foi includo no decorrer dos ltimos anos
aos correspondentes dados orientados ao tamanho deste projeto. A partir dos
dados brutos contidos na tabela, um conjunto de mtricas de qualidade e de
produtividade orientadas ao tamanho pode ser desenvolvido para cada proje-
to. Mdias podem ser computadas levando-se em considerao todos os pro-
jetos.
As mtricas orientadas ao tamanho provocam controvrsias e no so
universalmente aceitas como a melhor maneira de se medir o processo de
desenvolvimento de software. A maior parte da controvrsia gira em torno do
XXI

uso das linhas de cdigo (LOC) como uma medida-chave. Os proponentes da
afeio de linhas de cdigo afirmam que as mesmas so o "artefato" de todos
os projetos de desenvolvimento de software que podem ser facilmente conta-
dos, que muitos modelos existentes usam LOC ou KLOC (milhares de linhas
de cdigo) como entrada-chave e que j existe um grande volume de literatu-
ra e de dados baseados nas linhas de cdigo. Por outro lado, os opositores
afirmam que as medidas LOC so dependentes da linguagem de programa-
o utilizada na codificao do projeto, que elas penalizam programas bem
projetados, porm mais curtos, que elas no podem acomodar facilmente lin-
guagens no-procedurais e que seu uso em estimativas requer um nvel de
detalhes que pode ser difcil de conseguir (isto , o planejador deve estimar as
linhas de cdigo a ser produzidas muito antes que a anlise e o projeto te-
nham sido construdos).
Essa forma de medida foi uma herana do modelo de manufatura em
que os CIO'S podiam determinar os recursos necessrios para uma "corrida",
contando o nmero de produtos manufaturados necessrios. Essa mtrica
no leva em considerao o fato de que o desenvolvimento envolve um custo
relativo ao ambiente ou linguagem de programao utilizada. Por exemplo,
em orientao a objeto (OO), a flexibilidade da ferramenta no uso de meca-
nismos de herana dilui o resultado final da contagem de linhas.
A contagem de linhas de cdigo pode ser uma medida do que foi feito, e
no uma medida a ser utilizada para previso.


Mtricas Orientadas Funo


Consiste em um mtodo para medio de software do ponto de vista do
usurio, que determina de forma consistente o tamanho e complexidade de
um software, sob a perspectiva do usurio. Ele dimensiona um software,
quantificando a funcionalidade proporcionada ao usurio a partir do seu dese-
XXII

nho lgico. Ou seja, so medidas indiretas do software e do processo por
meio do qual ele desenvolvido. Em vez de contar linhas de cdigo, a mtrica
orientada funo concentra-se na funcionalidade ou utilidade do programa.
Uma abordagem foi sugerida baseada nesta proposta chamada de pontos-
porfuno (function point). Os pontos-por-funo (FPs) so derivados usan-
do-se uma relao emprica baseada em medidas de informaes e comple-
xidade do software.
Um dos princpios da anlise de pontos-por-funo focaliza-se na pers-
pectiva de como os usurios "enxergam" os resultados que um sistema pro-
duz. A anlise considera as vrias formas com que os usurios interagem
com o sistema, com os seguintes objetivos:

1. Fornecer medidas consistentes;
2. Medir funcionalidades que o usurio solicita ou recebe;
3. Independncia da tecnologia;
4. Mtodo simples.

As mtricas orientadas funo apresentam vrios benefcios, dentre
eles podemos citar o seguintes:

1. Uma ferramenta para dimensionar aplicaes;
2. Um veculo para quantificar custo, esforo e tempo;
3. Um veculo para calcular ndices de produtividade e qualidade;
4. Um fator de normalizao para comparar software.

Tal mtrica parece ser til e funcional para o desenvolvimento tradicio-
nal, mas apresenta algumas falhas com o modelo de desenvolvimento em ori-
entao a objeto (OO), pois alguns atributos do design em OO invalidam o
clculo de alguns pontos-por-funo. As caractersticas fundamentais de OO
tm efeito de reduzir a validade da contagem de funes para a avaliao de
esforo e recursos necessrios para a execuo de um projeto.
XXIII

A mtrica de pontos por funo foi originalmente projetada para siste-
mas de informao comerciais. Para acomodar estas aplicaes, a dimenso
dos dados foi enfatizada para a excluso de dimenses funcionais e de con-
trole. Por esta razo, a medida de pontos por funo era adequada para mui-
tos sistemas de engenharia. Um nmero de extenses para a medida bsica
de pontos por funo tem sido propostas para remediar esta situao.
Uma extenso de pontos por funo chamada "feature points" (ou, pon-
tos caractersticos) uma evoluo da medida de pontos por funo que pode
ser aplicada a sistemas e aplicaes de engenharia de software. A medida
"feature points" acomoda aplicaes em que a complexidade algortmica
alta. Sistemas real-time de controle de processos e outros apresentam alta
complexidade algortmica, e so receptivos a mtrica de "feature points".
Para computar o "feature point", valores do domnio so contados e
ponderados. A mtrica "feature point" conta uma nova caracterstica de soft-
ware, os algoritmos. Um algoritmo definido como "um problema computa-
cional que includo com um programa de computador especfico". Inverte
uma matriz, decodificar um bit de string ou manusear uma interrupo so e-
xemplos de algoritmos.
Outra extenso de pontos por funo para sistemas real-time e produ-
tos de engenharia tem sido desenvolvida por Boeing. A aproximao de Boe-
ing integra a dimenso dos dados de software com dimenses funcionais e de
controle para obter uma medida orientada funo, chamada pontos por fun-
o 3D, que receptiva a aplicaes que enfatizem capacidades de funo e
controle. Caractersticas de todas as trs dimenses do "contadas, quantifi-
cadas e transformadas" em uma medida que fornece uma indicao da fun-
cionalidade fornecida pelo software.
Contagem de dados retidos (a estrutura de dados interna do programa,
isto , arquivos) e dados externos (entradas, sadas e referncias externas)
so usados com medidas de complexidade para derivar uma contagem da
dimenso de dados.
XXIV

A dimenso funcional medida considerando "o nmero de informa-
es internas requeridas para transformar entradas em dados de sada". Para
os propsitos da computao de pontos por funo 3D, uma transformao
vista como uma srie de passos de processamento que so limitados por re-
gras semnticas estabelecidas. Como uma regra geral, a transformao
concluda com um algoritmo que resulta em uma mudana fundamental para
dados de entrada como so processados para se transformarem em dados de
sada. Passos de processamento que adquirem dados de um arquivo e sim-
plesmente os coloca na memria do programa no poderia ser considerado
uma transformao. O dado no sofreu nenhuma mudana.
O nvel de complexidade associado a cada transformao uma funo
do nmero de passos de processamento e o nmero de regras semnticas
que controla os passos de processamento.
A dimenso de controle medida pela contagem do nmero de transi-
es entre os estados. Um estado representa algum modo internamente ob-
servvel de comportamento e uma transio ocorre como resultado de algum
evento que fora o software ou sistema a mudar seu comportamento, isto ,
mudar seu estado.
Quando pontos por funo 3D so computados, transies no so as-
sociadas a valores de complexidade.
Nota-se que pontos por funo, "feature points" e pontos por funo 3D
representam a mesma coisa "funcionalidade" ou "utilidade" fornecida pelo
software. De fato, cada uma destas medidas resulta no mesmo valor se so-
mente a dimenso de dados de uma aplicao considerada.
Para sistemas real-time mais complexos, a contagem "feature points"
de 20 a 35% mais alta que a contagem determinada usando somente pontos
por funo.
Pontos por funo (e suas extenses), como a medida LOC, contro-
versa. Os proponentes acham que FP independente da linguagem de pro-
gramao, tornando-se ideal para aplicaes usando linguagens convencio-
nais e no procedurais, e que ela baseada em dados que so conhecidos
XXV

muito cedo na evoluo do projeto, fazendo a FP mais atrativa como uma es-
timativa mais prxima.
Oponentes acham que o mtodo requer alguma prestidigitao em que
a computao baseada em dados subjetivos, que a contagem das informa-
es de domnio (e outras dimenses) podem ser difceis de coletar depois de
terminado o projeto, e que FP no tem significado fsico direto. s um nme-
ro.

Mtricas Voltadas para Orientao a Objeto

Muitas mtricas j foram desenvolvidas para geraes passadas de
tecnologia e, em muitos casos, so usadas at para desenvolvimento OO, po-
rm no so muito coerentes, pois a diferena entre sistemas tradicionais e
sistemas OO so muito grandes.
Existem vrias propostas para mtricas OO que levam em considerao
as caractersticas bsicas e interaes do sistema como: nmero de classes,
nmero de cases, nmero de mtodos, mdias de mtodos, mdias de mto-
dos por classe, linhas de cdigo por mtodo, profundidade mxima da hierar-
quia de classes, a relao existente entre mtodos pblicos e privados, entre
outros.
Tais mtricas baseiam-se na anlise detalhada do design do sistema.
Como na tcnica de pontos-por-funo, faz sentido adicionar um peso s m-
tricas das classes para produzir uma medida de complexidade do sistema. A
maioria das medidas examina atributos em termos dos conceitos de OO, co-
mo herana, polimorfismo e encapsulamento. Para tanto, seria necessrio co-
letar um nmero significativo de contagens, ou seja, seria necessrio tomar
valores de vrios projetos e dimencion-los selecionando as classes, os m-
todos e os atributos desejveis para medir o tamanho e a complexidade de
um novo software, o que nos tomaria um longo tempo.
XXVI
















GQM GOAL QUESTIONS
METRICS
XXVII

GQM GOAL QUESTIONS METRICS


INTRODUO
Hoje, quase todas as organizaes esto envolvidas no desenvolvimento ou uso de software. A
qualidade do software tem uma importncia essencial para a competitividade de uma organizao
no mercado. Mas, na realidade, o processo de desenvolvimento e manuteno de software fre-
qentemente insuficiente com respeito qualidade, produtividade e previsibilidade.
Muitas organizaes estabeleceram processos de desenvolvimento e manuteno de uma maneira
ad-hoc, baseadas em experincias de outras empresas. Isso resultou muitas vezes em solues
incompatveis, conseqncias negativas e equipes sem motivao. Para melhorar a qualidade e
produtividade de software na indstria, necessrio entender o software e os processos de desen-
volvimento e manuteno de software especficos de uma empresa. O problema com o software,
que seu desenvolvimento influenciado por um espectro extremamente grande de fatores como:
de processo (p.ex. tcnicas, ferramentas usadas), produto (p.ex. linguagem de programao, plata-
forma) ou recursos (p.ex. experincia de desenvolvedores). Para adquirir uma viso mais profunda
deste processo de desenvolvimento e dos fatores de influncia, ns necessitamos de modelos for-
mais e de uma forma de organizao para a reutilizao de todo o conhecimento [BCR94a].
especialmente importante definir o nvel corrente de compreenso de processos e produtos de
software em uma empresa de uma forma quantitativa, de forma que as metas de negcios da em-
presa possam ser julgadas se esto satisfeitas ou no. Isso s pode ser obtido em uma empresa
atravs da modelagem e da mensurao explcita dos fatores que influenciam o processo de soft-
ware [Rom91].

PORQUE APLICAR MENSURAO EM PROJETOS DE SOFTWARE?

Geralmente aceito que a mensurao no um fim em si, mas um meio para o fim. Assim, obje-
tivos finais para o estabelecimento de um programa de mensurao em uma organizao de soft-
ware so [NAS94]:
Compreenso dos produtos e processos de software,
Gerncia de projetos de software,
XXVIII

Melhoramento contnuo.

O propsito subjacente de qualquer programa de mensurao deve ser o de alcanar os resultados
especficos da coleta e interpretao dos dados de mensurao. Sem tais objetivos, nenhum bene-
fcio ser alcanado atravs do esforo da mensurao.
Mensurao para compreender produtos e processos de software
Fundamental para o melhoramento sistemtico de processos e produtos de software a compreen-
so e o estabelecimento de linhas-base quantitativas com respeito aos processos atuais na organi-
zao. Esta compreenso dos processos e prticas na organizao crucial para planejar, controlar
e melhorar o desenvolvimento e a manuteno do software.
Exemplos de questes, expressando esta necessidade para compreenso so:
Como est distribudo o esforo no desenvolvimento e na manuteno de software?
Quanto esforo est sendo gasto em rework (devido correo de defeitos)?
Qual a porcentagem de falhas encontradas por inspeo?

Um primeiro passo para abordar estes assuntos estabelecer um a linha-base com respeito aos
produtos e processos de software na organizao. Com base na informao quantitativa ganha
atravs de um programa de mensurao, uma organizao pode construir seus modelos de quali-
dade especficos e pode examinar fatores de contexto que tm um impacto nos modelos. Por e-
xemplo, o esforo para o desenvolvimento de um sistema de software depende do tamanho de
sistema e da experincia dos desenvolvedores. Para uma compreenso completa da combinao
complexa dos vrios fatores de influncia, estes devem ser examinados dentro da organizao
especfica por um programa de mensurao.

Mensurao para gerenciar projetos de software
Os modelos organizacionais baseados na compreenso dos produtos e processos de software e os
fatores de influncia destes podem ser usados para prover melhor informao (quantitativa) para
decises de gerncia. O conhecimento ganho pela anlise e interpretao dos dados de mensura-
o pode ser usado para:

XXIX




Figura 1. Modelo de distribuio de esforo [NAS94]
Planejamento de novos projetos de software com base na estimativa de esforo requerido, cro-
nograma, alocao da equipe, etc. Atravs dos modelos formais baseados em dados de mensu-
rao, conhecimento sobre esses aspectos pode ser reutilizado para um planejamento mais in-
formado e apropriado. Um exemplo o modelo de distribuio de esforo por fases do ciclo
de vida de software na NASA com base em dados analisados de mais de 25 projetos nessa or-
ganizao.
Controle do projeto corrente atravs da comparao dos valores estimativos com os valores
atuais coletados pela mensurao acompanhando o projeto corrente. Resultando da monitoria
do estado do projeto, ajustes e aes corretivas podem ser iniciadas, quando desvios do plano
de projeto ou problemas aparecem. Para possibilitar esta comparao, os dados devem ter sido
coletados em programas de mensurao em projetos semelhantes j completados, e os dados
atuais tm que ser coletados em programas de mensurao do projeto corrente.


GQM

O mtodo GQM descreve o planejamento e execuo de um programa de mensurao baseado no
paradigma GQM. Com base nas experincias de aplicaes do paradigma GQM em vrias empre-
sas, o processo GQM foi modelado em detalhe [GHW95]. Padres suportando o mtodo GQM
foram desenvolvidos [Rom91, Bas92, GRR94], p.ex., para definio das metas. Diretrizes e heu-
rsticas para a aplicao prtica do mtodo GQM so dadas em [BDR97, GRR96, NAS94]. Um
exemplo completo de um programa de mensurao incluindo todos os artefatos relacionados
ilustrado em [GHW95].
A seguir, uma viso geral do mtodo GQM dada, a qual ento descrita passo-a-passo com base
no modelo de processo GQM [GHW95]. Outras experincias especficas de empresas com a apli-
cao do mtodo GQM so reportadas em [Das92, FLM96, SOL95, Sol95]. O escopo do mtodo
GQM inclui o planejamento, a execuo do programa de mensurao, e a captura das experincias
XXX

ganhas durante esse programa sob forma de modelos. As fases do processo GQM so orientadas
ao Paradigma de Melhoria de Qualidade (QIP). Uma viso geral dos passos do processo de um
programa de mensurao dada na figura 4. No comeo do programa de mensurao, um estudo
prvio realizado para encontrar modelos de experincia relevantes baseados nas metas e caracte-
rsticas da organizao e dos projetos. Um projeto piloto para a introduo do programa de men-
surao selecionado e caracterizado. Com base nessa informao, uma meta a ser atingida pelo
programa de mensurao especificada, definindo precisamente objeto, objetivo, enfoque de qua-
lidade, ponto de vista e contexto da anlise. Com respeito meta, um conjunto das medidas rele-
vantes derivado via perguntas e modelos, resultando em um plano GQM consistindo de uma
meta, perguntas, modelos e medidas.











Figura 4. Viso geral
do processo GQM


Um plano de mensurao definido pela integrao das medidas definidas no plano GQM e do
plano de projeto de software atravs da determinao de quando, como, e por quem os dados re-
queridos podem ser coletados. Durante a fase da execuo do programa de mensurao, os dados
so coletados de acordo com o plano de mensurao. Os dados coletados so analisados e inter-
pretados com respeito s metas GQM de acordo com o plano GQM em feedback sessions. Os
resultados de anlise e interpretao so acondicionados em modelos reutilizveis.
Ao se introduzir mensurao baseada em GQM em uma organizao, o mtodo ainda precisa ser
adaptado ao ambiente especfico. Assim, o suporte oferecido pelo mtodo GQM, incluindo des-

XXXI

cries de processos, padres e diretrizes no obrigatrio. Essencial para a aplicao da aborda-
gem GQM so os princpios fundamentais (como descrito acima) que necessitam ser considerados
para realizar um programa de mensurao baseado em GQM com sucesso.
No planejamento e execuo de um programa de mensurao dois papis principais so diferenci-
ados: a equipe de garantia de qualidade e a equipe do projeto (incluindo o gerente do projeto). A
equipe de garantia de qualidade tem conhecimento detalhado do processo GQM e responsvel
pelo planejamento e execuo do programa de mensurao. A equipe do projeto responsvel
pelo desenvolvimento de software no projeto atual e s participa em alguns passos do programa
de mensurao.
Nas prximas sees segue-se uma descrio detalhada de cada passo de um programa de mensu-
rao baseado em GQM. Diretrizes so dadas com base em experincias de empresas aplicando
essa abordagem na prtica.
ESTUDO PRVIO

O objetivo do estudo prvio a coleta de informao que pertinente introduo de um progra-
ma de mensurao na organizao. Esta informao usada para apoiar a seleo de um projeto
piloto para a introduo de um programa de mensurao e a definio das metas de mensurao.
Primeiro, precondies e restries relacionadas introduo do programa de mensurao so
identificados. Isto pode ser feito baseado em documentos j existentes (por exemplo o manual do
processo de software), ou - se disponvel - tambm em experincias de programas de mensurao
anteriores. Alm disso, a organizao caracterizada (p.ex. domnio de aplicao, setor de neg-
cios), e as metas de melhoria organizacionais so identificadas (p.ex. reduzir o nmero das falhas
nos sistemas de software entregues). Projetos potenciais para a aplicao de mensurao so ca-
racterizados (p.ex. durao, representatividade com respeito aos projetos da organizao). Com
base nessas informaes, um projeto piloto selecionado para a introduo de um programa de
mensurao baseado em GQM.

Diretrizes
muito importante que as pessoas envolvidas no projeto piloto que participaram no
programa de mensurao sejam motivadas e concordem com a introduo de um programa de
mensurao. Ento, estas pessoas tm de ser convencidas dos benefcios do estabelecimento
XXXII

de um programa de mensurao baseado em GQM. Isto pode ser feito (p.ex. no contexto de
um seminrio de mensurao) apresentando os benefcios de um programa de mensurao a-
tingidos em outros projetos ou contextos, mostrando como o trabalho deles pode ser apoiado,
quais problemas poderiam ser resolvidos e - se disponvel - histrias de sucesso de outros pro-
jetos.
A caracterizao organizacional e a caracterizao de projeto podem ser apoiadas pelo uso de
questionrios adaptados ao ambiente especfico. Um exemplo de tal questionrio pode ser en-
contrado em [GHW95].
As metas de melhoramento organizacionais so derivadas das metas de negcio e estrat-
gias da empresa. Isto pode ser apoiado mais adiante pela determinao dos fatores crticos de su-
cesso e reas de problema existentes na organizao.
A existncia de um modelo de processo de software essencial para planejar e executar
um programa de mensurao [BDT96]. Se nenhum existe refletindo o processo de software usado
no projeto atual, um modelo de processo descritivo tem que ser desenvolvido durante esta fase do
programa de mensurao.
Quando introduzindo mensurao baseada em GQM, o projeto piloto deveria ser sele-
cionado de acordo com os seguintes critrios [BDR97, GHW95]:
-deveria ser um projeto tpico para a organizao
- possvel de motivar a equipe de projeto para a aplicao de novas tecnologias
-escolher um projeto com necessidade de melhoramento
-considere os recursos dedicados ao programa de mensurao. Em geral, a durao do
projeto e o tamanho da equipe deveria ser razoavelmente pequena. -o projeto no deveria possuir
muito riscos.
Durante esse passo os participantes do programa de mensurao tm de ser treinados de
acordo com os papis deles na mensurao. O treinamento deveria cobrir o paradigma GQM (para
a compreenso bsica) e uma apresentao dos passos nos quais eles participaro ativamente.

IDENTIFICAO DE METAS GQM

Com base nas metas organizacionais e do projeto piloto, as metas a serem alcanadas pelo pro-
grama de mensurao so determinadas, como uma base para o desenvolvimento de um programa
de mensurao efetivo.
XXXIII


Com base na informao de contexto coletada no estudo prvio, metas GQM so derivadas das
metas de negcio, das metas estratgicas da organizao, ou mais diretamente das metas organi-
zacionais de melhoramento com respeito aos problemas conhecidos. As metas atingidas pela men-
surao so formuladas como metas GQM em termos de [BDR97,BCR94]:

O modelo da meta GQM foi desenvolvido para indicar a informao necessria para a
meta da mensurao e assim apia a atividade de definir a meta. A mensurao pode
ser direcionada aos vrios objetivos [BDR97]:
Caracterizao visa formar um instantneo do estado/performance atual dos pro-
dutos de processos de software.
Avaliao visa comparar e avaliar produtos e processos de software.
Monitorando visa seguir as tendncias/evoluo do estado/performance de pro-
cessos e produtos.
Predio visa identificar relaes entre vrios fatores de processo e produto, u-
sando estas relaes para predizer atributos externos pertinentes a produtos e proces-
sos.
Controle visa identificar relaes causais que influenciam o estado/performance
de processos e produtos.
Modificao visa identificar relaes causais para mudar o processo de software
para obter qualidade de produto e produtividade de processo mais alta.

Para se concentrar nas metas mais importantes, as metas GQM identificadas so priori-
zadas com respeito s necessidades da organizao e do projeto piloto e as mais impor-
tantes so selecionadas e aplicadas no projeto piloto.
Diretrizes
Para considerar o conhecimento e as experincias de todas as pessoas envolvidas no projeto
piloto, as metas GQM deveriam ser identificadas durante uma sesso de brainstorm. Isto tam-
bm importante devido ao fato de que o programa de mensurao s ser aceito, se as pessoas
Dimenso Definio Exemplo
Objeto de Estudo O que ser analisado? Processo de desenvolvimento, teste, documento de proje-
to, sistema de software
Objetivo Porque o objeto ser ana-
lisado?
Caracterizao, avaliao, predio, monitora, controle,
modificao
Enfoque de Qualidade Qual atributo do objeto
ser analisado?
Confiabilidade, custos, correo, remoo dos defeitos,
modificaes, manutenibilidade
Ponto de Vista Quem ser usar os dados
coletados?
Gerente do projeto, desenvolvedor, equipe de garantia de
qualidade, usurio, gerente
Contexto Em qual ambiente est
localizado?
Projeto A, departamento x,
XXXIV

sentem as necessidades delas refletidas e expressas pelo programa de mensurao.
As seguintes questes, que implicitamente consistem numa caracterizao de projeto e
organizao e identificao de meta de melhoramento, podem estimular a discusso para a defini-
o de meta [Sol95]:
1. O que so as metas estratgicas da organizao?
2. Que foras tm impacto nas metas estratgicas?
3. O que so as estratgias para alcanar as metas estratgicas da organizao?
4. Como voc pode melhorar a performance? O que so as preocupaes principais (problemas)?
5. O que so as metas de melhoria?
6. Como voc pode alcanar as metas de melhoria?
7. O que so possveis metas de mensurao? Quais metas de mensurao sero selecionadas?

Na definio de dimenses de metas os seguintes aspectos deveriam ser considerados [BDR97,
GHW95]:
-Objeto de Estudo deveria enfocar produtos ou processos com necessidade de serem compre-
endidos melhor. O modelo de processo pode ajudar a identificar e definir objetos relevantes.
. Objetivo deveria ser adaptado ao nvel de compreenso dos problemas na empresa (p.ex.
antes de comear modificar necessrio caracterizar a situao atual). O objetivo tambm precisa
ser adaptado estabilidade do processo e ao controle da performance.
. Enfoque de Qualidade deveria ser consistente com a prioridade de metas de melhoramen-
to organizacionais e deveria enfocar os pontos fracos mais urgentes em relao ao processo de
software.
. Ponto de Vista. Se GQM est sendo usado pela primeira vez recomendvel definir me-
tas GQM sob trs pontos de vista diferentes:

. ponto de vista das pessoas tcnicas que executam o projeto, p. ex. desenvolvedor
. ponto de vista do gerente do projeto
. ponto de vista das pessoas que pelo para o programa de mensurao, p.ex., gerente snior
Isto assegura que todas as pessoas pertinentes sero envolvidas e recebem benefcios do programa
de mensurao que em troca aumentar aceitao e cooperao de todas.
As metas GQM deveriam ser selecionadas rigorosamente se concentrando s nos assuntos mais
centrais e algumas metas importantes para assegurar o sucesso do programa de mensurao.
importante comear com poucas metas, para manter os custos baixos e mostrar a usabilidade
XXXV

da mensurao antes de amplificar o programa.
DESENVOLVIMENTO DO PLANO GQM

Planos GQM contm a informao necessria para planejar mensurao e analisar e interpretar os
dados coletados [BDR97]. De acordo com as metas GQM, um plano GQM desenvolvido para
cada meta GQM selecionada. Um plano GQM consiste de uma meta GQM e um conjunto das
perguntas, modelos e medidas [BDR97,BCR94]. O plano define precisamente porque as medidas
so definidas e como elas sero usadas. As perguntas identificam a informao necessria para
atingir a meta e as medidas definem operacionalmente os dados a serem coletados para responder
as perguntas. O modelo usa os dados coletados como entrada para gerar respostas s perguntas.
Para determinar as perguntas relevantes com respeito meta, entrevistas so feitas. O objetivo das
entrevistas adquirir o conhecimento implcito das pessoas envolvidas. Essas entrevistas so fei-
tas com as pessoas declaradas no ponto de vista da meta GQM, p.ex. desenvolvedores ou o geren-
te de projeto. O conhecimento adquirido durante a(s) entrevista(s) usado como uma base para a
derivao das perguntas, modelos e medidas relevantes meta.
Entrevistas GQM
As entrevistas deveriam ser feitas com as pessoas que so especificadas na dimenso ponto de
vista da meta GQM. Isto assegura que a informao pertinente ganha das pessoas que so os
peritos em relao perspetiva da meta de mensurao. Durante a entrevista, deveriam ser enfo-
cados os seguintes tpicos [GHW95,GRR94]:
Fatores de Qualidade: O que significa o enfoque de qualidade especificado na meta GQM
ao entrevistado?
Hiptese de Linha-Base: Para cada fator de qualidade que pertence ao enfoque de qualida-
de declarado: qual a estimativa do entrevistado no estado atual ao fator de qualidade?
Fatores de Variao: Quais fatores ambientais variveis tm possivelmente um impacto
nos fatores de qualidade?
Impacto na Hiptese de Linha-Base: Para cada fator de variao declarado: Qual a
estimativa do entrevistado do impacto do fator de variao no fator de qualidade?

Uma ferramenta para a aquisio e estruturao de conhecimento durante as entrevistas o Abs-
XXXVI

traction Sheet [GRR94]. O abstraction sheet um documento de uma pgina com quatro qua-
drantes, um para cada dos tpicos mencionados acima. No cabealho declarada a meta GQM
(veja figura 5).
O abstraction sheet facilita a comunicao entre a equipe de GQM e a equipe de projeto durante a
entrevista e a reviso do plano GQM representando uma viso simplificada do plano GQM. O
conhecimento adquirido durante uma entrevista documentado em um abstraction sheet. Para
completar a compreenso com respeito a uma meta GQM, o conhecimento resultando de varias
entrevistas com respeito meta resumido em um abstraction sheet. Conflitos e inconsistncias
que surgem juntando a informao tem que ser resolvidos em follow-up interviews.







Figura 5. Exemplo de um Abstraction Sheet

Diretrizes
Para capturar todas as informaes relevantes, entrevistas com varias pessoas representando o
ponto de vista declarado na meta deveriam ser feitas. E, para esclarecer pontos abertos vrias en-
trevistas em seguida poderiam ser necessrias.
Durante as entrevistas possivelmente pode ficar bvio que as metas GQM selecionadas no
cobrem adequadamente os objetos/objetivos a serem medidos. Neste caso, primeiro as metas
GQM tm que ser redefinidas.
A realizao de entrevistas individuais ampliam o conhecimento adquirido. Se isto im-
possvel, entrevistas podem acontecer em grupos pequenos dependo da dinmica do grupo perti-
nente com respeito possibilidade de discusses abertas e eventuais controvrsias.
Os entrevistados precisam ser motivados, treinados e informados sobre o programa de
mensurao e qual informao esperada deles nas entrevistas.
Objeto Processo de software Objetivo caracterizar Enfoque de Qualidade confiabili-
dade Ponto de Vista desenvolvedor Contexto Empresa x, Projeto A
Fatores de Qualidade Fatores De variao
-nmero total de defeitos -nmero dos
defeitos por criticalidade (no-crtico,
crtico) -nmero de defeitos por fase de
ciclo da vida introduzido (REQ, HLD,
LLD/IMP) -esforo total de rework (em
horas)
-tipo de inspeo de cdigo -experincia
de pessoas da equipe de desenvolvimento
Hiptese de Linha-Base Impacto na Hiptese de Linha-Base
- nmero total de falhas: 120 - com ad-hoc inspees de cdigo menos
-75% no-crtico, 25% crtico defeitos sero detectados do que com
-REQ 10, HLD 20, LLD/IMP 40, outros tipos de inspees.
TESTE 30 - pessoas da equipe de desenvolvimento
- esforo total de rework: 1000 h mais experientes introduzem menos defei-
tos.
XXXVII

No comeo confiana precisa ser assegurada e deve ser explicado como a informao ser
usada.
O entrevistador precisa ser bem preparado ao respeito meta especfica, o processo de
software a terminologia usados no projeto piloto. Experincias de programas de mensurao se-
melhantes podem ajudar na preparao das entrevistas.
A tarefa do entrevistador a aquisio de conhecimento, ele no deveria influenciar o
entrevistado em qualquer direo.
Modelos organizacionais, p.ex. o modelo de processo de software pode ser usado como
ponto de referncia na entrevista, se isto considerado til pelo entrevistado.

Refinamento de Plano GQM

O objetivo a definio quantitativa da meta GQM em um conjunto de medidas via perguntas e
modelos, com base nos fatores de qualidade e fatores de variao adquiridos durante as entrevis-
tas.
Neste passo o plano GQM desenvolvido. Primeiro, as perguntas so derivadas, expressando a
necessidade de informao em linguagem natural. Um exemplo de uma pergunta : Quantos de-
feitos so detectados dependente do tipo da inspeo usada? A resposta para uma pergunta pode
ser atingida atravs dos dados coletados e interpretados para as medidas derivadas atravs de mo-
delos de qualidade.
As perguntas so derivadas com base na informao documentada no abstraction sheet. Para cada
fator de qualidade no abstraction sheet, uma ou mais perguntas so formuladas expressando a
necessidade de informao relacionada ao fator de qualidade. A informao contida na seo fa-
tores de variao do abstraction sheet usada para derivar perguntas com respeito ao contexto
pertinente. Um exemplo dado na figura 6 com base no abstraction sheet mostrado em figura 5.
Para a operacionalizao dos planos GQM, modelos de qualidade precisam ser construdos. Os
atributos abstratos dos artefatos avaliados, p.ex., reutilizabilidade de componentes, precisam ser
definidos numa forma operacional adequada s metas e considerando suposies plausveis sobre
o meio ambiente em modelos descritivos [BDR97]. Comparaes e avaliaes precisam ser defi-
nidas precisamente pelo modelos de avaliao, p.ex. avaliando a complexidade de um componen-
te em relao aos outros componentes do domnio. Para fazer predies modelos preditivos preci-
XXXVIII

sam ser construdos. Isso inclui a considerao da forma funcional do modelo, a tcnica usada
para a construo e fatores de influncia.

DESENVOLVIMENTO DO PLANO DE MENSURAO

O objetivo principal do desenvolvimento do plano de mensurao a integrao apropriada de
medidas no plano do projeto. Para cada medida identificada nos planos GQM do programa de
mensurao, determinado quando, como e por quem os dados so coletados de acordo com o
processo de software. Critrios importantes que precisam ser considerados no desenvolvimento
dos procedimentos de coleta de dados so: a confiabilidade dos dados coletados e a intrusividade
da coleta dos dados [BDR97]. Os custos relacionados coleta dos dados deveriam ser minimiza-
dos at onde for possvel.
Para cada medida, o instante de tempo precisa ser determinado, o qual o melhor para coleta dos
dados. Dependente de objetivo de mensurao e dos dados coletados, trs tipos principais de es-
tratgias podem ser adotados para a coleta dos dados [BDR97]:
periodicamente (p.ex. coleta de dados de esforo por dia ou semana)
comeo/fim de atividades/fases (p.ex. grau de deteco de defeitos no fim da inspeo)
transio de estado de artefato (p.ex. complexidade de componentes quando eles entram
na gerncia de configurao)

Na definio do instante de tempo necessrio definir o nvel de granularidade de updates em
caso de uma coleta peridica. A definio de instantes de tempo orientada s atividades feita
com base no modelo de software que descreve as atividades e artefatos usados ou produzidos pe-
los processos. Diagramas de transio de estado de produtos podem ajudar definir os instantes de
tempo relacionados s transies de estados de artefatos.
Quando um cronograma para a coleta foi definido, determinado quem pode ou deve coletar os
dados. A primeira deciso se existe uma ferramenta para automatizar a coleta de dados. Se no,
subjetividade no poder ser prevenida. Assim a determinao do/a papel/pessoa certo/a para a
coleta de dados muito importante. Aqui os seguintes critrios deveriam ser considerados [B-
DR97]:
Expertise: Quem tem a expertise tcnica/gerencial para prover os dados com preciso?
Preconceito: H qualquer razo para o provedor de dados mostrar qualquer preconceito
XXXIX

nos dados ele prov?
Acesso: Quem tem acesso ao objeto que est sendo medido?
Custo: Pode o tempo gasto pela pessoa para coleta de dados ter efeitos crticos nos custos
do projeto?
Disponibilidade: A pessoa est disponvel para a coleta de dados?
Motivao: A pessoa est interessada no programa de mensurao?

Alm de se determinar quem coletar os dados, precisa ser determinado quem responsvel pela
garantia de qualidade e o armazenamento dos dados.
O projeto de instrumentos de mensurao crucial para receber dados confiveis. Trs categorias
de instrumentos de coleta de dados podem ser identificadas:
ferramentas (p.ex. analisadores de cdigo estticos)
questionrios
entrevistas estruturadas
A deciso sobre qual instrumento utilizado depende aos dados coletados. Fer-
ramentas podem ser usadas para medidas objetivas de artefatos (p.ex. linhas de cdi-
go), questionrios e entrevistas estruturadas para medidas de processo (p.ex. esforo
de rework) e medidas subjetivas de artefatos (p.ex. usabilidade de uma interface).


COLETA DE DADOS

Durante a fase de execuo do programa de mensurao, os dados so coletados de acordo com o
plano de mensurao.
Quando os dados foram coletados, tm de passar por um processo de garantia de qualidade antes
de poderem ser armazenados ou analisados. O processo de garantia de qualidade de dados coleta-
dos aborda os seguintes assuntos:
Completude. Precisa ser garantido que todos os questionrios foram submetidos e esto
completos (isso significa, se todos os dados necessrios foram providos). Se faltam alguns dados,
a causa precisa ser determinada, p.ex., as perguntas no so aplicveis no contexto especfico, no
so compreensveis, ou consideradas irrelevantes.
XL

Plausibilidade. Precisa ser controlado se os dados so do tipo especificado (p.ex. campos
numricos contendo valores no numricos) e a plausibilidade desses valores (p.ex. um valor de
100 horas para o esforo de uma pessoa por semana no plausvel).

Se o processo de garantia de qualidade descobre dados defeituosos ou faltantes, estes dados deve-
riam ser discutidos com os coletores de dados. Quando possvel, eles tm de corrigir os dados. Se
alguns dados especficos apresentam uma baixa confiabilidade regularmente, os procedimentos de
coleta de dados e/ou treinamento dos coletores deveriam ser reconsiderados, avaliados e eventu-
almente melhorados.
Os dados vlidos so armazenados no banco de dados de mensurao disponveis para a anlise.
Depois que os dados foram includos no banco de dados, necessrio controlar se as entradas
correspondem os dados originais.
Diretrizes
O tempo entre a coleta e garantia de qualidade de dados no deveria ser muito longo, para
permitir a correo, em caso da coleta de dados incompletos ou falsos.
Se dados histricos so usados no programa de mensurao para uma anlise postmortem,
este passo de processo s contm a garantia de qualidade dos dados j disponveis.
A garantia de qualidade e o armazenamento dos dados coletados manualmente deveriam
ser feitos com grande cuidado, uma vez que este processo uma fonte de erros. Este processo
pode ser suprfluo ou (pelo menos parcialmente) automatizado para dados que so coletados on-
line.

ANLISE DOS DADOS

Para anlise de dados podem ser aplicados p.ex. testes ao respeito s hipteses propostas no plano
GQM. O objetivo da anlise identificar padres e relaes entre atributos para permitir o estabe-
lecimento de linhas-base e a identificao de reas problemticas.
A anlise estatstica pode ser aprimorada atravs de uma anlise qualitativa, p.ex. usando a teoria
de Rough Sets [Ruh96, Paw91]. O objetivo gerar regras descrevendo e agregando resultados
experimentais. A teoria de Rough Sets deriva regras se-ento agregadas que podem ser usadas
XLI

formalmente como a base para a integrao de conhecimento de um perito humano com as regras
derivadas da anlise de dados experimentais [CGF97]. Um exemplo dessas regras pode ser, SE
(Tipo de verso = A) E (Nmero de modules novos = baixo) E (Nmero de LOC mudado = m-
dio) ENTO (esforo = muito alto).
A anlise de dados guiada pelo plano GQM. Os dados atuais so comparados com as hipteses
de linhas-base. As hipteses sobres as relaes entre os fatores de qualidade e os fatores de varia-
o so validadas e quantificadas [BDR97].
Comparao com linhas-base
Os dados coletados podem ser usados para construir linhas-base quantitativas para os projetos de
software da organizao. Em geral, interessante comparar as linhas-base medidas atualmente
com as hipteses esperadas que so definidas nos abstraction sheets. Isto permite investigar di-
vergncias e ativar discusses entre os desenvolvedores e gerentes para a interpretao dos dados.
Alm disso, essas divergncias provavelmente induzem a investigaes dos dados adicionais na
procura por fatores que explicam as diferenas.
Validao de hipteses sobre o impacto de fatores de variao
Dependendo do propsito da meta GQM, estratgias diferentes so aplicadas [BDR97]. Para o
objetivo de predio, as hipteses sobre o impacto de fatores de variao so testadas com respei-
to seguinte pergunta: o fator de variao teve o impacto esperado no fator de qualidade?
Se o impacto esperado no pode ser verificado, a excluso do fator de variao da coleta de dados
considerada, assumindo o uso de uma tcnica de modelagem adequada e um conjunto de dados
apropriado. Se o impacto esperado observado, a relao identificada pode ser usada para cons-
truir modelos novos ou mais confiveis para a administrao de projeto, garantia de qualidade etc.

Para o objetivo de controle ou mudana, assumindo que o fator de variao j mostrou que tem
algum impacto, a anlise se concentra em determinar se ou no este impacto devido a uma rela-
o causal entre o fator de qualidade e o fator de variao.
Os resultados da anlise de dados coletados so uma entrada essencial para a interpretao de
dados.
INTERPRETAO DOS DADOS
XLII


O dados coletados e analisados so interpretados no contexto da meta de mensurao. A interpre-
tao dos dados coletados feita em feedback sessions, reunies dos representantes do ponto de
vista especificado na meta e coletores de dados. O objetivo dos feedback sessions interpretar os
dados coletados com pessoal que tem a expertise necessria. Assim os dados analisados so apre-
sentados aos participantes da reunio, interpretaes possveis discutidas e modificaes para
melhoramento planejadas [BDR97, HOR96, GHW95].
Preparo do material de apresentao
O material a ser apresentado e discutido durante o feedback session preparado com base nos
dados coletados no contexto do plano GQM. O plano GQM apoia a anlise e a interpretao dos
dados sendo seguido bottom-up. As perguntas colocadas no plano GQM sero discutidas no feed-
back session com base nos dados coletados com respeito s perguntas. Para isso, os dados coleta-
dos so combinados s medidas no plano GQM e processados como descrito no modelo. Esses
resultados so colocados junto com as perguntas correspondentes e comparados s hipteses inici-
ais.
Diretrizes
O material de feedback session deveria indicar as perguntas do plano GQM que ele pre-
tende responder, a hiptese correspondente e o nmero de pontos de dados subjacentes.
Os dados deveriam ser apresentados numa forma fcil de entender, p. ex., evitar listas
longas de nmeros etc.
Valores inesperados ou pontos de dados que foram interpolados deveriam ser marcados.
Material indicando tendncias identificadas na anlise de dados pode ser adicionado.
Aspectos de privacidade com respeito aos dados precisam ser considerados cuidadosa-
mente. importante que sejam discutidos os assuntos de privacidade de dados abertamente e le-
vada a srio qualquer preocupao de algum dos participantes. Para assegurar privacidade s da-
dos acumulados deveriam ser includos no material.
O material de apresentao deveria ser entregue antes do feedback session para os partici-
pantes. Se o material de apresentao no esta pronto a tempo, recomendado postergar a reunio
em vez de executar o feedback session com pessoas desprevenidas.

Execuo de feedback sessions
O objetivo principal dos feedback sessions a interpretao de dados de mensurao, a verifica-
XLIII

o das hipteses declaradas nos planos GQM, e a identificao das possibilidades para melhora-
mento do processo de software.
Feeback sessions so reunies de grupo. Participantes so as pessoas que representam o ponto de
vista especificado nas metas, e os coletores de dados. O objetivo aproveitar o conhecimento
especifico dessas pessoas sobre o objeto avaliado na interpretao de dados para atingir conclu-
ses vlidas no contexto especifico. Alm disso, essas pessoas vo ser afetadas pelas mudanas de
processo atingindo o melhoramento da qualidade. A identificao e discusso dessas mudanas
com todas as pessoas envolvidas nos feedback sessions tambm ajuda a receber o comprometi-
mento pessoal necessrio para a realizao dessas mudanas [GHW95, SOL95,Sol95].
O material de apresentao deveria ser estruturado com respeito ao plano GQM e pelo menos
contar com todos os pontos de discusso identificados na anlise. Isso pode incluir:
explicao de divergncias existentes entre os dados atuais e as hipteses especificadas no
abstraction sheet
discusso de tendncias identificadas na anlise
verificao de relao entre fatores de qualidade e fatores de variao.

As pessoas que representam os pontos de vista das metas sabem usar os dados para os propsitos
delas, e os coletores de dados sabem quo bem os dados providos foram coletados na verdade e se
eles esto de acordo com a finalidade das metas de mensurao. Por exemplo, falsas concluses
podem ser tiradas de um nmero pequeno de falhas que so informadas, se os coletores de dados
no informam que nem toda falha identificada durante o teste foi informada devido presso de
tempo.
Os pontos de vista (e s eles) pode tirar concluses dos dados que altamente dependem do contex-
to do programa de mensurao. A razo subjacente que conduz s concluses e todas as explica-
es relacionadas deve ser documentada. Isto necessrio para que essas concluses sejam ques-
tionadas e refinadas mais tarde, se concluses incompatveis ou complementares so tiradas du-
rante feedback sessions futuros.
A interpretao dos dados deveria conduzir identificao de fraquezas dos processos aplicados e
discusso de possveis estratgias de melhoramento. Todas as sugestes e mudanas intenciona-
das para melhoramento precisam ser documentadas em detalhes para assegurar que estas mudan-
as sejam implementadas de fato. Caso contrrio, a conseqncia seria uma motivao imensa-
XLIV

mente reduzida das pessoas envolvidas. A iniciao de mudanas para alcanar melhoramento do
processo de software tem que ser preparada especificando pontos de ao para cada mudana:
Qual modificao foi concluda?
Quem responsvel pela implantao de modificaes?
Quando tem a modificao que ser implantada?

Uma outra meta importante dos feedback sessions a avaliao do programa de mensurao. Sub-
seqentemente aos feedback sessions, a anlise pode ser refinada, e se necessrio, tambm
o plano GQM e os procedimentos de coleta de dados com base em novas perguntas sugeridas. Se
interpretaes alternativas ainda existem depois do feedback session, anlises adicionais dos da-
dos podem ajudar selecionar a mais provvel. Durante os feedback sessions novos problemas po-
dem ser identificados e podem exigir uma anlise adicional para dirigi-los corretamente. Tambm,
a necessidade de dados adicionais para responder as perguntas pode ser identificada, necessaria-
mente resultando numa atualizao adequada do plano GQM.
O feedback session um meio para avaliar o prprio programa de mensurao:
Se alguns dados de mensurao mostram ter pequeno ou nenhum uso ou se referem a uma
pergunta que j foi respondida, esses dados (e as perguntas correspondentes) so excludos do
plano GQM.
Se os procedimentos de coleta so muito intrusivos, muito demorados, eles devem ser
simplificados.
Formas diferentes de apresentaes de dados podem ser propostas.
O foco de interesse pode mudar durante o programa de mensurao. Os feedback sessions
so o lugar certo para discutir a modificao ou expanso do programa de mensurao.

Em cada destes casos o plano GQM e o plano de mensurao precisam ser atualizados respecti-
vamente.
Os feedback sessions so uma parte imperativa do programa de mensurao onde aprendizagem
acontece. Os participantes do programa de mensurao so altamente motivados provendo e rece-
bendo feedback. Alm disso, as pessoas da equipe do projeto percebem que o programa de mensu-
rao atualmente apoia o trabalho delas, e no avalia-as.
XLV

Diretrizes
Feedback sessions deveriam ser feitos periodicamente (p. ex. cada 6-8 semanas) depen-
dendo da disponibilidade de dados novos. Se os intervalos entre feedback sessions so muito lon-
gos, h o risco de se perder o embaloe a motivao no programa de mensurao.
A durao de um feedback session recomendada no levar muito mais tempo do que 3
horas, porque requer um nvel alto de ateno por parte do participante.
Se os participantes no podem usar os dados, isto pode ser explicado de modos diferen-
tes:
Os resultados no so apresentados numa forma adequada ou compreensvel aos partici-
pantes.
Os dados no enfocam a meta de medida declarada, p.ex., as medidas definidas no captu-
ram o atributo que aquele pretende medir.
-Alguma informao necessria falta, p.ex., alguns fatores de contexto relevantes no es-
to sendo medidos.
Pode ser til ter acesso on-line ao banco de dados de mensurao durante o feedback
session. Assim, alguns pedidos para informao adicional podem ser satisfeitos imediata-
mente atravs de acessos on-line ao banco de dados.
Toda a interpretao feita pelas pessoas que representam o ponto de vista da meta. S
estas pessoas podem prover interpretaes vlidas. At mesmo, se resultados da anlise so inclu-
dos no material de feedback session, as decises concludentes se aceitar ou rejeitar uma hiptese
permanecem atadas a estas pessoas.
A implementao da modificao concluda essencial: caso contrrio o programa de
mensurao s implica esforo adicional sem qualquer benefcio.

CAPTURA DE EXPERINCIAS

O objetivo capturar explicitamente as experincias ganhas durante o programa de mensurao
para reutilizar esse conhecimento em projetos de software futuros [GB97, BCR94a]. Os dados
coletados, analisados e interpretados no programa de mensurao so usados para construir mode-
los organizacionais, como p.ex. modelos de custos e perfis de erro.
O impacto do uso de tecnologias em projetos de software analisado, como p.ex. projeto orienta-
do a objetos ou inspees. Esses experincias so continuamente sintetizadas a partir de vrios
projetos para se ganhar uma compreenso geral de produtos e processos na organizao. Identifi-
XLVI

cando tipos especficos de projetos, linhas-base so estabelecidas para modelos de qualidade na
organizao. Modelos de processos e produtos bsicos so desenvolvidos para a organizao.
Essas experincias so capturadas explicitamente em forma de [NAS94]:
Polticas e guias de gerncia de software, incluindo vrios modelos, p.ex. modelos prediti-
vos de esforo.
Padres de desenvolvimento e manuteno de software, definindo produtos, mtodos,
tcnicas e ferramentas que se mostraram benficas para a organizao.
Material de treinamento com respeito s tecnologias novas, padres, ferramentas ou pro-
cessos introduzidos na organizao.
Ferramentas e suporte automatizado, ajudando a gerncia de software, desenvolvimento
e manuteno ou processos de coleta de dados, p.ex. uma ferramenta para estimao de custos
com base em modelos locais.
Relatrios de estudos de processo enfocando as questes especficas, os mtodos aplica-
dos, os resultados medidos e os concluses a que se chegou.

Diretrizes
A aprendizagem sistemtica e a captura das experincias tem que ser separada do desen-
volvimento e manuteno de software [BCR94a].
Os pacotes de experincia tm que ser adaptveis s necessidades, extensveis, compreen-
sveis e acessveis aos projetos de software futuros.

RESUMO E CONCLUSO

A aplicao de mensurao baseada em GQM provou ter muito sucesso em vrias empresas. A
abordagem de GQM mostrou ser satisfatria para estabelecer um programa de mensurao efetivo
que enfoca a ateno nas reais causas de problemas do processo e produto de software. Como
resultado dos programas de mensurao a compreenso da qualidade do produto e do processo de
software aumentou significativamente. Os resultados da mensurao baseada em GQM permiti-
ram identificar foras e fraquezas do produto e processo e, assim, oportunidades para melhora-
mento baseadas na anlise qualitativa e quantitativa. Como est mostrado no captulo 5.2 benef-
cios considerveis de aplicar esta tecnologia foram identificados. O esforo adicional exigido
XLVII

considerado aceitvel pelas empresas, comparando com os benefcios alcanados.
Para aplicar mensurao e a abordagem GQM na prtica com sucesso, algumas linhas-base devem
ser consideradas [CEM96, Das92, NAS94]:
Infra-estrutura para mensurao necessria, isso inclui o estabelecimento de um grupo de
trabalho enfocando a garantia de qualidade do processo de software.
A gerncia tem que se comprometer com o programa de mensurao e apoiar modifica-
es motivadas atravs da mensurao.
Todas as pessoas envolvidas no programa de mensurao deveriam participar ativamente
no programa de mensurao.
Envolvimento de gerentes de projeto na administrao do programa de GQM.
Todas as pessoas envolvidas precisam ser informadas e treinadas apropriadamente.
Alocao de recursos suficientes para o programa de mensurao.
Um pr-requisito para o estabelecimento de um programa de mensurao com sucesso
a disponibilidade de um modelo de processo de software. O processo de software e os produtos
relacionados precisam ser modelados e os papeis envolvidos definidos.
Comea com um conjunto de medidas enfocando reas de melhoramento importantes e
evolui esse conjunto com tempo, ao invs de debater interminavelmente tentando de achar as me-
didas perfeitas.
As pessoas da equipe do projeto so os melhores para interpretar os dados coletados,
porque elas tm o expertise no domnio do projeto e podem derivar interpretaes vlidas. Um
consultor externo com expertise na analise de dados na rea de engenharia de software pode aju-
dar a iniciar e guiar essas atividades.
Ferramentas para suportar o programa de mensurao no so necessrias, mas podem
ajudar a implantao e reduzir o esforo necessrio facilitando a coleta dos dados. Essas incluem
p.ex. sistemas para clculo de custos, sistemas de gerncia de configurao, e sistemas de detec-
o de problemas. Mas automatizao tem limites e no todos os dados podem ser coletados au-
tomaticamente.
No enfoque na coleta de dados mas na anlise e interpretao dos dados.
No avalie ou controle pessoas pela mensurao. Mensurao no deveria ser usada para
qualificar ou caracterizar diferenas entre indivduos. Isto garante a confiabilidade de dados indi-
XLVIII

viduais.
Mensurao tem que ser integrada completamente nas atividades de projeto regulares para
ganhar aceitao e reduzir esforo relacionado.
Feedback sessions so o mecanismo chave para a interpretao dos dados.
Refinamento/adaptao contnuo do programa de mensurao no contexto e nas metas.

Mensurao no a meta. A meta melhoramento de processo de software atravs de mensurao
e os dados coletados, analisados e interpretados. Atravs da mensurao s podem ser mostrados
os problemas existentes e mudanas para melhoramento podem ser apontadas. Mas s a implanta-
o/realizao dessas mudanas pode trazer resultados e assim benefcios.
XLIX


REFERNCIA BIBLIOGRFICA
[Bas92] V. R. Basili. Software Modelling and Measurement: The Goal/Question/Metric Para-
digm. Technical Report CS-TR-2956, Department of Computer Science, University of Mary-
land, MD 20742, September 1992.
[BCM92] V. R. Basili, G. Caldiera, F. McGarry, R. Pajerski, G. Page, S. Waligora. The Software
Engineering Laboratory-An Operational Software Experience Factory. ACM,1992.
[BCR94a] V. R. Basili, G. Caldiera and H. D. Rombach. Experience Factory. In John C. Mar-
ciniak, editor, Encyclopedia of Software Engineering, volume 1. John Wiley & Sons, 1994.
[BCR94b] V.R. Basili, G. Caldiera and H. D. Rombach. Goal Question Metric Paradigm. In John
C. Marciniak, editor, Encyclopedia of Software Engineering, volume 1. John Wiley & Sons,
1994.
[BDR97] L. C. Briand, C. M. Differding and H. D. Rombach. Practical Guidelines for Measure-
ment-Based Process Improvement. Software Process Improvement and Practice, vol. 2, 1997.
[BDT96] A. Brckers, C. Differding and G. Threin. The Role of Software Process Modeling in
Planning Industrial Measurement Programs. In Proceedings of the METRICS 96. ICSE, 1996.
[BR88] V. R. Basili, H. D. Rombach. The TAME Project: Towards Improvement-Oriented Soft-
ware Environments. IEEE Transactions on Software Engineering, SE-14(6), 1988.
[BW84] V. R. Basili and D. M. Weiss. A Methodology for Collecting Valid Ssoftware Engineer-
ing Data. IEEE Transactions on Software Engineering, SE-10(6):728-738, November 1984.
[CEM96] The CEMP Consortium. Customized Establishment of Measurement Programs. Final
Report, ESSI Nr. 10358, 1996.
[CGF97] G. Cugola, C. Gresse, P. Fusaro, A. Fuggetta, L. Lavazza, S. Manca, M. R. Pagone,
G. Ruhe, R. Soro. A Case Study of Evaluating Configuration Management Practices with
Goal-Oriented Measurement. In Proceedings of the 4th International IEEE Symposium on
Software Metrics, 1997.
[Das92] M.K. Daskalantonakis. A Practical View of Software Measurement and Implementation
Experiences within Motorola. IEEE Transactions on Software Engineering, Vol. 18, No. 11,
1992.
[DHL95] C. Differding, B. Hoisl, C. Lott. Technology Package for the Goal/Question Metric
Paradigm. Technical Report 281-96, University of Kaiserslautern, Department of Computer
Science, D-67653 Kaiserslautern, Germany, 1995.
[GB97] C. Gresse, L. Briand. Requirements for the Know-ledge-Based Support of Software Engi-
neering Measurement Plans. In Proceedings of the 9th Int. Conference on Software Engineer-
ing and Knowledge Engineering, Spain, 1997.
[GHR97] C. Gresse, B. Hoisl, H. D. Rombach, G. Ruhe. Kosten-Nutzen-Analyse von GQM-
basiertem Messen und Bewerten: Eine replizierte Fallstudie. In O. Grn and L. J. Heinrich, ed.,
Wirtschaftinformatik - Ergebnisse empirischer Forschung, Springer Verlag, 1997.
L

[GHW95] C. Gresse, B. Hoisl, J. Wst. A Process Model for GQM- Based Measurement. Techni-
cal Report STTI-95-04-E, Software Technology Transfer Initiative, University of Kaiserslau-
tern, Department of Computer Science, Kaiserslautern, Germany, 1995.
[GRR94] H. Gnther, H. D. Rombach, and G. Ruhe. Kontinuierliche Qualittsverbesserung in der
Software Entwicklung - Erfahrungen bei der Allianz Lebensversicherungs-AG (in German).
Wirtschaftsinformatik 38, 1994.
[FLM96] A. Fuggetta, L. Lavazza, S. Morasca, S. Cinti, G. Oldano and E. Orazi. Applying GQM
in an Industrial Software Factory. To appear in ACM Transactions on Software Engineering
and Methodology.
[HOR96] B. Hoisl, M. Oivo, G. Ruhe, and F. van Latum. No Improvement without Feedback:
Experiences from goal-oriented measurement at Schlumberger. Fifth European Workshop on
Software Process Technology, Nancy, France, October 1996.
[NAS94] National Aeronautics and Space Administration. Software Measurement Guidebook.
Technical Report SEL-84-101, NASA Goddard Space Flight Center, Greenbelt MD 20771,
1994.
[Paw91] Z. Pawlak: Rough Sets: Theoretical Aspects of Reasoning about Data. Kluwer, 1991
[Rom91] H. D. Rombach. Practical Benefits of Goal-Oriented Measurement. Software Reliability
and Metrics, Elsevier Applied Science, 1991.
[Ruh96] G. Ruhe: Rough Set based Data Analysis in Goal Oriented Software Measurement. Third
Symposium on Software Metrics, Berlin, March 1996, IEEE Computer Society Press, p.10-19
[SLO95] R. van Solingen, F. van Latum, M. Oivo, and E. Berghout. Application of Software
Measurement at Schlumberger RPS: Towards Enhancing GQM. Proceedings of the Sixth Eu-
ropean Software Cost Modelling Conference (ESCOM), May 1995.
[Sol95] R. van Solingen. Goal-Oriented Software Measurement in Practice: Introducing Software
Measurement in Schlumberger Retail Petroleum Systems. Master Thesis Report, Schlumberger
RPS, Netherlands, 1995.















LI










CCMI MEDIES E
ANLISES

LII

EDOE8 E ANAL8E8
Nvel de Maturidade 2
Ob]etivo
O objetivo das Medies e Anlises desenvolver e sustentar a
capacidade de medies que utilizada para suportar as necessidades
de gerenciamento de informaes. [PA154]
Notas ntrodutrias
A rea de processo de Medies e Anlises envolve o seguinte:
[PA154.N101]
Especificar os objetivos de medies e anlises, de forma que
estes estejam alinhados com as necessidades e objetivos de
informaes identificados
Especificar as medidas, mecanismos de coleta de dados e
armazenamento, tcnicas de anlises e mecanismos de
comunicao e de feedback
Implementar a coleta, armazenagem, anlise e relatrios sobre os
dados
Fornecer resultados objetivos que possam ser utilizados na tomada
de decises bem informadas e na tomada das aes corretivas
apropriadas
A integrao das atividades de medies e anlises nos processos do
projeto suportam o seguinte: [PA154.N102]
Planejamento e estimativas objetivos
Rastreamento do desempenho real contra os planos e objetivos
estabelecidos
Identificao e resoluo de questes relacionadas a processos
Fornecimento de uma base para a incorporao das medies em
outros processos no futuro
A equipe necessria para implementar uma capacidade de medies
pode pertencer ou no a um programa separado da organizao. A
capacidade de medies pode estar integrada em projetos individuais
ou outras funes organizacionais (como por exemplo, a Garantia da
Qualidade). [PA154.N103]
O foco inicial das atividades de medies o projeto. Entretanto, uma
capacidade de medies pode se provar til para tratar as necessidades
de informaes de toda a organizao ou empreendimento. [PA154.N104]
Os projetos pode decidir armazenar dados e resultados especficos do
projeto em um repositrio especfico. Quando os dados so
compartilhados mais amplamente entre projetos, estes dados podem
ficar residentes em um repositrio de medies da organizao.
[PA154.N105]
LIII

Areas de Processos Relacionadas
Veja a rea de processo de Planejamento do Projeto para obter maiores
informaes sobre estimativa de atributos do projeto e outras
necessidades de informaes de planejamento. [PA154.R101]
Veja a rea de processo de Monitoramento e Controle do Projeto para
obter maiores informaes sobre monitoramento das necessidades de
informaes do desempenho do projeto. [PA154.R102]
Veja a rea de processo de Gerenciamento de Configuraes para
obter maiores informaes sobre o gerenciamento de produtos de
trabalho de medies. [PA154.R103]
Veja a rea de processo de Desenvolvimento de Requisitos para obter
maiores informaes sobre o atendimento dos requisitos de clientes e
necessidades de informaes relacionadas. [PA154.R104]
Veja a rea de processo de Gerenciamento de Requisitos para obter
maiores informaes sobre a manuteno da rastreabilidade dos
requisitos e necessidades de informaes relacionadas. [PA154.R105]
Veja a rea de processo de Definio do Processo Organizacional para
obter maiores informaes sobre o estabelecimento do repositrio de
medies da organizao. [PA154.R106]
Veja a rea de processo de Gerenciamento Quantitativo do Projeto para
obter maiores informaes sobre o entendimento das variaes e o uso
apropriado de tcnicas de anlises estatsticas. [PA154.R107]
Metas Especificas e Genricas
SG 1 Alinhar as Atividades de Medies e Anlises [PA154.IG101]
Os objetivos e atividades de medies so alinhados com as necessidades e
objetivos de informaes identificados.
SG 2 Fornecer Resultados de Medies [PA154.IG102]
Os resultados de medies que tratam as necessidades e objetivos de
informaes identificados so fornecidos.
GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]
O processo institucionalizado como um processo gerenciado.
(A seguinte meta no exigida para o nvel de maturidade 2, mas exigida para o nvel de
maturidade 3 e superiores).
GG 3 Institucionalizar um Processo Definido [CL104.GL101]
O processo institucionalizado como um processo definido.
LIV

Tabela de Relacionamentos Praticas-Metas
SG 1 Alinhar as Atividades de Medies e Anlises [PA154.IG101]
SP 1.1 Estabelecer Objetivos de Medies
SP 1.2 Especificar Medidas
SP 1.3 Especificar Procedimentos de Coleta e Armazenagem de Dados
SP 1.4 Especificar Procedimento de Anlises
SG 2 Fornecer Resultados de Medies [PA154.IG102]
SP 2.1 Coletar Dados de Medies
SP 2.2 Analisar Dados de Medies
SP 2.3 Armazenar Dados e Resultados
SP 2.4 Comunicar Resultados
GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]
GP 2.1 (CO 1) Estabelecer uma Poltica Organizacional
GP 2.2 (AB 1) Planejar o Processo
GP 2.3 (AB 2) Fornecer Recursos
GP 2.4 (AB 3) Atribuir Responsabilidades
GP 2.5 (AB 4) Treinar as Pessoas
GP 2.6 (DI 1) Gerenciar Configuraes
GP 2.7 (DI 2) Identificar e Envolver os Stakeholders Relevantes
GP 2.8 (DI 3) Monitorar e Controlar o Processo
GP 2.9 (VE 1) Avaliar Objetivamente a Aderncia
GP 2.10 (VE 2) Revisar o Status com o Nvel Mais Alto de Gerncia
(A seguinte meta no exigida e suas prticas no so esperadas para uma classificao de
nvel de maturidade 2, mas so exigidas e esperadas para uma classificao de nvel de
maturidade 3 e superiores).
GG 3 Institucionalizar um Processo Definido [CL104.GL101]
GP 3.1 Estabelecer um Processo Definido
GP 3.2 Coletar Informaes de Melhorias
Praticas Especificas por Meta
SG 1 Alinhar Atividade de Medies e Anlises
Os objetivos e atividades de medies so alinhados com as necessidades e
objetivos de informaes identificados. [PA154.IG101]
As prticas especficas cobertas por esta meta especfica podem ser
atendidas ao mesmo tempo ou em qualquer ordem: [PA154.IG101.N101]
Quando esto estabelecendo os objetivos de medies, os experts
muitas vezes pensam antecipadamente nos critrios necessrios
para especificar procedimentos de medies e anlises. Eles
tambm pensam, ao mesmo tempo, nas restries impostas pelos
procedimentos de coleta e armazenagem de dados.
Freqentemente, importante especificar as anlises essenciais
que sero feitas antes de tratar os detalhes da especificao de
medies, coleta de dados e armazenagem.
LV

SP 1.1 Estabelecer Objetivos de Medies
Estabelecer e manter os objetivos de medies que so derivados
das necessidades e objetivos de informaes identificados.
[PA154.IG101.SP101]
Os objetivos de medies documentam os propsitos para os quais as
medies e anlises so feitas, e especificam os tipos de aes que
podem ser tomadas com base nos resultados das anlises dos dados.
[PA154.IG101.SP101.N101]
As fontes para os objetivos de medies podem ser as necessidades de
gerenciamento, tcnicas, do projeto, do produto ou de implementao
do processo. [PA154.IG101.SP101.N102]
Os objetivos de medies podem ser restringidos pelos processos
existentes, recursos disponveis ou outras consideraes de medies.
necessrio julgar se o valor dos resultados ser proporcional aos
recursos dedicados a este trabalho. [PA154.IG101.SP101.N103]
Modificaes em necessidades e objetivos de informaes identificados
podem, por sua vez, ser indicadas em conseqncia do processo e dos
resultados das medies e anlises. [PA154.IG101.SP101.N104]
Fontes de necessidades de informaes e objetivos podem incluir:
[PA154.IG101.SP101.N105]
Planos de projeto
Monitoramento do desempenho do projeto
Entrevistas com gerentes e outros que tenham necessidades de
informaes
Objetivos de gerenciamento estabelecidos
Planos estratgicos
Planos de negcios
Requisitos formais ou obrigaes contratuais
Problemas tcnicos ou de gerenciamento recorrentes ou
perturbadores de outra forma
Experincia de outros projetos ou entidades organizacionais
Benchmarks de outras indstrias
Planos de melhoria de processos
Veja a rea de processo de Planejamento do Projeto para obter maiores
informaes sobre estimativa de atributos do projeto e outras
necessidades de informaes de planejamento. [PA154.IG101.SP101.N105.R101]
Veja a rea de processo de Monitoramento e Controle do Projeto para
obter maiores informaes sobre necessidades de informaes sobre o
desempenho do projeto. [PA154.IG101.SP101.N105.R102]
Veja a rea de processo de Desenvolvimento de Requisitos para obter
maiores informaes sobre o atendimento dos requisitos de clientes e
necessidades de informaes relacionadas. [PA154.IG101.SP101.N105.R103]
Veja a rea de processo de Gerenciamento de Requisitos para obter
maiores informaes sobre a manuteno da rastreabilidade dos
requisitos e necessidades de informaes relacionadas.
[PA154.IG101.SP101.N105.R104]
LVI

Produtos de Trabalho Tpicos
1. Objetivos de medies [PA154.IG101.SP101.W101]
Sub-prticas
1. Documentar as necessidades e objetivos de informaes.
[PA154.IG101.SP101.SubP101]
As necessidades e objetivos de informaes so documentadas para permitir a
rastreabilidade para as atividades de medies e anlises subseqentes.
[PA154.IG101.SP101.SubP101.N101]
2. Priorizar as necessidades e objetivos de informaes.
[PA154.IG101.SP101.SubP102]
Pode no ser possvel nem desejvel submeter todas as necessidades de
informaes inicialmente identificadas a medies e anlises. Prioridades tambm
precisam ser definidas, dentro dos limites dos recursos disponveis.
[PA154.IG101.SP101.SubP102.N101]
3. Documentar, revisar e atualizar os objetivos das medies.
[PA154.IG101.SP101.SubP103]
importante considerar com cuidado os objetivos e usos pretendidos das
medies e anlises. [PA154.IG101.SP101.SubP103.N101]
Os objetivos de medies so documentados, revisados pelos gerentes e outros
stakeholders relevantes e atualizados, conforme necessrio. Fazer isso possibilita
a rastreabilidade das atividades subseqentes de medies e anlises e ajuda a
assegurar que as anlises iro tratar, apropriadamente, das necessidades e
objetivos de informaes identificados. [PA154.IG101.SP101.SubP103.N102]
importante que os usurios dos resultados de medies e anlises sejam
envolvidos na definio dos objetivos das medies e na deciso sobre planos de
ao. Pode tambm ser apropriado envolver aqueles que fornecero os dados de
medies. [PA154.IG101.SP101.SubP103.N103]
4. Fornecer feedback para o refinamento e esclarecimento das
necessidades e objetivos de informaes, conforme necessrio.
[PA154.IG101.SP101.SubP104]
As necessidades e objetivos de informaes identificados podem precisar ser
refinados e esclarecidos, como resultado da definio dos objetivos das medies.
As descries iniciais das necessidades de informaes podem ser pouco claras
ou ambguas. Podem surgir conflitos entre as necessidades e objetivos existentes.
Objetivos precisos sobre uma medida j existente podem ser irreais.
[PA154.IG101.SP101.SubP104.N101]
5. Manter a rastreabilidade dos objetivos de medies com as
necessidades e objetivos de informaes identificados.
[PA154.IG101.SP101.SubP105]
Sempre deve haver uma boa resposta para a pergunta: Por que estamos
medindo isto? [PA154.IG101.SP101.SubP105.N101]
claro que os objetivos das medies podem tambm mudar para refletir a
evoluo das necessidades e objetivos de informaes. [PA154.IG101.SP101.SubP105.N102]
LVII

SP 1.2 Especificar Medidas
Especificar medidas para tratar os objetivos de medies.
[PA154.IG101.SP102]
Os objetivos de medies so refinados em medidas precisas e
quantificveis. [PA154.IG101.SP102.N101]
As medidas podem ser bsicas ou derivadas. Os dados para as
medidas bsicas so obtidos atravs de medio direta. Os dados para
medidas derivadas provm de outros dados, normalmente, atravs da
combinao de duas ou mais medidas bsicas. [PA154.IG101.SP102.N102]
Exemplos de medidas bsicas normalmente utilizadas incluem: [PA154.IG101.SP102.N103]
Medidas reais e estimadas de tamanho de produtos de trabalho (por exemplo,
quantidade de pginas)
Medidas reais e estimadas de esforo e custo (por exemplo, quantidade de horas
homem)
Medidas de qualidade (por exemplo, quantidade de defeitos, quantidade de
defeitos por gravidade)

Exemplos de medidas derivadas normalmente utilizadas incluem: [PA154.IG101.SP102.N104]
Valor Agregado
ndice de Desempenho do Cronograma
Densidade de defeitos
Cobertura de revises por pares
Cobertura de testes e verificaes
Medidas de confiabilidade (por exemplo, intervalo de tempo at ocorrer uma falha)
Medidas de qualidade (por exemplo, quantidade de defeitos por
gravidade/quantidade total de defeitos)

As medidas derivadas normalmente so expressas como razes,
ndices compostos e outras medidas de resumo agregadas. Elas so,
normalmente, mais confiveis quantitativamente e sua interpretao tem
mais sentido que as medidas bsicas utilizadas para ger-las.
[PA154.IG101.SP102.N105]
Produtos de Trabalho Tpicos
1. Especificaes de medidas bsicas e derivadas [PA154.IG101.SP102.W101]
Sub-prticas
1. Identificar medidas candidatas com base nos objetivos
documentados de medies. [PA154.IG101.SP102.SubP101]
Os objetivos de medies so refinados em medidas especficas. As medidas
candidatas identificadas so classificadas e especificadas por nome e unidade de
medida. [PA154.IG101.SP102.SubP101.N101]
2. Identificar medidas existentes que j atendem aos objetivos de
medies. [PA154.IG101.SP102.SubP102]
As especificaes para as medidas podem j existir, talvez estabelecidas
anteriormente com outros objetivos ou em outra parte da organizao.
[PA154.IG101.SP102.SubP102.N101]
LVIII

3. Especificar as definies operacionais para as medidas.
[PA154.IG101.SP102.SubP103]
As definies operacionais so declaradas em termos precisos e no ambguos.
Elas tratam de dois importantes critrios, como segue: [PA154.IG101.SP102.SubP103.N101]
Comunicao: O que est sendo medido, como foi medido, quais as unidades de
medida e o que foi includo ou excludo?
Repetibilidade: A medio pode ser repetida, dada a mesma definio, para obter
os mesmos resultados?
4. Priorizar, revisar e atualizar medidas. [PA154.IG101.SP102.SubP104]
As especificaes propostas das medidas so revisadas para verificar sua
adequao com os potenciais usurios finais e outros stakeholders relevantes. As
prioridades so definidas ou modificadas e as especificaes das medidas so
atualizadas, conforme necessrio. [PA154.IG101.SP102.SubP104.N101]
SP 1.3 Especificar Procedimentos de Coleta e Armazenagem de Dados
Especificar como os dados de medies sero obtidos e
armazenados. [PA154.IG101.SP103]
A especificao explcita de mtodos de coleta ajuda a assegurar que
os dados corretos esto sendo coletados de forma apropriada. Ela
tambm auxilia a esclarecer ainda mais as necessidades de
informaes e os objetivos das medies. [PA154.IG101.SP103.N101]
A ateno apropriada aos procedimentos de armazenagem e
recuperao ajuda a assegurar que os dados estaro disponveis e
acessveis para uso futuro. [PA154.IG101.SP103.N102]
Produtos de Trabalho Tpicos
1. Procedimentos de coleta e armazenagem de dados
[PA154.IG101.SP103.W101]
2. Ferramentas de coleta de dados [PA154.IG101.SP103.W102]
Sub-prticas
1. Identificar as fontes de dados existentes que so geradas a partir
dos atuais produtos de trabalho, processos ou transaes.
[PA154.IG101.SP103.SubP101]
As fontes de dados existentes podem j ter sido identificadas quando as medidas
foram especificadas. Mecanismos apropriados de coleta podem existir mesmo que
dados relevantes ainda no tenham sido coletados. [PA154.IG101.SP103.SubP101.N101]
2. Identificar medidas para as quais dados so necessrios, mas que
no esto atualmente disponveis. [PA154.IG101.SP103.SubP102]
3. Especificar como coletar e armazenar os dados para cada medida
necessria. [PA154.IG101.SP103.SubP103]
Especificaes explcitas so feitas sobre como, onde e quando os dados sero
coletados. Procedimentos para a coleta de dados vlidos so especificados. Os
dados so armazenados de maneira acessvel para a anlise e definido se eles
devem ser gravados para uma possvel reanlise ou para fins de documentao.
[PA154.IG101.SP103.SubP103.N101]
Questes a serem consideradas geralmente incluem: [PA154.IG101.SP103.SubP103.N102]
LIX

A freqncia da coleta e os pontos do processo onde as medies sero feitas
foram definidos?
O cronograma que ser necessrio para mover os resultados das medies dos
pontos de coleta para os repositrios, outros bancos de dados ou para os
usurios finais foi estabelecido?
Quem responsvel pela obteno dos dados?
Quem responsvel pela armazenagem, recuperao e segurana dos dados?
As ferramentas de suporte necessrias foram desenvolvidas ou adquiridas?
4. Criar mecanismos de coleta de dados e direcionamento do
processo. [PA154.IG101.SP103.SubP104]
Os mecanismos de coleta e armazenagem de dados so bem integrados com
outros processos de trabalho normais. Os mecanismos de coleta de dados podem
incluir formulrios e templates manuais ou automatizados. Um direcionamento
claro e conciso sobre os procedimentos corretos est disponvel para os
responsveis pela execuo do trabalho. O treinamento fornecido, conforme
necessrio, para esclarecer os processos necessrios para a coleta de dados
completos e precisos e para minimizar a carga dos que devem fornecer e registrar
os dados. [PA154.IG101.SP103.SubP104.N101]
5. Estabelecer suporte coleta automtica de dados onde for
apropriado e possvel. [PA154.IG101.SP103.SubP105]
O suporte automtico pode auxiliar na coleta de dados mais completos e precisos.
[PA154.IG101.SP103.SubP105.N101]
Exemplos de tais suportes automticos incluem: [PA154.IG101.SP103.SubP105.N102]
Logs de atividades com horrio registrado
Anlises estticas ou dinmicas de artefatos

Entretanto, alguns dados no podem ser coletados sem interveno humana (por
exemplo, satisfao do cliente ou outras opinies pessoais) e criar a infra-
estrutura necessria para as outras automaes pode ser muito caro.
[PA154.IG101.SP103.SubP105.N103]
6. Priorizar, revisar e atualizar os procedimentos de coleta e
armanezagem de dados. [PA154.IG101.SP103.SubP106]
Os procedimentos propostos so revisados com relao a sua adequao e
possibilidade de execuo com os responsveis pelo fornecimento, coleta e
armazenagem dos dados. Eles tambm podem ter sugestes teis sobre como
melhorar os processos existentes ou podem sugerir outras medidas e anlises
teis. [PA154.IG101.SP103.SubP106.N101]
7. Atualizar as medidas e os objetivos das medies, conforme
necessrio. [PA154.IG101.SP103.SubP107]
Devem ser revisadas as prioridades com base no seguinte: [PA154.IG101.SP103.SubP107.N101]
A importncia das medidas
A quantidade de esforo exigido para obter os dados
As consideraes incluem se sero necessrios novos formulrios, ferramentas
ou treinamento para obter os dados. [PA154.IG101.SP103.SubP107.N102]
LX

SP 1.4 Especificar os Procedimentos de Anlises
Especificar como os dados de medies sero analisados e
comunicados. [PA154.IG101.SP104]
Especificar antecipadamente os procedimentos de anlise assegura que
as anlises apropriadas sero executadas e comunicadas para atender
aos objetivos documentados das medies (e, portanto, as
necessidades e objetivos de informaes nos quais eles foram
baseados). Esta abordagem tambm garante uma conferncia se os
dados necessrios sero de fato coletados. [PA154.IG101.SP104.N101]
Produtos de Trabalho Tpicos
1. Especificao e procedimentos de anlises [PA154.IG101.SP104.W101]
2. Ferramentas de anlises de dados [PA154.IG101.SP104.W102]
Sub-prticas
1. Especificar e priorizar as anlises que sero executadas e os
relatrios que sero preparados. [PA154.IG101.SP104.SubP101]
Uma ateno antecipada dever ser dada s anlises que sero executadas e
maneira como os resultados sero relatados. Estes devero atender os seguintes
critrios: [PA154.IG101.SP104.SubP101.N101]
As anlises atendem explicitamente os objetivos documentados das medies
A apresentao dos resultados claramente compreendida pelas audincias a
quem os resultados so endereados
As prioridades podem ter que ser definidas dentro dos recursos disponveis.
[PA154.IG101.SP104.SubP101.N102]
2. Selecionar os mtodos e ferramentas de anlises de dados
adequados. [PA154.IG101.SP104.SubP102]
Veja as prticas especficas Selecionar Medidas e Tcnicas de
Anlises e Aplicar Mtodos Estatsticos para Entender Variaes
da rea de processo de Gerenciamento Quantitativo do Projeto
para obter maiores informaes sobre o uso apropriado de tcnicas
de anlises estatsticas e sobre o entendimento de variaes,
respectivamente. [PA154.IG101.SP104.SubP102.R101]
Questes a serem consideradas normalmente incluem: [PA154.IG101.SP104.SubP102.N101]
Escolha do layout e outras tcnicas de apresentao (por exemplo, grficos de
pizza, grficos de barra, histogramas, grficos de radar, grficos de linha, grficos
de disperso ou tabelas)
Escolha das estatsticas descritivas apropriadas (por exemplo, mdia aritmtica,
mediana ou modo)
Decises sobre os critrios de amostragem estatstica quando for impossvel ou
desnecessrio examinar todos os elementos de dados
Decises sobre como tratar a anlise na falta de elementos de dados
Seleo das ferramentas de anlises adequadas
Estatsticas descritivas so normalmente utilizadas na anlise de dados para fazer
o seguinte: [PA154.IG101.SP104.SubP102.N102]
Examinar a distribuio de medidas especficas (por exemplo, tendncia central,
extenso da variao, pontos de dados que exibem uma variao fora do comum)
LXI

Examinar os interrelacionamentos entre as medidas especificadas (por exemplo,
comparao de defeitos por fase do ciclo de vida do produto ou por componente
do produto)
Mostrar as mudanas ao longo do tempo
3. Especificar os procedimentos administrativos para a anlise dos
dados e comunicao dos resultados. [PA154.IG101.SP104.SubP103]
Questes a serem consideradas normalmente incluem: [PA154.IG101.SP104.SubP103.N101]
Identificar as pessoas e grupos responsveis por analisar os dados e apresentar
os resultados
Determinar o cronograma para analisar os dados e apresentar os resultados
Determinar os locais para a comunicao dos resultados (por exemplo, relatrio de
progresso, memorandos transmitidos, relatrios escritos ou reunies com a
equipe)
4. Revisar e atualizar o contedo e formato propostos das anlises e
relatrios especificados. [PA154.IG101.SP104.SubP104]
Todo o contedo e formato proposto est sujeito a ser revisto e revisado, incluindo
os mtodos e ferramentas de anlises, procedimentos administrativos e
prioridades. Os stakeholders relevantes consultados devero incluir os usurios
finais pretendidos, os patrocinadores, analistas e fornecedores de dados.
[PA154.IG101.SP104.SubP104.N101]
5. Atualizar as medidas e objetivos de medies, conforme
necessrio. [PA154.IG101.SP104.SubP105]
Da mesma maneira que as necessidades de medies dirigem as anlises de
dados, o esclarecimento dos critrios de anlises pode afetar a medio. As
especificaes de algumas medidas podem ser mais refinadas com base nas
especificaes estabelecidas para os procedimentos de anlise de dados. Outras
medidas podem provar ser desnecessrias ou a necessidade de medidas
adicionais pode ser percebida. [PA154.IG101.SP104.SubP105.N101]
O exerccio de especificar como as medidas sero analisadas e comunicadas
tambm pode sugerir a necessidade de refinamento dos prprios objetivos das
medies. [PA154.IG101.SP104.SubP105.N102]
6. Especificar os critrios para avaliao da utilidade dos resultados
de anlises e para a execuo das atividades de medies e
anlises. [PA154.IG101.SP104.SubP106]
Os critrios para avaliar a utilidade da anlise poderiam tratar a extenso na qual
se aplica o seguinte: [PA154.IG101.SP104.SubP106.N101]
Os resultados so (1) fornecidos pontualmente, (2) compreendidos e (3) utilizados
para a tomada de decises.
O trabalho no custa mais para ser executado do que se justifica pelos benefcios
que ele proporciona.
Os critrios para avaliar a execuo das medies e anlises poderia incluir a
extenso na qual se aplica o seguinte: [PA154.IG101.SP104.SubP106.N102]
A quantidade de dados faltando ou de inconsistncias identificadas est alm dos
limites especificados.
H uma seleo tendenciosa na amostragem (por exemplo, somente os usurios
finais satisfeitos foram pesquisados para avaliar a satisfao do usurio final ou
somente os projetos mal sucedidos foram avaliados para determinar a
produtividade geral).
LXII

Os dados de medies so repetveis (isto , estatisticamente confiveis).
As premissas estatsticas foram satisfeitas (isto , sobre a distribuio dos dados
ou sobre escalas apropriadas de medies).
SG 2 Fornecer Resultados de Medies
Resultados de medies que tratam as necessidades e objetivos de
informaes identificados so fornecidos. [PA154.IG102]
O motivo bsico para se fazer medies e anlises tratar as
necessidades e objetivos de informaes identificados. Os resultados
das medies baseados em evidncias objetivas podem ajudar a
monitorar o desempenho, cumprir obrigaes contratuais, tomar
decises tcnicas e de gerenciamento bem informadas e possibilitar
que sejam tomadas aes corretivas. [PA154.IG102.N101]
SP 2.1 Coletar Dados de Medies
Obter os dados de medies especificados. [PA154.IG102.SP101]
Os dados necessrios para a anlise so obtidos e conferidos quanto a
sua completitude e integridade. [PA154.IG102.SP101.N101]
Produtos de Trabalho Tpicos
1. Conjuntos de dados de medies bsicas e derivadas
[PA154.IG102.SP101.W101]
2. Resultados de testes de integridade de dados [PA154.IG102.SP101.W102]
Sub-prticas
1. Obter os dados da medidas bsicas. [PA154.IG102.SP101.SubP101]
Os dados so coletados, conforme necessrio, para medidas bsicas j utilizadas
ou recm-especificadas. Os dados existentes so reunidos dos registros do
projeto ou de outros locais da organizao. [PA154.IG102.SP101.SubP101.N101]
Note que os dados que foram coletados anteriormente podem no estar mais
disponveis para reutilizao em bancos de dados, registros em papel ou
repositrios formais. [PA154.IG102.SP101.SubP101.N102]
2. Gerar os dados para as medidas derivadas. [PA154.IG102.SP101.SubP102]
Os valores so novamente calculados para todas as medidas derivadas.
[PA154.IG102.SP101.SubP102.N101]
3. Executar conferncia da integridade de dados o mais prximo
possvel da fonte dos dados. [PA154.IG102.SP101.SubP103]
Todas as medies esto sujeitas a erros na especificao ou na gravao dos
dados. sempre melhor identificar tais erros e identificar as fontes dos dados que
faltam o mais cedo possvel no ciclo de medies e anlises.
[PA154.IG102.SP101.SubP103.N101]
As conferncias podem incluem checagem dos dados que esto faltando, valores
de dados fora dos limites e padres e correlaes no usuais entre medidas.
[PA154.IG102.SP101.SubP103.N102]
particularmente importante fazer o seguinte: [PA154.IG102.SP101.SubP103.N103]
LXIII

Testar e corrigir inconsistncias de classificaes feitas por pessoas (isto ,
determinar com que freqncia pessoas tomam diferentes decises de
classificaes com base nas mesmas informaes, tambm conhecido como
confiabilidade entre codificadores).
Examinar empiricamente as relaes entre as medidas que so usadas para
calcular as medidas derivadas adicionais. Fazer isso pode assegurar que
importantes distines no passem despercebidas e que as medidas derivadas
transmitam os significados pretendidos (tambm conhecido como validao de
critrios).
SP 2.2 Analisar os Dados das Medies
Analisar e interpretar os dados de medies. [PA154.IG102.SP102]
Os dados de medies so analisados conforme planejado, anlises
adicionais so conduzidas, conforme necessrio, os resultados so
revisados com os stakeholders relevantes e revises necessrias para
anlises futuras so anotadas. [PA154.IG102.SP102.N101]
Produtos de Trabalho Tpicos
1. Resultados de anlises e relatrios preliminares [PA154.IG102.SP102.W101]
Sub-prticas
1. Conduzir anlises iniciais, interpretar os resultados e escrever
concluses preliminares. [PA154.IG102.SP102.SubP101]
Os resultados das anlises de dados raramente so evidentes por si s. Devem
ser estabelecidos explicitamente critrios para a interpretao dos resultados e
para a definio de concluses. [PA154.IG102.SP102.SubP101.N101]
2. Conduzir medies e anlises adicionais, conforme necessrio, e
preparar os resultados para a apresentao. [PA154.IG102.SP102.SubP102]
Os resultados das anlises planejadas podem sugerir (ou exigir) anlises
adicionais no previstas. Alm disso, podem identificar necessidades de refinar as
medidas existentes, calcular medidas derivadas adicionais ou mesmo coletar
dados para medidas primitivas adicionais para completar, de forma apropriada, a
anlise planejada. De maneira semelhante, preparar os resultados iniciais para a
apresentao pode identificar a necessidade de anlises adicionais no previstas.
[PA154.IG102.SP102.SubP102.N101]
3. Revisar os resultados iniciais com os stakeholders relevantes.
[PA154.IG102.SP102.SubP103]
Pode ser apropriado rever as interpretaes iniciais dos resultados e a maneira
como elas sero apresentadas, antes de dissemin-las e comunic-las de forma
mais abrangente. [PA154.IG102.SP102.SubP103.N101]
Revisar os resultados iniciais antes de sua liberao pode evitar mal entendidos
desnecessrios e levar a melhorias na anlise e apresentao dos dados.
[PA154.IG102.SP102.SubP103.N102]
Os stakeholders relevantes com os quais as revises podem ser feitas incluem os
usurios finais pretendidos e os patrocinadores, bem como os analistas e
fornecedores de dados. [PA154.IG102.SP102.SubP103.N103]
4. Refinar os critrios para anlises futuras. [PA154.IG102.SP102.SubP104]
LXIV

Lies valiosas que podem melhorar os futuros esforos so, muitas vezes,
aprendidas na conduo de anlises de dados e na preparao dos resultados.
Da mesma forma, maneiras de melhorar as especificaes de medies e os
procedimentos de coleta de dados podem se tornar aparentes, bem como idias
para refinar as necessidades e objetivos de informaes identificados.
[PA154.IG102.SP102.SubP104.N101]
SP 2.3 Armazenar os Dados e Resultados
Gerenciar e armazenar os dados de medies, especificaes de
medies e resultados de anlises. [PA154.IG102.SP103]
Armazenar informaes relacionadas a medies possibilita o uso futuro
pontual e eficiente, em termos de custos, dos dados histricos e
resultados. As informaes tambm so necessrias para fornecer um
contexto suficiente para a interpretao dos dados, critrios de
medies e resultados das anlises. [PA154.IG102.SP103.N101]
As informaes armazenadas normalmente incluem: [PA154.IG102.SP103.N102]
Planos de medies
Especificaes de medidas
Conjuntos de dados que foram coletados
Relatrios de anlises e apresentaes
As informaes armazenadas contm ou fazem referncia s
informaes necessrias para entender e interpretar as medidas e
analis-las com relao motivao e aplicabilidade (por exemplo,
especificaes de medies usadas em diferentes projetos para a
comparao entre projetos). [PA154.IG102.SP103.N103]
Conjuntos de dados para medidas derivadas, normalmente, podem ser
recalculados e no precisam ser armazenados. Entretanto, pode ser
apropriado armazenar resumos baseados nas medidas derivadas (por
exemplo, grficos, tabelas de resultados ou relatrios descritivos).
[PA154.IG102.SP103.N104]
Resultados intermedirios das anlises no precisam ser armazenados
separadamente, se puderem ser eficientemente reconstrudos.
[PA154.IG102.SP103.N105]
Os projetos podem decidir armazenar dados e resultados especficos do
projeto em um repositrio especfico. Quando os dados so
compartilhados de forma mais abrangente entre projetos, os dados
podem residir no repositrio de medies da organizao.
[PA154.IG102.SP103.N106]
Veja a prtica especfica Estabelecer o Repositrio de Medies da
Organizao da rea de processo de Definio do Processo
Organizacional para obter maiores informaes sobre como estabelecer
o repositrio de medies da organizao. [PA154.IG102.SP103.N106.R101]
Veja a rea de processo de Gerenciamento de Configuraes para
obter maiores informaes sobre o gerenciamento dos produtos de
trabalho de medies. [PA154.IG102.SP103.N106.R102]
LXV

Produtos de Trabalho Tpicos
1. Inventrio dos dados armazenados [PA154.IG102.SP103.W101]
Sub-prticas
1. Revisar os dados para assegurar sua completitude, integridade,
exatido e atualizao. [PA154.IG102.SP103.SubP101]
2. Tornar o contedo armazenado disponvel para uso somente dos
grupos e pessoal autorizados. [PA154.IG102.SP103.SubP102]
3. Impedir que as informaes armazenadas sejam utilizadas de
forma inadequada. [PA154.IG102.SP103.SubP103]
Exemplos de maneiras de impedir o uso inadequado dos dados e informaes
relacionadas incluem o controle do acesso aos dados e a educao das pessoas
sobre o uso apropriado dos dados. [PA154.IG102.SP103.SubP103.N101]

Exemplos de uso inadequado incluem: [PA154.IG102.SP103.SubP103.N102]
Exposio de informaes que foram fornecidas confidencialmente
Interpretaes falhas baseadas em informaes incompletas, fora do contexto ou,
ainda, distorcidas
Medidas utilizadas para avaliar inadequadamente o desempenho de pessoas ou
classificar projetos
Gerar dvidas sobre a integridade de indivduos especficos

SP 2.4 Comunicar os Resultados
Relatar os resultados das atividades de medies e anlises para
todos os stakeholders relevantes. [PA154.IG102.SP104]
Os resultados do processo de medies e anlises so comunicados
aos stakeholders relevantes, de uma maneira pontual e fcil de se
utilizar, para suportar a tomada de decises e auxiliar na tomada das
aes corretivas. [PA154.IG102.SP104.N101]
Os stakeholders relevantes incluem os usurios pretendidos,
patrocinadores e analistas e fornecedores de dados. [PA154.IG102.SP104.N102]
Produtos de Trabalho Tpicos
1. Relatrios entregues e resultados de anlises relacionados
[PA154.IG102.SP104.W101]
2. Informaes de contexto ou direcionamento para auxiliar na
interpretao dos resultados das anlises [PA154.IG102.SP104.W102]
Sub-prticas
1. Manter os stakeholders relevantes pontualmente informados dos
resultados das medies. [PA154.IG102.SP104.SubP101]
Os resultados das medies so comunicados a tempo de serem utilizados para
seus propsitos pretendidos. Os relatrios possivelmente no sero utilizados se
forem distribudos com pouco esforo em seguir aqueles que precisam saber dos
resultados. [PA154.IG102.SP104.SubP101.N101]
LXVI

Na extenso que for possvel e como parte da maneira normal como trabalham, os
usurios dos resultados de medies so mantidos pessoalmente envolvidos na
definio de objetivos e deciso sobre os planos de ao para medies e
anlises. Os usurios so mantidos regularmente informados do progresso e dos
resultados intermedirios. [PA154.IG102.SP104.SubP101.N102]
Veja a rea de processo de Monitoramento e Controle do Projeto
para obter maiores informaes sobre o uso de resultados de
medies. [PA154.IG102.SP104.SubP101.N102.R101]
2. Auxiliar os stakeholders relevantes no entendimento dos
resultados. [PA154.IG102.SP104.SubP102]
Os resultados so relatados de uma maneira clara e concisa, apropriada
sofisticao metodolgica dos stakeholders relevantes. Eles so fceis de
entender, fceis de interpretar e claramente ligados a necessidades e objetivos de
informaes identificados. [PA154.IG102.SP104.SubP102.N101]
Os dados, muitas vezes, no so evidentes para quem no um expert em
medies. As escolhas das medies devero ser explicitamente claras sobre o
seguinte: [PA154.IG102.SP104.SubP102.N102]
Como e por que as medidas bsicas e derivadas foram especificadas
Como os dados foram obtidos
Como interpretar os resultados com base nos mtodos de anlises de dados que
foram utilizados
Como os resultados tratam as suas necessidades de informaes
Exemplos de aes para auxiliar o entendimento dos resultados incluem:
[PA154.IG102.SP104.SubP102.N103]
Discutir os resultados com os stakeholders relevantes
Fornecer um memorando que contenha uma fundamentao e uma explicao
para os resultados
Fornecer informaes detalhadas sobre os resultados antecipadamente para os
usurios
Fornecer treinamento para o uso e entendimento apropriados dos resultados de
medies

GG 2 Institucionalizar um Processo Gerenciado [CL103.GL101]
O processo institucionalizado como um processo gerenciado.
Compromisso
GP 2.1 (CO 1) Estabelecer uma Poltica Organizacional
Estabelecer e manter uma poltica organizacional para o
planejamento e execuo do processo de medies e anlises.
[GP103]
LXVII

Elaborao:
Esta poltica estabelece as expectativas organizacionais para o
alinhamento dos objetivos e atividades de medies com as
necessidades e objetivos de informaes identificados e para o
fornecimento dos resultados de medies. [PA154.EL101]
Habilitaes
GP 2.2 (AB 1) Planejar o Processo
Estabelecer e manter o plano para a execuo do processo de
medies e anlises. [GP104]
Elaborao:
Normalmente, este plano para a execuo do processo de medies e
anlises est includo no (ou referenciado pelo) plano do projeto, que
descrito na rea de processo de Planejamento do Projeto. [PA154.EL115]
GP 2.3 (AB 2) Fornecer Recursos
Fornecer os recursos adequados para a execuo do processo de
medies e anlises, desenvolvimento dos produtos de trabalho e
fornecimento dos servios do processo. [GP105]
Elaborao:
O pessoal que executa as medies pode trabalhar em perodo integral
ou em meio perodo. Um grupo de medies pode ou no existir para
suportar as atividades de medies em diversos projetos. [PA154.EL104]
Exemplos de outros recursos fornecidos incluem as seguintes ferramentas: [PA154.EL105]
Pacotes estatsticos
Pacotes que apiam a coleta de dados entre redes

GP 2.4 (AB 3) Atribuir Responsabilidades
Atribuir responsabilidades e autoridade para a execuo do
processo, desenvolvimento dos produtos de trabalho e
fornecimento dos servios do processo de medies e anlises.
[GP106]
GP 2.5 (AB 4) Treinar as Pessoas
Treinar as pessoas na execuo e suporte do processo de
medies e anlises, conforme necessrio. [GP107]
LXVIII

Elaborao:
Exemplos de tpicos de treinamento incluem: [PA154.EL107]
Tcnicas estatsticas
Processos de coleta de dados, anlise e criao de relatrios
Desenvolvimento de medies relacionadas a metas (por exemplo, Mtrica de
Questionamento de Metas - Goal Question Metric)

mplementaes
GP 2.6 (DI 1) Gerenciar Configuraes
Colocar os produtos de trabalho definidos do processo de
medies e anlises sob os nveis apropriados de gerenciamento
de configuraes. [GP109]
Elaborao:
Exemplos de produtos de trabalho colocados sob gerenciamento de configuraes
incluem: [PA154.EL108]
Especificaes de medidas bsicas e derivadas
Procedimentos de coleta e armazenagem de dados
Conjuntos de dados de medies bsicas e derivadas
Resultados de anlises e relatrios preliminares
Ferramentas de anlises de dados

GP 2.7 (DI 2) Identificar e Envolver os Stakeholders Relevantes
Identificar e envolver os stakeholders relevantes do processo de
medies e anlises, conforme planejado. [GP124]
Elaborao:
Exemplos de atividades para o envolvimento de stakeholders incluem: [PA154.EL114]
Estabelecimento de objetivos e procedimentos de medies
Anlise de dados de medies
Fornecimento de feedback significativo para os responsveis pelo fornecimento de
dados iniciais dos quais dependem a anlise e os resultados

GP 2.8 (DI 3) Monitorar e Controlar o Processo
Monitorar e controlar o processo de medies e anlises contra o
plano para a execuo do processo e tomar as aes corretivas
apropriadas. [GP110]
LXIX

Elaborao:
Exemplos de medidas utilizadas no monitoramento e controle incluem: [PA154.EL111]
Percentual de projetos utilizando medidas de progresso e desempenho
Percentual de objetivos de medies tratados

Verificaes
GP 2.9 (VE 1) Avaliar Objetivamente a Aderncia
Avaliar objetivamente a aderncia do processo de medies e
anlises contra sua descrio de processo, padres e
procedimentos e tratar as no conformidades. [GP113]
Elaborao:
Exemplos de atividades revisadas incluem: [PA154.EL112]
Alinhamento das atividades de medies e anlises
Fornecimento de resultados de medies

Exemplos de produtos de trabalho revisados incluem: [PA154.EL113]
Especificaes de medidas bsicas e derivadas
Procedimentos de coleta e armazenagem de dados
Resultados das anlises e relatrios preliminares

GP 2.10 (VE 2) Revisar o Status com o Nvel Mais Alto de Gerncia
Revisar as atividades, status e resultados do processo de
medies e anlises com o nvel mais alto de gerncia e resolver
questes. [GP112]
(A seguinte meta no exigida e suas prticas no so esperadas para uma classificao de
nvel de maturidade 2, mas so exigidas para uma classificao de nvel de maturidade 3 e
superiores).
GG 3 Institucionalizar um Processo Definido [CL104.GL101]
O processo institucionalizado como um processo definido.
GP 3.1 Estabelecer um Processo Definido
Estabelecer e manter a descrio de um processo definido de
medies e anlises. [GP114]
LXX

GP 3.2 Coletar Informaes de Melhorias
Coletar produtos de trabalho, medidas, resultados de medies e
informaes de melhoria derivados do planejamento e execuo
do processo de medies e anlises para suportar o uso futuro e a
melhoria dos processos e ativos de processos da organizao.
[GP117]

LXXI








Gesto e Medio
segundo o TMM
LXXII

TMM - Testing Maturity Model

Introduo ao processo de teste estruturado

Durante as dcadas de 60, 70 e 80, a atividade de teste era executada no fim do ciclo de de-
senvolvimento, normalmente pelos prprios analistas de sistemas ou desenvolvedores. O foco
era avaliar se o sistema estava funcionando e o objetivo era procurar erros. No haviam ainda
tcnicos especializados na atividade de testar aplicaes e nem metodologias estruturadas de
teste.

Apesar desta realidade ainda permanecer na maioria das empresas at os dias atuais, foi em
1979 que Glenford Myers publicou aquele que atualmente ainda considerado um dos melho-
res livros de teste existentes no mercado com o ttulo de The Art of Software Testing. Este
livro continua sendo a bblia de muitos dos testadores do sculo 21. Myers basicamente lem-
brava que testar era procurar defeitos e no provar que o software estava funcionando.

Um artigo publicado na revista Communications of the ACM com o ttulo The Growth of
Software Testing, escrito por David Gelperin e Bill Hetzel descrevia um processo de evolu-
o dos testes e lanava um documento que chamou de Plano de Testes. Esse documento, que
at hoje ainda usado, deveria ser escrito a partir dos requisitos do sistema e por si s j aju-
dava a reduzir a quantidade de defeitos dos sistemas, dando aos testadores os objetivos a se-
rem alcanados durante a atividade de teste.

As dcadas de 80 e 90 marcaram o surgimento dos grupos de garantia de qualidade na estrutu-
ra da rea de TI, escritrios de projetos, e mais recentemente os grupos de teste, quando a
atividade de testar software passou a fazer parte de um processo independente do processo de
desenvolver software, embora continuassem integradas. Os modelos de melhoria do processo
de software so basicamente voltados para a melhoria do desenvolvimento do software, como
o CMMI e o mps.BR, e o seu objetivo criar produtos de software melhores, mas no garan-
tem que esses softwares sero testados adequadamente.

A criao de um processo independente de teste demandou algumas necessidades de metodo-
logias, mtricas e melhorias, que j existiam no processo de desenvolvimento de software
original, mas que precisavam ser adaptadas a este novo processo.
LXXIII


Figura 1



LXXIV

Em 1996 foi desenvolvido por tcnicos do Illinois Institute of Technology (Illinois State Uni-
versity) um modelo para permitir fazer um diagnstico do processo de teste dentro das empre-
sas, definindo o seu nvel de maturidade e a partir desta avaliao definir um roteiro gradativo
de melhorias.

Mndc!ns dc ava!ian da maturidadc dn prnccssn dc tcstc

Existem vrios modelos de avaliao da maturidade do processo de testes. Alguns como o
TPI (Test Process Improvement), so bastante usados na Europa e outros como o TMM (Tes-
te Maturity Model) e TCMM (Test Capability Maturity Model) que so mais populares nos
Estados Unidos. Isso tambm ocorre com relao ao CMMI (Estados Unidos) e, o que foi
durante um perodo, o Bootstrap (Europa). No pretendemos neste artigo entrar no mrito de
qual dos modelos o melhor ou o mais popular, apenas escolhemos um deles, no caso o
TMM, que o mais popular nos EUA, e vamos procurar mostrar o seu relacionamento com o
CMMI. Para aqueles que no esto acostumados com os modelos de melhoria de processos de
teste, eu gostaria tambm de lembrar que o TPI, bastante usado na Europa, tambm um dos
mais consistentes modelos nesta rea. Um dos autores, Emerson Rios, modestamente, j criou
um modelo junto com o Trayahu Moreira, publicado no nosso livro Teste de Software, que foi
editado pela AltaBooks, e que agora se encontra na sua segunda edio. Na verdade o nosso
modelo foi apenas uma tentativa de dar uma viso mais didtica ao processo de melhoria, de
modo que os leitores iniciantes pudessem entender a finalidade desses modelos.

A atividade de testar componentes de software, dentro de um processo de desenvolvimento,
muito importante pois atravs dela que sai o aval para a garantia dos produtos que so entre-
gues aos usurios ou clientes. A falta de maturidade do processo de testes muitas vezes leva a
organizao a trat-lo como uma atividade menor e sem importncia. Ns sabemos que milha-
res de empresas amargam srios prejuzos em todo o mundo por causa de defeitos de softwa-
res. Essas organizaes, apesar de saberem que o custo da correo de um defeito em ambien-
te de produo chega a ser milhares de vezes maior do que a sua correo no incio do proces-
so de desenvolvimento, ainda insistem em negligenciar o processo de teste. Os sinais do mun-
do globalizado esto mostrando outros caminhos, como, por exemplo, aquele trilhado pela
ndia, pas extremamente pobre, que uma potncia mundial quando se trata de tecnologia da
informao. Este pas exporta 10 bilhes de dlares de produtos ligados a esta rea do conhe-
cimento e possui cerca de 80 empresas certificadas entre os diversos nveis do CMMI, en-
quanto o Brasil, segundo o MCT, 21 (vinte e uma) empresas foram certificadas CMMI at
agosto de 2006, sendo que 6 (seis) so nivel 5 e 4 (quatro) nvel 3, ficando as demais no nvel
2 (onze empresas).
LXXV


Figura 2

A regra 10 de Myers indica que o custo da correo dos defeitos tende a ser cada vez maior
tanto mais tarde ele for descoberto. Defeitos encontrados nas fases iniciais da etapa de desen-
volvimento do software so mais baratos de serem corrigidos do que aqueles encontrados na
produo.


Figura 3

Por outro lado existe tambm um momento onde o custo de prosseguir o teste ser mais caro
do que a falha causada por um defeito encontrado tardiamente. Os modelos de melhoria de
processos tm por objetivo permitir que atravs de um processo eficiente os defeitos venham
a serem encontrados no momento em que custar mais barato corrigi-los.

Dcscrcvcndn n TMM

Os modelos de avaliao da maturidade do processo de desenvolvimento de software, tais
como CMMI (Capability Maturity Model Integrated), ISO-15504-SPICE e mps.BR no tra-
LXXVI

tam adequadamente o processo de teste, razo pela qual o Illinois Institute of Technology cri-
ou o TMM-Test Maturity Model. O objetivo do TMM dar suporte s organizaes na me-
lhoria do processo de testes e tomou como base os seguintes paradigmas:
um modelo complementar ao CMMI com o qual mantm compatibilidade;
baseado na avaliao da situao atual do processo de testes atravs de regras claras
e objetivas;
uma linha para a melhoria contnua do processo de testes;
um modelo baseado nas melhores prticas de teste existentes no mercado.

Evidentemente que um modelo de melhoria de processo, como os citados anteriormente, po-
deria com pouca mudana ser adequado a um processo de teste, porm neste artigo iremos
apenas nos ater ao uso do TMM e em alguns momentos faremos uma comparao com o
CMMI.

O propsito do TMM segundo os seus autores est calcado nas seguintes afirmativas:
Deve ser uma forma de avaliao interna da equipe para identificar o seu correto esta-
do de capacitao;
Dever ser claro para que as gerncias superiores possam claramente aceita-lo como
um programa de melhoria de teste;
Deve permitir que a equipe de garantia de qualidade possa desenvolver e implementar
planos de melhoria de processo;
Deve permitir que as equipes de desenvolvimento possam tambm melhorar os seus
testes;
Os usurios e clientes devem tambm poder ocupar o seu papel no processo de melho-
ria.

Embora exista um paralelismo entre o CMMI e o TMM os seus nveis no necessariamente se
correspondem, como veremos adiante neste artigo. Os 5 (cinco) nveis do TMM so os se-
guintes:


Nvcis Dcscrin dns nvcis
1 Inicial
2 Fase de definio
3 Integrao
4 Gesto e medies
5 Otimizao, preveno de defeitos e
controle de qualidade
Tabela 1
Da mesma forma que o CMMI onde o nvel 1 no possui nenhuma rea Chave de Processo
associada, o mesmo ocorre com o TMM, cujas metas de maturidade so as seguintes:

LXXVII


Nveis Obj Descrio do objetivo Explicaes
1 - Teste normalmente feito pela
equipe de desenvolvimento de
forma rudimentar
A atividade de testar um
processo catico e no
existe uma diferena entre
testar e buscar erros. O
teste executado sem
ferramentas, equipes trei-
nadas e outros recursos.
1 Desenvolver os objetivos do teste
2 Iniciar um processo de planeja-
mento de teste
2
3 Institucionalizar tcnicas e mto-
dos bsicos de teste
O propsito do teste
mostrar que o software
funciona.
1 Estabelecer uma organizao de
teste de software
2 Integrar o teste no ciclo de vida
do software
3 Controlar e monitorar o processo
de teste
3
4 Estabelecer um programa de
treinamento
O propsito do teste
mostrar que o software
no funciona
1 Estabelecer um programa amplo
de reviso
4
2 Estabelecer um programa de me-
dies de teste
3 Evoluir a qualidade do software
O propsito do teste no
provar nada mas reduzir
os riscos causados pelos
defeitos a nveis aceit-
veis.
1 Aplicar processos de preveno
de defeitos
2 Controlar a qualidade
A atividade de testar no
um ato, mas uma disci-
plina mental que resulta
em baixos riscos para o
software com pouco es-
foro de teste.
5
3 Otimizar o processo de teste
Tabela 2
O TMM, a exemplo do CMMI, tambm possui um modelo de validao, baseado num questi-
onrio, onde verificado o nvel de maturidade da rea de TI em relao ao teste. Definido o
nvel, a equipe de testes dever se submeter a um processo de migrao para um nvel superi-
or de maturidade, o que vai significar uma melhoria no processo de testes. Para isso algumas
prticas devem ser adotadas baseadas nas metas estabelecidas para o nvel a ser alcanado.

LXXVIII

Rc!an cntrc ns mndc!ns TMM c CMMI

Nvcis
dn TMM
Nvcis dn
CMMI cnrrc-
!atns
Arcas chavcs dc prnccssn
cnrrcspnndcntcs
1 1
2 2 Gerncia de Requisitos Gerncia
de Configurao
Planejamento do Projeto de Soft-
ware
2 Garantia de Qualidade de Software
e Superviso e Acompanhamento e
Monitorao de Projeto de Softwa-
re
3
3 Foco no Processo da Organizao
Definio do Processo da Organi-
zao e
Treinamento
Validao
3 Reviso por parceiros
Verificao
4
4 Gerncia Quantitativa de Processo
5 5 Anlise e Deciso
Tabela 3
O quadro mostra que existe uma correlao aproximada mas no precisa entre os nveis do
TMM e o que seria o nvel correspondente no CMMI. Como podemos observar no existe
uma correspondncia direta, pois a evoluo no TMM tende a ser mais rpida, embora exista
uma ligao muito forte com a evoluo do CMMI. Por exemplo, alcana-se o nvel 3 do
TMM enquanto a rea de desenvolvimento ainda est no nvel 2. No entanto impossvel
migrar-se para o TMM nvel 4 sem que a organizao esteja no nvel 3, para que seja mantido
o equilibro entre os processos.


Estrutura do modelo de maturidade TMM
Cada nvel dever ter a seguinte diviso:

Objetivos de maturidade;
o Sub-objetivos de maturidade;
Atividades, tarefas e responsabilidades.

Os objetivos de maturidade so equivalentes s reas de processo do CMMI. O TMM possui
13 (treze) objetivos de maturidade nos seus 5 (cinco) nveis.

Para cada objetivo de maturidade, sub-objetivos mais concretos so definidos de tal forma que
o objetivo possa ser sustentado adequadamente.

LXXIX

Atividades e tarefas so aes especficas que precisam ser tomadas para melhorar a capaci-
dade de teste e as responsabilidades pela sua execuo so passadas para gerentes, desenvol-
vedores/testadores e usurios/clientes.

O TMM foi baseado nas seguintes fontes de conhecimento:

CMMI de onde o conceito de nveis de maturidade, com todas as suas divises e sub-
divises, foi tirado;
O modelo de teste de Gelperin e Hetzel;
Prticas industriais correntes;
As fases progressivas de Beizer de um modelo mental de testadores, que mostra que a
maturidade de cada organizao conseguida atravs de habilidades, conhecimentos e
atitudes das pessoas que trabalham nela.

Avaliao dos nveis de maturidade

Em nenhum material do TMM que tivemos acesso encontramos em algum lugar uma descri-
o do que seriam as possveis evidncias que deveramos procurar para avaliar se a organiza-
o atingiu o nvel de maturidade desejado. A experincia em trabalhos de avaliao em em-
presas em CMMI e mps.BR nos levou a sugerir no decorrer desse trabalho possveis evidn-
cias que deveriam ser buscadas pelo avaliador. Cabe portanto esclarecer, que, sempre que
citarmos evidncias, essas foram sugeridas por esses autores e no fazem parte do documento
original criado pelo Illinois Institute of Technology.

Nvc! 1 - Inicia!

Neste nvel os testes so executados de forma catica. Possivelmente no existe uma equipe
responsvel pela execuo dos testes que via de regra so executados pelos prprios desen-
volvedores. O nvel de qualidade bastante baixo e a incidncia de defeitos encontrados em
produo bastante alta.

Nvc! 2 Fasc dc dcIinin

Para que a rea de testes consiga cumprir as metas para atingir o nvel 2 precisa implantar os
seguintes objetivos de maturidade:

Desenvolver os objetivos de teste;
Iniciar um processo de planejamento de teste;
Institucionalizar tcnicas e mtodos bsicos de teste.

Neste nvel o teste j tem um ciclo de vida e planejado, alm de ser suportado por tcnicas e
mtodos. Desta forma pode ser repetido para cada um projeto de software. Existe uma separa-
o clara nos nveis de teste.

Desenvolver os objetivos de teste

LXXX

A organizao deve separar claramente os nveis de teste, ou seja, quem executa os testes uni-
trios, de integrao, de sistema e de aceitao.

Os sub-objetivos de maturidade so os seguintes:

A organizao deve formar uma equipe de teste para cada um dos seus nveis de teste.
Evidncias possveis: Deve haver um documento definindo quem ir executar cada n-
vel de teste (unitrio, integrao, sistema e aceitao).
A equipe de teste deve desenvolver e registrar os seus objetivos;
Evidncias possveis: A equipe encarregada pelos testes deve definir claramente os
seus objetivos e registr-los num documento.
Todos os documentos criados pela equipe de teste, e especificamente os seus objeti-
vos, devem ser distribudos por todos os gerentes de projetos e desenvolvedores.
Evidencias possveis: Os documentos criados pela equipe de teste devem ser distribu-
dos para todos os envolvidos. O comum seria isso estar registrado no plano do projeto
do software ou no plano de teste identificado como plano de comunicao, conforme
definido no prximo sub-objetivo.. Uma lista de objetivos claros a serem alcanados
pela equipe deve ser suficiente para atender a esse sub-objetivo.
Os objetivos de teste devem estar nos planos de teste. Neste caso a empresa poder j
trabalhar com um documento definido para este fim como o chamado Plano de Teste,
ou ter esses objetivos embutidos no plano do projeto de projeto de desenvolvimento.
Evidncias possveis: Deve haver um plano de teste ou um plano do projeto de softwa-
re que contemple esses objetivos. Lembre-se que neste nvel o teste pode ainda estar
sendo feito por uma equipe montada exclusivamente para este fim.

Iniciar um processo de planejamento de teste

O processo de planejamento espera-se deva seguir os preceitos mnimos para a elaborao de
um plano de teste bem definido. Um caminho consistente aquele definido pelo PMI. O Pla-
no de Teste pode ser um documento separado e preparado exclusivamente pela equipe de teste
ou pode estar embutido no plano do projeto de desenvolvimento do software. Entendemos que
um plano especfico deve ser muito mais fcil de entender e por isso o melhor caminho a
adoo de um Plano de Teste especfico para o projeto de teste.

Os sub-objetivos de maturidade so os seguintes:

Deve ser definido um documento de polticas de planejamento de teste que abranja to-
da a organizao e esta poltica deve ser apoiada pelos diversos nveis de administra-
o.
Evidncias possveis: A organizao ou empresa deve ter um documento de polticas
onde o planejamento de teste esteja claramente definido.
Deve haver um modelo de plano de teste institucionalizado na organizao e seguido
pela equipe de teste e pela equipe de desenvolvimento;
Evidncias possveis: A organizao ou empresa deve ter um local nico que seja de
livre acesso aos grupos envolvidos para armazenar o template previamente definido e
institucionalizados a ser usado na elaborao do Plano de Teste.
Os lderes de projeto e outros tcnicos devem ser treinados para elaborar e usar o pla-
no de teste.
Evidncias possveis: A organizao ou empresa deve planejar e executar treinamen-
tos de institucionalizao dos processos e as suas listas de presena devem ser arqui-
LXXXI

vadas. Os templates definidos devem conter instrues de preenchimento para facilitar
as auditorias.
Os procedimentos para a elaborao do plano de teste devem contemplar como entra-
da para este documento os requisitos do software elaborados pelos usurios;
Evidncias possveis: A organizao ou empresa deve manter de forma controlada as
verses das especificaes / requisitos elaborados. Os procedimentos para elaborar o
plano de teste devem claramente definir como entrada os requisitos do software.
O plano deve ser controlado, alterado, avaliado e monitorado, inclusive, com o apoio
de todos os gerentes.
Evidncias possveis: Devem existir registros que claramente mostrem que o plano de
teste est sendo monitorado. Uma boa evidncia seriam registros de reunies onde cla-
ramente este assunto tenha sido tratado.
A organizao ou empresa deve ter o controle das alteraes das verses e estas de-
vem sofrer aprovaes pelos grupos envolvidos. Essas aprovaes devem ser armaze-
nadas de forma a propiciar o rastreamento nas auditorias.

Institucionalizar tcnicas e mtodos bsicos de teste

Os sub-objetivos de maturidade so os seguintes:

Os gerentes devem institucionalizar um grupo de polticas que garantam que as tcni-
cas e os mtodos ou metodologias definidos sejam aplicados por toda a organizao;
Evidncias possveis: As listas de presenas dos treinamentos de institucionalizao
devem ser armazenadas e a cada novo profissional deve ser informado da existncia
das polticas e o mesmo deve tomar cincia.
Uma equipe de teste deve ser formada para estudar, avaliar e recomendar um grupo de
tcnicas bsicas de teste, assim como ferramentas, que suportem a execuo dos testes
na organizao.
Evidncias possveis: A organizao ou empresa deve manter uma equipe com conhe-
cimento em teste, com perfil definido para as atividades a serem desempenhadas. Esta
equipe deve comprovar experincia e/ou treinamentos para desempenharem as funes
definidas para cada cargo.

Alguns autores apresentam cada nvel de maturidade atravs da viso de cada um dos seus
atores ou participantes, neste nvel temos as seguintes vises:

Viso dos gerentes;
Viso dos desenvolvedores e testadores;
Viso dos usurios ou clientes.

Esta abordagem ser usada apenas como exemplo para este nvel 2.

Viso dos gerentes

Os seguintes compromissos devem ser assumidos ao nvel gerencial:

As gerncias superiores devem fornecer todo o apoio, recursos e treinamento
necessrios para a implantao de uma poltica de planejamento de testes;
LXXXII

Evidncias possveis: Armazenar as listas de presena dos treinamentos reali-
zados e ou os certificados que comprovem a experincia necessria as funes
exercidas.
O gerente do projeto de testes deve ser o responsvel pela negociao dos
compromissos e responsabilidades junto a equipe de desenvolvimento para a
elaborao do Plano de Testes e de todos os artefatos criados pelo projeto de
testes;
Evidncias possveis: As reunies para as definies com os grupos envolvidos
devem gerar atas e estas devem ser armazenadas assim com todos os artefatos
gerados.
O gerente do projeto de testes deve ter a garantia de que os usurios aceitam e
apiam o Plano de Testes, incluindo a forma de encaminhamento dos requisi-
tos.
Evidncias possveis: A aprovao do documento Plano de Teste pelo grupo
envolvido deve ser armazenada em local de fcil acesso para as auditorias.

Viso dos desenvolvedores e testadores

Os seguintes compromissos devem ser assumidos pelas equipes de teste e
de desenvolvimento:

Fornecer subsdios para elaborao do Plano de Testes, ajudando no es-
tabelecimento de metas de teste, mtodos, procedimentos, ferramentas e cro-
nogramas;
Evidncias possveis: As reunies para as definies com os grupos envolvidos
devem gerar atas e estas devem ser armazenadas assim com todos os artefatos
gerados.
Desenvolver especificaes de teste, casos de teste, critrios para identificao
ou no de defeitos para cada um dos nveis do Plano de Testes;
Evidncias possveis: Todos os artefatos listados no Plano de Teste devem ser
elaborados e armazenados com um controle de verso para as suas possveis
alteraes. Para cada artefato elaborado deve ser preparado um template e este
deve conter as referidas instrues de preenchimento.
Apoiar na definio dos equipamentos, softwares e outros recursos necessrios
para a execuo dos testes.
Evidncias possveis: Os recursos a serem utilizados no processo de teste de-
vem ser devidamente acordados entre a equipe de teste no incio de cada proje-
to e com a concordncia dos envolvidos de forma a garantir a melhor utilizao
dos recursos computacionais.

Viso dos usurios ou clientes

Os seguintes compromissos devem ser assumidos pelos usurios ou clientes:

Fornecer apoio para a elaborao e aceitao do Plano de Testes;
LXXXIII

Evidncias possveis: As reunies para as definies e posteriores aprovaes,
com os grupos envolvidos devem gerar atas e estas devem ser armazenadas as-
sim com todos os artefatos gerados.
Apoiar na descrio dos requisitos funcionais, de performance e outros
atributos de qualidade tais como, segurana, portabilidade, usabilidade
e interoperabilidade.
Evidncias possveis: As reunies para as definies com os grupos envolvidos
devem gerar atas e estas devem ser armazenadas assim com todos os artefatos
gerados.

Nvc! 3 - Intcgran

O objetivo a ser alcanado neste nvel um nvel de integrao entre o teste e o de-
senvolvimento do software, atravs dos ciclos de vida de ambos projetos. Neste n-
vel deve estar constitudo formalmente uma organizao para a execuo dos tes-
tes.

Para que a rea de testes consiga cumprir as metas para atingir o nvel 3 precisa implantar os
seguintes objetivos de maturidade:

Estabelecer uma organizao de teste de software;
Estabelecer um programa de treinamento tcnico;
Integrar o teste no ciclo de vida do software;
Controlar e monitorar o processo de teste.

Estabelecer uma organizao de teste de software

No nvel 3 deve haver um grupo dentro da organizao formalmente encarregado da
execuo dos testes. No nvel anterior a equipe poderia ser temporria e alocada
eventualmente, mas no estava integralmente voltada para esta atividade.

Os sub-objetivos de maturidade so os seguintes:

Deve ser criada formalmente uma organizao de teste de software dentro da
estrutura organizacional da empresa.
Evidncias possveis: A empresa deve possuir uma equipe fixa encarregada da execu-
o dos testes dentro do seu organograma e separada da equipe de desenvolvimento e
subordinados a uma gerncia especfica.
Regras e responsabilidades devem ser definidas para o grupo de teste;
Evidncias possveis: A rea de teste deve possuir uma equipe apartada das
demais equipes com as respectivas definies de cargos e funes para os
seus membros devidamente descritas. A evidncia a ser buscada deve ser
um documento que comprove essa estrutura organizacional.
Um grupo de tcnicos treinados e motivados dever compor o grupo de teste.
Evidncias possveis: A organizao ou empresa deve manter uma equipe especializa-
da em teste, com perfil definido para as atividades a serem desempenhadas. Essa equi-
pe deve comprovar experincia e/ou treinamentos para desempenharem as funes de-
finidas para cada cargo. Regularmente (periodicidade estabelecida pela equipe de qua-
LXXXIV

lidade) a equipe de qualidade deve analisar o ndice de satisfao motivacional da e-
quipe. Na busca dessa evidncia devem ser avaliados tambm listas de presena em
treinamentos e questionrios de avaliao de satisfao.
Deve haver uma ligao formal entre as atividades de teste e os usurios de
forma a facilitar o trabalho do grupo de teste principalmente no que se refere
ao entendimento dos requisitos.
Evidncias possveis: Os requisitos gerados devem ser analisados e aprova-
dos pela equipe de teste de forma a criar um comprometimento entre as equi-
pes (desenvolvimento, teste e usurios). A ata da reunio de kick off do pro-
jeto pode ser um desses registros de que os usurios tm pleno conhecimen-
to da atividade de teste desde que conste claramente esse objetivo.


Estabelecer um programa de treinamento tcnico

Os sub-objetivos de maturidade so os seguintes:

A gerncia deve estabelecer um programa de treinamento com recursos financeiros e
apoio administrativo.
Evidncias possveis: Programa de treinamento da empresa contemplando teste de
software.
Um comit dever desenvolver e divulgar uma poltica de treinamento;
Evidncias possveis: Algum registro que mostre a divulgao da poltica de treina-
mento da empresa e que contemple teste de software.
Os planos e objetivos de treinamento devem ser elaborados a partir de informaes co-
letadas junto dos gerentes.
Evidncias possveis: Documento que mostre que a equipe de teste esteve envolvida
no processo de elaborao do plano de treinamento. Ex.: E-mail enviando as necessi-
dades de treinamento.
Um grupo de treinamento na empresa deve ser estabelecido com ferramentas, equipa-
mentos e todo apoio necessrio.
Evidncias possveis: A empresa deve ter uma equipe ou rea de treinamento.

Integrar o teste no ciclo de vida do software

Este objetivo visa a garantir que o processo de teste seguir um ciclo de vida clara-
mente definido e que este ser totalmente integrado ao ciclo de desenvolvimento do
software.

Os sub-objetivos de maturidade so os seguintes:

O processo de teste deve ter um ciclo de vida separado em fases e sub-fases
de tal forma que possa se integrar com o ciclo de vida do processo de desen-
volvimento, baseado em polticas organizacionais freqentemente revistas
junto aos gerentes.
Evidncias possveis: Procedimentos de teste, com ciclo de vida aderente ao
processo de desenvolvimento, com registros de atualizao. Deve haver uma
poltica organizacional que sirva de base para escrever esses procedimentos.
O registro dos documentos de teste sob uma gerncia de configurao muitas
vezes suficiente para provar que existem diferentes verses.
LXXXV

Um modelo de teste (por exemplo um modelo V) deve ser formalmente defini-
do com fases e sub-fases claramente definidas.
Evidncias possveis: Procedimentos de teste distribudos nas fases do ciclo
de vida do projeto.
Devem existir recursos que permitam a integrao entre as atividades de tes-
te e aquelas correspondentes no ciclo de vida de desenvolvimento do softwa-
re;
Evidncias possveis: Plano de teste definindo claramente a participao da
equipe de teste no projeto.
Definies padronizadas devem ser desenvolvidas para os produtos de teste
e a sua qualidade deve ser medida.
Evidncias possveis: Devem haver mtricas que permitam medir a qualidade
dos produtos de teste. Os produtos de teste devem estar claramente definidos
nos procedimentos de teste.
Deve haver procedimentos formais que permitam aos testadores trabalhar
junto aos desenvolvedores com facilidade.
Evidncias possveis: Procedimentos de teste devidamente definidos e insti-
tucionalizados.

Observao geral: Empresas que possuem um processo de teste claramente
definido normalmente conseguem atender a todos os sub-objetivos definidos.

Controlar e monitorar o processo de teste

Os sub-objetivos de maturidade so os seguintes:

A organizao deve criar mecanismos e polticas para controlar e monitorar o processo
de teste.
Evidncias possveis: Mtricas de controle do processo de teste envolvendo a sua de-
finio e o seu uso.
Um grupo de medidas do processo de teste deve ser definida e coletada regularmente e
os seus resultados distribudos.
Evidncias possveis: Mtricas de controle do processo de teste e evidncias da sua
distribuio pelas partes envolvidas no teste.
Medidas corretivas devem ser tomadas sempre que o processo de teste se desviar sig-
nificativamente do que estava planejado.
Evidncias possveis: Reunies de acompanhamento do projeto de teste mostrando o
progresso do projeto. Documento provando que os desvios foram registrados e que es-
to sendo acompanhados.

Nvc! 4 - Gcstn c mcdics

Para que a rea de testes consiga cumprir as metas para atingir o nvel 4 precisa implantar os
seguintes objetivos de maturidade:

Estabelecer um programa de revises;
Estabelecer um programa de medies;
Avaliao da qualidade do software.
LXXXVI


Neste nvel o foco ampliar a atividade de teste e melhorar as suas medies. Devem ser in-
cludas atividades de revises em todos os documentos criados pelo processo de teste. Desta
forma as reas de processo de validao e verificao devem estar cobertas neste nvel por
esta expanso da atividade de teste.

Estabelecer um programa de revises

Os sub-objetivos de maturidade so os seguintes:

Os diversos nveis de gerncia devem instituir um programa formal de reviso
e garantir a sua integrao dentro da cultura da organizao.
Evidncias possveis: Documento definindo o funcionamento do programa de
reviso. Exemplo: Plano de Reviso.
O grupo de teste deve definir formalmente objetivos de reviso que devero
ser aplicados durante todo o ciclo de vida de teste de software e do ciclo de
vida do desenvolvimento do software.
Evidncias possveis: Plano de reviso dos documentos de teste definido e
divulgado.
Os itens de reviso devem estar claramente definidos por projeto;
Evidncias possveis: Plano de reviso dos documentos de teste.
As equipes devem ser treinadas para poderem cumprir essas prticas de re-
viso de artefatos
Evidncias possveis: Registro de treinamentos em reviso.

Estabelecer um programa de medies

Os sub-objetivos de maturidade so os seguintes:

Deve ser definida uma poltica de medio cujos objetivos contemplem o pro-
cesso de teste de software.
Evidncias possveis: Documento descrevendo a poltica de medio da em-
presa onde devem estar listadas as mtricas de teste.
Um plano de medies deve ser desenvolvido com mecanismos para coleta,
anlise e compilao de dados.
Evidncias possveis: Plano de medies para o projeto de teste onde deve
estar claramente definido quem ir coletar, analisar e compilar os dados. Isso
significa buscar os dados, fazer uma reviso e enviar para os tomadores de
deciso.
Deve haver plano de ao cujo objetivo seja usar os resultados das medies
para melhorar o processo de teste.
Evidncias possveis: Plano de medio definindo as aes a serem tomadas
a partir dos resultados coletados. Por exemplo, aes devem ser tomadas ca-
so os valores atinjam determinado limite. Este plano deve estar relacionado
com a lista de risco do projeto de teste.

Observao geral: Evidentemente que caso a empresa tenha um processo de
medio instalado e funcionando corretamente, o que ocorre nas empresas
com nvel de maturidade CMMI 2 ou mps.BR F essas evidncias sero en-
contradas com facilidade.
LXXXVII


Avaliao da qualidade do software

Os sub-objetivos de maturidade so os seguintes:

Os grupos de garantia de qualidade devem definir polticas, objetivos de qua-
lidade e atributos de qualidade para cada produto de software.
Evidncias possveis: Processo de garantia de qualidade institucionalizado
com os seus responsveis claramente definidos.
A organizao dever ter procedimentos formais para avaliar os resultados do
processo de avaliao.
Evidncias possveis: Procedimentos a serem tomados com os resultados das
medies onde os responsveis pela ao devem ser claramente definidos.
O processo de teste deve ser estruturado, medido e avaliado para garantir
que os objetivos de qualidade sejam atingidos.
Evidncias possveis: Processo de teste contemplando os objetivos definidos
para qualidade. Exemplo: Medies efetuadas em um projeto e resultados
analisados.

Neste nvel espera-se que algumas caractersticas de qualidade do software possam
ser atingidas e avaliadas (ver ISO-9126).

Nvc! 5 - Otimizan, prcvcnn dc dcIcitns c cnntrn!c dc qua!idadc

Para que a rea de testes consiga cumprir as metas para atingir o nvel 5 precisa
implantar os seguintes objetivos de maturidade:

Aplicao de processo para preveno de defeitos;
Controle de qualidade;
Otimizao do processo de teste

Aplicao de processo para preveno de defeitos

Os sub-objetivos de maturidade so os seguintes:

A organizao deve desenvolver e manter uma poltica que permita a preveno de de-
feitos.
Evidncias possveis: Poltica de preveno definida e institucionalizada.
A preveno de defeitos deve ser uma poltica suportada pelos diversos nveis geren-
ciais.
Evidncias possveis: Poltica de preveno institucionalizada.
Os defeitos encontrados e removidos devem ser identificados e registrados durante ca-
da fase do ciclo de vida do software.
Evidncias possveis: Os defeitos encontrados devem ser rastreados at a sua conclu-
so. Deve haver uma base de registros de defeitos.
Um mecanismo deve ser definido para buscar a causa dos defeitos.
Evidncias possveis: Os defeitos encontrados devem ser analisados e as suas causas
identificadas e registradas. Deve haver um registro da resoluo dos defeitos.
LXXXVIII

Deve haver um plano integrado envolvendo testadores e desenvolvedores visando
preveno de defeitos e este plano deve ser rastreado e monitorado.
Evidncias possveis: Documento que comprove a integrao entre as equipes na bus-
ca da melhoria contnua. O plano de preveno deve estar definido e precisa ser moni-
torado.


Controle de qualidade

Os sub-objetivos de maturidade so os seguintes:

A organizao deve desenvolver e manter procedimentos de controle de qualidade.
Evidncias possveis: A empresa ou organizao deve demonstrar que realiza auditoria
nos processos e procedimentos visando buscar a melhoria contnua.
Os grupos de teste e de controle de qualidade devem estabelecer metas claras de qua-
lidade visando a reduo de defeitos nos produtos de softwares.
Evidncias possveis: Possuir objetivos e metas definidas no plano de medio da em-
presa. No pode haver nenhuma medio que no se saiba o que fazer com os seus re-
sultados.
Os gerentes de teste devem incluir as metas de qualidade nos seus planos.
Evidncias possveis: Possuir objetivos e metas de qualidade definidas no plano de
testes.
O grupo de teste deve ser treinado em mtodos estatsticos;
Evidncias possveis: Lista de presena dos treinamentos realizados.
Informaes dos usurios devem ser coletadas para serem integradas ao modelo de
qualidade.
Evidncias possveis: Relatrio de satisfao do cliente

Otimizao do processo de teste

Os sub-objetivos de maturidade so os seguintes:

A organizao deve desenvolver e manter procedimentos de melhoria do pro-
cesso de teste.
Evidncias possveis: Processo para viabilizar as buscas de melhorias. E-
xemplo: Processo de Melhoria definido e institucionalizado, o que normalmen-
te ocorre com empresas CMMI nvel 5 ou mps.Br nvel A.
O grupo de melhoria de processo de teste deve ser estabelecido para monito-
rar o processo de teste e identificar possibilidades de melhoria.
Evidncias possveis: Definio do grupo de melhoria de teste com os seus
responsveis.
Um mecanismo deve ser criado para avaliar novas ferramentas e tecnologias
que possam melhorar a maturidade e capacidade do processo de teste.
Evidncias possveis: Procedimentos para soluo tcnica com o estudo de
alternativas. Demonstrar que existem estudos e que decises foram tomadas.
A efetividade do processo de teste deve ser constantemente avaliada e as
decises de quando interromper o processo de teste devem estar relaciona-
das aos objetivos de qualidade de uma forma mensurvel.
LXXXIX

Evidncias possveis: As medies devem mostrar que um determinado nvel
de qualidade claramente definido j foi alcanado que o processo pode ser in-
terrompido. Medies precisam ser feitas para avaliar o atendimento da meta.

Evidncias diretas para todos os sub-objetivos

Os avaliadores de maturidade de empresas nos modelos CMMI e mps.BR costu-
mam comprovar as evidncias diretas atravs de documentos de projetos mostrando
que as prticas foram implementadas e que esto sendo usadas. No caso do TMM a
idia deve ser a mesma. O documento organizacional s serve para mostrar que o
objetivo ou sub-objetivo est claramente definido, mas caso seja necessrio de-
monstrar o seu uso o avaliador dever buscar as tais evidncias diretas. Por exem-
plo, o projeto de teste de um projeto uma evidncia direta de que o projeto est
sendo planejado.
























XC















Mtricas de Defeitos,
Cobertura e Progresso de
Testes
XCI


Good Enough Software (GES) desponta como um decisor pragmtico para liberao de verses
de um software. Um produtor de software que adota GES decide liberar uma verso para uso mesmo
que esta ainda contenha alguns defeitos (bugs) e desde que ela j possa ser til para seus usurios.
A expectativa de ir consertando os bugs em verses futuras medida em que tambm se incrementa
(possivelmente) a funcionalidade do software. Claro que dependendo das condies e exigncias do
mercado e clientes, pode no ser fcil ou mesmo possvel, adotar GES. O atrativo do GES que o
produtor pode reduzir o prazo-de-entrega da verso, trazendo algum retorno financeiro mais rapida-
mente.

Os defeitos residuais no podem ser crticos (por exemplo, destruir o sistema de arquivos) nem em
nmero excessivo. Um grande nmero de defeitos causaria falhas freqentes do software, exasperando
o usurio. de importncia pois, conhecer o nmero de defeitos no software para que se decida (ou
no) pela sua liberao para uso.

Conhecer precisamente o nmero de defeitos em um Software relativamente extenso e complexo
no trivial e talvez, nem possvel. A no-deteco de defeitos aps uma bateria de testes em um
software extenso no deve ser motivo de euforia. Normalmente significa apenas que os defeitos exis-
tem e no foram descobertos! Alguns bugs s aparecem aps muito tempo de uso por uma grande
populao de usurios, uma vez que testes exaustivos (nos testes alfa e beta) muitas vezes no podem
ser feitos. Isto porque o total de combinao de seqncias de comandos e situaes (estados) do
ambiente de execuo do software pode ser elevadssimo.

Assim, como estimar o nmero de defeitos? A resposta necessria para a adoo de GES com
risco razovel (afinal a reputao e o futuro do produtor podem ser comprometidos seriamente caso
os usurios no tolerem a freqncia de falhas). Infelizmente, a literatura de Engenharia de Software
no traz muitas informaes sobre previso de defeitos. Felizmente, existem alguns procedimentos
relativamente simples que podem ser adotados para reduzir a prtica de decises no escuro ou na
base do chute. Dois dos mais simples destes procedimentos so discutidos aqui.

Independentemente do procedimento adotado, a providncia de registrar o histrico de defeitos
nos vrios sistemas ou produtos que desenvolve a nica maneira para o produtor calibrar ou vali-
dar as estimativas que far. Esta providncia raramente tomada, mas voc no ir muito longe se no
passar a execut-la imediata e continuadamente. S com o histrico da distribuio de defeitos e do
nvel de satisfao de usurio voc poder aumentar a confiabilidade de suas estimativas e a conse-
qente deciso de liberao de verses. O primeiro procedimento ajudar a ilustrar a aplicao deste
histrico.


Procedimento 1 Uso do Histrico de Qualidade de Desenvolvimento

Por exemplo, o Bom Soft verso 1.1 com 10.000 linhas de cdigo (= 10 KLOC ou seja, 10
Kilo Lines Of Code) apresentou 40 defeitos detectados nos testes alfa e beta e que foram removidos
antes da liberao; e, outros 10 defeitos reportados pelos usurios (para o departamento de suporte
tcnico). A distribuio final de defeitos neste caso foi de 50 defeitos em 10 KLOC ou 5,0 defei-
tos/KLOC. O ndice de remoo de defeitos antes da liberao foi de 40/50 (ou 80%). Os usurios
reclamaram enfaticamente, mas foram acalmados pelo suporte aps algum esforo. Na verso 1.2 a
distribuio foi de 6,0 defeitos/KLOC; consertados todos os defeitos anteriores (foram acrescentados 5
KLOC e introduzido um total final de 30 novos defeitos), com ndice de remoo antes de liberao de
70%. Desta vez, os usurios quase que se rebelavam, ameaando aes judiciais por perdas e danos. A
situao foi crtica, mas contornada eventualmente. Neste ponto, sabe-se que a qualidade do desenvol-
vimento deste produtor est na faixa de 5,0 - 6,0 defeitos/KLOC e que o produto pode se queimar no
XCII

mercado ou com o cliente contratante se o ndice de remoo de defeito antes da liberao no for no
mnimo, 70%. Agora, deve-se decidir a liberao de Bom Soft v1.3, qual foram acrescentadas 20
KLOC e os testes detectaram 80 defeitos (o que d uma distribuio de 4 defeitos/KLOC). A no ser
que haja muita confiana na melhoria de qualidade do desenvolvimento, recomendam-se extrema cau-
tela e providncia de reviso de cdigo (mais testes, por exemplo) uma vez que a taxa de remoo
antes de liberao esperada ficar abaixo de 70% ( entre 50a 65%). Neste caso, uma aparentemente
menor distribuio de defeitos detectados nos testes motivo de apreenso e no de euforia.

Procedimento 2 Agrupamento de Defeitos

O segundo procedimento foi apresentado por Steve McConnell, da Construx Sofware Builders de Wa-
shington, EUA na revista IEEE Software de maio/junho 1997. Intitulado de Agrupamentos de Defei-
tos (Defect Pooling), o procedimento consiste basicamente em agrupar os defeitos sendo descober-
tos em dois conjuntos: A e B. Aqui, o importante ter independncia entre os dois agrupamentos - o
conjunto A montado por uma equipe que testa todo o produto e o conjunto B, por outra equipe sepa-
rada que tambm testa todo o produto. Alternativamente, uma nica equipe de testes poderia construir
o conjunto A com os defeitos econtrados nos dias de datas pares e o conjunto B com os defeitos em
datas mpares. Fechados os conjuntos A e B (no final dos testes), conte o nmero de defeitos:
- no conjunto A (DA);
- no conjuntoB (DB); e,
- que esto simultaneamente no conjunto A e no B (DAxDB)

Aplicando Teoria dos Conjuntos (vide figura), o nmero total de defeito distintos em ambos os con-
juntos D(A+B):

D(A+B) = DA + DB - D(Ax B)
XCIII


A+B


A B


AxB



O nmero total estimado de defeitos (durante testes e aps liberao do produto) pode ser aproximado
por:

Dtotal = ( DA x DB ) / D(AxB)


Voltando ao exemplo de Bom Soft v 1.3 e supondo que DA= 50, DB = 45 e DAxB = 15, o nmero
de defeito distintos 50 + 45 - 15 = 80 ( o nmero j fornecido). Contudo, o nmero total de defeitos
estimado pela ltima frmula ( 50x 45 ) / 15 = 150. Ou seja, espera-se ainda detectar 70 defeitos, o
que levaria a um ndice de remoo antes de liberao um pouco acima de 50%. melhor talvez, no
liberar esta verso na sua forma atual.

Note a importncia de se coletar o histrico neste caso (ltimo exemplo) para verificar a preciso da
estimativa e ajustar a credibilidade que o produtor passar a ter na estimativa gerada.

Os leitores interessados em um terceiro procedimento (um pouco mais complexo e trabalhado), bem
como na combinao de procedimentos, podem examinar o artigo de McConnell com mais vagar.

Para concluir e se voc desejar uma referncia para o seu produtor (ou equipe de desenvolvimento), o
ndice tpico de remoo de defeitos antes de liberao no EUA de 85%. Os melhores produtores
esto no patamar de 95-97%. Dos defeitos aps liberao, 30% so detectados aps 1 ano de uso do
produto e os restantes at o 4 ano de uso. Estas estatsticas so do Capers Jones, guru americano na
rea de Engenharia de Software.

Planejamento de Teste
Iremos apresentar uma descrio do Planejamento de Teste. Os detalhes de cada item esto
descritos abaixo.
Avaliao de Risco do Produto
Categorias e parmetros de risco do produto
Para conseguir fazer uma boa avaliao de risco do produto juntamente com o mtodo adota-
do, necessrio conhecer as caractersticas e subcaractersticas segundo a norma ISO 9126-1.
As caractersticas de qualidade segundo esta norma so mostradas na Tabela 4 Caractersti-
cas de qualidade segundo a norma ISO 9126-1.
Caracterstica Descrio
Funcionalidade Capacidade do software de fornecer funcionalidade que atendam a neces-
sidades definidas quando usado sob determinadas condies preestabeleci-
das.
XCIV

Confiabilidade Capacidade do software de manter um nvel especfico de performance
quando usado sob determinadas condies preestabelecidas.
Usabilidade Capacidade do software de ser entendido, aprendido, usado e atrativo
quando usado sob determinadas condies especficas.
Eficincia Capacidade do software de manter a performance, em relao aos recursos
disponveis, quando usado sob determinadas condies especficas.
Manutenibilidade Capacidade do software de ser mantido.
Portabilidade Capacidade do software de ser transferido de um ambiente para outro.
Tabela 4 Caractersticas de qualidade segundo a norma ISO 9126-1

As subcaractersticas de qualidade segundo a norma ISO 9126-1 so mostradas na Tabela 5
Subcaractersticas de qualidade segundo a norma ISO 9126-1.

Caracterstica Subcaractersticas Descrio
Funcionalidade Adequao Capacidade do software de fornecer um grupo de
funcionalidades adequadas para tarefas especficas e
para os objetivos dos usurios.
Acurcia Capacidade do software de fornecer resultados corre-
tos e acordados com o necessrio grau de preciso.
Interoperabilidade Capacidade do software de interagir com um ou mais
sistemas especificados.
Segurana Capacidade do software de proteger informaes e
dados, de tal modo que pessoas ou sistemas no au-
torizados no consigam acess-las. Por outro lado,
aqueles que esto autorizados podero acessar essas
informaes ou dados.
Conformidade com
a finalidade
Capacidade do software de aderir aos padres, con-
venes, regras, regulamentaes e leis relacionadas
funcionalidade.

Confiabilidade
Maturidade Capacidade do software de evitar falhas decorrentes.
Tolerncia a falhas Capacidade do software de manter um nvel especfi-
co de performance em caso de falhas ou de violaes
em sua interface especfica.
Recuperabilidade Capacidade do software de restabelecer um nvel
especfico de performance e recuperar os dados dire-
tamente afetados em caso de falhas.
Conformidade com
a confiabilidade
Capacidade do software de aderir a padres, conven-
es, regras, regulamentaes e leis relacionadas
confiabilidade.
Usabilidade Inteligibilidade Capacidade do software de permitir ao usurio en-
tender se o programa amigvel e como ele pode ser
usado para tarefas particulares e outras condies.
Apreensibilidade Capacidade do software de permitir ao usurio a-
prender com sua aplicao.
XCV

Operabilidade Capacidade do software de permitir ao usurio ope-
r-lo e control-lo.
Atratividade Capacidade do software de ser atrativo para o usu-
rio.
Conformidade com
a usabilidade
Capacidade do software de aderir aos padres, con-
venes, regras, regulamentaes e leis relacionadas
usabilidade.
Eficincia Comportamento em
relao ao tempo
Capacidade do software de fornecer tempos apropri-
ados de resposta e de processamento, relativos
soma de recursos usados e sob condies preestabe-
lecidas.
Comportamento em
relao aos recursos
Capacidade do software de utilizar a soma e os tipos
de recurso quando executar suas funcionalidades sob
condies preestabelecidas.
Conformidade com
a eficincia
Capacidade do software de aderir aos padres, con-
venes, regras, regulamentaes e leis relacionadas
eficincia.

Manutenibilidade
Analisabilidade Capacidade do software de passar por diagnsticos
em busca de deficincias, origens de falhas ou para a
identificao de partes que devem ser alteradas.
Modificabilidade Capacidade do software de permitir que uma altera-
o especfica seja implementada.
Estabilidade Capacidade do software de evitar efeitos inesperados
em decorrncia de alteraes.
Testabilidade Capacidade do software de ser testado aps altera-
es.
Conformidade com
a manutenibilidade
Capacidade do software de aderir aos padres, con-
venes, regras, regulamentaes e leis relacionadas
manutenibilidade.
Portabilidade Adaptabilidade Capacidade do software de ser adaptado a ambientes
diferentes sem a aplicao de aes ou outros meios
que no aqueles previamente estabelecidos.
Facilidade de insta-
lao
Capacidade do software de ser instalado num ambi-
ente especfico.
Coexistncia Capacidade do software de coexistir com outro soft-
ware no mesmo ambiente e compartilhar recursos.
Capacidade para
substituir
Capacidade do software de substituir outro software
no mesmo ambiente para o mesmo propsito.
Conformidade com
a portabilidade
Capacidade do software de aderir aos padres, con-
venes, regras, regulamentaes e leis relacionadas
portabilidade.

Tabela 5 Subcaractersticas de qualidade segundo a norma ISO 9126-1

As tabelas acima ajudam na identificao e priorizao dos riscos do produto.
XCVI

Identificao dos riscos do produto
Para que a identificao dos riscos do produto seja feita de maneira rpida e eficiente agregan-
do maior valor e confiabilidade, o time de desenvolvimento deve contribuir nessa identifica-
o e na anlise desses riscos.
Algumas tcnicas de identificao de risco do produto que sero utilizadas so: brainstorming,
entrevistas tcnicas, listas de verificao e lies aprendidas. Lembrando que no existe a o-
brigatoriedade de usar todas as tcnicas acima.
necessrio identificar tambm as partes interessadas associadas com cada risco.
Anlise dos riscos do produto
Aps a identificao dos riscos do produto, chega o momento de analis-los. Para isso, ne-
cessrio documentar tudo o que foi discutido e definido entre as partes interessadas.
Como fao para documentar os riscos?
Para documentar e fazer o acompanhamento dos riscos necessrio ter uma Matriz de
Anlise de Riscos. Nessa matriz temos alguns campos, por exemplo:
o ID do Risco: campo utilizado para identificar o risco;
o ID do Requisito: campo utilizado para identificar qual requisito est associa-
do com o risco, se aplicvel;
o Projeto: campo utilizado para identificar o projeto associado ao risco;
o Item de Risco: campo utilizado para documentar qual o item de risco;
o Status: campo utilizado para saber qual o status do risco, por exemplo, aber-
to, fechado ou parado;
o Impacto: campo utilizado para saber qual o impacto do risco, por exemplo,
alto, mdio ou baixo;
o Plano de Mitigao e Contingncia: campo utilizado para documentar o pla-
no de mitigao e contingncia;
o Pessoa Responsvel: campo utilizado para identificar a pessoa responsvel
para ajudar, acompanhar ou resolver o risco;
o Acompanhamento / Comentrios: campo utilizado para documentar o a-
companhamento e comentrios em geral;
o Data de Abertura: campo utilizado para indicar a data de abertura do risco;
o Data de Fechamento: campo utilizado para indicar a data de fechamento do
risco;
o Durao (dias): campo utilizado para indicar a quantidade de dias que o risco
ficou aberto.
Vale lembrar, que ainda nessa fase, algumas mudanas podem ocorrer como a possibilidade de
criao ou mudana dos requisitos, mudanas na abordagem do desenvolvimento do software
em decorrncia do resultado da anlise do risco.

Abordagem de Teste
XCVII

Funcionalidades e itens para serem testados
Quando chega o momento de identificar as funcionalidades e itens que devem ser testados,
devemos levar em considerao os riscos do produto e o tipo de sistema. Nem sempre conse-
guiremos identificar todas as funcionalidades e itens que devero ser testados, mas a idia
tentar identificar o mximo possvel no deixando de testar nenhum requisito. Com o passar
do tempo, o time de teste vai adquirindo conhecimento tcnico do(s) sistema(s), da(s) tecnolo-
gia(s) e ficando cada vez mais maduro incluindo os processos e tcnicas de teste. Com isso, o
time de teste conseguir no futuro, identificar possveis funcionalidades e itens que devem ser
testados e no foram identificados/testados anteriormente.
Para ajudar o time de teste nessa tarefa, essencial que o time de desenvolvimento tente revi-
sar as funcionalidades e itens sugeridos para teste. Muitas vezes algumas sugestes no so
necessrias, pois o risco de acontecer algum defeito muito baixo e o custo pode ser muito al-
to, novamente necessrio levar em considerao a anlise de riscos.
Outra ferramenta que ajudar muito nessa atividade uma Matriz de Teste por Tipo de Fun-
cionalidade, a qual deve ser atualizada com novos tipos de testes a cada funcionalidade nova
identificada ou alterada. Essa matriz ajudar principalmente na fase de Estimativa e Anlise de
Teste servindo como critrio de entrada.
Abaixo seguem alguns exemplos de testes para algumas funcionalidades:
Boto;
Boto limpar;
Boto submeter;
Campo texto;
Campo arquivo;
Campo senha;
Campo mltipla seleo;
Campo nica seleo;
Campo escondido;
Campo rea de texto;
Campo combobox;
Campo listbox;
Campo especfico;
Campo numrico;
Campo alfanumrico;
Campo de data;
Campo mandatrio;
Campo opcional;
Teclas de atalho;
Visual Interface visual do usurio;
Navegao Links, Tab;
Modo de adio e edio de dados;
Integridade dos dados;
XCVIII

Usabilidade.
Aspectos a serem cobertos:
Funcionalidades:
o Links
Todos os links externos e internos;
Todos os links de e-mail;
Pginas rfs e links quebrados.
o Formulrios
Checar a formatao de todos os campos;
Checar as validaes, tratamento de entradas invlidas, valores default
e campos obrigatrios opcionais.
o Cookies
Verificar se os cookies esto habilitados e como sero expirados.
o Indexao de pginas
Meta Tags;
Frames;
Sintaxe HTML.
o Base de dados
Integridade dos dados: perda ou erros nos dados armazenados nas ta-
belas;
Erros de sada dos dados: possveis erros durante as operaes de es-
crita, edio e leitura dos dados nas tabelas.
Usabilidade:
o Navegao
Navegao e uso de controles na interface (Botes, caixas de texto,
etc);
Navegao na aplicao atravs da tecla TAB, teclas de funo, con-
trole e mouse;
Acessibilidade das principais funes atravs da pgina principal do
site.
o Contedo
Ortografia e Gramtica;
Atualizao da informao, detalhes de contato, fonte das informa-
es, referncias, etc.
o Aparncia Geral
Aparncia das pginas e uso de frames;
Cores e tamanho da fonte utilizada;
Design consistente, localizao de smbolos e logomarcas.
Interface do Usurio:
XCIX

o Verificar as possveis resolues de tela que o usurio pode adotar (800600,
1024768);
o Garantir a persistncia de todos os valores. Aps a entrada desses, montar um
formulrio e enviar os dados para outra pgina;
o Verificar se a paginao do site esta apropriada;
o Identificar se os botes possuem uma boa localizao e tamanhos adequados;
o Uso de criptografia de senhas em pginas de login e uso de caixas de texto do
tipo password;
o Em caso de operaes ilegais, uso de mensagens simples e claras para o en-
tendimento do usurio;
o Uso de mensagens de confirmaes nas operaes realizadas de envio, exclu-
so, atualizao de dados;
o Disponibilidade;
o Continuidade de uso do sistema ou determinadas funcionalidades em determi-
nados perodos ou de forma continua (247);
o Uso de espao de disco e memria.
Interface com o lado Servidor:
o Verificar se a comunicao esta sendo feita corretamente (aplicao web Ser-
ver e aplicaes servidoras de banco de dados).
o Compatibilidade entre o software servidor, hardware, conexes de rede e
banco de dados.
o Compatibilidade com os Clientes
Plataformas;
Windows;
Unix e Linux.
o Navegadores
Internet Explorer;
Firefox;
Mozila;
Configuraes dos navegadores (segurana, grfico, Java, etc.) e fra-
mes.
Uso de Grficos
o Carregamento de imagens;
o Uso de arquivos Flash, PDF, etc.
Segurana
o Validao de acesso ao sistema e limites para as tentativas de acesso;
o Possibilidade de acesso pginas restritas atravs da digitao da URL; dire-
tamente no navegador, bypassed pgina de acesso ao sistemas;
o Verificar se a criptografia est correta caso o uso de SSL;
o Validao XSS (Cross Site Scripting).
Performance:
C

o Velocidade da Conexo
Tentar o acesso com os diversos tipos de conexes (Cable DSL, etc);
Unix e Linux.
o Carga
Verificar a performance atravs de testes de carga e nmero de usu-
rios por perodo do dia;
Acesso simultneo a determinadas pginas e transferncia de dados
(download / upload).
o Stress
Testes de stress em determinadas funcionalidades, para definir as limi-
taes e recuperaes em casos de crashes do sistema;
Sistema em condies anormais.
Abordagem de teste
A abordagem de teste definida para mitigar os riscos dos produtos identificados e prioriza-
dos. Ela deve ser descrita com um nvel de detalhe suficiente para suportar o estgio de identi-
ficao de tarefas de teste com uma estimativa de tempo requerido para cada uma.
A tcnica de design de teste usada poder ser alterada de acordo com alguns critrios:
Tipos do sistema;
Requisitos contratuais ou de clientes;
Nvel de risco;
Tipo de risco;
Documentao disponvel;
Conhecimento tcnico da equipe de teste;
Ciclo de vida de desenvolvimento;
Experincia anterior de tipos de defeitos encontrados.

Abordagem para reviso dos produtos de trabalho de teste
Os produtos de trabalho de teste devem ser revisados pelo menos pelo prprio time de teste
no sendo necessrio haver uma inspeo ou reviso formal para os mesmos juntamente com
o time de desenvolvimento.
Abordagem para re-teste
Todos os casos de teste que falharam em um determinado momento do ciclo de execuo de-
vero ser re-testados assim que o time de desenvolvimento tiver corrigido o defeito. Com isso,
um novo ciclo de execuo incluindo os testes que falharam dever ser criado e os testes exe-
cutados, seguindo a poltica de execuo de teste.
Abordagem para teste de regresso
Na abordagem de teste de regresso necessrio definir alguns pontos como:
Por que Regresso?
Seleo de Teste
Matriz de Rastreabilidade de Requisitos
CI

Nvel de regresso
o Sanity Bsico;
o Sanity Estendido;
o Regresso Bsica;
o Regresso Estendida;
o Regresso Total.
Testes Essenciais
Ferramentas de teste
Na abordagem de teste muito importante definir ferramentas que auxiliaro no seu gerenci-
amento. Quando se fala em gerenciamento de teste no significa que se fala apenas dos testes,
pois no pode olhar para os casos de teste somente como o produto final sem considerar o ti-
me de desenvolvimento e todo o ciclo de vida do desenvolvimento de software. necessrio
verificar se a ferramenta adotada para cada fase atende as necessidades dos times e, neste caso,
fazer um levantamento de prs e contras.
Para melhorar ainda mais a qualidade do produto levando em considerao todos os times en-
volvidos no desenvolvimento de software, temos que definir ferramentas para as seguintes -
reas:
Gerenciamento de testes;
Gerenciamento de defeitos;
Gerenciamento de requisitos;
Gerenciamento de controle de verso de software.
Revisar a abordagem de teste com as partes interessadas
A reviso da abordagem de teste deve ser revisada com as partes interessadas, como por e-
xemplo, com o time de desenvolvimento.
Rever a abordagem de teste
O time de teste deve rever a abordagem de teste sempre que possvel e necessrio.
Critrio de entrada
Os critrios de entrada so definidos para evitar o incio dos testes em condies que no per-
mitam um processo rigoroso.
Para cada fase de teste necessrio definir os critrios de entrada para que o planejamento,
acompanhamento e execuo da prxima fase sejam feitos da melhor maneira possvel criando
ou atualizando os riscos do projeto. Abaixo temos alguns exemplos de critrios de entrada que
podemos utilizar no nosso processo:
Disponibilidade de um relatrio sumrio de teste da fase de teste anterior;
Disponibilidade de um ambiente de teste de acordo com os requisitos;
Disponibilidade de documentao, por exemplo, nota do release de teste, manual do
usurio e instalao, etc;
No ter defeitos pendentes com prioridade alta;
Todos os defeitos pendentes com prioridade alta devem ter pelo menos uma breve
anlise.
CII

Critrio de sada
Os critrios de sada so definidos para planejar quando parar de testar.
Para cada fase de teste necessrio definir os critrios de sada para saber se necessrio con-
tinuar investindo em teste e se o produto, sistema ou software est com a qualidade definida
anteriormente pelas partes interessadas. Abaixo existem alguns exemplos de critrios de sada
relacionados com o processo de teste que podem ser utilizados:
Porcentagem de testes preparados para execuo;
Porcentagem da cobertura de teste, por exemplo, cobertura de requisitos ou cdigo;
Disponibilidade de um relatrio sumrio de teste aprovado pelas partes interessadas.
extremamente necessrio tambm definir os critrios de sada relacionados com a qualidade
do produto. No basta simplesmente definir critrios de sada relacionados com o processo de
teste se ambos no estiverem alinhados e atingindo o objetivo final: qualidade do produto en-
tregue. Segue abaixo alguns exemplos de critrios de sada relacionados com a qualidade do
produto que podem ser utilizados no processo:
Todos os riscos do produto com prioridade alta mitigados;
A taxa de deteco de defeitos acima do definido anteriormente;
Porcentagem de casos de teste inspecionados ou revisados;
Porcentagem de mdulos do software testados por unidade ou ad-hoc.
Critrio de suspenso e reincio
Os critrios de suspenso e reincio so definidos para suspender todas ou parte das tarefas de
teste.
Para cada fase de teste necessrio definir os critrios de suspenso e reincio para saber se
necessrio suspender ou reiniciar atividades analisando os critrios de entrada e sada. Segue
abaixo alguns exemplos de critrios de suspenso que podem ser utilizados no processo:
Nmero de defeitos crticos;
Nmero de defeitos no reproduzveis;
Problemas com a execuo de teste devido aos ambientes de teste.

Estimativa de Teste
Estrutura de nvel superior
A atividade de estimativa muito importante para o planejamento do projeto. Para fazer um
projeto mais confivel e prximo da realidade, preciso ter uma estimativa bem detalhada a-
nalisando os requisitos, ambiente de teste e desenvolvimento, ferramentas, etc. Isso necess-
rio para no elaborar uma estimativa no achismo ou dar um tiro no escuro. Ter embasamen-
to nas informaes indispensvel, pois todos os produtos de trabalho na fase de estimativa
sero usados como entradas para o planejamento incluindo os riscos do projeto.
Na Figura 4 Estrutura de nvel superior: possvel verificar a integrao entre as atividades
de teste.
CIII


Figura 4 Estrutura de nvel superior
Ciclo de vida de teste
O ciclo de vida do teste faz parte do ciclo de vida do software e eles devem ser iniciados ao
mesmo tempo. O processo de design e desenvolvimento de testes pode ser to complexo quan-
to o processo de desenvolvimento do software em si. Se os testes no forem iniciados junta-
mente com os primeiros releases executveis do software, o esforo de teste retardar a desco-
berta de muitos problemas no ciclo de desenvolvimento. Em geral, isso resulta em um longo
perodo de correo de erros aps a programao de desenvolvimento, acabando com as metas
e as vantagens do desenvolvimento iterativo.
Alm da possibilidade de retrabalho j mencionada, a equipe de teste precisa ter cuidado para
manter seu papel como consultora de qualidade imparcial e no se desviar das atividades de
design e dos requisitos iniciais, atuando como "guardi da qualidade".
Os problemas localizados durante uma iterao podem ser solucionados ou adiados para a
prxima uma deciso que fica, em ltima instncia, a critrio do Gerente de Teste. Uma das
principais tarefas da equipe de teste e dos gerentes de projeto consiste em medir a abrangncia
da iterao, verificando se os objetivos de cada iterao foram alcanados. A "deteco de re-
quisitos" realizada continuamente a cada iterao, e voc precisa estar atento e preparado pa-
ra gerenci-la.
CIV

Na Figura 5 Ciclo de vida de teste possvel observar todas as fases de teste graficamente.

Figura 5 Ciclo de vida de teste

Aps cada iterao ou fase necessrio re-planejar as atividades seguintes, caso necessrio.
Em alguns casos, os projetos podem ter somente a fase de execuo de teste aps a fase de
planejamento de teste.
Estimativa de esforo e custo de teste
Para que a estimativa de esforo e custo de teste seja feita da maneira mais cuidadosa possvel,
deve-se levar em considerao algumas atividades para isso, como por exemplo:
Determinar e manter as estimativas dos produtos de trabalho e tarefas de teste;
Estudar os fatores que possam influenciar a estimativa;
Selecionar modelos e/ou dados histricos que serviro para transformar os produtos de
trabalho e tarefas de teste em estimativas de esforo e custo;
Incluir as necessidades de infra-estrutura;
Documentar os riscos resultantes da anlise dos documentos;
Documentar os dados da estimativa, incluindo as informaes necessrias para a reuti-
lizao em novas estimativas.
O modelo que ser utilizado no processo de estimativa a intuio e julgamento de um espe-
cialista baseados na experincia em planejar e testar sistemas semelhantes. Dessa forma, a
preciso da estimativa depende da experincia, competncia, objetividade e percepo de
quem realiza a estimativa.
Nessa fase, devemos levar em considerao tambm a funcionalidade e itens a serem testados
incluindo a Matriz de Teste por Tipo de Funcionalidade, a qual sempre dever ser atualizada
aps uma estimativa, caso seja necessrio.
CV

Os produtos de trabalhos gerados na fase de estimativa so os critrios de entrada para a fase
de planejamento onde verificado o esforo e custo do projeto incluindo a disponibilidade de
recurso, infra-estrutura, negociao com o time de desenvolvimento, etc. Abaixo seguem al-
guns itens que poder ser utilizados na estimativa de esforo:
Documentos usados para estimar: Nome e verso dos documentos utilizados durante
a estimativa;
Data: Data quando a estimativa foi completada;
Data da Requisio: Data quando a estimativa foi solicitada;
Responsvel: Pessoa que fez a estimativa, podendo haver mais de uma pessoa respon-
svel;
Esforo Atual da Estimativa: Esforo gasto na estimativa;
Complexidade: Indica se a funcionalidade tem uma complexidade baixa, mdia ou alta
para testar. Considerar quantidade de suporte de teste requerido, riscos e desafios;
Razo para complexidade: indicar o porqu a funcionalidade foi marcada com a dada
complexidade;
Anlise de Teste
o Requisitos Funcionais: Nmero de requisitos funcionais aplicveis;
o Requisitos de Interface: Nmero de requisitos de interface aplicveis;
o Casos de Teste: Nmero de Casos de Teste estimado;
o Suposies: Suposies identificadas para fase de design;
o Esforo Calculado: Esforo de anlise calculado baseado no nmero de casos
de teste estimado;
o Esforo Calculado para Reviso: Esforo da reviso dos casos de teste suge-
ridos na fase de anlise.
Design de Teste
o Casos de Teste: Nmero de Novos Casos de Teste;
o Casos de Teste Reutilizados: Nmero de Casos de Teste Reutilizados (nenhum
esforo de design requerido);
o Suposies: Suposies identificadas para fase de design;
o Esforo Calculado: Esforo de design calculado baseado no nmero de casos
de teste a serem criados;
o Esforo Calculado para Reviso: Esforo da reviso dos casos de teste cria-
dos na fase de design.
Execuo de Teste
o Casos de Teste: Nmero de Casos de Teste que sero executados para a fun-
cionalidade incluindo testes de regresso;
o Total de Casos de Teste: Nmero Total de Casos de Teste que sero executa-
dos incluindo a porcentagem de casos de testes falhados e bloqueados para
todos os ciclos de execuo;
o Suposies: Suposies identificadas para fase de execuo. Podendo conter
tambm indicaes sobre casos de teste adicionais de regresso ou reuso, por-
centagem de defeitos encontrados, porcentagem de re-execuo de casos de
teste passados;
CVI

o Esforo Calculado; Esforo de execuo calculado baseado no nmero de ca-
sos de teste a serem executados.
Otimista: Valor otimista da estimativa gerada;
Mais provvel: Valor mais provvel da estimativa gerada;
Pessimista: Valor pessimista da estimativa gerada.
Para ajudar a calcular o valor otimista, mais provvel e pessimista, pode- se usar a simulao
de Monte Carlo.
Uma melhor prtica para ajudar o trabalho de estimativa de teste utilizar um mapa da mente,
por exemplo, usar o software Free Mind e tambm gerar uma Matriz de Critrio de Adequa-
o, a qual deve conter o cabealho do caso de teste, requisitos testado, categoria do teste e ti-
po de teste.

Plano de Teste
Um Plano de Teste deve ser estabelecido e mantido como base para o gerenciamento de teste e
comunicao para as partes interessadas.
Cronograma de teste
Aps a fase de estimativa de teste chega a hora de fazer o planejamento com um cronograma
dos critrios de sada ou produtos criados na fase de estimativa.
Nessa fase seremos capazes de dizer se realmente teremos recursos e tempo suficiente para fi-
nalizar o projeto de teste. Abaixo esto alguns itens que ajudaro na criao do cronograma:
Identificar a durao da tarefa, recursos, e entradas necessrias;
Identificar as dependncias de cada tarefa de teste;
Identificar as tarefas que tem prioridade;
Definir o tempo das atividades e fases do ciclo de vida de teste;
Documentar as suposies feitas na fase de planejamento levando em considerao
todos os riscos levantados anteriormente;
Verificar se o cronograma de teste est adequado na mesma janela de tempo do crono-
grama do time de desenvolvimento.
Para facilitar a criao do cronograma de teste podemos utilizar o software Microsoft Office
Project.
Recursos de teste
Temos papis e responsabilidades para cada integrante do time de teste e cada um com um
perfil diferente. Quando falamos Recurso de teste estamos falando das pessoas envolvidas
nas atividades de teste, ou melhor, do ncleo de teste onde se concentra todo o conhecimento,
perfil dos recursos de teste.
Em um time de teste muito importante saber qual o perfil de cada recurso e quais as suas
qualificaes, especificidades e reas de conhecimento para que as necessidades de teste sejam
atribudas para os recursos mais apropriados minimizando assim o risco de cada projeto. Com
isso tambm possvel identificar as reas onde necessrio um treinamento.
Todo conhecimento e qualificaes do time de teste devem ser documentados no Plano de
Treinamento e Controle de Qualificaes. Neste plano possvel:
Determinar os requisitos dos recursos baseado na estrutura de nvel superior;
CVII

Identificar o conhecimento e perfil necessrio para executar uma determinada tarefa
de teste;
Identificar a necessidade de novos treinamentos podendo ser treinamento interno, ex-
terno, acompanhamento tcnico de recursos experientes, etc.
Com todas as informaes contidas acima possvel identificar o nvel de maturidade do time
de teste. Abaixo iremos mostrar graficamente um exemplo:
Componente/Projeto
Analista
1
Analista
2
Analista
3
Analista
4
Total por
Projeto
% Habili-
dade
Componente 1 2 1 0 1 4 33,33%
Projeto 1 0 3 2 0 5 41,67%
Componente 2 3 0 0 2 5 41,67%
Projeto 2 1 2 1 3 7 58,33%
Tabela 6 Habilidades do Time de Teste x Componente / Projeto

Sem experincia 0
Tem pouca ou nenhuma experincia com o compo-
nente/projeto
Conhecimento Bsico 1
Tem sido treinado e/ou teve algum contato com o
componente/projeto
Conhecimento Intermedi-
rio 2
Executou casos de teste no componente/projeto por
pelo menos 3 meses
Conhecimento Avanado 3
Tem conhecimento geral do componente/projeto e
consegue executar testes exploratrios sem nenhum
suporte interno ou externo
Tabela 7 Habilidades do Time de Teste x Componente / Projeto (Legenda)


Figura 6 - Habilidades do Time de Teste x Componente / Projeto
Treinamento
Analista
1
Analista
2
Analista
3
Analista
4
Total de Treina-
mento
% Treina-
mento
Componente 1 1 0 1 1 3 75,00%
Projeto 1 0 1 0 1 2 50,00%
CVIII

Componente 2 1 1 1 1 4 100,00%
Projeto 2 0 1 0 1 2 50,00%
Tabela 8 Treinamentos dos Componentes / Projetos x Recursos

Sem treinamento 0 No foi treinado
Treinado 1
Foi treinado e obteve o conhecimento necessrio para conduzir as
atividades de Estimativa, Anlise, Design e Execuo de Teste
Tabela 9 Treinamentos dos Componentes / Projetos x Recursos (Legenda)


Figura 7 Treinamentos dos Componentes / Projetos x Recursos

Envolvimento das partes interessadas
Em cada fase de teste necessrio identificar as partes interessadas atribuindo o nvel de en-
volvimento ou participao nas atividades da fase corrente. Essa participao facilmente i-
dentificada utilizando os critrios de entrada e sada de cada fase, pois por meio deles sabemos
dizer qual parte interessada (ou time) dever contribuir com os critrios.
Riscos do projeto de teste
Os riscos do projeto de teste so identificados, analisados e documentados de acordo com a
Avaliao de Risco do Projeto.
Plano de Teste
Todos os resultados das atividades de teste so documentados em um plano de teste o qual po-
der consolidar ou no todas as informaes em um nico documento. Os itens que fazem par-
te de Plano de Teste (exemplo) esto abaixo:
Matriz de Anlise de Riscos;
Matriz de Teste por Tipo de Funcionalidade;
Estimativa de Esforo;
CIX

Matriz de Critrio de Adequao;
Funcionalidades que sero testadas ou no;
Requisitos de ambiente de teste;
Treinamento para os recursos caso seja necessrio;
Partes interessadas;
Grfico Curva-S;
Cronograma do Projeto de Teste.
Para auxiliar ainda mais na criao de um Plano de Teste, necessrio consultar a IEEE Std
829-1998, IEEE Stardard for Software Test Documentation.

Comprometimento para o Plano de Teste
Reviso do plano de teste
Aps a criao do Plano de Teste ser necessrio revis-lo com as partes interessadas para en-
tender os compromissos de teste. Caso seja preciso, podem ocorrer mudanas na abordagem
de teste que devero ser documentadas no plano de teste.
Reconciliar trabalho e recurso
O objetivo de reconciliar trabalho e recurso revisar o plano de teste para refletir os recursos
estimados e disponveis. Algumas atividades para ajudar nessa tarefa esto listadas abaixo:
Revisar a abordagem de teste;
Renegociar oramentos de teste;
Revisar o cronograma de teste;
Revisar a lista de riscos;
Renegociar os acordos das partes interessadas.
Aps a reviso das tarefas acima, se necessrio, os documentos associados a elas devero ser
atualizados e as partes interessadas notificadas.
Comprometimento do plano de teste
O objetivo do comprometimento do plano de teste obter o compromisso das partes interessa-
das em executar e suportar a execuo do plano de teste.
Nesse momento possvel identificar o suporte necessrio e negociar os compromissos com
as partes interessadas relevantes.







CX














Definio, Planejamento e
Execuo de um Plano de
Medio
CXI

Fase da Metodologia: testes e Validao
Introduo
Durante o processo de desenvolvimento de software, h uma grande possibilidade de ocorrn-
cia de falhas no produto e o custo associado correo destas falhas muito alto. Por este
motivo, uma srie de testes bem executados, iniciados no comeo do ciclo de vida do softwa-
re, reduz significativamente o custo com manuteno de software.
Os testes representam a ltima oportunidade de detectar erros antes do software ser distribu-
do aos usurios, e podem ser feitos de forma manual e/ou automtica. Os principais objetivos
do Fluxo de Testes so:
verificar a correta integrao entre todos os componentes do software;
verificar se todos os requisitos do sistema foram corretamente implementados;
planejar os testes que devem ser executados em cada iterao, incluindo testes de
integrao e sistema;
executar vrios testes e comparar o resultado dos mesmos com os resultados espe-
rados, a fim de produzir uma indicao da qualidade e da confiabilidade do software;
realizar os testes de aceitao (homologao).

O processo de gerenciamento dos testes pode ser feito com a utilizao de ferramentas ade-
quadas para cada sistema. Estas devem ser definidas logo que surgir uma concepo mais
clara sobre o tipo de software a ser produzido.
Rcspnnsvcis c artcIatns
Os responsveis e artefatos envolvidos neste fluxo so mostrados a seguir:
Testador
- Plano de Teste
- Relatrio de Avaliao dos Testes
Programador
- Componentes de Teste

O Plano de Testes descreve as estratgias, os casos e os procedimentos de testes realizados em
uma iterao e seu cronograma. Na estratgia de teste esto definidos os tipos de teste que
sero executados na iterao e os objetivos que devem ser atingidos. Um caso de teste especi-
fica uma maneira de testar o sistema: o que testar, que procedimentos de teste usar levando
em considerao um aspecto de qualidade como, por exemplo, corretude, desempenho ou
robustez. Um procedimento de teste especifica como realizar um ou diversos casos de teste.
um conjunto de instrues para execuo e avaliao de resultados para um ou mais casos de
teste, que podem ser efetivadas manualmente ou atravs de ferramentas.
O Relatrio de Avaliao dos Testes uma anlise da cobertura dos casos de teste, bem como
de mtricas associadas aos testes, de modo a verificar a necessidade de realizao de novos
testes ou de testes de regresso na prxima iterao.
Um Componente de Teste automatiza um ou mais procedimentos de teste, ou partes deles, e
pode ser desenvolvido usando-se uma linguagem de programao ou gerado atravs de uma
interao com uma ferramenta de testes. Os componentes de teste podem ser programas, ou
scripts e so usados para testar os componentes do modelo de implementao, fornecendo
entradas, controlando e monitorando a execuo e reportando os resultados.
CXII

Fluxo de atividades

O fluxo de atividades da fase de testes e validao composta das seguintes atividades:

1) Elaborar Plano de Testes Testador.
2) Implementar Testes Programador
3) Realizar Testes Testador
4) Avaliar Testes Testador
5) Executar Testes de Aceitao Usurio/cliente validador.
Elaborar Plano de Testes
Fluxo: Testes Atividade: Elaborar Plano de Testes
Objetivos:
Documentar as informaes relevantes ao planejamento dos testes para cada iterao.
Entradas:
Documento de Requisitos (E temos?)
Sadas:
Plano de Testes
Passos:
Definir requisitos a testar
Descrever casos de testes
Estruturar Procedimentos de testes
Projetar componentes
Responsvel: Testador
Referncias: -

Definir requisitos a testar
Neste passo so definidos os requisitos (casos de uso e requisitos no-funcionais) que devem
ser testados. Requisitos a testar so itens que tm seus comportamentos observados e medi-
dos. Eles podem ser originados de vrias fontes (ex: Documento de Requisitos) e, portanto,
muito importante que toda a documentao do sistema esteja atualizada neste momento.
Descrever casos de teste
A identificao dos casos de testes feita atravs da anlise dos fluxos de eventos, e dos dife-
rentes cenrios dos casos de uso.
A anlise dos fluxos de eventos tem por objetivo descrever as aes do ator ao interagir com o
sistema e utilizar estas aes para identificar os casos de testes necessrios.
Os casos de testes funcionais so identificados a partir dos diferentes cenrios dos casos de
uso (fluxos bsicos e alternativos).
O modelo de anlise e projeto e os requisitos no-funcionais devem ser analisados para iden-
tificar casos de testes no-funcionais, que podem no ter sido encontrados apenas com base
nos casos de uso e seus cenrios.
Estruturar procedimentos de teste
Um procedimento de testes descreve, basicamente, passos e informaes necessrios para
realizao do caso de teste ao qual est associado. Deve conter:
preparao do ambiente (environment set-up): Prover as condies (massa de da-
dos, ferramentas de apoio e equipamentos) necessrias para que o caso de testes
CXIII

seja executado adequadamente e permita a simulao do ambiente real de produ-
o;
como (atravs de ferramentas de automao de testes, scripts, etc.) e quando forne-
cer os dados de entrada e obter os resultados da sada;
passos para implementao e execuo dos testes;
forma de avaliao dos resultados.
Os procedimentos de testes definiro como os testes sero implementados e executados.
Projetar componentes
Projetar os componentes constitui basicamente em definir quais sero os componentes de
apoio, e como devero ser implementados. Esses componentes podem ser scripts gerados com
o auxlio da ferramenta de teste como o WinRunner, componentes que vo ler um arquivo
texto e popular uma tabela, stubs que vo simular um componente que ainda no existe, etc.

Implementar Testes
Fluxo: Testes Atividade: Implementar Testes
Objetivos:
Automatizar procedimentos de teste, criando componentes de teste consistentes com os casos
de teste associados.
Entradas:
Plano de Testes (casos e procedimentos de
teste)
Sadas:
Componentes de Teste
Passos:
Gerar componentes de teste
Definir conjunto de dados externo
Responsvel: Programador
Referncias: -

Nesta atividade, so gerados componentes de teste para dar apoio execuo dos testes. Por
exemplo, a gerao de stubs para simular o comportamento de mdulos do sistema que ainda
no esto prontos; componentes para gerao de massa de dados, para converso de base de
dados, para registro das entradas e sadas do sistema; e scripts que simulam o funcionamento
do sistema so artefatos que podem ser gerados durante a implementao dos testes.
Gerar componentes de teste
Neste passo, componentes de apoio existentes podem ser modificados, ou novos componentes
podem ser iniciados.
Os componentes de teste so responsveis por executar os casos e procedimentos de teste de-
finidos e podem ser gerados de duas formas:
utilizando ferramenta de automao de testes;
programando explicitamente os componentes de teste;
Definir conjuntos de dados externos
Aqui o objetivo criar e manter os dados armazenados externamente aos componentes de
teste (em arquivos ou banco de dados, por exemplo), e que sero usados por estes componen-
tes de teste durante a execuo dos mesmos.
Os conjuntos de dados externos agregam valor ao teste das seguintes maneiras:
CXIV

dados externos podem ser facilmente modificados com pouco ou nenhum impacto
nos componentes de teste;
casos de teste adicionais podem ser facilmente inseridos nos dados de teste com
pouca ou nenhuma modificao nos componentes de teste;
dados externos podem ser compartilhados por vrios componentes de teste;
conjuntos de dados externos podem conter valores de dados usados para controlar
os componentes de teste.

Executar Testes
Fluxo: Testes Atividade: Executar Testes
Objetivos:
Verificar a corretude e a qualidade dos casos de uso, builds e releases implementados, avali-
ando os resultados e registrando os problemas encontrados.
Entradas:
Plano de Testes
Componentes de teste
Sadas:
Registro dos resultados
Passos:
Executar os procedimentos de teste
Registrar resultados
Responsvel: Testador
Referncias: -

A execuo dos testes acontece, basicamente, em trs momentos bem definidos: durante a
implementao dos casos de uso (testes unitrios), onde realizada pelo prprio programador;
aps a integrao dos casos de uso e/ou dos demais mdulos do sistema (testes de integrao
e/ou de sistemas), onde os testes so realizados pelos prprios programadores ou, por uma
equipe independente de testes; e durante a homologao do sistema, onde os testes so
executados pelo usurio (testes de aceitao)..
Executar os procedimentos de teste
Neste passo, os procedimentos e casos de testes so executados com objetivo de encontrar
falhas no caso de uso ou mdulo em teste. Para tanto, o ambiente de teste, as ferramentas e
componentes de apoio devem estar conforme descrito nos procedimentos de teste para que o
testador possa executar os casos de teste nas condies ideais. Os testes realizados neste passo
so os testes de integrao ou de sistema.
Registrar resultados
Os resultados dos testes devem ser registrados sob forma de algum dado que possa ser
posteriormente analisado: planilha, arquivo texto, etc.
CXV

Avaliar Testes
Fluxo: Testes Atividade: Avaliar Testes
Objetivos:
Medir quantitativamente e qualitativamente o progresso dos testes e gerar um relatrio de ava-
liao dos testes.
Entradas:
Plano de Testes
Registro dos resultados
Sadas:
Relatrio de Avaliao de Testes
Passos:
Avaliar procedimentos de teste
Verificar se os critrios de completude e sucesso dos testes foram atingidos
Responsvel: Testador
Referncias: -

A avaliao dos testes pode ser feita atravs de resultados e grficos produzidos por ferramen-
tas de testes, usadas durante a execuo dos testes.
Avaliar procedimentos de teste
A avaliao dos procedimentos de teste envolve verificar se o ambiente definido para os testes
realizados refletiu a necessidade dos testes, ou seja, se os testes foram realizados no ambiente
definido. Tambm devem ser analisados aspectos que envolvem a cobertura dos casos de tes-
tes projetados, ou seja, se os casos de testes definidos cobriram todos os cenrios para o caso
de uso associado e se as informaes contidas em cada caso de teste realmente refletiram o
que precisava ser testado.
Verificar se os critrios de completude e sucesso dos testes foram atingidos
O objetivo deste passo determinar se os testes foram completamente executados e de forma
aceitvel. Neste momento a estratgia definida no Plano de Testes deve ser revisada. Esta
estratgia deve apresentar critrios de teste em termos de cobertura dos testes e/ou avaliao
de defeitos. Os resultados dos testes, os defeitos e a anlise destes defeitos devem ser estuda-
dos para verificar se eles satisfizeram os critrios estabelecidos.
No caso dos critrios no terem sido atingidos, h algumas alternativas:
Coletar informaes adicionais e repetir os testes;
Modificar o critrio de aceitao dos testes e repeti-los;
Sugerir testes adicionais.

Executar testes de aceitao
Fluxo: Testes Atividade: Executar testes de aceitao
Objetivos:
Executar testes de aceitao para o ltimo build gerado e registrar os problemas encontrados.
Entradas:
ltimo build gerado
Sadas:
Observaes do validador
Responsvel: Usurio validador
Referncias: -

CXVI

Os testes de aceitao devem ter incio quando a avaliao dos testes indicarem que o sistema
atingiu os objetivos de qualidade definidos no Plano de Testes. Esta atividade no possui pas-
sos, uma vez que o usurio responsvel por realizar e executar testes sem seguir um roteiro
fixo. Os problemas encontrados devem ser reparados.