Fundamentos de Métricas e Medidas

Prévia do material em texto

DESCRIÇÃO
A definição e aplicação de métricas de software e medidas no gerenciamento de projetos de software, na melhoria de
processos de software e na qualidade do produto.
PROPÓSITO
O entendimento das métricas de software capacita os profissionais de Tecnologia da Informação (TI) a fazer
estimativas de tamanho, esforço, duração e custos de um projeto. A aplicação das métricas durante a realização do
projeto ajuda a equipe a identificar cada vez mais cedo os problemas e a propor soluções, apoiando o gerenciamento
de riscos. As métricas também são essenciais para a definição das relações de contratação entre as organizações.
OBJETIVOS
MÓDULO 1
Reconhecer a importância de métricas e medidas
MÓDULO 2
Analisar as características gerais de uma métrica
MÓDULO 3
Classificar as métricas de software apresentando os métodos utilizados
MÓDULO 4
Empregar métricas de software no acompanhamento da evolução de um projeto
INTRODUÇÃO
Neste conteúdo, aprenderemos os principais fundamentos de métricas e medidas de software. Veremos como
identificar, classificar, analisar e aplicar métricas de software como ferramenta essencial no gerenciamento de projetos.
Relacionaremos os principais fundamentos com a apresentação de exemplos práticos presentes no cotidiano dos
profissionais de Tecnologia da Informação (TI), como medidas de controle de produtividade e qualidade.
Também apresentaremos as técnicas utilizadas para fazer a análise de requisitos de um projeto e, dessa forma,
quantificar o tamanho de um software, que representa a entrada principal para a realização de estimativas de esforço,
custos e duração de um projeto. Por fim, será demonstrado o processo de medição de software para o
acompanhamento da execução de um projeto.
MÓDULO 1
 Reconhecer a importância de métricas e medidas
MOTIVAÇÃO
As primeiras perguntas que nos deparamos antes de iniciarmos um projeto de software são:
Quanto tempo o projeto irá durar? 
Qual é o custo deste projeto?
Diferentemente das áreas de Engenharia e Arquitetura, em que podemos prever todas as características da construção
de uma casa, por exemplo, antes mesmo de levantarmos um único tijolo, na área de Ciência da Computação os
requisitos tendem a aumentar com o tempo. Na medida em que o projeto vai se desenvolvendo, os usuários passam a
vislumbrar novas características que inicialmente não eram percebidas ou não eram importantes nas primeiras versões
do projeto. Essa natureza expansiva dos requisitos é uma realidade que ocorre em quase todos os projetos de
software e influencia diretamente o tempo em que o projeto será entregue e o seu custo final.
Atender aos requisitos que tendem à expansão envolve um aumento no esforço para realizar o projeto, e a disputa por
recursos tende à escassez, como recursos humanos, materiais, financeiros e o próprio tempo, que é limitado. Manter
essa situação sob controle é o maior desafio do gerenciamento de projetos de software, que busca atender ao máximo
às expectativas dos clientes com a utilização mínima de recursos.
Conforme poderemos observar no relatório Chaos Manifesto (THE STANDISH GROUP, 2013), continuamente
atualizado, projetos fracassados continuam acontecendo na indústria de software: 39% dos projetos foram bem-
sucedidos, ou seja, foram entregues no tempo, no orçamento, com as características e funções requisitadas; 18% dos
projetos fracassaram, ou seja, foram cancelados antes do término ou entregues e nunca usados; e 43 % dos projetos
foram contestados, ou seja, entregues com atraso, com estouro do orçamento e/ou com menos características e
funções requisitadas.
 
 Gráfico: Chaos Report 2013 
Extraído de: Standish Group, adaptado por Gian Corapi.
Por outro lado, analisando os relatórios publicados anteriormente pelo Standish Group desde 1994, constatamos que o
número de projetos fracassados vem diminuindo ao longo dos anos e o número de projetos bem-sucedidos vem
aumentando, conforme tabela a seguir.
2012 2010 2008 2006 2004 2002 2000 1998 1996 1994
Sucesso 39% 37% 32% 35% 29% 34% 28% 26% 27% 16%
Contestado 43% 42% 44% 19% 53% 15% 23% 28% 40% 31%
Fracasso 18% 21% 24% 46% 18% 51% 49% 46% 33% 53%
 Atenção! Para visualizaçãocompleta da tabela utilize a rolagem horizontal
 Tabela: Chaos Report de 1994 até 2012. 
Adaptada de: Standish Group
Embora a série histórica do Standish Group seja atualizada todos os anos, o relatório de 2012 demonstra como a
adoção de novas metodologias de desenvolvimento de software, assim como a adoção das métricas no gerenciamento
de projetos, afetaram positivamente o mercado de TI. Os dados após aquele relatório não variaram muito, justamente
pelas medidas tomadas a partir daquele ano, de modo que essa melhoria não seria percebida com a série histórica
atualizada.
Agora, vamos analisar o que mudou nesse período?
Primeiro, a mudança nos processos de desenvolvimento de software nas empresas que antes utilizavam processos em
cascata (waterfall ) ou sequenciais, em que, por exemplo, era necessário conhecer detalhadamente todos os
requisitos do projeto desde as suas fases iniciais antes da sua implementação, o que gerava estimativas imprecisas.
Esse fato impulsionou vários avanços: a mudança para uma abordagem de desenvolvimento ágil, como o Extreme
Programming (XP) e o Scrum; a popularização do gerenciamento de projetos através do Project Management Institute
(PMI) e publicação do Guia PMBOK ; os modelos de maturidade tais como o CMMI (Capability Maturity Software
Integration ou Modelo Integrado de Maturidade em Capacitação) e MPS-BR (Melhoria de Processo de Software
Brasileiro); técnicas de medição de software como a APF – Análise de Pontos de Função; tecnologias orientadas a
objetos; linguagens de quarta geração; componentização; uso intensivo de pacotes de software, em especial os ERPs;
ambientes integrados de desenvolvimento, entre outras mudanças.
 SAIBA MAIS
Antigamente, as medições eram encaradas por muitas empresas de software apenas como uma tarefa ou um trabalho
adicional sem muito entusiasmo, enquanto hoje é uma disciplina proativa e a informação gerada pela medição é
considerada como um recurso competitivo e estratégico. Atualmente, muitas empresas utilizam tecnologias como
Business Intelligence (BI) e Big Data para fazer a análise desses dados e gerar informações valiosas de modo a apoiá-
las na tomada de decisões.
POR QUE MEDIR?
O Software Engineering Institute (SEI) responde a dois questionamentos que vêm à tona após as nossas explanações
iniciais:
Por que medir? Porque sem dados você tem somente opiniões. 
 
Por que analisar? Porque os dados que você coleta não podem te ajudar se você não os entende e os usa para tomar
suas decisões.
Tom DeMarco, consultor e pesquisador norte-americano reconhecido na área de Engenharia de Software, responde ao
primeiro questionamento da seguinte forma:
“Não se pode gerenciar o que não se pode medir”.
Roger Pressman (2016, p. 136), autor do livro Engenharia de Software: uma abordagem profissional , considerado a
maior referência na área de Engenharia de Software, responde aos dois questionamentos da seguinte forma:

SE VOCÊ NÃO SABE PARA ONDE QUER IR, QUALQUER CAMINHO
VOCÊ PODE SEGUIR. SE VOCÊ NÃO SABE ONDE VOCÊ ESTÁ, UM
MAPA NÃO VAI TE AJUDAR!
Comparando as respostas anteriores, podemos identificar um benefício importante da medição, que é a visibilidade.
Com ela, é possível saber para onde ir antes de iniciar a caminhada, assim como saber se o caminho em curso é o
correto. Dessa forma, é possível definir objetivos realistas e adotar medidas necessárias à prevenção e correção dos
desvios que causam impacto negativo no cumprimento desses objetivos.
A imagem a seguir ilustra um cenário clássico de problemas que podem ocorrer durante o desenvolvimento de um
software, que se não identificados e solucionados desde cedo, comprometem a entrega final do produto.
 
Imagem: Autor desconhecido, adaptada por Gian Corapi
 Cenário com as etapas de desenvolvimentode um projeto
Como podemos observar confrontando o primeiro e o último quadro, o cliente não conseguiu comunicar o que o
produto deveria ser, ou seja, quais as suas características principais e o que ele esperava que fosse entregue.
Utilizando métricas e medições, essa falha na comunicação seria percebida e corrigida desde o início do projeto.
 No penúltimo quadro, verificamos também que o projeto foi concluído com atraso, pois a figura do boneco de neve
sinaliza que a estação do ano em que o produto foi entregue foi o inverno, diferentemente das dos demais quadros.
 No sétimo quadro, também verificamos que houve um estouro no orçamento do projeto, demonstrado pela
poltrona. Um dos objetivos do uso das métricas, conforme explicamos no início deste módulo, é possibilitar o
acompanhamento do projeto mantendo a situação sob controle, ou seja, tentando cumprir o que foi planejado no início
do projeto, durante a sua realização, evitando dessa forma o estouro no prazo e nos custos do projeto.
Portanto, verificamos que as métricas são um artefato essencial para o gerenciamento de projetos.
O Project Management Institute (PMI), em seu Guia do conjunto de conhecimentos em gerenciamento de projetos
(PMBOK) , agrupa os processos que visam permitir o gerenciamento de projetos em cinco grandes grupos, dos quais
iremos destacar três:
 Planejamento
 Execução
 Monitoramento e controle
Durante o planejamento, são definidos os planos de projeto que são refinados ao longo do seu curso, e neles são
definidas as linhas de base (baselines ) que irão nortear a execução e o monitoramento e controle do projeto. A linha
de base de cada um desses planos é criada por meio de técnicas de estimativas utilizando métricas.
No plano de gerenciamento de tempo, criamos um cronograma, com os prazos estimados para a realização de cada
uma das atividades e o recurso (profissional) que irá executá-las, e durante a execução e o monitoramento e controle
do projeto é que efetivamente ocorrem as medições, quando confrontamos o que foi planejado com o que está sendo
realizado e analisamos o progresso do projeto.
As métricas também:
1
São utilizadas para avaliar a aquisição de pacotes (make-or-buy ), apoiando a organização na tomada da decisão de
fazer ou comprar um software no mercado.
Suportam análises de produtividade e qualidade, medindo o desempenho da equipe no curso do projeto e oferecendo
indicadores de quantidade de defeitos/PF, por exemplo, que são úteis na avaliação da qualidade do software.
2
3
Auxiliam na remuneração de fornecedores, na medida em que se pode quantificar a funcionalidade que foi entregue
pelo fornecedor em determinado período e, dessa forma, calcular quanto se deve pagar por aquilo que lhe foi entregue.
Apoiam a realização de estudos de Benchmarking, que são importantes para as organizações compararem os seus
produtos e/ou serviços com os do concorrente e, assim, traçarem o seu planejamento estratégico.
4
5
Ajudam, ainda, a justificar as solicitações de novas ferramentas ou treinamentos, observando os indicadores de
produtividade do time do projeto.
Reduzem frustrações e pressões de cronograma, pois as informações ficam transparentes para o cliente e são
“quantificáveis”, fato que, inclusive, ajuda a melhorar o relacionamento.
6
7
Ajudam a entender e aperfeiçoar o processo de desenvolvimento de software, fazendo com que, nos últimos anos, as
empresas procurassem se certificar com os modelos propostos pelo CMMI e MPS-BR, por exemplo, para atestarem a
qualidade dos seus processos de desenvolvimento e, assim, atraírem mais clientes e investidores no mercado.
Em seu guia sobre medições de software, Park, Goethert e Florac observam as razões por que medimos:
(1) caracterizar, para obter um entendimento de processos, produtos, recursos e ambientes, e estabelecer referenciais
para comparações com futuras avaliações.
(2) avaliar para determinar o status com relação aos planos.
(3) prever, entendendo as relações entre os processos e produtos, criando modelos dessas relações.
(4) melhorar, identificando etapas, causas-raiz de problemas, ineficiências e outras oportunidades de melhoria da
qualidade do produto e do desempenho do processo.
MÉTRICAS E MEDIDAS EM ENGENHARIA DE
SOFTWARE
O especialista apresentará conceitos sobre métricas e medidas em sistemas de software, ressaltando a sua
importância para o ciclo de vida dos sistemas.
VERIFICANDO O APRENDIZADO
1. AO LONGO DOS ÚLTIMOS VINTE ANOS, HOUVE UMA EVOLUÇÃO SIGNIFICATIVA NA
INDÚSTRIA DE TECNOLOGIA DA INFORMAÇÃO, FATO QUE LEVOU AS EMPRESAS A
INVESTIREM MAIS NA ADOÇÃO DE NOVAS METODOLOGIAS DE DESENVOLVIMENTO DE
SOFTWARE E DE GERENCIAMENTO DE PROJETOS. COM BASE NESSA DECLARAÇÃO,
PODEMOS AFIRMAR QUE
A) As empresas passaram a adotar a metodologia de desenvolvimento de software em cascata a fim de obter
estimativas mais acertadas desde o início do projeto.
B) Técnicas de medição de software como a Análise de Pontos de Função passaram a ser cada vez mais utilizadas
pelas empresas, o que contribuiu para que ao longo desses anos houvesse um aumento no número de projetos bem-
sucedidos.
C) Antigamente as empresas de software utilizavam as medições como um recurso competitivo e estratégico, e o
trabalho de medição sempre foi encarado com entusiasmo, o que justifica o aumento do número de projetos bem-
sucedidos ao longo dos anos.
D) A maioria dos requisitos dos projetos de software é conhecida desde o início do projeto e não tende à expansão.
E) Projetos de software entregues com atraso, com estouro no orçamento, ou com menos características e funções do
que as requisitadas não ocorrem com frequência.
2. A ADOÇÃO DAS MÉTRICAS DE SOFTWARE PROVÊ UMA SÉRIE DE BENEFÍCIOS ÀS
ORGANIZAÇÕES. SOBRE ESSES BENEFÍCIOS, PODEMOS AFIRMAR:
A) A adoção de métricas de software aumenta as frustrações e pressões no cronograma porque o desempenho da
equipe do projeto diminui quando as entregas passam a ocorrer no prazo.
B) A remuneração de fornecedores normalmente é contratada pelas empresas utilizando a forma de contratação
homens-hora, sendo a adoção das métricas de software desnecessária para esse fim.
C) Os estudos de benchmarking, que comparam os produtos de uma empresa com os das empresas concorrentes,
não utilizam métricas de software, pois não são relevantes para o planejamento estratégico de uma empresa.
D) As métricas de software podem ser utilizadas para avaliar a aquisição de pacotes de software, ajudando a empresa
na tomada de decisão de fazer ou comprar um software no mercado.
E) As solicitações de novas ferramentas e treinamento são feitas com base nas opiniões do gerente de projetos, que é
responsável por monitorar o cronograma e o desempenho da equipe do projeto.
GABARITO
1. Ao longo dos últimos vinte anos, houve uma evolução significativa na indústria de Tecnologia da
Informação, fato que levou as empresas a investirem mais na adoção de novas metodologias de
desenvolvimento de software e de gerenciamento de projetos. Com base nessa declaração, podemos afirmar
que
A alternativa "B " está correta.
 
A fim de atender à tendência dos requisitos propensos à expansão na maioria dos projetos de software e manter essa
situação sob controle, ou seja, entregar cada vez mais os projetos com os requisitos solicitados, no prazo e com o
custo estimado, ao longo dos últimos anos as empresas passaram a adotar técnicas de medição de software como a
Análise de Pontos de Função, o que pode ser observado no relatório do Chaos Report de 2013, publicado pelo
Standish Group, que mostra o aumento no número de projetos bem-sucedidos com relação aos anos anteriores.
2. A adoção das métricas de software provê uma série de benefícios às organizações. Sobre esses benefícios,
podemos afirmar:
A alternativa "D " está correta.
 
As métricas de software geram indicadores que auxiliam as empresas na avaliação da aquisição de pacotes de
software. Por exemplo, uma empresa que deseja desenvolver um aplicativomóvel, e que não possui uma equipe de
desenvolvimento especialista nessa área, pode avaliar, com base nos indicadores dos seus registros históricos, se é
mais lucrativo pagar pelo treinamento dos seus profissionais e obter no médio e longo prazo o retorno desse
investimento, ou se é melhor contratar no mercado uma fábrica de software que possua o know-how na tecnologia e
possa entregar em um prazo mais curto o produto final, ou seja, o aplicativo móvel.
MÓDULO 2
 Analisar as características gerais de uma métrica
O QUE MEDIR?
Quando um arquiteto faz a planta de uma casa, ele define as suas dimensões e qual o tamanho da área a ser
construída em dado terreno utilizando o m² (metro quadrado) como unidade de medida. Por exemplo, o arquiteto faz o
projeto com uma área construída de 100m² dentro de um terreno de 500m², e os seus ambientes internos como sala,
quarto, banheiro e cozinha são divididos utilizando a mesma unidade de medida, que é o m² (metro quadrado).
Fazendo uma analogia com o mundo do software, para se construir um software, devemos definir também quais são as
suas dimensões e as suas características utilizando uma unidade de medida. As duas principais unidades de medida
utilizadas pela indústria de TI para dimensionar o tamanho de um software são LOC (Lines of Code ou Linhas de
Código) e PF (Pontos de Função).

Medidas diretas, tangíveis e verificáveis, como as citadas, que possuem uma grandeza numérica e que são
quantificáveis, nem sempre são possíveis no mundo do software, e como medidas e métricas são muitas vezes
indiretas, ou seja, derivadas de outras medidas, como confiabilidade, eficiência e segurança, e possuem um maior grau
de subjetividade com base em critérios e regras qualitativas, elas estão abertas ao debate.
No contexto da Engenharia de Software, de acordo com Pressman (2016, p. 654), “embora os termos medida, medição
e métricas sejam, com frequência, usados indistintamente, existem diferenças sutis entre eles”. Uma medida fornece
uma indicação quantitativa da extensão, quantidade, capacidade ou do tamanho de algum atributo de um produto ou
processo.
Medição é o ato de determinar uma medida.
O IEEE Standard Glossary of Software Engineering Terminology (PRESSMAN, 2016, p. 654) define métrica como
“uma medida quantitativa do grau com o qual um sistema, componente ou processo possui determinado atributo”.
Para entendermos melhor cada um desses conceitos, vamos a um exemplo prático observando a tabela a seguir, que
possui três projetos de desenvolvimento de software já concluídos de uma empresa fictícia. Nesse caso, as medidas
estabelecidas foram LOC, esforço, custo ― representado pelo símbolo $(000) ―, erros, defeitos e pessoas. A
medição, conforme vimos, é o ato de determinar uma medida e ocorre como resultado da coleta de um ou mais pontos
de dados, ou seja, no projeto Alfa foram registrados 134 erros durante os testes, por exemplo, enquanto no projeto
Beta 27.200 LOC (linhas de código) foram criadas por 62 pessoas-mês de trabalho, a um custo de $440.000. Por fim, a
partir desses dados, podemos determinar um conjunto de métricas que relaciona as medidas individuais de alguma
maneira como: a quantidade média de erros por KLOC (mil linhas de código); defeitos por KLOC; erros por pessoa-
mês; e custo ($) por página de documentação. Outras métricas podem ser obtidas a partir dos dados coletados, sendo
derivadas a partir de objetivos definidos pela empresa a fim de obter um melhor entendimento dos seus projetos.
]
Projeto LOC Esforço $(000) Pág. doc. Erros Defeitos Pessoas
alfa 12.100 24 168 365 134 29 3
beta 27.200 62 440 1224 321 86 5
gama 20.200 43 314 1050 256 64 6
 Atenção! Para visualizaçãocompleta da tabela utilize a rolagem horizontal
 Tabela: Métricas de software 
Extraída de: PRESSMAN, 2016, p. 709
No exemplo da tabela acima, foram apresentadas métricas de projeto de software, que são usadas para fins táticos ou
gerenciais, baseadas em metas operacionais, e atividades técnicas, diferentemente das métricas de processo de
software, que são baseadas nas metas da empresa e possuem objetivos estratégicos, como estudos de mercado e
análise competitiva.
Dentre as propriedades desejáveis de uma métrica, destacam-se as seguintes:
 Deve ser simples o suficiente para ser facilmente calculada, entendida e testada;
 Deve ser passível de estudos estatísticos;
 Deve ser expressa em alguma unidade (tempo, pessoas, $);
 Deve ser obtida o mais cedo possível durante o ciclo de vida do software;
 Deve ser passível de automação;
 Deve ser repetível e independente do observador;
 Deve ser comprometida com uma estratégia de melhoria;
 Deve ser válida, quantificando o que se quer medir;
 Deve ser confiável, produzindo os mesmos resultados nas mesmas condições;
 Deve ser prática, ou seja, barata, fácil de calcular e fácil de interpretar.
Agora que já conhecemos a sutil diferença entre medida, medição e métrica, surgem os seguintes questionamentos:
Por que obter métricas de software? 
 
O que fazer com esses dados?
Respondendo ao primeiro questionamento, obtemos métricas ou um conjunto de métricas para extrair indicadores a
partir delas, que nos proporcionam uma compreensão e uma visão mais aprofundada do processo, do projeto ou do
produto de software. Os indicadores podem ser obtidos a partir de bases de dados históricas de projetos que já foram
concluídos, por exemplo, para ajudar na tomada de decisões em um projeto corrente, fato que nos ajuda a responder o
segundo questionamento.
Por meio dos indicadores, alguém pode descobrir, por exemplo, que a inclusão de revisões técnicas formais no
processo de desenvolvimento ocasiona uma redução de 40% na taxa de erros encontrados nos testes.
No exemplo visto, o uso do indicador “taxa de redução percentual de erros na etapa de teste”, que foi utilizado em
projetos passados e obtido por intermédio das bases históricas de projetos, poderá ser utilizado em um projeto corrente
a fim de se obter o benefício da redução de 40% na taxa de erros encontrados nos testes, visando, dessa forma,
melhorar a qualidade e o desempenho do projeto.
Outros exemplos de indicadores úteis são: retorno do investimento, economia média líquida de esforço (pessoas x
hora) por quantidade de código desenvolvido e quantidade média de erros por linha de código. Por fim, indicadores são
instrumentos valiosos para orientar ações no sentido de melhorar um produto, um projeto ou um processo.
Para empresas que desejam começar a investir em métricas de software e que não possuem uma base de dados
histórica de processos, projetos ou produtos, ou até para as empresas que já usam métricas de software e desejam
comparar os seus indicadores com indicadores de mercado, há uma organização sem fins lucrativos conhecida como
ISBSG (International Software Benchmarking Standards Group), que mantém um repositório público de dados de
aproximadamente 9.502 projetos que são alimentados continuamente por organizações de todo o mundo e de
diferentes áreas de negócio. Esse repositório possibilita que sejam feitas diversas análises e pesquisas abordando
questões como estimativa, produtividade, boas práticas, dentre outras. Periodicamente, o ISBSG publica diversos
relatórios, oferecendo análises detalhadas do seu repositório sob diversos aspectos.
Veja um dos relatórios na tabela a seguir.
Linguagem de
Programação
N Min P10 P25 Mediana P75 P90 Max
ABAP 5 8.0 - 13.3 13.8 18.0 - 24.3
C 27 2.8 6.4 8.5 14.9 19.8 27.4 41.4
C++ 20 1.2 5.9 9.3 17.4 24.4 42.3 69.3
CLIPPER 4 8.6 - 8.6 8.8 11.4 - 18.7
COBOL 64 1.2 5.2 9.4 16.0 26.0 42.4 69.7
JAVA 10 5.3 6.6 14.7 19.6 26.7 67.8 68.2
ORACLE 49 1.2 3.0 6.0 9.6 15.9 28.1 78.1
SQL 56 0.5 3.4 8.2 13.6 19.3 35.3 60.7
VISUAL BASIC 54 0.4 2.7 3.8 7.5 14.0 37.2 68.0
 Atenção! Para visualizaçãocompleta da tabela utilize a rolagem horizontal
 Tabela: Produtividade (Horas/PF) por linguagem de programação. 
Extraída de: Vazquez, Simões, Albert, 2013, p. 39.Utilizando os indicadores da tabela acima, é possível que uma empresa tome a decisão de desenvolver um novo
projeto utilizando a linguagem de programação Visual Basic ao invés da linguagem ABAP, pois, observando a mediana
exposta na tabela, conclui-se que fazer um desenvolvimento utilizando Visual Basic demanda quase a metade do
esforço do que utilizando a linguagem ABAP, visto que um programador desenvolvendo em Visual Basic faz um
esforço de 7,5 horas para entregar 1 Ponto de Função, enquanto um programador desenvolvendo em ABAP faz um
esforço de 13,8 horas para entregar 1 Ponto de Função.
COMO DEFINIR AS MEDIDAS?
O primeiro passo para o estabelecimento de uma política de medidas é a identificação adequada das medidas a serem
coletadas. Essa definição deve ser feita com base em critérios bem fundamentados, devido ao grande número de
opções possíveis e ao custo envolvido na coleta de cada informação.

Com o intuito de guiar o processo de definição das medidas, vários métodos foram propostos, como Balanced
Scorecard (BSC), Goal-Question-Metric (GQM), Goal-Driven Software Measurement (GDSM) e Pratical Software
and System Measurement (PSM). Dentre esses modelos propostos, iremos dar enfoque ao GQM e ao PSM.
No artigo intitulado Software modeling and measurement: The Goal/Question/Metric paradigm , publicado pelo
Departamento de Ciência da Computação da Universidade de Maryland, Victor R. Basili propôs um modelo para guiar
a escolha das medidas mais adequadas para um processo de mensuração. Esse método ficou conhecido como GQM
(Goal/Question/Metric ). A ideia básica desse método é derivar métricas de software a partir de perguntas e objetivos.
O modelo é composto por três níveis que visam definir se uma métrica atenderá ou não aos objetivos da empresa e se
ela será coletada e utilizada. O primeiro nível, conhecido como Conceitual (Goal ), busca definir os objetivos da
organização, ou seja, as metas a serem atingidas pelo programa de medição. O segundo nível, conhecido como
Operacional (Question ), consiste em um conjunto de perguntas que é elaborado com relação a cada objetivo
identificado no nível anterior. Por fim, no terceiro nível, conhecido como Quantitativo (Metrics ), um conjunto de
métricas é estabelecido, de maneira a responder cada pergunta elaborada no nível anterior.
Para entendermos melhor o GQM, observe a situação a seguir.
 EXEMPLO
Suponhamos que uma organização possua um projeto de software em desenvolvimento rodando no ambiente de
produção dos clientes, e que a cada atualização de versão ocorra a introdução de muitos defeitos, gerando uma
insatisfação por parte dos clientes. Para reverter essa situação, a organização resolveu definir algumas métricas de
qualidade, bem como a meta (Goal ) de assegurar que todos os defeitos fossem corrigidos antes da liberação das
versões para o ambiente de produção.
Com base nessa meta, a organização respondeu a três perguntas (Question):
 Quantos defeitos temos atualmente?
 Qual o status de cada defeito?
 Qual a cobertura dos testes?
Após a obtenção das respostas, definiu as seguintes métricas (Metrics ): números de defeitos, números de defeitos
por status e número de casos de testes planejados x executados.
 
Imagem: Bruno Freitas Braga, adaptado por Gian Corapi
 Exemplo de aplicação do método QGM para definição de métrica
Outra abordagem para a definição de métricas foi publicada no guia PSM (Pratical Software and System
Measurement), patrocinado pelo Departamento de Defesa dos Estados Unidos. O PSM focaliza as medições no nível
de projetos e utiliza dois modelos integrados que são: o modelo de informação para medição (measurement
information model ) e o modelo do processo de medição (measurement process model ).
O primeiro modelo fornece um caminho para a seleção das medidas a serem utilizadas, enquanto o segundo modelo
serve de guia para a implementação do PSM. O PSM inclui um conjunto de medidas já utilizadas com sucesso pela
indústria, distribuídas em categorias previamente definidas como: prazo e progresso, recursos e custo, tamanho e
estabilidade do produto, qualidade do produto, performance do processo, eficácia da tecnologia e satisfação do cliente.
Conforme observado a seguir, temos um exemplo da obtenção de uma métrica de produtividade utilizando o modelo de
informação do PSM.
 
JONES et al., 2021, p. 18, adaptada por Bruno Freitas Braga e Gian Corapi
 Exemplo de produtividade utilizando o Modelo de Informação do PSM
No exemplo da imagem anterior, buscou-se extrair um indicador visando a uma estimativa de produtividade. Como
resultado, obteve-se o indicador Horas/PF (Ponto de função), ou seja, quantas horas em média (esforço) um
profissional levará para entregar 1 ponto de função (tamanho).
Independentemente do modelo utilizado para implementar um programa de métricas, a coleta de métricas é apenas um
dos requisitos envolvidos, e o processo de medição de software envolve mais etapas além desta, as quais veremos
posteriormente.
CARACTERÍSTICAS DE MÉTRICAS EM SOFTWARE
O especialista apresentará as principais características das métricas em sistemas de software.
VERIFICANDO O APRENDIZADO
1. SOBRE OS CONCEITOS DE MEDIDA, MEDIÇÃO E MÉTRICAS, É CORRETO AFIRMAR:
A) Uma medida fornece uma indicação qualitativa sobre um projeto de software baseada em opiniões dos especialistas
do projeto.
B) As duas principais unidades de medida utilizadas pela indústria de TI são eficiência e confiabilidade.
C) Todas as medidas de software são quantificáveis, baseadas em critérios técnicos, regras bem definidas e em uma
grandeza matemática.
D) As métricas de projeto de software são utilizadas para fins estratégicos, visando às metas da empresa.
E) As duas principais unidades de medida utilizadas pela indústria de TI para dimensionar o tamanho de um software
são LOC (linhas de código) e PF (pontos de função).
2. SOBRE O PROCESSO DE DEFINIÇÃO DE MEDIDAS, QUE VISA DEFINIR AS MEDIDAS
MAIS ADEQUADAS A SEREM COLETADAS PELA ORGANIZAÇÃO, PODEMOS AFIRMAR:
A) O modelo GQM (Goal/Question/Metric ) se guia por unidades de medida padrão, e não derivadas, para orientar a
empresa na definição de suas melhores métricas.
B) Para se definir boas métricas na empresa, é necessário conhecer todos os modelos propostos para a definição de
métricas como o Balanced Scorecard (BSC), Goal-Question-Metric (GQM), Goal-Driven Software Measurement
(GDSM) e Pratical Software and System Measurement (PSM).
C) O modelo GQM (Goal/Question/Metric ) deriva métricas de software a partir de perguntas e objetivos.
D) O modelo proposto pelo PSM (Pratical Software and System Measurement ) focaliza as medições no nível de
processos.
E) O PSM (Pratical Software and System Measurement ) visa propor um conjunto de novas medidas que sejam
melhores do que as já existentes no mercado, e que não foram utilizadas ainda pela indústria, e focaliza as medições
no nível de projetos.
GABARITO
1. Sobre os conceitos de medida, medição e métricas, é correto afirmar:
A alternativa "E " está correta.
 
As duas principais unidades de medida utilizadas para dimensionar o tamanho de um software são LOC (linhas de
código) e PF (pontos de função), pois a partir delas são extraídos os indicadores necessários para se fazer as
estimativas de esforço, tempo e custo dos projetos.
2. Sobre o processo de definição de medidas, que visa definir as medidas mais adequadas a serem coletadas
pela organização, podemos afirmar:
A alternativa "C " está correta.
 
O modelo GQM (Goal/Question/Metric ) é composto por três níveis, sendo que o primeiro nível, conhecido como
Conceitual (Goal ), busca definir as metas da organização, enquanto o segundo nível, conhecido como Operacional
(Question ), consiste em um conjunto de perguntas elaboradas para cada uma das metas definidas no nível anterior, e
o terceiro nível, conhecido como Quantitativo (Metrics ), deriva um conjunto de métricas baseado nas respostas do
nível anterior.MÓDULO 3
 Classificar as métricas de software apresentando os métodos utilizados
MÉTRICAS DIRETAS E INDIRETAS
No mundo físico, as medições podem ser classificadas de duas maneiras: medidas diretas, como tensão elétrica,
massa, velocidade ou temperatura, e medidas indiretas, como a velocidade média de um carro, sabendo que ele
percorreu um espaço x em um intervalo de tempo y.
Como podemos observar, as medidas diretas são mais fáceis de serem obtidas, pois podem ser mensuradas a partir
da observação direta dos atributos envolvidos, enquanto as medidas indiretas são obtidas a partir da derivação de
outras métricas. Inspiradas no mundo físico, as métricas de software são medidas de maneira similar.
No mundo do software, as métricas diretas são a quantidade de linhas de código produzida, o número de defeitos
relatados durante o desenvolvimento do software, o custo do software, o esforço aplicado durante seu desenvolvimento
e sua manutenção, o número de diagramas, a complexidade ciclomática ou complexidade condicional, que mede a
quantidade de caminhos de execução independentes a partir de um código fonte, dentre outras.

Já as métricas indiretas como qualidade, funcionalidade do software, ou a sua capacidade de manutenção,
confiabilidade, eficiência, dentre outras, são mais difíceis de serem obtidas e só podem ser medidas de forma indireta.
Para entendermos melhor uma métrica indireta, vamos a um exemplo de uma métrica para manutenção utilizada para
medir o grau de estabilidade de um produto. Essa métrica conhecida como SMI (Software Maturity Index ou Índice de
Maturidade de Software) se baseia nas alterações ocorridas em cada versão do produto, e é determinada com as
seguintes informações:
MT = número de módulos da versão atual 
Fc = número de módulos na versão atual que foram alterados 
Fa = número de módulos na versão atual que foram acrescentados 
Fd = número de módulos da versão anterior que foram excluídos na versão atual 
Considerando as informações anteriores, podemos calcular o índice de maturidade do software por meio da seguinte
fórmula:
SMI =
MT - FA + FC + FD
MT
À medida que o SMI se aproxima de 1, o produto começa a estabilizar.
[ ( ) ]
MÉTRICAS DE PROCESSO, PROJETOS E PRODUTO
No contexto da Engenharia de Software, o domínio das métricas de software é dividido em três grupos distintos que
visam objetivos diferentes durante o ciclo de vida do software, que são: métricas de processo, métricas de projeto e
métricas de produto.
Segundo Pressman:

AS MÉTRICAS DE PROCESSO SÃO COLETADAS EM TODOS OS
PROJETOS, NO DECORRER DE LONGOS PERÍODOS, E TÊM POR
FINALIDADE GERAR UM CONJUNTO DE INDICADORES DE
PROCESSO QUE LEVAM À MELHORIA DO PROCESSO DE
SOFTWARE NO LONGO PRAZO.
MÉTRICAS DE PROCESSO
As métricas de processo são usadas com finalidade estratégica, ou seja, visam benefícios para projetos futuros, e
não para o projeto que está sendo medido; têm como objetivo melhorar o processo de forma contínua e medir
características do processo de desenvolvimento como um todo.
Essas métricas objetivam criar um padrão dentro da organização, que possa ser estendido para todos os projetos
de software, independentemente do contexto em que ele seja aplicado. Um exemplo de uma métrica de processo é o
número de defeitos encontrados ao longo do processo para diferentes metodologias de teste e de revisão.
Modelos como o CMMI e o MPS-BR apresentam um conjunto de boas práticas de melhoria de processo de software,
as quais se tornaram uma referência para a indústria de TI.
De acordo com Pressman (2016),

AS MÉTRICAS DE PROJETO PERMITEM AO GERENTE DE
PROJETOS DE SOFTWARE: 
 
(1) AVALIAR O ESTADO DE UM PROJETO EM ANDAMENTO; 
(2) RASTREAR OS RISCOS EM POTENCIAL; 
(3) DESCOBRIR ÁREAS PROBLEMÁTICAS ANTES QUE SE TORNEM
“CRÍTICAS”; 
(4) AJUSTAR O FLUXO DE TRABALHO OU TAREFAS; 
(5) AVALIAR A HABILIDADE DA EQUIPE DE PROJETO PARA
CONTROLAR A QUALIDADE DOS ARTEFATOS DE SOFTWARE. 
MÉTRICAS DE PROJETO
As métricas de projeto são usadas com finalidade tática, ou seja, para adaptar o fluxo de trabalho e atividades técnicas
de forma imediata, em benefício do próprio projeto que está sendo medido. Essas métricas têm como objetivo
minimizar o cronograma e monitorar a qualidade do produto, e o seu primeiro emprego ocorre nas estimativas
preliminares, e, à medida que o projeto evolui, os resultados são confrontados para monitorar e controlar o progresso.
Taxa de produção, horas de revisão e tamanho (físico ou funcional) dos artefatos produzidos são exemplos de métricas
de projetos.
Ainda de acordo com Pressman,

AS MÉTRICAS DO PRODUTO SÃO USADAS PARA AVALIAR A
QUALIDADE DO PRODUTO ENQUANTO ELE ESTÁ SENDO
PROJETADO. ESSAS MEDIDAS DE ATRIBUTOS INTERNOS DO
PRODUTO FORNECEM UMA INDICAÇÃO EM TEMPO REAL DA
EFICÁCIA DOS MODELOS DE REQUISITOS, DO PROJETO E DO
CÓDIGO; DA EFICIÊNCIA DOS CASOS DE TESTE; E DA QUALIDADE
GERAL DO SOFTWARE QUE SERÁ CRIADO.
MÉTRICAS DE PRODUTO
As métricas de produto têm por objetivo analisar as características físicas do software, e podem ser subdivididas em:
 métricas para o modelo de requisitos;
 métricas para o modelo de projeto;
 métricas de projeto para webapps e aplicativos móveis;
 métricas para código-fonte;
 métricas para teste;
 métricas para manutenção.
Como exemplo de métricas de produtos, temos pontos de função e linhas de código, que objetivam determinar o
tamanho de um software e que serão derivadas nas estimativas de esforço, tempo, custos e recursos (pessoas).
MÉTRICAS DE PROJETO
As métricas de projeto são usadas com finalidade tática, ou seja, para adaptar o fluxo de trabalho e atividades
técnicas de forma imediata, em benefício do próprio projeto que está sendo medido. Essas métricas têm como
objetivo minimizar o cronograma e monitorar a qualidade do produto, e o seu primeiro emprego ocorre nas
estimativas preliminares, e, à medida que o projeto evolui, os resultados são confrontados para monitorar e
controlar o progresso. Taxa de produção, horas de revisão e tamanho (físico ou funcional) dos artefatos
produzidos são exemplos de métricas de projetos.
MÉTRICAS ORIENTADAS A TAMANHO
O tamanho de um software é a sua dimensão mais importante, pois é a partir dele que são derivados os principais
indicadores que serão utilizados desde as estimativas iniciais do projeto até a entrega final do produto. Durante muito
tempo, a comunidade de Engenharia de Software vem discutindo qual é a melhor medida para representar o tamanho
de um software, e a unidade mais intuitiva é o número de linhas de código.
As métricas de software orientadas a tamanho consideram o tamanho físico do software que foi produzido (linhas de
código), e referem-se a todas as atividades de engenharia (análise, projeto, código, teste). Essas métricas são
derivadas de bases históricas de projetos e criadas pela normalização de medidas de qualidade e/ou produtividade.
 ATENÇÃO
A partir de dados contidos nos registros históricos dos projetos, podemos derivar algumas métricas orientadas a
tamanho como: Erros por KLOC (mil linhas de código), Defeitos por KLOC, $ (Custo) por KLOC e Páginas por KLOC.
Além desses exemplos, podem ser calculadas outras métricas interessantes, que não necessariamente utilizem linhas
de código como: Erros por pessoa-mês e $ (Custo) por página de documentação.
Apesar dos esforços feitos na tentativa de normatizar as linhas de código (LOC) como uma unidade de medida padrão,
elas ainda não são universalmente aceitas como o melhor modo de medir, pois pode-se incorrer no risco de dois pesos
e duas medidas, se alguns pontos não forem esclarecidos como:
 Inclusão na contagem da quantidade de linhas de comentários, linhas em branco ou comandos nulos;
 Inclusão na contagem de diretrizes de compilação;
 Contagem de múltiplos comandos ou declarações em uma única linha como várias linhas, uma para cada
comando ou declaração;
 Contagem de uma única linha nos casos em que um único comando ou declaração é expresso em múltiplaslinhas;
 Inclusão na contagem de delimitadores de blocos de comandos nos casos em que, de fato, haja mais de um
comando;
 Desconsideração de blocos de comandos nos casos em que sua utilização seja opcional.
Um dos modelos baseados em LOC mais conhecidos é o COCOMO (COnstructive COst Model ou Modelo de Custo
Construtivo), proposto em 1981 pelo Dr. Barry Boehm. Esse modelo utiliza LOC como subsídio para a geração de
estimativas de esforço, prazo e custo. Com o surgimento de novas tecnologias como componentização e programação
visual, um novo modelo foi proposto para contemplar esses aspectos e ficou conhecido como COCOMO II.
Os apoiadores das métricas do LOC argumentam que como as linhas de código são um artefato de todos os projetos
de software, podem ser facilmente contadas, além de haver uma gama de literatura, dados e modelos baseados em
LOC, como o COCOMO.
Por outro lado, os opositores argumentam que a dependência da linguagem de programação torna o LOC uma unidade
de medida duvidosa ao se comparar projetos desenvolvidos em diferentes linguagens de programação, como, por
exemplo, COBOL e JAVA, pois os números são penalizados devido às diferenças tecnológicas, como a tecnologia
orientada a objetos que oferece recursos como reutilização, tornando o código em JAVA mais curto e eficiente. A
dificuldade na obtenção de estimativas nas fases iniciais do projeto utilizando LOC é outro fator que motivou o
surgimento de outras métricas no mercado.
 
Foto: Shutterstock.com
MÉTRICAS ORIENTADAS A FUNÇÃO
Em decorrência da urgência na solução dos reveses que aconteciam nos projetos que utilizavam o LOC (linhas de
código) como unidade de medida padrão, em 1975, Allan Albrecht definiu os conceitos que serviriam de base para a
métrica de ponto de função (FP, function point ), e esta passou a ser a métrica funcional mais usada.
 SAIBA MAIS
As métricas orientadas a função, ou simplesmente, métricas funcionais, fornecem uma medida da funcionalidade
oferecida pela aplicação como valor de normalização. A funcionalidade é medida indiretamente, a partir de outras
medidas diretas, e o valor resultante é denominado tamanho funcional do sistema.
A métrica funcional tem como objetivos: medir a funcionalidade solicitada, reconhecível e recebida pelo usuário, e
medir de forma independente da tecnologia utilizada, dentro de uma ótica de negócio e não técnica. Além disso, as
métricas funcionais devem ser simples, para viabilizar o esforço de medição, e consistentes entre diferentes projetos,
organizações e tecnologias.
Para entendermos melhor as diferenças entre as métricas de linhas de código (LOC) e pontos de função (PF), vamos
observar o quadro comparativo a seguir.
LOC PF
Necessário que se esteja em um estágio adiantado do
projeto.
Estimativa de tamanho pode ser realizada na
fase inicial do projeto.
Atrasa na geração de indicadores úteis.
Gera indicadores úteis desde a fase inicial do
projeto.
Definição da linguagem de programação nem sempre é
realizada na fase inicial do projeto.
Independente da tecnologia empregada.
Indicadores penalizados devido às técnicas de engenharia
utilizadas, como reutilização.
Indicadores são independentes de requisitos
não funcionais.
 Atenção! Para visualizaçãocompleta da tabela utilize a rolagem horizontal
 Quadro: LOC x PF. 
Elaborado por: Bruno Freitas Braga
A relação entre linhas de código e pontos de função não é uma relação linear; no entanto, o QSM (Quantitative
Software Management ou Gerenciamento Quantitativo de Software) elaborou um estudo relacionando essas duas
unidades de medida, fornecendo estimativas aproximadas da média do número de linhas de código necessárias para
criar um ponto de função em várias linguagens de programação.
O IFPUG (International Function Points Users Group ) elaborou um manual de práticas de contagem conhecido como
CPM (Counting Practices Manual ) cuja última versão é a 4.3.1, para normatizar a medição do tamanho funcional
utilizando pontos de função.
A técnica da APF (Análise de Pontos de Função) passou a ser a mais utilizada no Brasil desde os anos 1990,
principalmente nas licitações públicas de projetos de desenvolvimento de software, e o Portal da Transparência do
Governo Federal oferece uma gama de dados a respeito de projetos de software concluídos e em andamento
utilizando essa métrica.
As principais métricas funcionais usadas no mercado são pontos de função e pontos de caso de uso; no entanto, o
último ainda não está aderente ao padrão ISO, sendo relativamente novo e pouco utilizado.
CLASSIFICAÇÃO DAS MÉTRICAS EM ENGENHARIA
DE SOFTWARE
O especialista apresentará os tipos de métricas utilizadas em sistemas de software, de acordo com diferentes critérios
de classificação.
VERIFICANDO O APRENDIZADO
1. SOBRE AS MÉTRICAS DIRETAS E INDIRETAS, ASSINALE A ALTERNATIVA CORRETA.
A) As métricas diretas são derivadas a partir de outras métricas e são mais complexas de serem obtidas.
B) A quantidade de linhas de código, o número de defeitos e o custo do software são exemplos de métricas indiretas.
C) As medidas diretas são mais fáceis de serem obtidas, pois podem ser obtidas a partir da observação direta dos
atributos envolvidos.
D) A complexidade ciclomática é um exemplo de uma métrica indireta e mede a quantidade de caminhos de execução
dependentes a partir do código fonte.
E) Qualidade, confiabilidade, eficiência e capacidade de manutenção são exemplos de métricas diretas.
2. NO CONTEXTO DA ENGENHARIA DE SOFTWARE, AS MÉTRICAS DE SOFTWARE SÃO
DIVIDIDAS EM MÉTRICAS DE PROCESSO, MÉTRICAS DE PROJETO E MÉTRICAS DE
PRODUTO. SOBRE ESSAS MÉTRICAS, ASSINALE A ALTERNATIVA CORRETA.
A) As métricas de processo são usadas com finalidade tática, visando obter o benefício de seu uso nos projetos
correntes.
B) Modelos como o CMMI (Capability Maturity Software Integration ou Modelo Integrado de Maturidade em
Capacitação) e o MPS-BR (Melhoria de Processo de Software Brasileiro) apresentam um conjunto de boas práticas de
melhoria de processo de software.
C) As métricas de projeto são usadas com finalidade estratégica, visando obter os benefícios de seu uso em todos os
projetos da organização.
D) As métricas de produto são usadas para avaliar se o projeto está seguindo o cronograma conforme foi estimado na
etapa de planejamento e se está dentro do orçamento proposto no início do projeto.
E) Taxa de produção, horas de revisão e tamanho são exemplos de métricas de processo.
GABARITO
1. Sobre as métricas diretas e indiretas, assinale a alternativa correta.
A alternativa "C " está correta.
 
As métricas diretas são mais fáceis de serem obtidas, pois, assim como ocorrem com as métricas que são utilizadas
para observar os fenômenos da natureza como massa, tensão elétrica, temperatura etc., são obtidas a partir da
simples observação dos atributos envolvidos. Por exemplo, o número de linhas de código e o número de defeitos de
um software são métricas obtidas a partir de uma simples observação.
2. No contexto da Engenharia de Software, as métricas de software são divididas em métricas de processo,
métricas de projeto e métricas de produto. Sobre essas métricas, assinale a alternativa correta.
A alternativa "B " está correta.
 
Modelos como o CMMI e o MPS-BR vêm sendo adotados cada vez mais pelas empresas de Tecnologia da Informação
com o objetivo de atestar a qualidade e o nível de maturidade dos seus processos de desenvolvimento de software
MÓDULO 4
 Empregar métricas de software no acompanhamento da evolução de um projeto
O PROCESSO DE MEDIÇÃO DE SOFTWARE
Para entendermos como fazer o acompanhamento das métricas durante o ciclo de vida do software, iremos abordar
nesta seção os princípios e o funcionamento do processo de medição de software.
Um processo de medição é o conjunto de atividades repetitivas aplicadas a um processo existente, com o objetivo de
extrair métricas e indicadores a partir dos resultados obtidos dos processos medidos.

Basicamente, a mediçãopode ser um conjunto de atividades de um processo existente ou ser um processo mais
amplo que envolve medir outras atividades. Seu objetivo principal é prover informação relevante e confiável para
permitir o gerenciamento do processo alvo.
Um processo de medição pode ser caracterizado por cinco atividades: formulação, coleta, análise, interpretação e
feedback (realimentação).
FORMULAÇÃO
A formulação consiste na derivação de medidas e métricas de software adequadas para a representação do software
considerado.
COLETA
A coleta consiste no mecanismo usado para acumular os dados necessários.
ANÁLISE
A análise consiste no cálculo de métricas e aplicação das ferramentas matemáticas.
INTERPRETAÇÃO
A interpretação consiste na avaliação das métricas em um esforço para ganhar profundidade na visão da qualidade de
representação.
FEEDBACK
O feedback (realimentação) consiste nas recomendações derivadas da interpretação das métricas de produto
transmitidas à equipe de software.
O processo de medição de software é um processo cíclico e que envolve: planejar, medir, analisar os dados, tomar
decisões baseadas na análise, implementar as decisões e voltar a planejar e medir.
Um processo de medição deve fornecer uma base para a melhoria contínua do processo, quantificar a qualidade e
produtividade, estar integrado com o ciclo de vida de desenvolvimento e medir o impacto de vários métodos,
ferramentas e técnicas de melhorias.
A figura abaixo ilustra como esse processo é realizado no PSM, à semelhança do clássico ciclo P-D-C-A (do inglês
Plan – Do – Check – Act, ou seja, Planeje – Faça – Avalie – Aja).
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
 
Imagem: PSM, 2011 / SEBoK / CC-BY-NC SA 3.0, adaptada por Gian Corapi
Os princípios do processo de medição do software são:
1
Medições devem ter seu uso focado para medir processos.
O processo de medição deve ter propósitos bem definidos.
2
3
O processo de medição deve ser solidamente ligado ao processo de gerência da qualidade e integrado a planos e
orçamentos.
O processo de coleta de dados deve ser simples e utilizar ferramentas automáticas para extração de dados.
4
5
As medições devem ser repetíveis independentemente do observador.
O processo de medição é contínuo e sujeito à melhoria.
6
7
Os resultados das métricas devem ser compartilhados com os desenvolvedores.
Os principais problemas encontrados durante o processo de medição de software são:
OVERKILL 
(EXAGERO)
Consiste na coleta de muitos dados e em desperdício de esforço.
MEASUREMENT DYSFUNCTION (DISFUNÇÃO DE MEDIÇÃO)
Ocorre quando as métricas de dados reais podem se tornar problemáticas por causa do seu uso indevido e da
avaliação de pessoas, que pode variar de uma para outra.
MEASURAMENT MISMATCH (MEDIÇÃO INCOMPATÍVEL)
Consiste na derivação de medidas erradas, ambíguas ou inconsistentes.
PROCCESS MISMATCH (PROCESSOS INCOMPATÍVEIS)
Consiste em medidas que reforçam os processos errados.
CARACTERÍSTICAS DO PROCESSO DE MEDIÇÃO
Um processo de medição deve atender a todos os itens a seguir para se tornar eficiente e eficaz:
Melhorar a rapidez na obtenção de métricas e indicadores do processo medido, ou seja, deve promover um
aumento na velocidade que levamos para recuperar, analisar e demonstrar os resultados das medições.
Garantir a confiabilidade dos resultados obtidos, prevendo etapas de verificação e validação dos dados obtidos, de
forma a tentar eliminar possíveis distorções resultantes de dados “poluídos”.
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
Garantir que a coleta dos dados seja obtida da maneira mais direta possível, isto é, procure maneiras de
automatizá-la usando ferramentas nas quais os dados são colhidos diretamente da execução dos processos.
Garantir que o armazenamento dos dados seja feito de maneira controlada, ou seja, é necessário controlar quem
registrou, quando registrou, quando alterou e outras informações relevantes que permitam rastrear a origem do dado.
Garantir que os resultados sejam formatados e apresentados de maneira apropriada, usando gráficos,
histogramas, linguagem do público-alvo e outros recursos que permitam a comparação dos resultados.
Garantir a correta contextualização e interpretação, de modo que as informações apresentadas possuam atributos
que facilitem a comunicação com o público-alvo e que identifiquem sobre o que se está falando.
Garantir a segurança da informação, evitando que dados sensíveis da empresa caiam em mãos erradas, como, por
exemplo, um cenário de corte de recursos que a empresa esteja planejando, com base nos resultados obtidos.
Promover a melhoria contínua do processo medido, ou seja, se os resultados obtidos e apresentados não são
utilizados ou não permitem que possamos avaliar se o processo medido necessita ou não de mudanças, todo esforço
de medição foi em vão.
PERSPECTIVAS
Para medir um processo de software, cinco perspectivas podem ser adotadas, como perguntas a serem respondidas,
de maneira que se possa englobar tudo o que se pode medir:
PERFORMANCE
O que o processo está produzindo agora, de acordo com os atributos de qualidade, quantidade, custo e tempo?
ESTABILIDADE
O processo que estamos medindo está se comportando de maneira previsível?
CONFORMIDADE
O processo é suportado de maneira suficiente? Ele é executado de maneira fiel? A maturidade da empresa é
adequada para a execução do processo?
CAPACIDADE
O processo é capaz de entregar os produtos que atendem aos requisitos? A performance do processo atende às
necessidades de negócio da empresa?
MELHORIA
O que podemos fazer para melhorar a performance do processo? O que podemos fazer para reduzir a variabilidade?
Como podemos elevar as médias para níveis mais rentáveis? Como podemos saber se as melhorias que implantamos
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
estão funcionando?
As perspectivas são grupos de métricas utilizadas para responder a perguntas específicas, de um ponto de vista
comum, relativas ao processo medido.
INDICADORES DE PERFORMANCE
A perspectiva de performance agrupa os indicadores para medir os resultados do processo, utilizando valores
históricos para saber como o processo se comportou no passado, comparando os resultados atuais e podendo, em
certas condições, indicar uma previsão de resultados futuros.
Os indicadores de performance devem satisfazer os seguintes critérios para serem considerados bem definidos:
COMUNICAÇÃO
As métricas de performance devem:
 estar fortemente relacionadas à questão estudada;
 ter alto conteúdo informativo;
 refletir a realidade;
 permitir e facilitar a coleta de dados;
 ter os dados coletados bem definidos;
 demonstrar variações mensuráveis;
 demonstrar um valor diagnóstico, indicando a causa do problema.
REPETIÇÃO
Garantir que, se outra pessoa repetir a medição, obtenha os mesmos resultados.
RASTREABILIDADE
Garantir que os dados originais possuam atributos de rastreabilidade, como data, horário, atividade, sequência,
produto, projeto, status, ambiente, ferramentas utilizadas, responsável pela coleta etc.
Exemplos de indicadores de performance são: estimativas de prazo, prazo real, estimativas de custo, custo real,
número de defeitos previstos, tamanho do software e produtividade.
MUDANÇA ORGANIZACIONAL
A implantação do processo de medição de software envolve muitos desafios com os quais muitas empresas terão que
aprender a lidar com a implantação do novo processo. Esses desafios envolvem mudança organizacional, ou seja,
mudanças no comportamento da empresa.
A mudança organizacional geralmente ocorre em resposta a pressões externas ou internas. Conduzir uma boa
mudança organizacional faz parte do que chamamos de gestão de mudanças.

Pequenas empresas comerciais precisam se adaptar para sobreviver contra concorrentes maiores. Elas também
precisam aprender a prosperar nesse ambiente. Os grandesrivais precisam se adaptar rapidamente quando um
concorrente menor e inovador entra em cena.

Para evitar ficar para trás, ou para permanecer um passo à frente de seus rivais, uma empresa deve buscar maneiras
de operar com mais eficiência. Também deve se esforçar para operar de maneira mais econômica.
Os elementos da mudança são: visão, habilidades, incentivos, recursos e plano de ação.
Para entendermos como implementar a mudança organizacional, iremos dividir os tipos de medições em estratégicas e
táticas. As medições estratégicas estão alinhadas com as metas da empresa, enquanto as medições táticas estão
alinhadas com as metas operacionais e com as decisões técnicas.
Os tipos de dados que nos dão a sensibilidade sobre as medidas estratégicas e táticas são agrupados nas seguintes
categorias: hard, soft e padronização. Os tipos de dados hard são quantitativos, empíricos e numéricos, enquanto os
tipos de dados soft são qualitativos, baseados em julgamentos e opiniões, e, por fim, os tipos de dados padronização
criam métricas padrões que podem ser calculadas para diferentes situações. A tabela a seguir mostra medidas
eficazes que podem nos auxiliar a implementar a mudança organizacional.
Tipo de dados Medidas estratégicas Medidas táticas
Hard Estudos de mercado Número de profissionais por tarefa
Estudos de lucratividade Esforço por atividade ou tarefa
Custos anuais de software Custos por atividade ou tarefa
Custos anuais de hardware Projetos entregues
Custos anuais de pessoal Taxas de produção do staff
Soft Objetivos executivos Efetividade de ferramentas
Cultura corporativa Utilidade de métodos
Análise competitiva Habilidades de profissionais
Padronização Total de pontos de função Tamanho do projeto
 Atenção! Para visualizaçãocompleta da tabela utilize a rolagem horizontal
 Quadro: Medidas estratégicas e táticas do processo de medição de software 
Elaborado por: Bruno Freitas Braga.
MÉTRICAS E MEDIDAS EM ENGENHARIA DE
SOFTWARE
O especialista apresentará conceitos sobre métricas e medidas em sistemas de software, ressaltando a sua
importância no ciclo de vida dos sistemas.
VERIFICANDO O APRENDIZADO
1. SOBRE O PROCESSO DE MEDIÇÃO DE SOFTWARE, PODEMOS AFIRMAR:
A) Medições devem ter seu uso focado para medir projetos.
B) Pode ser caracterizado por cinco atividades: formulação, coleta, análise, interpretação e feedback .
C) No processo de medição, as métricas são definidas no início do projeto, não havendo a necessidade de reavaliá-las,
pois a avaliação já foi realizada durante a definição das métricas.
D) Durante a atividade de feedback ou reavaliação, as métricas são compartilhadas apenas entre os profissionais
envolvidos no gerenciamento de projetos.
E) O processo de medição deve avaliar somente os projetos concluídos a fim de determinar quais métricas serão
utilizadas nos novos projetos.
2. A MUDANÇA ORGANIZACIONAL É UM DOS PRINCIPAIS DESAFIOS PARA IMPLEMENTAR
O PROCESSO DE MEDIÇÃO DE SOFTWARE. SOBRE ESSA AFIRMATIVA, ASSINALE A
ALTERNATIVA CORRETA.
A) A mudança organizacional está alinhada apenas com as metas operacionais e técnicas da empresa, como a
medição da efetividade de ferramentas.
B) Para entendermos o processo de mudança organizacional, devemos primeiro classificar os tipos de dados em hard,
soft e padronização e derivar medidas eficazes a partir deles.
C) O processo de mudança organizacional deve ser baseado nas opiniões dos especialistas que fazem uma avaliação
da situação e determinam as mudanças eficazes.
D) As medições estratégicas estão alinhadas com as metas operacionais durante a implementação do processo de
mudança organizacional.
E) Os dados qualitativos são suficientes para a definição das medidas estratégicas e táticas.
GABARITO
1. Sobre o processo de medição de software, podemos afirmar:
A alternativa "B " está correta.
 
O processo de medição é caracterizado por cinco atividades, e na atividade de formulação são derivadas as medidas e
métricas adequadas para o software, enquanto na coleta são criados os mecanismos para acumular os dados
necessários. Já na análise ocorre o cálculo das métricas, e na interpretação é realizada a análise dos resultados, para
dar o feedback à equipe.
2. A mudança organizacional é um dos principais desafios para implementar o processo de medição de
software. Sobre essa afirmativa, assinale a alternativa correta.
A alternativa "B " está correta.
 
A partir da classificação dos dados em hard (dados quantitativos), soft (dados qualitativos) e padronização (métricas
padrões), as medidas estratégicas e táticas necessárias para o processo da mudança organizacional são definidas e
implementadas durante o processo de medição de software. Durante o processo de medição, as medidas são
avaliadas quanto à sua eficácia.
CONCLUSÃO
CONSIDERAÇÕES FINAIS
Como vimos, as métricas de software ajudam as empresas a compreenderem melhor os seus processos, projetos e
produtos. Com um entendimento mais claro sobre os requisitos de seus projetos, os gerentes de projetos conseguem
fazer estimativas de esforço, prazo e custos mais precisas.
Foram apresentados os conceitos de medida, medição e métrica, a fim de se obter um entendimento claro sobre o
papel de cada um desses conceitos com o intuito de facilitar a análise dos dados obtidos nos registros históricos dos
projetos e avaliá-los.
Verificamos que existem modelos para a definição de métricas, como o GQM (Goal/Question/Metrics ) e o PSM
(Practical Software Systems Measurement ), que nos apoiam na determinação das melhores métricas a serem
utilizadas na organização.
Analisamos as métricas de tamanho como LOC (linhas de código) e PF (pontos de função) e verificamos como derivar
indicadores a partir delas com o objetivo de planejar e controlar melhor os nossos projetos.
Vimos que as métricas de processo permitem que a organização tenha uma visão estratégica, fornecendo informações
sobre a eficiência de um processo de software, em conformidade com seus objetivos e suas metas.
Por fim, compreendemos como funciona o processo de medição de software para o acompanhamento das métricas
durante o ciclo de vida de desenvolvimento do software.
AVALIAÇÃO DO TEMA:
REFERÊNCIAS
JONES, C. L. et al . Practical software and systems measurement continuous iterative development
measurement framework. 2021. Consultado na internet em: 30 jun. 2021.
PARK, R. E.; GOETHERT, W. B.; FLORAC, W. A. Goal driven software measurement – a guidebook. CMU/SEI-96-
BH-002, Software Engineering Institute, Carnegie Mellon University, 1996. Consultado na internet em: 30 jun. 2021.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH,
2016.
THE STANDISH GROUP. CHAOS Manifesto 2013. Consultado na internet em 30 jun. 2021.
VAZQUEZ, C. E.; SIMÕES, G. S.; ALBERT, R. M. Análise de pontos de função: medição, estimativas e
gerenciamento de projetos de software. 13. ed. São José dos Campos: Érica, 2013.
EXPLORE+
Pesquise o artigo intitulado Software modeling and measurement: The Goal/Question/Metric paradigm e veja como
Victor R. Basili apresentou um modelo bastante ilustrativo e útil no processo de identificação das características de
uma métrica.
CONTEUDISTA
Bruno Freitas Braga