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 desenvolvimento de um projetoComo 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 aplicativo móvel, e que não possuiuma 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 tabelaacima, é 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 apresentandoos 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últiplas linhas;
 Inclusão na contagem de delimitadores de blocos de comandos nos casos emque, 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ção pode ser um conjunto de atividades de um processo existente ou ser um processo mais amplo que envolvemedir
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.
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
javascript:void(0)
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).
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.
javascript:void(0)
javascript:void(0)
javascript:void(0)
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”.
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.
javascript:void(0)
javascript:void(0)
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
javascript:void(0)
javascript:void(0)
javascript:void(0)
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 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:
javascript:void(0)
javascript:void(0)
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 grandes rivais precisam se adaptar rapidamente quando um concorrente menor e inovador entra emcena.

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