metricas

Prévia do material em texto

Métricas
Marco Lordello Chaim
ACH 2006 – Engenharia de Sistemas de 
Informação I
Métricas
● Métricas, medidas e indicadores
● Dimensões de utilização das métricas
− para estimação de custo e prazo de software
− para avaliação:
● produto;
● projeto;
● processo.
Métricas
● Métricas de tamanho e estimação
− linhas de código;
− pontos de função.
● Estimação a partir das métricas de tamanho.
− dados históricos da organização;
− modelos empíricos para estimação.
Métricas
● Métricas de avaliação de qualidade
− utilização de métricas para avaliação de fatores de 
qualidade.
− Métricas para avaliação da análise de requisito
− Métricas para avaliação do projeto
− Métricas para avaliação do código
− Métricas para avaliação do teste
Métricas
− Métricas para avaliação da manutenção.
● Considerações finais.
Medidas, métricas e indicadores
● A medida é o indicador quantitativo, o valor, 
estabelecido para um dado atributo em uma 
dada unidade.
− a distância entre São Paulo e Rio de Janeiro é 600 
quilômetros.
− Meu automóvel gasta 50 litros de gasolina para ir 
de São Paulo ao Rio de Janeiro.
Medidas, métricas e indicadores
● Uma métrica relaciona duas medidas.
● O consumo de um carro é dado em quilômetros 
por litro de gasolina.
− Meu automóvel faz na estrada 12 quilômetros por 
litro.
● Uma métrica, ou um conjunto de métricas, 
fornece um indicador que permite 
compreender, comparar processos, grandezas.
Medidas, métricas e indicadores
● Exemplo de Engenharia de Software:
− duas equipes utilizando técnicas de revisão de 
código distintas.
− a métrica número de defeitos encontrados por 
arquivo permite avaliar qual técnica obteve melhor 
desempenho.
− a obtenção de métricas repetidas e em contextos 
diferentes auxilia na decisão organizacional sobre 
qual técnica é mais eficaz e eficiente.
Métricas: para que usar
● Uma dimensão de uso das métricas é na 
estimação dos prazos e custos para 
desenvolver software.
● Tipicamente, a estimação é feita 
determinando-se o tamanho previsto para o 
software.
● Este tamanho é previsto em termos de linhas 
de código do software e de pontos de função 
que o software possui.
Métricas: para que usar
● As linhas de código de um software é uma 
estimação de medida direta de tamanho.
● Os pontos de funções são uma medida indireta 
que procura avaliar a funcionalidade a ser 
desempenhada pelo software.
● As medidas estimadas podem ser utilizadas de 
duas maneiras para a estimação de prazos e 
custos. 
Métricas: para que usar
● Uma delas é utilizando dados históricos da 
organização desenvolvedora. 
● Por exemplo, por meio da coleta de métricas de 
projetos anteriores pode-se determinar que a 
organização consegue desenvolver e testar 
5kLOC em quatro meses, ou desenvolver e 
testar 20 pontos de função (PF) em 4 meses, 
utilizando um desenvolvedor.
Métricas: para que usar
● Se a estimativa de um software é 20 kLOC ou 
80 PF, é possível determinar o prazo e 
estabelecer os custos.
● Outra maneira é utilizando modelos empíricos 
que no formato:
− E = A + B x (ev)^c
− onde A, B, e C são constantes derivadas 
empiricamente e
− ev é a estimativa de tamanho (LOC ou PF).
Métricas: para que usar
● Exemplo de modelos empíricos:
− E= 5,5 + 0,73x(kLOC)^1,16 – modelo de 
Bailey-Basili
− E = -13,39 + 0,0545x FP – modelo de Albrecht e 
Gaffney.
− COCOMO (Constructive Cost Model) – Bohem, 
utiliza LOC, FP e pontos de objeto como variável 
estimada.
Métricas: para que usar
● Problemas do uso de medidas de tamanho 
para estimar:
− uso de LOC requer uma subdivisão em funções e 
subfunções para estimar o tamanho do software. 
Requer experiência, dados históricos e bom feeling. 
LOC varia muito em função das linguagens de 
programação. Uma LOC de C é muito diferente de 
uma linha em SQL. É necessário fazer este ajuste.
Métricas: para que usar
● Problemas do uso de medidas de tamanho 
para estimar:
− PF é uma medida muito dependende da 
experiência do planejador, da disponibilidade de 
dados históricos. PF é voltada para sistemas de 
informação clássicos, não sendo adequada para 
sistemas em tempo real e orientado a objetos. 
− Esta última crítica não procede haja vista que 
várias propostas de utilização de PF nestes 
contextos foram desenvolvidas.
Métricas: para que usar
● Métricas são utilizadas para avaliar um dado artefato de 
software, isto é, um produto.
− LOC de um método ou função.
− complexidade de McCabe de um método ou função.
− número de defeitos encontrados no documentos de 
requisitos.
● Note-se que as métricas acima são medidas diretas. No 
entanto, fornecem indicações indiretas atributos de qualidade 
do software.
Métricas: para que usar
● Por exemplo, um método com LOC acima de 
um dado valor será mais difícil de testar, pois 
exigirá mais casos de teste e, por conseguinte, 
mais esforço. Logo, o atributo de testabilidade 
de um módulo pode ser avaliada indiretamente.
● Métodos ou funções muito complexas são 
difíceis de manter.
Métricas: para que usar
● O número de defeitos encontrados no 
documento de requisitos informa a respeito da 
confiabilidade do artefato. 
● Muitos defeitos, principalmente relacionados 
com a falta de requisitos, indica que a fase de 
análise não foi realizada corretamente.
Métricas: para que usar
● Note-se que as métricas associadas nos 
permitem avaliar atributos como testabilidade, 
confiabilidade, manutenibilidade do artefato 
produzido.
● Logo, elas são indicadores da qualidade do 
produto produzido no processo de 
desenvolvimento de software.
● O produto é associado a uma ou a um grupo de 
pessoas.
Métricas: para que usar
● As métricas obtidas não devem ser utilizadas 
como avaliação pessoal.
● Elas indicam como estão sendo realizadas as 
atividades de desenvolvimento de um dado 
projeto em andamento.
● A compilação dos resultados da coleta de 
métricas de vários projetos informa sobre a 
qualidade do processo de desenvolvimento de 
software da organização. 
Métricas: para que usar
● Portanto, as métricas podem ser utilizadas para 
estimar prazos e custos para produzir o 
software e para avaliar o sofware produzido e 
também o processo que o produz.
● A seguir vamos descrever várias métricas 
utilizadas nas diferentes fases de 
desenvolvimento de software, a saber, análise 
de requisitos, projeto, codificação, etc.
Métricas de Análise
● As métricas de análise procuram avaliar o 
tamanho e a complexidade de um software a 
partir das informações disponíveis no 
documento de requisitos.
● A métrica típica de análise são os pontos de 
função. Determinando-se os pontos de função 
e utilizando dados histórico avaliar os custos, 
prazos, taxa de defeitos por PF, etc.
Pontos de Função
● Baseados em uma relação empírica baseada 
em medidas de contagem (direta) do domínio 
de informação do software e avaliação de 
complexidade.
● Cinco caractarísticas do domínio da informação 
são determinadas e as contagens são 
registradas em uma tabela.
Pontos de Função
● Quantidades de entradas do usuário:
− cada entrada do usuário, que fornece dados distintos 
orientados à aplicação, do software é contada. Entradas são 
distintas de consultas.
● Quantidades de saídas do usuário:
− cada saída do usuário, que fornece informação orientada à 
aplicação para o usuário, é contada. Neste contexto, saída 
refere-se a relatórios, telas, mensagens de erro, etc. Itens 
de dados individuais dentro de um relatório não são 
contados separadamente.
Pontos de Função
● Número de consultas do usuário:
− uma consulta é definida como uma entrada on-line, 
que resulta na geração de alguma resposta 
imediata do software sob a forma de uma saída 
on-line. Cada consulta distinta é contada.
● Quantidade de arquivos:
− cada arquivo mestre lógico (i.e., grupo de dados 
lógico que pode ser parte de uma base de dados 
maior ou um arquivo separado) é contado.
Pontos de Função
● Quantidade de arquivos:
− Todas as interfaces em linguagem de máquina(e.g., 
arquivos de dados em um meio de armazenamento), que 
são usadas para transmitir informação a outro sistema, são 
contadas.
● Um valor de complexidade (simples, médio, complexo) é 
associado com cada valor contado.
● Atribuição de complexidade é subjetiva e específica da 
organização.
Pontos de Função
Pontos de Função
● Para determinar os PF é necessário utilizar a 
fórmula abaixo:
− FP = contagem total x[0,65 +0,01x Somatório(F_i)]
− F_i (i = 1 a 14) são valores de complexidade, 
baseados nas respostas às seguintes perguntas:
1. o sistema requer backup e recovery
2. Comunicações de dados são necessárias
3. ... ate 14
Pontos de Função
● Cada uma dessas questões é respondida 
usando uma escala que varia entre zero (não 
importante ou não aplicável) a 5 
(absolutamente essencial).
● Os fatores de peso (F_i), as constantes são 
determinados experimentalmente.
● Uso de PF: erros por FP; defeitos por FP; $ por 
FP; páginas de documentação por FP; 
pessoa-mês por FP.
Pontos de Função
● Pontos de de função foram estendidos para 
contexto de software de sistema, aplicações de 
tempo real.
● Pontos de Casos Usos foram criados a partir 
de PF para serem utilizados no contexto de 
orientação a objetos. São muito utilizados na 
prática.
Métricas nos Métodos Ágeis
● Velocidade: 
○ contar o número de histórias do usuário 
completadas por interação e calcular a média.
● A média define quantidade de histórias da 
próxima interação.
● Problema:
○ algumas histórias são mais difíceis que outras.
● Solução simples:
○ atribuir um número de pontos para cada história 
para indicar a sua dificuldade.
Métricas nos Métodos Ágeis
● Valor de um ponto:
○ número de horas de codificação esperadas pelo 
time para implementar a história.
○ Todo o time deve concordar com o valor de um 
ponto.
○ Não só representa horas, mas também incerteza.
● Exemplo:
○ Escala de 3 pontos;
○ Um ponto representa 3 horas de trabalho
○ Uma HU de 1 ou 2 pontos são fáceis de estimar.
○ E uma HU de 3 pontos?
Métricas nos Métodos Ágeis
● Exemplo:
○ Definir um limite para quebrar uma HU muito 
complexa para poder estimar com confiança.
○ HU de mais de 3 pontos deve ser subdividida.
● Planning Poker:
○ Cada membro do time anota em uma carta sua 
estimativa de complexidade.
○ Cartas para: "não sei" e "muito complicado".
○ O time deve chegar a um acordo.
○ O acordo pode ser: dividir a HU.
Métricas nos Métodos Ágeis
● O que torna uma HU complexa?
○ Incerteza: nova tecnologia que requer um spike
● Spike: 
○ um investigação prévia sobre uma nova técnica, 
teconologia ou problema antes de começar a 
escrever código.
● No final de cada iteração, calcular o total de 
pontos entregues e estabelecer a velocidade 
do projeto.
Métricas nos Métodos Ágeis
● Velocidade mede o desempenho baseado na 
autoavaliação do time.
● O propósito é dar um ideia de quantas 
interações serão necessárias para adicionar as 
features desejadas.
● Note-se que a data de entrega do software vai 
depender da velocidade…e não de uma data 
pré-defininda.
○ Será?
● Time and materials x Fixed bid basis
Métricas de Projeto
● Durante a fase de projeto é possível medir o 
projeto realizado e obter métricas.
● Tipicamente, estas métricas estão preocupadas 
em avaliar três aspectos importantes dos 
módulos do projeto, a saber, 
− a complexidade,
− a coesão e
− o acoplamento.
Métricas de Projeto
● Considerando arquiteturas de software estilo 
chamada-retorno (que tipicamente ocorrem nos 
projetos que utilizam Análise Estruturada), Card 
e Glass propuseram métricas de complexidade.
● Complexidade estrutural:
− S(i) = fout(i)^2 onde fout(i) é o número de módulo 
imediatamente subordinados ao módulo i.
Métricas de Projeto
● Complexidade dos dados:
− D(i) = v(i) div [fout(i)+1] onde v(i) é o número de 
variáveis de entrada e saída que são passadas 
para e do módulo i.
● Complexidade de sistema:
− C(i) = S(i) + D(i) 
Métricas de Projeto
● À medida que os valores dessas 
complexidades aumentam, aumenta a 
complexidade arquitetural global do sistema. 
● Isto leva a uma maior probabilidade de 
aumento do esforço de teste e de integração de 
um dado módulo i.
Métricas de Projeto
● Considerando projetos OO, Chidamber e 
Kamerer propuseram algumas métricas que 
permitem avaliar a coesão e o acomplamento 
de classes.
● Falta de coesão em métodos (lack of cohesion 
in methods – LCOM):
− Se 4 métodos acessam um ou mais atributos em 
comum então LCOM é 4 e isto indica que os 
métodos estão acoplados por estes atributos.
Métricas de Projeto
● Acoplamento entre as classes de objetos 
(coupling between object classes – CBO). É o 
número de colaborações de uma classe, isto é, 
o número de classes cujos objetos são 
invocados pela classe para realizar suas 
responsabilidades.
● Valores altos de CBO indicam alto acoplamento 
e dificuldades para se realizar modificações, 
testes, etc.
Métricas de código
● Métricas de código são utilizadas para avaliar a 
complexidade do código.
● Um código complexo leva a um código difícil de 
testar (baixa testabilidade) e difícil de manter 
(baixa manutenibilidade).
● Uma maneira mais direta de medir a 
complexidade do código de um procedimento 
ou método é o número de linhas de código.
Métricas de código
● Esta métrica possui problemas já discutidos 
como a variabilidade da linguagem ou 
paradigma de programação.
● Porém, outros aspectos não são captados por 
esta métrica. Por exemplo, ela não avalia o 
fluxo de controle. Um procedimento pode ter 
poucas linhas de código, mas pode possuir 
vários laços aninhados, permeados por 
comandos break, continue ou goto. 
Métricas de código
● Isto torna um trecho pequeno de código 
extremamento complexo. Estes trechos de 
programa são chamados como spaghetti code 
dada a sua confusão no fluxo de controle.
● A métrica de McCabe, também chamada de 
complexidade ciclomática, leva em 
consideração o fluxo de controle para gerar 
uma medida da complexidade do código.
Métricas de código
● Complexidade Ciclomática de um trecho de 
código t é dado por:
− CC(t) = E – N +2 onde E é o número de arestas do 
grafo de fluxo de controle que representa o trecho t 
e N é o número de nós.
− as arestas representam as transferências de fluxo 
de controle entre trecho de código executados 
seqüencialmente, chamados nós.
Métricas de código
● Estudos realizados por McCabe para 
programas procedimentais indicam que 
programa com complexidade ciclomática acima 
de 10 é muito complexo, trazendo problemas 
para ser testado ou mantido.
● Halstead também desenvolveu métricas para 
determinar o tamanho e complexidade do 
software que levam em consideração o número 
de operadores e operandos do programa.
Métricas de Teste
● As métricas de teste têm como objetivo avaliar 
o andamento dos testes. Isto é, avaliar o 
quanto falta para testar adequadamente um 
programa.
● Métricas neste sentido sentido são 
estabelecidas pelos critérios de teste, sejam 
estruturais ou funcionais.
● Os primeiros indicam trechos do programa que 
ainda necessitam ser testados.
Métricas de Teste
● Por exemplo, o critério todos nós avalia se um 
dado conjunto de teste contém casos de teste 
que executam pelo menos um vez cada nó do 
programa. Analogamente, todos arestas 
procuram exercitar todas as arestas.
● Critérios funcionais como particionamento de 
equivalência requer que cada classe de 
equivalência de entrada e de saída sejam 
testadas.
Métricas de Teste
● O teste somente estará adequado se o 
conjunto de casos de teste exercitar ao menos 
uma vez cada requisito de teste estabelecido 
pelos critérios de teste.
● Assim, a cobertura, segundo um critério de 
teste, obtida por um conjunto de caso de teste 
é uma medida da adequação do teste 
realizado. Logo, os critérios de teste podem ser 
entendidos como métricas de teste.
Métrica de Manutenção
● O fato de o software já ter sido entregue não 
significa ele não vá mais ser medido.
● Durante amanutenção, medidas de tempo de 
atendimento de pedidos de modificações são 
indicadores da facilidade de manutenção do 
software. 
● O número de modificações de um módulo, se 
muito alto, é uma indicação de que o módulo é 
um candidato a sofrer manutenção preventiva.
Conclusões
● Medir o software é uma atividade essencial 
para estimar o trabalho e o custo de 
desenvolvê-lo, avaliar a qualidade do software 
produzido e avaliar o processo que o produz.
● As métricas relacionam medidas e dão 
indicações de custos, prazos e qualidade do 
software e do processo.
Conclusões
● Por isso, medidas e métricas devem ser 
computados ao longo do ciclo de vida do 
software para prever e avaliar as próximas 
etapas e a qualidade do que foi realizado.
Bibliografia
● Roger S. Pressman, “Engenharia de Software”, 
5a. Edição,Rio de Janeiro: McGraw-Hill, 2002.
● Armando Fox e David Patterson, "Engineering 
Software as a Service: An Agile Approach Using 
Cloud Computing", 2a. Edição, 2021.