Ponto de Função

Departamento de Computação
Trabalho de Conclusão de Curso
THEO IGNEZ PAVAN
O Uso de Análise de Pontos por Função no Planejamento

de Processo de Desenvolvimento de Software
Londrina
2004
THEO IGNEZ PAVAN
O Uso de Análise de Pontos por Função no

Planejamento de Processo de Desenvolvimento de
Software
Trabalho de conclusão de curso obrigatório

desenvolvido durante o 4o ano do Curso de
Graduação em Ciência da Computação co-
mo requisito parcial à obtenção do título de
Bacharel.
Orientador: Rodolfo Miranda de Barros
2004
THEO IGNEZ PAVAN
O Uso de Análise de Pontos por Função no

Planejamento de Processo de Desenvolvimento de
Software
COMISSÃO EXAMINADORA
____________________________________
Prof. Eduardo Cotrin Teixeira
UEL
____________________________________
Prof. Esio Dolci
UEL
____________________________________
Prof. Rodolfo Miranda de Barros
UEL
Londrina, ___ de ___________ de 2004

DEDICATÓRIA
Dedico este trabalho a Deus, que me deu forças, e a

meus pais, sem os quais este não seria possível.
RESUMO
Este presente trabalho descreve a importância do planejamento no processo de desenvolvi-

mento de software e por que é necessário estimar durante essa atividade. Mostra também o
conceito de métricas de software, com ênfase na análise de pontos por função. Além disso,
mostra como a ferramenta APF desenvolvida no estágio pode auxiliar no processo de desen-
volvimento de software.
ABSTRACT
This present work describes about the importance of planning in the software development
process and why is necessary to estimate during this activity. It shows the conceit of soft-
ware's metrics, with emphasis in function points analysis. In addition to that, it shows how
APF tools developed can help in the software development process.
Palavras-chave: Análise de Pontos por Função, Métricas Funcionais, Planejamento de Soft-
ware.
SUMÁRIO
1 INTRODUÇÃO...............................................................................................................11
2 A CRISE DO SOFTWARE E ENGENHARIA DE SOFTWARE.............................13
3 PLANEJAMENTO DE PROJETO DE SOFTWARE................................................15
4 MÉTRICAS E MEDIÇÕES DE SOFTWARE............................................................17

4.1 MÉTRICAS DO PRODUTO ....................................................................................18
4.2 MÉTRICAS DO PROCESSO...................................................................................19
4.3 MÉTRICAS DE PRODUTIVIDADE E QUALIDADE DE SOFTWARE E
MÉTRICAS TÉCNICAS ......................................................................................................19
4.4 MÉTRICAS ORIENTADAS AO TAMANHO ........................................................19
4.5 MÉTRICAS ORIENTADAS A FUNÇÃO ...............................................................20
5 MÉTRICAS FUNCIONAIS – ANÁLISE DE PONTOS POR FUNÇÃO .................21
5.1 IFPUG .......................................................................................................................21
5.2 NESMA ....................................................................................................................22
5.3 MARK II ...................................................................................................................22
5.4 COSMIC – FFP.........................................................................................................22
5.5 IBSG .........................................................................................................................23
6 ANÁLISE DE PONTOS POR FUNÇÃO NO BRASIL ..............................................24
6.1 BFPUG .....................................................................................................................25
7 PROCESSO DE CONTAGEM – ANÁLISE DE PONTOS POR FUNÇÃO ............28
7.1 DETERMINAÇÃO DO TIPO DE CONTAGEM .....................................................28
7.1.1 Contagem de um projeto de desenvolvimento..................................................29
7.1.2 Contagem de um projeto de melhoria ..............................................................29
7.1.3 Contagem de uma aplicação (ou baseline) ......................................................29
7.2 O ESCOPO DA CONTAGEM E A FRONTEIRA DA APLICAÇÃO .....................29
7.3 FUNÇÕES DO TIPO DADO....................................................................................29
7.3.1 Arquivo Lógico interno.....................................................................................30
7.3.2 Arquivo de interface externa ............................................................................31
7.4 FUNÇÕES DO TIPO TRANSAÇÃO .......................................................................32
7.4.1 Entrada Externa................................................................................................33
7.4.2 Saída Externa....................................................................................................34
7.4.3 Consulta Externa ..............................................................................................35
7.5 PONTOS POR FUNÇÃO NÃO-AJUSTADOS .......................................................37
7.6 FATOR DE AJUSTE................................................................................................37
7.7 PONTOS POR FUNÇÃO AJUSTADOS .................................................................38
7.7.1 Cálculo para projeto de Desenvolvimento.......................................................38
7.7.2 Cálculo para projeto de Melhoria ....................................................................39
7.7.3 Cálculo para Aplicação ....................................................................................39
8 ESTIMATIVAS ..............................................................................................................41
8.1 MÉTODO DELPHI .................................................................................................41
8.2 MÉTODO WIDEBAND-DELPHI (BOEHM) .........................................................41
8.3 MÉTODO PUTMAN................................................................................................41
8.4 MODELO COCOMO E COCOMO II......................................................................41
8.5 ANÁLISE DE PONTOS POR FUNÇÃO .................................................................42
9 NORMAS E PADRÕES .................................................................................................44
9.1 PADRÃO ISO...........................................................................................................44
9.2 CMM.........................................................................................................................45
10 FERRAMENTA APF.................................................................................................47
10.1 FUNCIONALIDADES .............................................................................................47
10.2 COMO FOI DESENVOLVIDA ...............................................................................49
10.3 REQUISITOS MÍNIMOS DE FUNCIONAMENTO ...............................................49
11 CONCLUSÃO .............................................................................................................50
REFERÊNCIAS ......................................................................................................................51
LISTA DE TABELAS
Tabela 1 – Métricas Orientadas ao Tamanho .......................................................................... 20

Tabela 2 - Métricas primitivas utilizadas para medir a qua lidade dos processos de software..24
Tabela 3 – Métricas primitivas utilizadas para medir a produtividade dos processos de softwa-
re ............................................................................................................................................. 25
Tabela 4 – Exames CFPS Realizados pelo BFPUG ............................................................... 26
Tabela 5 – Países com maiôs número de CFPS ...................................................................... 27

Tabela 6 – Complexidade ALI ................................................................................................ 30
Tabela 7 – Pontos por Função ALI ......................................................................................... 31
Tabela 8 – Complexidade AIE ................................................................................................ 32

Tabela 9 – Pontos por Função AIE ......................................................................................... 32
Tabela 10 – Complexidade EE ............................................................................................... 33

Tabela 11 – Pontos por Função EE ......................................................................................... 34
Tabela 12 – Complexidade SE ................................................................................................ 35
Tabela 13 – Pontos por Função SE ......................................................................................... 35

Tabela 14 – Complexidade CE ............................................................................................... 36
Tabela 15 – Pontos por Função CE ......................................................................................... 36

Tabela 16 – Níveis de Influência ............................................................................................ 38
Tabela 17 – Linguagens de Programação ............................................................................... 43
Tabela 18 – Níveis do modelo CMM ...................................................................................... 45

Tabela 19 – Áreas chaves de cada nível .................................................................................. 46
LISTA DE FIGURAS
Figura 1 - Fases do processo de desenvolvimento de software ................................................15
Figura 2 - Classificação das Métricas de Software...................................................................18
Figura 3 - Métricas primitivas utilizadas para medir a qualidade e produtividade dos
processos de software. ......................................................................................................25
Figura 4 - Evolução da Quantidade de CFPS Brasileiros .........................................................27
Figura 5 - Processo de Contagem.............................................................................................28
Figura 7 - Tela Principal Ferramenta APF ...............................................................................47
Figura 8 - Tela Pontos por Função Não-Ajustados ..................................................................48
Figura 9 - Tela Pontos por Função Ajustados ..........................................................................48
Figura 10 - Funcionamento da Ferramenta APF ......................................................................49
LISTA DE ABREVIATURAS E SIGLAS
APF Análise de Pontos por Função

ALI Arquivo Lógico Interno
AIE Arquivo de Interface Externa

BFPUG Brazilian Function Point Users Group
CE Consulta Externa
CFPS Certificação de especialista em pontos por função

CGS Características gerais de sistema
COSMIC Common Software Measurement International Consortium

CPM Counting Pratices Manual
EE Entrada Externa
FFP Full Function Points

FSM Functional Size Measurement
IBSG International Software Benchmarking Standards Group

IFPUG International Function Point Users Group
NESMA Netherlands Software Metrics Users Association
PF Pontos por Função

SE Saída Externa
VAF Value Adjustment Factor

11
1 INTRODUÇÃO
O trabalho de conclusão de curso (TCC) tem como tema a importância do

planejamento para a obtenção de qualidade no processo de desenvolvimento de software, e a
importância de se estimar durante a fase de planejamento. O trabalho introduz várias formas
de métricas e métodos de estimativa de software, dando ênfase à medição funcional de tama-
nho, ou seja, a Análise de Pontos por Função.
Grande parte dos problemas que ocorre no desenvolvimento de softwares é

causada pela falta de um processo de desenvolvimento do software bem definido, originando
erros de estimativas de prazos e custos, falta de controle do processo, menor qualidade do
produto final, pouca produtividade, inexistência de um processo repetível e vários outros pro-
blemas.
Se as empresas já encontram dificuldade na definição do processo de desen-

volvimento, é normal ainda encontrem dificuldades nas atividades de planejamento e gerenc i-
amento de projeto de software. Para que seja possível realizar essas atividades no processo de
desenvolvimento de software, necessita-se, entre outros pré-requisitos, a determinação do ta-
manho do software. E esta tarefa aparentemente simples acaba se mostrando difícil de ser
realizada.
Há vários métodos de medição de software como os baseados na quantidade
de linhas do código fonte dos programas e muitos outros métodos de medidas derivadas das
características técnicas do software. Ambos tipos não são considerados satisfatórios, pois não
podem ser aplicados no início do processo de desenvolvimento do software ou são pouco
precisos.
O conceito de Medição Funcional de Tamanho (Functional Size Measure-
ment - FSM) ultrapassa essas limitações, deixando de medir o software como implementado,
para medir o tamanho, nos termos das funções requeridas pelo usuário. A contagem dos pon-
tos de função é realizada com base em cinco tipos de componentes de software: arquivos ex-
ternos, arquivos internos, entradas, saídas e consultas. Esses termos possuem um sentido es-
pecífico na Análise de Pontos por Função, e a sua identificação e classificação exigem um es-
pecialista.
Segundo AZEVEDO (2003) a análise por pontos de função auxilia: no cál-

culo do custo real do software, na estimativa do custo do projeto e da implementação, no en-
tendimento dos gastos na manutenção, nas negociações de contrato entre outros.
12
Os capítulos 1,2 e 3 contextualizam a análise de pontos por função na área

da Engenharia de Software. O capítulo 4 discute o que é uma métrica, o por que de se medir
um software e quais tipos de métricas de software existem, e suas características. O capítulo 5
apresenta vários tipos de análise de pontos por função utilizados pelos principais grupos de
usuários do mundo. Já o capítulo 5 mostra o uso de análise de pontos por função no Brasil a-
tualmente. O capítulo 7 mostra como é o processo de contagem de pontos por função segundo
o IFPUG. O capítulo 8 discute os principais métodos de estimativa de software. O capítulo 9
contextualiza a análise de pontos por função dentro das normas e padrões ISO e CMM. O ca-
pítulo 10 descreve a importância da ferramenta desenvolvida no estágio, a ferramenta APF, na
contagem de pontos por função.
13
2 A CRISE DO SOFTWARE E ENGENHARIA DE SOFTWARE
O termo “crise do software” foi muito utilizado na década de 60 devido a

um conjunto de problemas encontrado no processo de desenvolvimento do software. Esses
problemas eram fortemente marcados pela desestruturação dos desenvolvedores, que não
seguiam nenhuma regra, norma ou padrões, ou seja, o desenvolvimento do software
encontrava-se fora de controle.
Os principais problemas relacionados à crise do software são: inadequação

do software, cronogramas e custos imprecisos, insatisfação dos usuários e clientes, comunica-
ção deficiente entre as partes envolvidas, dificuldades na manutenção, etc.
Foi nesse cenário que surgiu a Engenharia de Software, pois era preciso dar
um tratamento mais sistemático e controlado ao processo de desenvolvimento. Sendo assim,
estabeleceram-se padrões, métodos, ferramentas e procedimento para contornar a crise do
software.
A primeira definição atribuída a Engenharia de Software foi dada por Fritz

Bauer em 1969 apud Pressman (1995):
“O estabelecimento e uso de sólidos princípios de engenharia
para se possa obter economicamente um software que seja

confiável e que funcione eficientemente em máquinas reais.”
A definição proposta pelo IEEE, que é uma das mais utilizadas hoje em dia,
defende que a Engenharia de Software é uma aplicação de um processo sistemático, discipli-
nado e quantificado ao desenvolvimento, operação e manutenção de software. Sendo assim, a
engenharia software é nada mais que a aplicação da engenharia ao software.
Os principais objetivos da Engenharia de Software são: melhorar a qualida-
de, entregar o produto dentro dos prazos e custos estabelecidos, incrementar a produtividade
do desenvolvimento, etc.
A principal preocupação da engenharia de software é a qualidade. Segundo
Maldonado (2001) a qualidade de do produto de software está intimamente ligada à qualidade
do processo de software.
O processo de software envolve um conjunto de atividades e resultados as-

sociados que geram o produto de software, ou seja, o produto final (Sommerville, 2003).
14
Prantoni (2001) afirma que um dos maiores problemas encontrados no de-

senvolvimento do software é a determinação correta do tempo e do esforço necessário para o
projeto.
A atividade responsável por essas estimativas é a de planejamento de proje-
tos de software. Através da determinação do tempo e do esforço necessários para o desenvo l-
vimento do software, a empresa consegue prever à qual qualidade e produtividade atingirá o
projeto.
Segundo Cordeiro (2000), se não há previsibilidade, é porque não se conse-

gue realizar estimativas apropriadas e isto é o mesmo que andar no escuro.
15
3 PLANEJAMENTO DE PROJETO DE SOFTWARE
Segundo Maldonado (2001), há três fases no processo de desenvolvimento

de software:
1. Definição: inclui as etapas análise de sistema, o planejamento do proje-

to e a análise de requisitos. Define quais informações serão processa-
das, quais funções e desempenho são desejados, quais interfaces devem
ser estabelecidas, quais restrições do projeto e critérios de validação são
necessários.
2. Construção: inclui as etapas projeto, codificação e o teste do software.

Define como devem ser projetadas as estruturas de dados e a arquitetura
do software.
3. Manutenção: tem como objetivo as mudanças e correções de erros, a-

daptações necessárias e melhoramentos relacionados às novas necessi-
dades do usuário.
Figura 1 - Fases do processo de desenvolvimento de software
Observa-se na figura acima que a atividade de planejamento encontra-se na

fase de definição do projeto. Ela começa a ser realizada no início do ciclo de vida. É muito
comum ocorrer modificações durante as atividades posteriores, uma vez que essas ainda não
estão totalmente definidas.
O planejamento de projeto está fortemente ligado ao desenvolvimento de

um plano. Este plano especifica o que deve ser feito, a divisão de tarefas, estimativas de pra-
zos e custos, etc.
No entanto, é muito comum surgir perguntas do tipo: “por que planejar se já

sei o deve ser feito?”. Segundo Alessandro (2003), um profissional experiente é capaz de sa-
ber o que deve ser feito, porém nenhum projeto envolve apenas uma pessoa.
16
O planejamento é muito importante, pois se reduz à probabilidade de impre-

vistos e de problemas e, conseqüentemente, falsas expectativas, etc. É fundamental para qua l-
quer empresa que queria obter resultados e melhorias nos processos e no produto final.
A determinação de estimativas do planejamento de software não é uma tare-
fa fácil. Segundo Prantoni (2001), não é possível medir ou estimar características de um soft-
ware sem que haja um método de desenvolvimento bem definido, em cada uma de suas ativi-
dades, fases, entradas e saídas. Essas informações estabelecem pontos de controle para que os
dados necessários para o planejamento possam ser obtidos ao longo do processo. Sendo as-
sim, é através dessas estimativas que a empresa consegue prever o custo de seu projeto e veri-
ficar se há sincronização entre as atividades de desenvolvimento.
Para a determinação de estimativas durante o planejamento de software, em
primeiro lugar, defini-se uma forma de medir o software, ou seja, uma forma de definir um
tamanho para o software. A medição do software é chamada de métrica, e é discutida no capí-
tulo seguinte.
17
4 MÉTRICAS E MEDIÇÕES DE SOFTWARE
Segundo Boehm (1981), uma métrica é uma forma padrão de medir um atri-
buto do processo de desenvolvimento de software. As métricas fornecem informações quant i-
tativas sobre o ambiente e o progresso de desenvolvimento do produto.
Por que medir um software? Segundo Wiegers (1999) os projetos de softwa-

re são famosos por estourar o prazo e o orçamento e por apresentar problemas de qua lidade. A
mensuração de software permite que você quantifique prazo, esforço, tamanho do produto,
status do projeto e desempenho da qualidade. Se o usuário não cuidar de medir seu desempe-
nho atual e utilizar os dados para melhorar suas estimativas futuras, tais estimativas serão a-
penas "chutes". Como os dados de hoje tornam-se os dados históricos no futuro, nunca é tarde
para começar a registrar as informações importantes dos projetos.
Quando se considera boa parte dos empreendimentos técnicos, verifica-se

que as medições e as métricas permitem um melhor entendimento do processo utilizado para
desenvolver um produto, assim como uma melhor avaliação do próprio produto.
A quantificação dos aspectos relacionados ao processo de desenvolvimento

de software, assim como do próprio software, é importante, pelas seguintes razões:
? No caso do processo de desenvolvimento, as medições podem permi-

tir melhorias no processo, aumentando a sua produtividade;
? No caso do produto, as medições podem proporcionar informações a

respeito de sua qualidade.
Segundo Pressman (1995) as medições de software podem ser classificadas
em duas categorias principais:
? Medições diretas, por exemplo, o número de linhas de código (LOC)

produzidas, o tamanho de memória ocupado, a velocidade de execu-
ção, o número de erros registrados num dado período de tempo, etc...
? Medições indiretas, as quais permitem quantificar aspectos como a

funcionalidade, complexidade, eficiência, manutenibilidade, etc...
As medições diretas, tais quais aquelas exemplificadas acima, são de obten-

ção relativamente simples, desde que estabelecidas às convenções específicas para isto. Por
outro lado, aspectos como funcionalidade, complexidade, eficiência, etc..., são bastante difí-
ceis de se quantificar.
18
Segundo Gustafson (2003) as métricas de software podem ser divididas em

métricas do produto e métricas do processo.
Já Pressman (1995) afirma que as métricas de software podem ser divididas

em métricas de produtividade, métricas de qualidade e métricas técnicas. E que uma outra di-
visão em categorias pode ser feita: métricas orientadas ao tamanho, orientadas à função e ori-
entadas às pessoas. Verifica-se melhor essa duas classificações segundo a figura abaixo:
Figura 2 - Classificação das Métricas de Software
4.1 MÉTRICAS DO PRODUTO
Gustafson (2003) relata que métricas do produto são métricas que podem ser
calculadas para o documento, não importando a forma como foi produzido. Geralmente elas
estão relacionadas de alguma maneira à estrutura do código fonte, mas podem ser definidas de
outras formas, por exemplo, pelo número de parágrafos na especificação de requisitos.
19
4.2 MÉTRICAS DO PROCESSO
Métricas do processo são métricas definidas de forma a medir o processo.

Segundo Gustafson (2003) a produtividade é uma das métricas básicas do processo, que é cal-
culada pela divisão do total de linhas de código fonte (LOC) entregues pelos programadores
por dia, atribuídos ao projeto do software. As unidades geralmente são LOC/programador/dia.
4.3 MÉTRICAS DE PRODUTIVIDADE E QUALIDAD E DE SOFTWARE E MÉ-

TRICAS TÉCNICAS
Pressman (1995) afirma que dentro do contexto de gerenciamento de proje-

tos de software, há uma maior preocupação com métricas de produtividade e de qua lidade,
medidas através do resultado do desenvolvimento de software como uma função do esforço
aplicado e medidas da “adequação ao uso” do resultado que é produzido. Para propósitos de
planejamento e estimativa, o interesse é histórico.
Métricas da produtividade são baseadas na saída do processo de desenvo l-

vimento do software com o objetivo de avaliar o próprio processo. Já as métricas da qualidade
permitem indicar o nível de resposta do software às exigências explícitas e implícitas do cli-
ente.
Nas métricas técnicas, encaixam-se aspectos como funcionalidade, modula-
ridade, manutenibilidade, etc.
4.4 MÉTRICAS ORIENTADAS AO TAMANHO
Segundo Pressman (1995), métricas de software orientadas ao tamanho são

medidas diretas do software e do processo pelo qual ele é produzido. Se a empresa possuir re-
gistros simples, uma tabela como a da figura abaixo, poderá ser criada.
20
Tabela 1 – Métricas Orientadas ao Tamanho
págs. do-
projeto esforço LOC erros pessoas
$ cum.
aaa-01 24 168 12.1 365 29 3
ccc-04 62 440 27.2 1224 86 5
fff-03 43 314 20.2 1050 64 6
.. .. .. .. .. .. ..
Fonte: (Pressman, 1995)

Segundo JON (1986) apud Pressman (1995), as métricas orientadas ao ta-
manho provocam controvérsias e não são universalmente aceitas como a melhor maneira de
se medir o processo de desenvolvimento de software. O motivo principal é o uso de LOC co-
mo medida, já que seu uso em estimativas é complexo, necessitando de um nível de detalhes
muito grande. O planejador deve estimar o número de linhas de código que serão desenvolvi-
das muito antes que a análise e o projeto tenham sido concluídos.
4.5 MÉTRICAS ORIENTADAS A FUNÇÃO
Pressman (1995) afirma que as métricas de software orientadas à função são

medidas indiretas de software e do processo ao qual é desenvolvido. A métrica orientada à
função não conta linhas de código, e sim a “funcionalidade” ou ”utilidade” do programa.
Métricas orientadas à função serão mais bem comentadas no capítulo Métri-

cas Funcionais – Análise de Pontos por Função.
21
5 MÉTRICAS FUNCIONAIS – ANÁLISE DE PONTOS POR FUNÇÃO
Silva (2000) afirma que a Análise de Pontos por Função procura fornecer
uma unidade de medida para a indústria do software. Esta unidade de medida não depende da
plataforma ou da linguagem em que o software será desenvolvido. Um aplicativo por mais
simples e modesto que seja, sempre executa algumas determinadas funções. Determinar estas
funções segundo critérios precisos e dar-lhes uma medida de referência é o ponto-chave da
Análise de Pontos por Função.
Segundo Pressman (1995) os conceitos sobre pontos de função foram intro-
duzidos por Allan J. Albrech, da IBM, em 1979. Melhorados e transformados em metodologia
formal, esses conceitos vieram a público em 1984. Já em 1986, uma comunidade de usuários
criou o IFPUG – Grupo Internacional de usuários de Pontos por Função, maior divulgador da
técnica nos tempos de hoje. No entanto, há outros grupos como BFPUG, NESMA, Mark II e
COSMIC – FFP, que serão comentados no decorrer deste trabalho.
Mas o que é um ponto por função? Segundo Silva (2000) ponto por função é
uma medida que procura definir o tamanho do que faz o software, independente de como pos-
sa ser produzido e implementado. Assim, tamanho funcional é uma medida de tamanho de
software baseado numa avaliação padronizada dos requisitos lógicos dos usuários.
5.1 IFPUG
O IFPUG 1 – International Functio n Point Users Group (Grupo Internacional

de Usuários de Ponto por Função) é uma entidade sem fins lucrativos, composta por pessoas e
empresas de diversos países, cuja finalidade é promover um melhor gerenciamento dos pro-
cessos de desenvolvimento e manutenção de software, utilizando a técnica de pontos por fun-
ção e outras.
O IFPUG lança desde 1990 o CPM – Counting Pratices Manual ou Manual

de Práticas de Contagem, que está atualmente na versão Release 4.1.1. Desde seu lançamento
este manual é considerado como padrão pela maioria das indústrias de software para pontos
de função.
O Grupo Internacional de Usuários de Ponto por Função realiza conferên-
cias anuais, seminários e workshops educacionais com o intuito de divulgar a técnica de pon-
1
http://www.ifpug.org.
22
tos por função. Além de possuir uma certificação profissional, a CFPS visa dar certificação
aos usuários da técnica como especialistas em pontos de função.
O Grupo também possui vários comitês, como o de certificação responsável

pelo desenvolvimento do programa de certificação, o comitê de comunicação responsável por
manter a comunicação entre o IFPUG e seus membros, o comitê de conferências responsável
por promover a conferência anual, o comitê de práticas de contagem responsável por manter o
CPM, o comitê de educação responsável por promover os seminários e workshops, entre vá-
rios outros comitês responsáveis por manter, desenvolver e divulgar a técnica da Análise de
Pontos por Função.
5.2 NESMA
O NESMA2 – Netherlands Software Metrics Users Association, ou associa-

ção de usuários de métricas de software da Holanda, foi criada inicialmente com o nome de
NEFPUG – Netherlands Function Point Users, ou grupo de usuários de pontos por função da
Holanda. O NESMA é um dos maiores grupos de usuários de pontos por função da Europa,
utilizando filosofia, conceitos termos e regras bem parecidos com as do IFPUG, mas com al-
gumas diretrizes diferentes. A NESMA, desde 1990, possui seu próprio manual de contagem,
atualmente na versão 2.0, sendo que sua forma de contagem é bem próxima da do manual do
IFPUG chegando em resultados bem próximos.
5.3 MARK II3
O Mark II foi formulado por Charles Symons em meados da década de 80,

inspirado por Albrecht. Seu trabalho ficou muito conhecido depois de uma publicação na re-
vista IEEE – Transactions on Software Engineering. No entanto, a técnica não se tornou mui-
to usada pelo fato de que, inicialmente, era um método proprietário da consultoria KPMG.
Hoje a técnica é de domínio público, e a UKSMA, Associação de Métricas

do Reino Unido, é a associação responsáve l por mantê- la. No entanto, a técnica é muito restri-
ta ao Reino Unido.
5.4 COSMIC – FFP
Em 1997, um grupo de pesquisadores da Universidade de Quebec desenvo l-

veu um método chamado FFP – Full Function Points, que era destinado à medição funcional
2
http://www.nesma.nl.
23
de sistemas de tempo real. No entanto, percebeu-se que a mesma técnica poderia ser usada em
sistemas tradicionais. Assim em 1998 um grupo de especialistas liderados por Alain Albran e
Charles Symons, formou o COSMIC 4 – Common Software Measurement International Con-
sortium com o objetivo de criar uma nova técnica utilizando o melhor de cada método já exis-
tente.Mas, acabou sendo um refinamento do FFP, sendo chamado então de COSMIC – FFP.
5.5 IBSG
O IBSG5 – International Software Benchmarking Standards Group é uma

organização sem fins lucrativos, resultado da iniciativa de várias organizações métricas do
mundo, de países como Estados Unidos, Reino Unido, Holanda, Japão, Itália, entre outros, cu-
jo principal motivo de existência é manter um repositório público de métricas de projetos de
software que possa ajudar na gestão dos recursos de TI pela melhoria das estimativas de pro-
jeto e produtividade, análise de riscos e benchmarking.
O IBSG fornece um modelo padrão para o registro e coleta de dados de pro-
jetos de software, fornece uma ferramenta de auxílio na coleta de dados, gerencia o repositó-
rio de dados de projetos, coordena uma pesquisa baseada em seu repositório e publica livros e
relatórios. Periodicamente o IBSG publica o “The software Metrics Compendium” que con-
tém uma análise estatística detalhada do seu repositório.
Qualquer organização pode contribuir com informações de seus projetos pa-
ra o repositório do IBSG, este garante que estes dados serão confidenciais.
3
http://www.uksma.co.uk.
4
http://www.cosmicon.com.
5
http://www.ibsg.org.au.
24
6 ANÁLISE DE PONTOS POR FUNÇÃO NO BRASIL
Segundo a pesquisa Tecnologia da Informação – Qualidade e Produtivida-

deno Setor de Software de 2001 do Ministério da Ciência e tecnologia, no Brasil, a medição
de linhas de código foi a métrica mais aplicada no passado, quando o código era dominante
nas estimativas de custo. Desde a década de 1990, vem ganhando espaço a técnica de avalia-
ção de um sistema, conhecida como FPA – Function Point Analysis, baseada na medição do
valor das funções executadas pelos programas, ao invés de utilizar como base o volume ou a
complexidade do código dos programas.
Na pesquisa, verificou-se que para medir a qualidade dos processos de soft-

ware quase 10% das empresas utilizavam pontos por função e 6% linhas de código. A tabela
abaixo ilustra essa situação:
Tabela 2 - Métricas primitivas utilizadas para medir a qualidade dos processos de software
Categorias Nº de organizações %
Linhas de código ( LOC ) 25 5,6
Pontos por função ( function point ) 43 9,6
Outras métricas 26 5,8
Não utiliza 363 81,4
Base 446 100
Fonte: Ministério da Ciência e Tecnologia
Enquanto como métricas primitivas para medir a produtividade, os resulta-

dos eram de 18% para FPA e 10% para linhas de código.A tabela abaixa ilustra essa situação::
25
Tabela 3 – Métricas primitivas utilizadas para medir a produtividade dos processos de softwa-
re.
Categorias Nº de organizações %
Linhas de código ( LOC ) 46 10,3
Pontos por função ( function point ) 81 18,2
Outras métricas 30 6,7
Não utiliza 312 70,0
Base 446 100
Fonte: Ministério da Ciência e Tecnologia
Figura 3 - Métricas primitivas utilizadas para medir a qualidade e produtividade dos

processos de software.
O Brasil já possui um grupo de usuários de pontos por função nos moldes
do IFPUG, chamado BFPUG descrito a seguir.
6.1 BFPUG
O BFPUG 6 é um grupo de usuários constituído com o objetivo de divulgar a

utilização de métricas no desenvolvimento de sistemas, principalmente a Análise de Pontos de
Função. Destina-se aos profissionais interessados em aprender, praticar e divulgar o uso de
métricas e de Pontos por Função. O BFPUG é a representação brasileira oficial do IFPUG.
26
No Brasil já ocorreram cinco exames da certificação CFPS, sendo o último

realizado no dia 22 de novembro de 2003 sob patrocínio do BFPUG. A tabela abaixo mostra a
evolução dos exames patrocinados pelo BFPUG:
Tabela 4 – Exames CFPS Realizados pelo BFPUG
Ano Mês Candidatos Aprovados % Aprov. Localidade(s) Obs. Qtd CFPS
2001 06 31 10 32 Rio 12
2002 06 56 34 61 Rio 1 recertificou-se 45
Rio, São Paulo e

2003 03 76 45 59 1 recertificou-se 89
Brasília
Rio, São Paulo, Bra-
2003 11 105 Aguarde Aguarde
sília e Vitória
Fonte: BFPUG
Segundo o site do BFPUG, o Brasil possuia, até 22/11/2003, 89 especialis-

tas certificados pelo IFPUG, sendo hoje veja na figura abaixo extraída do site do BFPUG a
evolução do número de certificados com a certificação CFPS no Brasil:
6
http://www.bfpug.com.br.
27
Figura 4 - Evolução da Quantidade de CFPS Brasileiros
Segundo o BFPUG, o Brasil é o terceiro país com maior número de especia-

listas certificados pelo IFPUG. A tabela abaixo, criada com dados do BFPUG, mostra os cin-
co países com maior número de especialistas certificados do mundo:
Tabela 5 – Países com maiôs número de CFPS
Posição País
1 Estados Unidos
2 Itália
3 Brasil
4 Japão
5 Canadá
Fonte: BFPUG
28
7 PROCESSO DE CONTAGEM – ANÁLISE DE PONTOS POR FUNÇÃO
O processo de contagem de pontos por função, segundo o CPM 4.1.1 do IF-

PUG, segue o esquema da figura abaixo retirada de (Vazquez et al, 2003).
Figura 5 - Processo de Contagem
7.1 DETERMINAÇÃO DO TIPO DE CONTAGEM
Segundo Vazquez et al (2003) existem três tipos de contagem de Pontos por

Função, são eles:
? Contagem de um projeto de desenvolvimento;
? Contagem de um projeto de melhoria;
? Contagem de uma aplicação (ou baseline).

A técnica utilizada na contagem é a mesma em cada tipo, a diferença está no
que é considerado em cada um. Essa diferença será vista no cálculo de pontos por função a-
justados.
29
7.1.1 Contagem de um projeto de desenvolvimento

Este tipo de contagem mede a funcionalidade fornecida aos usuários finais
do software quando da sua primeira instalação. Isso significa que essa contagem também a-
brange as eventuais funções de conversão de dados necessárias à implantação do sistema. No
entanto, qualquer contagem feita antes do término de um projeto é, na verdade, uma estimati-
va da funcionalidade que o projeto terá quando estiver pronto.
7.1.2 Contagem de um projeto de melhoria

Este tipo de contagem mede as funções adicionadas, modificadas ou excluí-
das do sistema pelo projeto. Mede ainda as funções de conversão de dados. Quando o projeto
de melhoria é concluído, os pontos por função da aplicação devem ser atualizados para refletir
as alterações desse projeto.
7.1.3 Contagem de uma aplicação (ou baseline)

Este tipo de contagem mede os pontos por função de uma aplicação instala-
da e mostra a atual funcionalidade obtida pelo usuário da aplicação. Este tipo de contagem é
iniciado no final da contagem do projeto de desenvolvimento e é atualizado depois do projeto
de melhoria.
7.2 O ESCOPO DA CONTAGEM E A FRONTEIRA DA APLICAÇÃO
O escopo da contagem define a contagem abrangerá um ou mais sistemas ou

apenas parte de um sistema. Já a fronteira da aplicação deverá separar o software que será
medido e o mundo exterior. Segundo Silva (2000) a fronteira do aplicativo separa os compo-
nentes de um aplicativo dos componentes de outros aplicativos.
7.3 FUNÇÕES DO TIPO DADO
Segundo Vazquez et al (2003) as funções do tipo dado representam a fun-

cionalidade fornecida ao usuário para atender a suas necessidades de dados internos e exter-
nos à aplicação. São classificados em Arquivos Lógicos Internos (ALI) e Arquivos de Interfa-
ce Externa (AIE). O termo Arquivo se refere a um grupo de dados logicamente relacionados e
reconhecido pelo usuário.
O processo de contage m dos ALI e AIE se resumem em: identificar arqui-

vos lógicos internos, sua complexidade e contribuição.
30
7.3.1 Arquivo Lógico interno

Silva (2000) afirma que um Arquivo Lógico Interno (ALI) é um grupo de
dados relacionados, identificados pelo usuário, que reside inteiramente dentro da fronteira do
aplicativo. O conjunto de dados é sempre baseado na visão do usuário e é um elemento lógico
e persistente. É lógico, pois não se prende a qualquer implementação física e persistente, pois
permanece sempre disponível para o usuário.
Segundo Vazquez et al (2003) uma definição para ALI é:
? Um grupo de dados ou informações de controle;
? Identificável pelo usuário;
? Mantido dentro da fronteira da aplicação;
Segundo Silva (2000) o processo de contagem de ALI é baseado em regis-

tros lógicos referenciados e dados elementares referenciados. Um registro lógico referenciado
é um subgrupo de dados que devem ser enxergados como um elemento único. Caso não exis-
tam subgrupos de dados, então considera que o ALI possui um registro. Os dados elementares
referenciados dão suporte às necessidades do usuário, segundo sua própria visão. Não devem
ser contados dados que sejam recursivos.
Com base nos números de registros lógicos referenciados e dados elementa-
res referenciados, deve-se calcular a complexidade do ALI seguindo a tabela a seguir:
Tabela 6 – Complexidade ALI
20 a 50 dados ele- 51 dados elementares

1 a 19 dados elemen-
mentares referencia- referenciados em di-
tares referenciados
dos ante
1 registros lógicos re-

Simples Simples Média
ferenciados
2 a 5 registros lógi-
Simples Média Complexa
cos refe renciados

ferenciados em dian- Média Complexa Complexa
te
De acordo com Vaquez et al (2003), depois de determinada a complexidade

de um ALI, determina-se a contribuição que ele vai proporcionar. Na tabela a seguir, verifica-
31
se o número de pontos por função que um Arquivo Lógico Interno proporciona em função de
sua complexidade.
Tabela 7 – Pontos por Função ALI
Complexidade Pontos por Função
Simples 7
Média 10
Complexa 15
7.3.2 Arquivo de interface externa

Segundo Silva (2000) um Arquivo de Interface Externa (AIE) é um grupo
lógico de dados relacionados, identificados pelo usuário, usados apenas como referência pelo
aplicativo. Estes dados residem inteiramente fora da fronteira do aplicativo e são mantidos por
outros aplicativos.
Segundo Vazquez et al (2003) uma definição para AIE é:
? Um grupo de dados ou informações de controle;
? Identificável pelo usuário;
? Logicamente relacionados;
? Mantido dentro da fronteira da aplicação.
O processo de contagem de Arquivos de Interface Externa é semelhante ao

de contagem de Arquivos Lógicos Internos. Ou seja, os dois são baseados em registros lógi-
cos referenciados e dados elementares referenciados.
Sendo assim, com base nos números de registros lógicos referenciados e da-
dos elementares referenciados, calcular-se a complexidade do AIE seguindo a tabela a seguir:
32
Tabela 8 – Complexidade AIE
20 a 50 dados ele- 51 dados elementares

1 a 19 dados elemen-
mentares referencia- referenciados em di-
tares referenciados
dos ante

ferenciados
2 a 5 registros lógi-
cos referenciados

te

de um AIE, determina-se a contribuição que ele vai proporcionar. A tabela a seguir mostra o
número de pontos por função que um Arquivo Interface Externa proporciona em função de
sua complexidade.
Tabela 9 – Pontos por Função AIE
Simples 5
Média 7
Complexa 10
7.4 FUNÇÕES DO TIPO TRANSAÇÃO
Segundo Vazquez et al (2003) as funções do tipo transação representam a

funcionalidade fornecida ao usuário para atender as suas necessidades de processamento de
dados pela aplicação. São classificadas em Entradas Externas (EE), Saídas Externas (SE) ou
Consultas Externas (CE).
O processo de contagem das funções de transação se resume em determinar
a complexidade e a contribuição de cada EE, SE e CE e somar todas as contribuições.
33
7.4.1 Entrada Externa

Silva (2000) afirma que uma Entrada Externa é um processo elementar que
recebe dados vindos de fora da fronteira do aplicativo. Os dados podem ser recebidos de telas
de entrada de dados ou diretamente de outros aplicativos. Os dados podem ser informações de
negócio ou informações de controle. Uma informação de negócio é um dado que precisa ser
tornado persistente, ou seja, que precisa ser armazenado em algum arquivo lógico interno. Já
uma informação de controle é um dado que influência um processo elementar.
Segundo Vazquez et al (2003) uma definição para Entrada externa é:
? Um processo elementar;
? Que processa dados ou informações de controle recebidos de fora da

fronteira da aplicação;
? Cuja principal intenção é manter um ou mais arquivos lógicos inter-

nos e ou modificar o comportamento do sistema.
A complexidade de uma Entrada Externa é calculada de acordo com o nú-
mero de Arquivos Lógicos referenciados e de dados elementares referenciados, então calcula-
se a complexidade seguindo os dados da tabela à seguir:
Tabela 10 – Complexidade EE
15 dados elementares
1 a 4 dados elemen- 5 a 15 dados elemen-
referenciados em di-
tares referenciados tares referenciados
ante
0 ou 1 arquivos lógi-
cos referenciados
2 arquivos lógicos re-

ferenciados

te

de uma EE, determinamos a contribuição que ela vai proporcionar. Na tabela a seguir vemos o
número de pontos por função que uma Entrada Externa proporciona em função de sua com-
plexidade.
34
Tabela 11 – Pontos por Função EE
Simples 3
Média 4
Complexa 6
7.4.2 Saída Externa

Silva (2000) afirma que uma Saída Externa é um processo eleme ntar através
do qual dados derivados são enviados para além da fronteira do aplicativo. Os dados podem
ser relatórios ou arquivos de saída que são enviados para outros aplicativos. A finalidade bási-
ca de uma saída externa é a de recuperar dados, processá- los e enviá-los para além da frontei-
ra do aplicativo. No entanto, uma saída externa pode, às vezes, atualizar arquivos lógicos in-
ternos.
Segundo Vazquez et al (2003) uma definição para Saída externa é:
? Que envia dados ou informações de controle para fora da fronteira

da aplicação;
? Cuja principal intenção é apresentar informação ao usuário por meio

de lógica de processamento que não seja apenas a recuperação de
dados ou informações de controle.
A complexidade de uma Saída Externa é calculada de acordo com o número

de Arquivos Lógicos referenciados e de dados elementares referenciados, então calcula-se a
complexidade seguindo os dados da tabela à seguir:
35
Tabela 12 – Complexidade SE
ante
cos referenciados
cos referenciados

te

de uma SE, determinamos a contribuição que ela vai proporcionar. Na tabela a seguir vemos o
número de pontos por função que uma Saída Externa proporciona em função de sua comple-
xidade.
Tabela 13 – Pontos por Função SE
Simples 4
Média 5
Complexa 7
7.4.3 Consulta Externa

Silva (2000) afirma que uma Consulta Externa é um processo elementar
com componentes de entrada e saída recuperados de arquivos lógicos internos e de interface
externa. Os dados são enviados para alem da fronteira da aplicação. O processo não atualiza
nenhum arquivo lógico interno e os dados enviados não sofrem qualquer tipo de transforma-
ção.
Segundo Vazquez et al (2003) uma definição para Consulta externa é:
36
? Que envia dados ou informações de controle para fora da fronteira

da aplicação;
? Cuja principal intenção é apresentar informação ao usuário por meio

de uma simples recuperação de dados ou informações de controle de
um ALI ou AIE.
A complexidade da Consulta Externa é calculada de acordo com a quantida-

de de arquivos lógicos referenciados e de dados elementares referenciados. Os elementos da
parte de entrada devem ser somados aos elementos da parte de saída. Para a identificação de
uma consulta externa deve-se utilizar as mesma regras usadas para uma entrada externa ou pa-
ra uma saída externa, usando em seguida a tabela a seguir para determinar a complexidade:
Tabela 14 – Complexidade CE
ante
cos referenciados
cos referenciados

te

de uma CE, determinamos a contribuição que ela vai proporcionar. Na tabela a seguir verifi-
ca-se o número de pontos por função que uma Consulta Externa proporciona em função de
sua complexidade.
Tabela 15 – Pontos por Função CE
Simples 3
Média 4
Complexa 6
37
7.5 PONTOS POR FUNÇÃO NÃO-AJUSTADOS
Cada função, tanto do tipo dado, quanto do tipo transação são classificadas
em simples, média ou complexa. E com base nessa classificação foram calculadas suas con-
tribuições, que dependem do tipo de cada função e de sua complexidade. O número de Pontos
por Função Não-Ajustados é o somatório das contribuições de todas as funções do aplicativo.
7.6 FATOR DE AJUSTE
Segundo Silva (2000) o fator de ajuste (VAF – Value Adjustment Factor) é

baseado em 14 características gerais de sistema (CGS), listadas na seqüência:
1. Comunicação de Dados;
2. Performance;
3. Volume de Transações;
4. Interface com o Usuário;

5. Processamento Complexo;
6. Facilidade de Implantação;
7. Múltiplos Locais;
8. Processamento Distribuído;
9. Utilização de Equipamento;
10. Entrada de Dados "on- line";
11. Atualização "on- line";

12. Reutilização de Código ;
13. Facilidade Operacional;
14. Facilidade de Mudanças.
Enqua nto as funções do tipo dado refletem um requisito específico de arma-

zenamento e as funções do tipo transação um requisito específico de processamento, as CGS
refletem funções que afetam a aplicação de maneira geral. Cada uma das 14 características re-
cebe um valor de nível de influência de 0 a 5 mostrados na tabela à seguir:
38
Tabela 16 – Níveis de Influência
0 - Não tem influência

1 - Influência incidental
2 - Influência moderada
3 - Influência média
4 - Influência significativa
5 - Influência essencial
Vazquez et al (2003) afirma que o IFPUG fornece diretrizes que ajudam a

diminuir a subjetividade na determinação do nível de influência. O IFPUG diz que determina-
dos os níveis de influência dos 14 CGS, o fator de ajuste é calculado da seguinte forma: VAF
= (TDI x 0,01) + 0,65. Em que TDI (total degree of influence) é o somatório dos níveis de in-
fluencia das características gerais. O fator de ajuste ajusta o número de pontos por função
não-ajustados em no máximo + ou – 35%.
O IFPUG tornou o fator de ajuste facultativo para poder se adequar as nor-

mas do ISO/IEC, pois a determinação do fator de ajuste requer a utilização de requisitos tec-
nológicos e de qualidade, que são incompatíveis com o modelo ISO.
7.7 PONTOS POR FUNÇÃO AJUSTADOS
Segundo o manual do IFPUG existem três formas de se calcular os pontos

por função ajustados. Existe uma para cada tipo de contagem, são elas: projeto de Desenvo l-
vimento, projeto de Melhoria e Aplicação.
7.7.1 Cálculo para projeto de Desenvolvimento

DFP = (UFP + CFP) x VAF
Onde:
? DFP: Número de pontos por função do projeto de desenvolvimento.
? UFP: Número de Pontos por função não ajustados das funções dis-
poníveis após instalação.
? CFP: Número de pontos por função não-ajustados das funções de

conversão.
39
? VAF: Valor do fator de ajuste;
7.7.2 Cálculo para projeto de Melhoria

EFP = [(ADD + CHGA + CFP) x VAFA] + (DEL X VAFB)
Onde:
? EFP: Número de pontos por função do projeto de melhoria.
? ADD: Número de pontos por função não-ajustados das funções in-

cluídas pelo projeto de melhoria.
? CHGA: Número de pontos por função não-ajustados das funções

modificadas. Reflete as funções depois das modificações.
? CFP: Número de pontos por função não-ajustados adicionados pela

conversão.
? VAFA: Valor do fator de ajuste da aplicação depois do projeto de

melhoria.
? DEL: Número de pontos por função não-ajustados das funções ex-

cluídas pelo projeto de melhoria.
? VAFB: Valor do fator de ajuste da aplicação antes do projeto de me-

lhoria.
7.7.3 Cálculo para Aplicação

Segundo Vazquez et al (2003), há duas formas de se calcular o número de
pontos por função da aplicação. Uma para a primeira contagem dos pontos por função da a-
plicação e outra para depois do projeto de melhoria.
Fórmula Contagem inicial:

AFP = ADD x VAF
Onde:
? AFP: Número de pontos por função ajustados da aplicação.
? ADD: Pontos por função não-ajustados das funções instaladas.
? VAF: Valor do fator de ajuste da aplicação.
Fórmula após projeto de melhoria:

AFP = [(UFPB + ADD + CHGA) – (CHGB + DEL)] x VAFA
40
Onde:
? AFP: Número de pontos por função ajustado da aplicação.
? UFPB: Pontos por função não-ajustados da aplicação antes do proje-

to de melhoria.
? ADD: Pontos por função não-ajustados das funções incluídas pelo

projeto de melhoria.
? CHGA: Pontos de função não-ajustados das funções alteradas pelo

projeto de melhoria depois de seu término.
? CHGB: Pontos de função não-ajustados das funções alteradas pelo

projeto de melhoria antes de seu término.
? DEL: Pontos de função não-ajustados das funções excluídas pelo

projeto de melhoria.
? VAFA: Valor do fator de ajuste depois do projeto de melhoria.

41
8 ESTIMATIVAS
8.1 MÉTODO DELPHI
A Estimativa de Delphi é um modelo empírico, que se resume à consulta de

especialistas, linguagem de programação e outros assuntos para que, ao utilizar sua experiên-
cia e entendimento do projeto proposto, faça as devidas estimativas.
8.2 MÉTODO WIDEBAND-DELPHI (BOEHM)
Este método sugere que vários desenvolvedores envolvidos no projeto ind i-

quem suas estimativas individualmente. Em seguida, aplica-se o processo Delphi para se obter
uma estimativa convergente. O que difere os métodos Delphi e WideBand-Delphi é que o
primeiro não envolve reuniões entre os especialistas. A escolha entre esses dois modelos fica
a critério da empresa.
8.3 MÉTODO PUTMAN
A Estimativa de Putman é um modelo dinâmico de múltiplas variáveis que

pressupõem uma distribuição do esforço específico ao longo da existência de um projeto de
desenvolvimento de software. Este modelo associa experimentação associada a levantamento
de dados históricos e inferência estatística (Putnam, 1978) apud (Haufe, 1999).
8.4 MODELO COCOMO E COCOMO II
Segundo Sommerville (2003), o modelo COCOMO (constructive cost mo-

del – modelo de custo construtivo) é um modelo empírico. Ele foi derivado da coleta de dados
a partir de um grande número de projetos de software e, em seguida, pela análise desses dados
para descobrir fórmulas que fossem mais adequadas às observações.
Sommerville (2003) afirma que a primeira versão do COCOMO (hoje co-

nhecida como COCOMO 81) possuía três níveis, e cada nível refletia os detalhes da estimati-
va de custos. O primeiro nível, o nível básico, fornecia uma estimativa inicial, preliminar; o
segundo nível modificava essa condição, utilizando uma série de multiplicadores de projeto e
processo, e o nível mais avançado produzia estimativas para diferentes fases do projeto.
Segundo Trindade et al (1999) o modelo COCOMO II é uma versão atuali-

zada do COCOMO 81, que condiz com as tecnologias dos anos 90 e foi desenvolvido já se
pensando nas próximas décadas.
42
Sommerville (2003) identifica níveis para o COCOMO II, são eles:
1. Nível inicial de prototipação: As estimativas de tamanho são feitas

com base em pontos de objeto, e uma fórmula simples de tama-
nho/produtividade é utilizada para estimar o esforço requerido.
2. Nível inicial de projeto: Esse nível corresponde à conclusão dos re-

quisitos do sistema com (talvez) algum projeto inicial. As estimati-
vas são baseadas em pontos por função, que são convertidas para o
número de linhas de código-fonte. A fórmula segue o modo-padrão,
com a diferença de um simples conjunto de multiplicadores associa-
dos a ela.
3. Nível pós-arquitetura: Uma vez projetada a arquitetura do sistema,
uma estimativa razoavelmente exata do tamanho do software pode
ser feita. A estimativa desse nível utiliza um conjunto mais amplo de
multiplicadores, refletindo a capacidade pessoal, as características de
produto e de projeto.
8.5 ANÁLISE DE PONTOS POR FUNÇÃO
Busca medir a complexidade do produto pela quantificação de funcionalida-

de. Um modelo lógico, entretanto, expressa a visão que o usuário tem do mesmo. O modelo
FPA mede o que é o sistema, o seu tamanho funcional e não como este será, além de mens u-
rar a relação do sistema com usuários e com outros sistemas. FPA é completamente indepen-
dente de tecnologia e mede uma aplicação pelas funções que desempenha.
Os modelos COCOMO e Putman e vários outros métodos de estimativa uti-

lizam como base os LOC, linhas de código. No entanto, podemos transformar o número de
pontos por função em número de linhas de código utilizando tabelas padrão que nos indicam o
número de linhas de código aproximado para cada linguagem de programação. A tabela abai-
xo, mostra um exemplo:
43
Tabela 17 – Linguagens de Programação
Nº de linhas de código para cada ponto por

Linguagem
função
1st Generation default 3200
2nd Generation default 107
FORTRAN 107
C++ 53
Delphi 29
JAVA 53
Visual C++ 34
44
9 NORMAS E PADRÕES
9.1 PADRÃO ISO
Segundo Vazquez et al (2003) já no final de 1992, existiam vários métodos

de Medição Funcional de Tamanho (Functional Size Measurement – FSM), surgidos a partir
do método original de Análise de Pontos por Função proposto por Allan Albrecht. Com o ob-
jetivo de resolver as inconsistências existentes entre tais métodos e estabelecer um método
mais rigoroso de medição funcional, os gr upos de usuários de métricas de software da Austrá-
lia, Estados Unidos, Holanda e Reino Unido formaram o grupo denominado WG12 – Wor-
king Group 12, subordinado ao SC77 – Sub-Committee Seven do JTC1 – Join Technical
Committee One estabelecido pela ISO – International Organization for Standardization em
conjunto com o IEC – International Engineering Consortium.
Dos trabalhos do WG12 foram criados um conjunto de normas internacio-

nais chamado de norma 14143, dividida em cinco partes:
? 14143-1: Definição de conceitos;
? 14143-2: Avaliação da Conformidade de Métodos de Medição de Soft-

ware com relação ao padrão ISSO/IEC 14143-1;
? 14143-3: Verificação de um Método de Medição de Tamanho Funcio-

nal;
? 14143-4: Modelo de Referência para Medição de tamanho Funcional;
? 14143-5: Determinação de Domínios Funcionais para uso com Medição

de Tamanho Funcional.
A norma ISO/IEC 14143 foi desenvolvida com o intuito de garantir que to-
dos os métodos de Medição Funcional de Tamanho sejam baseados em conceitos similares.
Atualmente são quatro os métodos padrão de Medição de Tamanho Funcio-
nal reconhecidos pela norma ISO/IEC 14143, são eles:
? IFPUG CPM 4.1 (ISO/IEC 20926:2002);
? NESMA CPM 2.0 (ISO/IEC 24570:2002);
? Mark II COM 1.3.1 (ISO/IEC 20968:2002);
7
http://www.jtcl-sc7.org
45
? COSMIC-FFP Measurement Manual 2.1 (ISO/IEC 19761:2003).
9.2 CMM
O CMM é o modelo de capacitação para medição de maturidade mais am-

plamente aceito para o entendimento do processo de desenvolvimento de software. Segundo
Pádua (2003), um modelo de capacitação serve de referência para avaliar a maturidade dos
processos de uma organização.
Há cinco níveis de maturidade e cada uma delas, exceto o nível 1, possui á-

reas chaves que identificam quais questões devem ser resolvidas para atingir esse nível e defi-
nem um conjunto de metas Pádua (2003).
Tabela 18 – Níveis do modelo CMM
Número do nível Nome do nível Características dos

processos
Nível 1 Inicial Caótico
Nível 2 Repetitivo Disciplinados
Nível 3 Definido Padronizados
Nível 4 Gerido Previsíveis
Nível 5 Otimizante Melhoria contínua
Fonte: (Pádua, 2003)
46
Tabela 19 – Áreas chaves de cada nível
Nível CMM Áreas Chaves
1 - Inicial ------------------------------------------------
Gerenciamento de Requisitos
Planejamento do Projeto de Software
Acompanhamento e Supervisão do Projeto de
2- Repetitivo Software
Gerência de Subcontratação de Software
Garantia da Qualidade de Software
Gerenciamento de Configuração de Software
Processos de engenharia e apoio

Foco do processo organizacional
Definição do processo organizacional
3- Definido Programa de treinamento
Gerenciamento de software integrado
Engenharia de produto de software
Coordenação intergrupos
Revisão conjunta
Qualidade do produto e do processo
4- Gerido Gerenciamento quantitativo dos processos
Gerenciamento da qualidade de software
Melhoramento contínuo do processo
5- Otimizante Prevenção de defeitos
Gerenciamento de mudanças tecnológicas
Gerenciamento de mudanças no processo
O nível 2 está relacionado a um ambiente estável para que ocorra a repetição

de práticas de sucesso. A organização é capaz de assumir compromissos referentes a requis i-
tos, prazos e custos com alta probabilidade de cumpri- los Pádua (2003).
Quanto à área chave Planejamento do Projeto de Software, seu objetivo é
estabelecer planos razoáveis para a execução das atividades e gerenciamento do projeto de
software. É onde ocorre o cálculo de estimativas, estabelecimento de compromissos necessá-
rios e a definição de um plano de execução de trabalho. Uma das metas dessa área chave é
documentar as estimativas de software para o uso e acompanhamento no projeto de software.
47
10 FERRAMENTA APF
10.1 FUNCIONALIDADES
A ferramenta APF tem como principal função auxiliar o desenvolvedor de

software no cálculo do tamanho funcional da aplicação que será desenvolvida. É usada duran-
te o planejamento de software e, com base nos dados inseridos pelo usuário, a ferramenta cal-
cula os pontos por função do software a ser desenvolvido.
A ferramenta APF também pode auxiliar o usuário na obtenção de estima-

tivas do modelo COCOMO II, como estimativa de esforço pessoas/mês e de tempo de desen-
volvimento em meses.
Figura 6 - Tela Principal Ferramenta APF

48
Figura 7 - Tela Pontos por Função Não-Ajustados
Figura 8 - Tela Pontos por Função Ajustados

49
10.2 COMO FOI DESENVOLVIDA
A ferramenta APF foi desenvolvida utilizando o ambiente de programação

visual Borland Delphi 6.0 e o banco de dados Borland Interbase 6.0, e o help da ferramenta
foi desenvolvido utilizando o Microsoft FrontPage.
A ferramenta se comunica com o banco de dados BD_APF.GDB por meio

de componentes do tipo IBDatabase, IBTransaction, IBDataSet e DataSource presentes no
form3 (conexão.pas), este é um form invisível do tipo DataModule. Conforme na figur a abai-
xo:
Figura 9 - Funcionamento da Ferramenta APF
10.3 REQUISITOS MÍNIMOS DE FUNCIONAMENTO
Um computador precisa dos seguintes programas instalados para executar a

ferramenta APF:
? Borland Delphi 6.0;
? Borland Interbase 6.0;
? Windows 98 ou superior.
O computador precisa ter os requisitos mínimos de hardware para a execu-
ção dos programas acima citados para que possa executar a ferramenta APF sem problemas.
50
11 CONCLUSÃO
O planejamento de projeto de software é muito importante, pois se reduz à

probabilidade de problemas no desenvolvimento do software. No entanto, é certo de que ape-
nas o planejamento não garante que o processo de software obtenha qualidade, ele é apenas
uma ferramenta que auxilia na obtenção desta qualidade.
Dentro do planejamento, a análise de pontos por função é uma técnica ex-
tremamente útil, pois permite não só medir o tamanho do sistema em termos da funcionalida-
de fornecida ao usuário, mas também estimar o seu tamanho em qualquer fase do seu ciclo de
vida, mesmo que os requisitos ainda não tenham sido detalhados.
51
REFERÊNCIAS
(Alessandro, 2003) ALESSANDRO, A. Planejamento e Acompanhamento de Projetos – Os

Principais Problemas Típicos. Revista Developers, n. 81, ano 7, p. 15-16, maio, 2003.
(Azevedo 2003), Douglas José Peixoto de. Disponível na Internet: http://www.SoftwareMetrics.com

(29/05/2003)
(Boehm, 1981) BOEHM, BARRY W. Software Engineering Economics. New Jersey, Prentice Hall
PTR, 1981.
(Cordeiro, 2000) CORDEIRO M. A. Foco no Processo. Disponível em

http://www.pr.gov.br/batebyte/edicoes/2000/bb100/foco.htm
(Gustafson, 2003) GUSTAFSON D. A.. Engenharia de Software. Porto Alegre, Bookman, 2003.
(Haufe, 1999) HAUFE, M. I. Produtividade no desenvolvimento de software. In: Semana A-

cadêmica do Programa de Pós Graduação em Computação. RS, 1999.
(Maldonado, 2001) MALDONADO, J.C.; Weber, K.C. e ROCHA, A.R.C. Qualidade de Soft-
ware - Teoria e Prática , Makron Books, 2001.
(Pádua, 2003) PAULA FILHO, W. P. Engenharia de Software – fundamentos, métodos e pa-

drões. Rio de Janeiro, LTC, 2003.
(Prantoni, 2001) PRANTONI G. Estimativa de Tamanho de Software Baseada em Objetos,

2001 Disponível em http://www.choose.com.br/infochoose/artigos/viewer.asp?n=37&a=2
(Pressman, 1995) PRESSMAN, Roger S. Engenharia de Software. São Paulo, Makron Bo-
oks, 1995.
(Silva, 2000) SILVA I. J. de M.. Delphi 5 – Análise de Pontos por Função. Rio de Janeiro,
Book Express, 2000.
(Sommerville, 2003) SOMMERVILLE, I. Engenharia de Software. Addison Wesley, 2003.
(Trindade et al, 1999) TRINDADE A. L. P.; PESSÔA M. S. P.; SPINOLA M. M.. COCOMO
II uma compilação de informações sobre a nova métrica. In V Congresso Interbacional de
52
Engenharia Informática da Universidade de Buenos Aires – Argentina. Disponível em

http://www.psphome.hpg.ig.com.br/downloads/cocomo2.pdf
(Vazquez et al, 2003) VAZQUEZ, C. E.; SIMÕES G. S.; ALBERT R. M. Análise de Pontos
por Função. São Paulo, Érica, 2003.
(Wiegers, 1999) WIEGERS K. E. Process Impact. Tradução Mauricio Aguiar. Disponível em

http://www.bfpug.org/fpug_rio/Newsletter/0101/Introducao_Metricas_Software.htm

Ponto de Função

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ponto de Função

Transféré par

Droits d'auteur :

Formats disponibles

Departamento de Computação

Trabalho de Conclusão de Curso

THEO IGNEZ PAVAN

O Uso de Análise de Pontos por Função no Planejamento

O Uso de Análise de Pontos por Função no

Trabalho de conclusão de curso obrigatório

O Uso de Análise de Pontos por Função no

Londrina, ___ de ___________ de 2004

Dedico este trabalho a Deus, que me deu forças, e a

Este presente trabalho descreve a importância do planejamento no processo de desenvolvi-

2 A CRISE DO SOFTWARE E ENGENHARIA DE SOFTWARE.............................13

3 PLANEJAMENTO DE PROJETO DE SOFTWARE................................................15

4 MÉTRICAS E MEDIÇÕES DE SOFTWARE............................................................17

Tabela 1 – Métricas Orientadas ao Tamanho .......................................................................... 20

Tabela 5 – Países com maiôs número de CFPS ...................................................................... 27

Tabela 7 – Pontos por Função ALI ......................................................................................... 31

Tabela 8 – Complexidade AIE ................................................................................................ 32

Tabela 10 – Complexidade EE ............................................................................................... 33

Tabela 12 – Complexidade SE ................................................................................................ 35

Tabela 13 – Pontos por Função SE ......................................................................................... 35

Tabela 15 – Pontos por Função CE ......................................................................................... 36

Tabela 17 – Linguagens de Programação ............................................................................... 43

Tabela 18 – Níveis do modelo CMM ...................................................................................... 45

APF Análise de Pontos por Função

AIE Arquivo de Interface Externa

CFPS Certificação de especialista em pontos por função

COSMIC Common Software Measurement International Consortium

FFP Full Function Points

IBSG International Software Benchmarking Standards Group

NESMA Netherlands Software Metrics Users Association

PF Pontos por Função

VAF Value Adjustment Factor

O trabalho de conclusão de curso (TCC) tem como tema a importância do

Grande parte dos problemas que ocorre no desenvolvimento de softwares é

Se as empresas já encontram dificuldade na definição do processo de desen-

Segundo AZEVEDO (2003) a análise por pontos de função auxilia: no cál-

Os capítulos 1,2 e 3 contextualizam a análise de pontos por função na área

2 A CRISE DO SOFTWARE E ENGENHARIA DE SOFTWARE

O termo “crise do software” foi muito utilizado na década de 60 devido a

Os principais problemas relacionados à crise do software são: inadequação

A primeira definição atribuída a Engenharia de Software foi dada por Fritz

para se possa obter economicamente um software que seja

O processo de software envolve um conjunto de atividades e resultados as-

Prantoni (2001) afirma que um dos maiores problemas encontrados no de-

Segundo Cordeiro (2000), se não há previsibilidade, é porque não se conse-

3 PLANEJAMENTO DE PROJETO DE SOFTWARE

Segundo Maldonado (2001), há três fases no processo de desenvolvimento

1. Definição: inclui as etapas análise de sistema, o planejamento do proje-

2. Construção: inclui as etapas projeto, codificação e o teste do software.

3. Manutenção: tem como objetivo as mudanças e correções de erros, a-

Figura 1 - Fases do processo de desenvolvimento de software

Observa-se na figura acima que a atividade de planejamento encontra-se na

O planejamento de projeto está fortemente ligado ao desenvolvimento de

No entanto, é muito comum surgir perguntas do tipo: “por que planejar se já

O planejamento é muito importante, pois se reduz à probabilidade de impre-

4 MÉTRICAS E MEDIÇÕES DE SOFTWARE

Por que medir um software? Segundo Wiegers (1999) os projetos de softwa-

Quando se considera boa parte dos empreendimentos técnicos, verifica-se

A quantificação dos aspectos relacionados ao processo de desenvolvimento

? No caso do processo de desenvolvimento, as medições podem permi-

? No caso do produto, as medições podem proporcionar informações a

? Medições diretas, por exemplo, o número de linhas de código (LOC)

? Medições indiretas, as quais permitem quantificar aspectos como a

Londrina, _ de _________ de 2004