Palestra ministrada na Semana de Tecnologia da Faculdade Joaquim Nabuco - Campus Olinda em 22/10/2015.

1. Métricas de Software: modelos de
contratação e planejamento de
projetos
José Claudemir Pacheco
Júnior
MSc, AGTIC
jcpacheco.junior@gmail.com
Palestra ministrada na Semana de
Tecnologia da Faculdade Joaquim
Nabuco – Campus Olinda em
22/10/2015

2. Agenda
Introdução
Métricas de Software
Modelos de Contratação de Serviços de
Software
Visão Geral da Análise de Pontos de Função
APF no Planejamento de Projetos
Conclusão

3. Introdução
Engenharia de Software: produzir
sistemas de software de maneira
controlada, quantificada e previsível;
Mais da metade de grandes projetos de
software se deparam com algum tipo de
atraso, excesso de custo ou prazo ou
mesmo fracasso total
(cf. Chaos Report, Standish Group)
“Não se pode gerenciar o
que não se pode medir” (Tom
De Marco)

4. Introdução
Por quê medir software?
• Entender e aperfeiçoar o processo de
desenvolvimento
• Melhorar a gerência de projetos e o
relacionamento com clientes
• Reduzir frustrações e pressões de
cronograma
• Gerenciar contratos de software
• Indicar a qualidade de um produto de software
• Avaliar a produtividade do processo

5. Introdução
Por quê medir software?
• Avaliar os benefícios (em termos de produtividade
e qualidade) de novos métodos e ferramentas
de engenharia de software
• Avaliar retorno de investimento
• Melhorar a exatidão das estimativas
• Oferecer dados qualitativos e quantitativos ao
gerenciamento de desenvolvimento de software,
de forma a realizar melhorias em todo o
processo de desenvolvimento de software

6. Introdução
Principais papéis de Medições de Software, de
acordo com Humphrey:
Processos,
Produtos e
Serviços de
Software
Entender
Avaliar Prever
Controlar

7. Métricas de Software

8. Métricas de Software
Medição de um atributo (propriedades ou
características) de uma determinada entidade (produto,
processo ou recursos) de software. Exemplos:
• Tamanho do produto de software (ex: nº de linhas de código,
nº de casos de uso)
• Número de pessoas necessárias para implementar um caso
de uso
• Número de defeitos encontrados por fase de desenvolvimento
• Esforço para a realização de uma tarefa
• Tempo para a realização de uma tarefa
• Custo para a realização de uma tarefa
• Grau de satisfação do cliente (ex: adequação do produto ao
propósito, conformidade do produto com a especificação)

9. Métricas de Software
Uma métrica deve ser:
• Expressa em alguma unidade
• Válida: quantifica o que queremos
medir
• Confiável: produz os mesmos
resultados dadas as mesmas condições
• Prática: barata, fácil de calcular,
entender e testar

10. Métricas diretas
• Medida realizada em
termos de atributos
observados
• Ex.: custo, esforço, nº
de linhas de código, nº
de casos de uso, nº de
diagramas, nº de
requisitos funcionais, nº
de erros por fase etc.
Métricas
indiretas
• Medidas obtidas a
partir de outras
métricas
• Ex.: complexidade,
eficiência,
confiabilidade,
facilidade de
manutenção etc.
Métricas de Software –
Categorização

11. Métricas orientadas a
tamanho
• Medidas diretas do
tamanho dos artefatos
de software associados
ao processo por meio
do qual o software é
desenvolvido.
• Ex.: esforço, custo, nº
de páginas de
documentação, nº de
erros, nº de linhas de
código
Métricas orientadas por
função
• Medição de software do
ponto de vista do
usuário, determinando
de forma consistente o
tamanho e a
complexidade de um
software
Métricas de Software –
Categorização

12. Métricas de
produtividade
• Concentram-se
na saída do
processo de
engenharia de
software.
• Ex.: nº de casos
de uso por
iteração
Métricas de
qualidade
•Oferecem uma
indicação de
quanto o software
se adequa às
exigências
implícitas e
explícitas do
cliente.
•Ex.: nº de erros por
fase
Métricas
técnicas
•Concentram-se nas
características do
software e não no
processo por meio do
qual o software foi
desenvolvido.
•Ex.: complexidade
lógica, reusabilidade,
facilidade de
manutenção
Métricas de Software –
Categorização

13. Comparar a produtividade de engenheiros
de software em termos de linha de código
• Está sendo utilizado a mesma unidade de
medida?
• O que é uma linha de código válida?
• O contexto considerado é o mesmo?
• Mesma linguagem de programação?
• Mesmo framework e bibliotecas?
• O que se quer realmente é o tamanho do
código?
• E a qualidade do código?
Métricas de Software –
Dificuldades

14. Modelos de Contratação de
Serviços de Software

15. Modelos de Contratação de
Serviços de Software
Terceirização de Serviços de TI
• A década de 90 foi caracterizada no Brasil pela
terceirização, inclusive em TI
• Até então o desenvolvimento e manutenção de
sistemas era executado por equipes internas
(analistas de sistemas e programadores)
• Atualmente as organizações buscam manter a sua
equipe de TI com foco no seu negócio principal
(analistas de negócio) e contratam fornecedores
especializados para execução dos serviços

16. Homem-
Hora
Preço
Fixo
Preço
Unitário
Modelos de Contratação de
Serviços de Software

17. Contratação por Homem-Hora
• Serviços (nem sempre projetos) executados pela alocação
de profissionais terceirizados
• Remuneração pela qualificação da equipe e esforço gasto
• Contrato de gestão mais simples
• Agilidade na resposta à mudanças de requisitos
• Não demanda negociação contratual
• Remuneração desvinculada dos resultados entregues
• Antítese da produtividade
• Custo do projeto é orientado pelos aspectos internos do
trabalho (quanto de esforço e nível de especialização).
Estes aspectos estão sob controle do fornecedor
Modelos de Contratação de
Serviços de Software

18. Contratação por Preço Fixo
• Custo do projeto definido em função do escopo apresentado pelo
cliente
• Escopo precisa ser bem definido
• Preço embute risco do escopo
• Previsibilidade de custo (?)
• E se o preço foi mal estabelecido?
• E se o escopo mudar?
• O “fixo” torna-se variável e leva a nova negociação, mas em que
condições?
• Como trabalhar num preço fixo e escopo fechado se a única certeza
sobre um projeto de software é que mudanças de requisitos irão
ocorrer?
Modelos de Contratação de
Serviços de Software

19. Contratação por Preço Unitário
• Quando a unidade de remuneração representa uma entrega de valor
para o cliente, há mais equilíbrio entre riscos e responsabilidades entre
cliente e fornecedor
• Produtividade e qualidade Fornecedor
• Escopo Cliente
• O desafio é ter uma unidade que seja:
• Medida de forma consistente e uniforme
• Orientada ao negócio do cliente
• Auditável
• Vinculada dos resultados entregues
• Uma solução: adotar Pontos de Função para medir projetos de software
Modelos de Contratação de
Serviços de Software

20. Visão Geral da Análise de
Pontos de Função

21. Visão Geral da Análise de
Pontos de Função
Surgiu na
IBM no início
da década de
1970 com
Allan
Albrecht,
como
alternativa às
métricas
baseadas em
linhas de
código
Fundação
do
Internation
al
Function
Point User
Group
(IFPUG)
em 1986
Publicação
em 1988
da versão
2.0 do
Manual de
Práticas
de
Contagem
(CPM)
Publicação
em 1990
da versão
3.0 do
Manual de
Práticas
de
Contagem
(CPM)
A versão
mais atual
do CPM
(4.3.1) foi
publicada
em janeiro
de 2010
Históric
o

22. Perspectivas
• O uso da técnica de APF começou significativamente no Brasil no
início da década de 90
• Difusão consistente e crescente
• A partir de 2008, a adoção ao uso de PFs acelerou-se no Governo
Federal por causa da IN 04/2008
• TCU aponta Ponto de Função (PF) como sendo a unidade mais
adequada para determinar o tamanho de qualquer sistema de
informação
• Governos estaduais e municipais tem seguido a mesma diretriz
• O mercado privado também vem usando o processo: Bradesco,
OI, TAM, BM&FBOVESPA, Porto Seguro, Redecard, Cielo, ONS,
Totvs
• Brasil é o país com maior quantidade de usuários da APF
Visão Geral da Análise de
Pontos de Função

23. APF: Técnica de medição das funções (requisitos funcionais)
de um software sob o ponto de vista do usuário
• Usuário é qualquer pessoa ou coisa que se comunica ou interage
com o software a qualquer momento
• Ponto de Função (PF) é a sua unidade de medida
• Medição independente da tecnologia utilizada na construção do
software
• Mede o que o software faz, e não como ele foi construído
A medição é baseada em uma avaliação padronizada dos
requisitos funcionais do usuário, definida pelo IFPUG
• Pode ser feita por qualquer profissional, não restrito à área de TI
• Processo de medição pode ser aprendido em dois dias de treinamento
APF permite não só medir o tamanho do sistema em termos da funcionalidade fornecida
ao usuário, mas também estimar seu tamanho em qualquer fase do seu ciclo de vida,
mesmo que os requisitos ainda não tenham sido detalhados
Visão Geral da Análise de
Pontos de Função

24. • Solicitadas e recebidas pelo usuário do software
• De projetos de desenvolvimento e melhoria de software de
forma independente de sua implementação, e de aplicações já
implementadas (inventário de software)
Medir Funções:
• Consistente: pessoas diferentes medindo devem chegar ao
mesmo resultado
• Simples: o esforço de medição deve onerar o mínimo o esforço
total do projeto
• Clara: entendida pelo cliente e pelo fornecedor
Ser um método de medição:
Objetivos da APF
Visão Geral da Análise de
Pontos de Função

25. A análise “quebra” o sistema em
funções que:
• Permitem ao usuário interagir com o sistema – Funções de Transação
• E armazenar dados – Funções de Dados
Atribui um peso (pontos de função) para cada uma delas
fronteira da aplicação
entradas externas
arquivos
de
interface
externa
consultas externas
Fatto Sistemas
__________________
Sumário Executivo de Projeto
Projeto : BR01020
Cliente : Banco Istabel
Base : 31/05/1998
Custos x Faturado
......................
......................
......................
......................
......................
......................
......................
saídas externas
arquivos lógicos internos
Visão Geral da Análise de
Pontos de Função

26. CE
EE
ALI
EE
SE
Cada função identificada é
classificada quanto ao tipo e à
complexidade
Visão Geral da Análise de
Pontos de Função

27. Pontos de função não medem diretamente esforço, produtividade ou
custo. É exclusivamente uma medida de tamanho funcional do
software. Este tamanho em conjunto com outras variáveis é que pode ser
usado para derivar produtividade, estimar esforço e custo
Requisitos não funcionais são desconsiderados na
medição de PFs
• Tecnologia: sistema operacional, linguagem de programação, etc
• Qualidade: performance, usabilidade, portabilidade, etc
• Padrões: interface, segurança, auditoria, etc
Manutenções que não alteram funções não são medidas
em PF
• Em contratos por PF, o que a APF não mede pode afetar o R$/PF ou
ser alvo de uma métrica diferente
Visão Geral da Análise de
Pontos de Função
Restrições da APF

28. Uma ferramenta para determinar o tamanho de um pacote
adquirido pela contagem de todas as funções
incluídasPermite avaliar o impacto da introdução de mudanças
no processo de desenvolvimento de software (novas ferramentas,
métodos, etc.)Contribui para uma comunicação mais efetiva entre
usuário x desenvolvedor
Suporta a análise de produtividade e qualidade, seja
diretamente ou em conjunto com outras métricas como
esforço, defeitos e custo
Apoia o gerenciamento de escopo de projetos
Complementa o gerenciamento dos requisitos ao
auxiliar na verificação da solidez e completeza dos requisitos
especificados
Visão Geral da Análise de
Pontos de Função
Benefícios da adoção da APF

29. Permite remunerar o fornecedor do desenvolvimento e
manutenção de software pelos resultados entregues (funções do
sistema), não pelo esforço gasto (Homem-Hora)
Provê auxílio aos usuários na determinação dos benefícios de um pacote
para sua organização através da contagem das funções que
especificamente correspondem aos seus requisitos (make or buy)
Um meio para estimar custo e recursos para o
desenvolvimento e manutenção de software
Um fator de normalização para comparação de software
ou para comparação da produtividade na utilização de
diferentes técnicas
Uma ferramenta para fundamentar a negociação
de contratos
Visão Geral da Análise de
Pontos de Função
Benefícios da adoção da APF

30. Usado por milhares de organizações no
Brasil e no mundo, o que aumenta a
possibilidade de benchmarking
Suportado por uma organização de alcance
mundial (IFPUG)
Aplicável a todos os tipos de software
Aplicável a todas as fases de um projeto
de software, inclusive nas fases iniciais
Visão Geral da Análise de
Pontos de Função
Benefícios da adoção da APF

31. Visão Geral da Análise de
Pontos de Função
Quanto custa (R$) 1 PF?

32. Não existe uma tabela padrão de preços do PF
Os preços normalmente são estabelecidos em
função de:
• Concorrência
• Contexto no qual o serviço será executado (requisitos técnicos, de qualidade,
padrões, grau de complexidade, quantidade de artefatos entregáveis etc)
Tudo o que não é diretamente medido pelos PFs afetará o
R$/PF
Ou seja, quanto mais alta são as exigências técnicas e de qualidade,
maior tende a ser o R$/PF
• Por exemplo: um apto de 100 m2 ficará mais caro com um acabamento de alto
luxo, mas continuará tendo 100 m2
Visão Geral da Análise de
Pontos de Função
Quanto custa (R$) 1 PF?

33. • Uma tela de cadastro (inclui, altera, exclui e consulta) possui em
torno de 30 PFs
• Um relatório pode ter de 3 a 7 PFs
Para melhor entender o que representa o volume em PFs:
Organização Ano Volume (PF)/ano R$/PF
ATI-PE 2011 25.300 352
Caixa Econômica Federal 2010 2.000 900
Conselho Nacional de Justiça 2010 40.000 383
Eletrobrás 2009 12.000 542
Emprel 2011 15.000 846
Ministério da Educação 2010 31.200 352
Ministério da Fazenda 2010 14.500 217
Ministério da Justiça 2009 21.400 476
Polícia Federal 2010 10.000 415
Supremo Tribunal Federal 2009 11.000 398
TJ-PE 2011 2.000 322
Fonte: http://fattocs.com/pt/recursos/editais
Visão Geral da Análise de
Pontos de Função
Quanto custa (R$) 1 PF?

34. APF no Planejamento de
Projetos

35. APF no Planejamento de
Projetos
Estimar tamanho do software (Fase de Concepção)
Medir tamanho do software (Fase de Elaboração)
Medir produtividade da equipe (Horas / PF)
Estimar esforço em horas (PF * Produtividade)
Estimar capacidade de produção da equipe (PF/Homem-Mês)
Quando aplicado adequadamente, o processo de
medição por pontos de função possibilita:

36. Estimar prazo do projeto (Tamanho + Produtividade + Nº
de Colaboradores)
Estimar custo para o projeto (PF Estimado * Custo PF)
Medir indicador de qualidade por projeto (Defeitos / PF)
Apoiar o gerenciamento de escopo do projeto
• Estabilidade dos requisitos = PFatual / PFinicial
• Baseline da organização
• Tamanho do backlog = ∑ PF Projetos
APF no Planejamento de
Projetos
Quando aplicado adequadamente, o processo de
medição por pontos de função possibilita:

37. APF no Planejamento de
Projetos
Os indicadores de
projetos passados
auxiliam no planejamento
de novos projetos
similares
A utilização de
benchmarking também
pode servir de referência
para estimar o esforço de
um novo projeto
Programming
Language N Min P10 P25
Media
n P75 P90 Max Mean StDev
ABAP 5 8.0 - 13.3 13.8 18.0 - 24.3 15.5 6.1
ACCESS 28 0.3 0.5 1.1 2.0 - 5.5 27.0 3.3 5.1
C 27 2.8 6.4 8.5 14.9 19.8 27.4 41.4 15.6 8.9
C++ 20 1.2 5.9 9.3 17.4 24.4 42.3 69.3 21.2 16.9
COBOL 64 1.2 5.2 9.4 16.0 26.0 42.4 69.7 20.1 15.2
JAVA 10 5.3 6.6 14.7 19.6 26.7 67.8 68.2 26.8 22.8
NATURAL 21 2.3 4.8 5.7 9.6 13.7 33.0 42.0 12.7 11.1
ORACLE 49 1.2 3.0 6.0 10.3 15.9 28.1 78.1 13.4 12.9
VISUAL BASIC 54 0.4 2.7 3.8 7.5 14.0 37.2 68.0 13.3 14.9
Fonte ISBSG: The Software Metrics Compendium – 2002
Estatísticas quanto à produtividade (H/PF) por linguagem de prog

38. Conclusão

39. A utilização de métricas e indicadores permite padronizar a
precificação e contratação de software, além de fornecer
informações relevantes para o planejamento de projetos de software
APF surge como uma técnica robusta para medir software com
fundamento na visão de negócio, provendo maior aproximação entre
a área de TI e a área de negócio
APF apoia de maneira significativa a gestão do processo de
contratação ou desenvolvimento de software
O modelo de contratação de software por PF possibilita:
• Aumento na vazão das demandas (interesse do fornecedor é maximizar
as entregas e com isso seu faturamento)
• Redução de custos (correção de defeitos e improdutividade é ônus do
fornecedor)
• Melhoria na qualidade de requisitos dos projetos, gerando menos
retrabalho (a APF ajuda indiretamente a verificar e validar requisitos)
• Visibilidade dos resultados entregues no serviço
Conclusão

41. Métricas de Software: modelos de
contratação e planejamento de
projetos
José Claudemir Pacheco
Júnior
MSc, AGTIC
jcpacheco.junior@gmail.com