UNIVERSIDADE ESTÁCIO DE SÁ

MÉTRICAS DE SOFTWARE

André Ezías

São Paulo (2017)

 SUMÁRIO
INTRODUÇÃO 2

ENGENHARIA X MÉTRICAS 2

PLANEJAMENTO X REALIDADE 2

A QUALIDADE VOLTADA PARA O USUÁRIO 3

ANÁLISE DE PONTOS POR FUNÇÃO 3

Vantagens x Desvantagens 4
Elementos levados em consideração 4
Componentes funcionais básicos 4

CALCULANDO PONTOS POR FUNÇÃO 5

Exemplo 5
Usando um case real 7

APROFUNDANDO MAIS SOBRE O ASSUNTO 8

CONCLUSÃO 9

REFERÊNCIAS 10

DIFICULDADES 11

LIÇÕES APRENDIDAS 11

1
INTRODUÇÃO

Neste trabalho pretendo destacar a necessidade de os profissionais de engenharia de software

aprimorarem sua visão e prática para melhorar softwares para atender um mercado cada vez
mais exigente e de rápida expansão.
Falaremos sobre métricas que ajudam a mapear e definir quais mudanças precisam ser feitas
e como podemos gerenciar um projeto de software.
Mencionaremos também casos em que as métricas foram utilizadas com sucesso e entender o
papel do engenheiro de software durante o processo.
A métrica que iremos destacar nestas linha é a análise de pontos por função que é bem
utilizada nos dias atuais e existe a possibilidade de obter certificações. A prática dessa
metodologia ajuda os profissionais da área a entregar valor e produtividade.

ENGENHARIA X MÉTRICAS

Criada para contornar a chamada Crise do software em 1961, a Engenharia de Software tem
como o objetivo de planejar, construir e fazer a manutenção de programas de computador
com qualidade a fim de atender às necessidades específicas de cada organização.
Para tratarmos de qualidade é imprescindível termos métricas que definem a qualidade do
software, o custo do desenvolvimento e o prazo de entrega, pois a final, todos esses itens
influenciam diretamente na qualidade do software como um todo.
Atualmente o mercado exige que façamos programas mais sofisticados, com curto prazo,
orçamentos apertados e alta usabilidade. Isso reforça a importância de termos métricas que
nos ajudam a determinar o quão viável será o projeto para uma organização.
Portanto o engenheiro de software deve estar atualizado no tocante à atualização de
ferramentas que ajudam a controlar o processo como um todo e também nos seus mínimos
detalhes.
Sabemos que todo projeto deve ser gerenciável e que não é possível gerenciar o que não se
pode medir.

PLANEJAMENTO X REALIDADE

Um dos grandes vilões dos orçamentos é a falta de cumprimento de prazos de entrega ou alto
custo na manutenção de um software. Muitos projetos se tornam obsoletos antes mesmo de

2
estarem prontos, o que aumenta muito os custos de estrutura e mão de obra. Dessa maneira a
relação com o cliente fica deteriorada e muitas vezes o projeto é cancelado em pleno
desenvolvimento.
Por isso desde o levantamento de requisitos devemos envolver métricas que nos aproxime da
realidade, baseando-se em dados históricos para aperfeiçoar as técnicas de desenvolvimento.
Muitos concordam que um software, por se tratar de um produto lógico, é muito difícil de
obter exatidões entre implementação e projeção, porém usando as métricas coerentes no
planejamento poderemos evitar erros catastróficos que podem arruinar todo o trabalho.

A QUALIDADE VOLTADA PARA O USUÁRIO

Toda organização exige de seus colaboradores que sejam produtivos em suas funções,
portanto temos que ter em mente que um software deve tornar a vida das pessoas mais
produtiva e quanto mais pudermos garantir a entrega do quê e quando o usuário precisa,
podemos dizer que estamos no caminho certo.
Como estamos lidando com produtividade, temos que entender o que isso significa quando
lidando com desenvolvimento e manutenção softwares. Como afirma Albrecht (1979),
produtividade é a razão entre bens ou serviços produzidos por unidades de tempo ou custo,
portanto temos dois tipos de variáveis para medir a produtividade: bônus (ativos) e ônus
(passivos).
A quantificação do ônus é mais simples pois temos grandezas mais tangíveis como custo ou
esforço, no entanto o bônus temos grandezas mais abstratas de se calcular como linhas de
códigos por exemplo. Temos diferentes números dependendo da linguagem que se utiliza
para executar as mesmas funções. Outra alternativa seria a contagem de quantidade de telas
que será disponibilizada ao usuário.
Para resolver essa discrepância em relação à mensuração de bônus o IFPUG ( International
Function Point Users Group) trouxe uma métrica pontos por funções que falaremos mais
adiante.
O que podemos concluir como qualidade voltada para o usuário é entregar mais do que o
usuário precisa com menos esforço, tempo e custo possível. Por isso mencionei a análise de
ponto por função,pois é uma técnica que mede as funções de um software do ponto de vista
do usuário.

ANÁLISE DE PONTOS POR FUNÇÃO

3
Pontos por função serve para medir o tamanho funcional de um software, essa métrica é
usada efetivamente para medir funcionalidades fornecidas por um sistema por meio de dados
históricos. É importante ressaltar que estruturas físicas ou aspectos de implementação não são
levadas em conta nessa métrica e sim tarefas e serviços, portanto com essa métrica teremos
uma medição em perspectiva de produto e de serviços.
É evidente que somente essa métrica não consegue administrar completamente um projeto de
software porém essa métrica tem sido usada por um número crescente de profissionais da
área.

Vantagens x Desvantagens
Vejamos as vantagens aplicadas :
● Pode ser feito logo no início do projeto;
● Determina o benefício de um pacote de aplicação para a organização;
● Permite medir as unidades de um produto de software;
● Vasto material publicado;
● Possibilita cálculos de custo e recursos necessários para a manutenção e
desenvolvimento.
Vejamos também algumas desvantagens :
● Contagem não pode ser facilmente automatizada;
● Faixas de complexidade de difícil adaptação para a realidade em alguns casos;
● Variantes do método.

Elementos levados em consideração

● Requisitos funcionais : a descrição do que o software deve fazer em termos de tarefas

e serviços;
● Ponto por função (PF): unidade de medida deste método;
● Usuário : qualquer pessoa ou coisa que se comunica com o software ( uma idéia muito
próxima ao ator utilizado em casos de uso);
Objetivo do processo de medição :

● Simplicidade : para minimizar o esforço aplicado para evitar o aumento de custos;

● Consistência : deve dar sempre o mesmo resultado mesmo quando medido por
pessoas diferentes.

Componentes funcionais básicos

Ao olhar os requisitos funcionais podemos dividi-los em componentes funcionais básicos (ou
funções) que permitem interação com o sistema e armazenamento de dados. Para
4
compreender melhor o como podemos organizar vamos considerar que um componente
funcional básico pode ser composto por :

● Interação ou Função de transação;

○ Entrada externa;
○ Saída externa;
○ Consulta externa;
● Armazenamento ou Função de Dados;
○ Arquivo lógico interno;
○ Arquivo de interface Externa;

Para quantificar cada um desses elementos vamos considerar a tabela de complexidade de

cada elemento. Cada elemento pode ter três níveis de complexidade portanto vamos ver a
tabela para termos uma noção :

Veja que para cada elemento a ser avaliado temos níveis de complexidade a considerar
(Baixo, Médio e Alto).

Resumidamente identificamos as funções presentes no software, definimos a complexidade

de cada uma e somamos os valores então teremos o PFNA (Pontos por função não
Ajustados).

CALCULANDO PONTOS POR FUNÇÃO

Inicialmente iremos para um exemplo fictício para entendermos a aplicação. Mais adiante
iremos aplicar nos baseando em um exemplo real.

Exemplo

Vamos considerar as seguintes funções :

● Listar usuários;

5
 ● Cadastrar novo usuário;
● Editar dados do usuário;
● Excluir cadastro.

Vamos agora eleger os tipos de funções. Então temos a tabela a seguir :

Função Tipo de Função

Listar usuários Saída externa

Cadastrar novo usuário Entrada externa

Editar dados do usuário Entrada externa

Excluir usuário Entrada Externa

Temos então :
● Saídas externas : 25% do total de PFs;
● Entradas externas: 75% do total de PFs.

Para simplificar vamos considerar a complexidade de todas as funções como média. Então
podemos preencher a tabela PF:

Tipo de Função Complexidade Funcional Total por tipo de função

Entradas Externas 4*4 16

Saídas Externas 1*5 5

Total PF Não Ajustados ( Fator de ajuste = 1) 21

A seguir iremos calcular o PFA (pontos por função ajustados) que procede da seguinte
maneira :
● PFA = PFNA * [0,65 + 0,01 * ∑ (Fi)] ;
○ PFNA é a contagem total de todas entradas de PF obtidas.
○ Fi (i = 1 a 14) : são fatores de ajuste de valor (VAF) baseada em 14 questões
que podem ser avaliadas de 0 ( Não importante ou não aplicável) a 5
(essencial);

Para prosseguir vamos considerar que as respostas às 14 perguntas foram de 38 vamos

prosseguir com o cálculo :

PFA = PFNA * [0,65 + 0,01 * ∑ (Fi)]

PFA = 24 * [0,65+0,01 * 38]

6
PFA = 24* 1,03
PFA = 24,72 ~= ​25

Usando um case real

Temos uma tela que deve fazer um CRUD de mercadorias em estoque. Vamos ver a tela :

A seguir vamos colocar as tabelas com as contagens :

FUNÇÕES DE TRANSAÇÕES

Funcionalidade Tipo Complexidade Pontos de Função

Consultar dados da Consulta externa Média 4

mercadoria

Incluir Mercadoria Entrada Externa Média 4

Alterar mercadoria Entrada Externa Média 4

Excluir mercadoria Entrada Externa Média 4

7
 FUNÇÕES DE DADOS

Arquivo Tipo Complexidade Pontos de Função

Mercadoria Arquivo Lógico Simples 7

Interno

Fornecedor Arquivo Lógico Simples 7

Interno

TOTAL DE PONTOS POR FUNÇÃO

Total de pontos por função não ajustados 4+4+4+4+7+7 = ​30

Fator de Ajuste 0,89

Total de pontos de função ajustados 30*0,89 = ​26,7

Consideremos uma equipe de 2 pessoas com uma produtividade média de 2hPF, com jornada
de 6h diárias e R$35,00/h de trabalho. Vamos estimar os valores:
● Esforço total em horas ;
○ 5hPF* 26,7PF = ​53,4h
● Prazo em dias;
○ 53,4/(2*6) = ​4,5 Dias
● Custo em R$;
○ 53,4*R$35,00 = ​R$1869,00

APROFUNDANDO MAIS SOBRE O ASSUNTO

A APF (Análise de pontos por unção) é uma das métricas que o profissional de engenharia de
software pode usar para a criação de um projeto, no entanto as referências dadas aqui são bem
superficiais, minha intenção aqui é fomentar o aprimoramento das técnicas de qualidade,
portanto devo mencionar que é possível obter uma certificação em Pontos por Função do
IFPUG. Este grupo é grande e sempre tem atualizado as técnicas de tempos em tempos.
Você pode encontrar mais informações em ​http://www.apfmetricas.com.br/​.

8
CONCLUSÃO

Somente com uma análise voltada ao usuário podemos entregar software de valor. Temos em
vistas que de forma alguma devemos deixar as métricas de lado mas devemos a dar atenção
para não cairmos em um ciclo onde só pensemos em melhorar os números das métricas mas
não deixamos os usuários satisfeitos. Então de posse desse conceito concluo que as métricas
são um meio importante mas nunca será um fim.

9
REFERÊNCIAS
Material de apoio Métricas de Software , Universidade estácio de Sá - Disponível em :
<​http://pos.estacio.webaula.com.br/Biblioteca/Acervo/Basico/POS716/Biblioteca_16565/Bibli
oteca_16565.pdf​>

O Que é Análise de Pontos de Função - Disponível em:

<https://www.youtube.com/watch?v=9N1FMXrB9Kk>

Análise de Pontos de Função – Medição e Estimativa de Software - Disponível em:

<​https://www.youtube.com/watch?v=KCsvYY4eASA&t=2231s​>

Estimativas de software usando pontos de função - Disponível em:

<​https://pt.slideshare.net/claudiomartins2000/estimativa-de-software-usando-pontosfuncao​>

10
DIFICULDADES

Ainda noto uma grande falta de exatidão em muitas métricas quando se trata de classificar o
tamanho ou complexidade de um projeto pois entendo que isso sofre alterações de parâmetros
quando se trata de profissionais com mais ou menos tempo de experiência, ou seja, o que
pode ser de grande complexidade para mim pode ter menos complexidade para um
profissional com mais experiência. Isso também se aplica à áreas de atuação do negócio, ou
seja, se o software será usado para pessoas do campo da medicina ou por pessoas do meio
jurídico. Acredito que só um conhecimento genérico sobre o assunto não é o suficiente para
captar a necessidade dos usuários. Um profissional que já desenvolveu aplicações para certas
áreas específicas já tem uma noção de como determinar a complexidade do software ao passo
que outro profissional que nunca desenvolveu para aquela área deverá ter em mente como
algo mais complicado.

LIÇÕES APRENDIDAS

Embora ter métricas voltada à itens menos tangíveis seja algo flutuante, a ausência de
métricas pode piorar muito mais a situação tornando o projeto obsoleto ou inviável em meio à
produção. Então aprendi que as métricas podem suavizar as curvas de erros e tornar a
aplicação mais confiável.
Aprendi que as métricas auxiliam nas negociações com os clientes quando se trata de
contratos e argumentação de custos pois não podemos superestimar e nem subestimar os
custos de uma aplicação dependendo de seu tamanho e complexidade.
Aprendi que tudo que é gerenciável deve ser mensurável pois se tratando de engenharia de
software, o controle do que se está fazendo e do que se pretende fazer depende das métricas.

11