Você está na página 1de 89

UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN UTFPR

DIRETORIA DE PESQUISA E PS-GRADUAO


ESPECIALIZAO EM ENGENHARIA DE SOFTWARE

DANIELE WOLFART

ESTIMATIVA DE TAMANHO DE SOFTWARE POR MEIO DA


TCNICA DE ANLISE DE PONTOS DE FUNO

MONOGRAFIA DE ESPECIALIZAO

MEDIANEIRA
2012
DANIELE WOLFART

ESTIMATIVA DE TAMANHO DE SOFTWARE POR MEIO DA


TCNICA DE ANLISE DE PONTOS DE FUNO

Monografia apresentada como requisito


parcial obteno do ttulo de Especialista
na Ps Graduao em Engenharia de
Software, da Universidade Tecnolgica
Federal do Paran UTFPR Cmpus
Medianeira.

Orientador: Prof. M.Sc. Alan Gavioli

MEDIANEIRA
2012
Dedico este trabalho a minha famlia.
AGRADECIMENTOS

Agradeo a Deus pela famlia que me deste, pela minha sade e pelas
oportunidades me proporcionadas at hoje.
Agradeo aos meus pais pela minha vida e pela educao que me deram.
Agradeo em especial aos meus irmos que foram fundamentais para que a
concluso deste trabalho tenha sido realizada.
Agradeo ao meu orientador, professor Alan Gavioli, pela ajuda
proporcionada e pela compreenso e apoio para a finalizao deste trabalho.
Ningum vai bater mais forte do que a vida. No importa como voc bate, mas sim o
quanto aguenta apanhar e continuar lutando, o quanto pode suportar e seguir em
frente. assim que se ganha.

"Rocky Balboa".
RESUMO

WOLFART, Daniele. Estimativa de tamanho de software por meio da tcnica de


Anlise de Pontos de Funo. 2012. 88. Monografia (Especializao em Engenharia
de Software). Universidade Tecnolgica Federal do Paran, Medianeira, 2012.

Um dos maiores problemas encontrados no processo de desenvolvimento de


sistemas concluir projetos com qualidade, dentro dos prazos e oramentos
previstos. Tendo conhecimento do que e quanto precisa ser produzido aumenta
indiscutivelmente o sucesso do gerenciamento e finalizao com xito dos produtos
de software. Desta forma este estudo tem por objetivo definir o conceito de
estimativa de software e sua aplicabilidade no processo de desenvolvimento, como
sendo uma ferramenta de apoio ao planejamento e gerenciamento de sistemas
visando o aumento da qualidade do produto final. Alm de apresentar os tipos de
estimativas disponveis no processo de estimar sistema, o trabalho busca identificar
quais so as principais tcnicas de estimativa de tamanho de software disponveis
no mercado, sua aplicabilidade e suas principais vantagens, para auxiliar no
conhecimento da dimenso dos produtos a serem desenvolvidos. O trabalho
tambm apresenta a definio, o funcionamento e as vantagens da tcnica de
estimativa de tamanho de software: Anlise de Pontos de Funo. Por fim,
apresentado um estudo de caso para demonstrar a aplicabilidade desta tcnica,
atravs da obteno da estimativa de tamanho de um sistema real.

Palavras-chave: Estimativa; Pontos de Funo; Mtricas.


ABSTRACT

WOLFART, Daniele. Estimating software size using the technique of Function Point
Analysis. 2012. 88. Monografia (Especializao em Engenharia de Software).
Universidade Tecnolgica Federal do Paran, Medianeira, 2012.

One of the bigger problem encountered in the process of system development is to


complete projects with quality, on time and budgets provided. Having knowledge of
what and how much needs to be produced arguably increases the success of the
management and successful completion of the systems. Therefore, this study aims to
define the concept of software estimation and its applicability in the development
process, as a tool to support planning and management systems to increase the
quality of the final product. Besides presenting the types of available estimates in the
process of estimating system, the paper seeks to identify which are the main
techniques for estimating size of software available on the market, its applicability
and its main advantages, to assist in understanding the size of the systems to be
developed. The paper also presents the definition, operation and advantages of the
technique to estimate software size: Function Point Analysis. Finally, we present a
case study to demonstrate the applicability of this technique, by obtaining the
estimated size of a real system.

Keywords: Estimate; Function Points; Metrics.


LISTA DE FIGURAS

Figura 1 - Anlise de Projetos de Softwares ............................................................. 15


Figura 2 - Processo de Estimativas de Projetos de Software .................................... 20
Figura 3 - Processo de Contagem de Pontos de Funo.......................................... 47
Figura 4 - Complexidade funcional de ALI e AIE ....................................................... 53
Figura 5 - Contribuio do ponto por funo das funes do tipo dado .................... 55
Figura 6 - Complexidade para entradas externas ..................................................... 56
Figura 7 - Complexidade para sadas externas e consultas externas ....................... 56
Figura 8 - Contribuio dos pontos por funo das funes de transao ................ 58
Figura 9 - Grau de Influencia para as CGS ............................................................... 60
Figura 10 - Modelo de Dados do sistema CBP ......................................................... 75
Figura 11 Tela de Cadastro de Bem Patrimonial.................................................... 77
LISTA DE TABELAS

Tabela 1 - Funes de Dados do sistema CBP......................................................... 76


Tabela 2 - Contribuio das Funes de Dados ....................................................... 76
Tabela 3 - Funes Transacionais do sistema CBP.................................................. 77
Tabela 4 - Contribuio Funes de Transao........................................................ 79
Tabela 5 - Influncia das CGS no sistema CBP ........................................................ 80
LISTA DE SIGLAS

AIE - Arquivo de Interface Externa


ALI - Arquivo Lgico Interno
APF - Anlise de Pontos de Funo
AR - Arquivo Referenciado
BFPUG - Brazilian Function Point Users Group
CBP - Controle de Bens Patrimoniais
CE - Consulta Externa
CFPS - Certified Function Point Specialist
CGS - Caractersticas Gerais de Sistema
COSMIC - Common Software Measurement International Consortium
CPM - Counting Practices Manual / Manual de Prticas de Contagem
EE - Entrada Externa
FFP - Full Function Points
FSM - Functional Size Measurement
GIT - Grau de Influncia Total
GUIDE - Grupo de Usurios IBM
IBM - International Business Machines
IEC - International Engineering Consortium
IFPUG - International Function Point Users Group
ISO - International Organization for Standardization
JTC1 - Joint Technical Committee One
LOC - Lines of Code
PF - Ponto de Funo
SC7 - Sub-Committee Seven
SE - Sada Externa
TD - Tipo de Dado
TI - Tecnologia de Informao
TR - Tipo de Registro
UCP - Use Case Points
UKSMA - United Kingdom Software Metrics Association
VAF - Valor do Fator de Ajuste
XP - Extreme Programming
WG12 - Working Group 12
SUMRIO

1 INTRODUO ............................................................................................... 13
1.1 OBJETIVO GERAL ......................................................................................... 14
1.2 OBJETIVOS ESPECFICOS........................................................................... 14
1.3 JUSTIFICATIVA .............................................................................................. 15
1.4 ESTRUTURA DO TRABALHO ....................................................................... 17
2 ESTIMATIVA DE SOFTWARE ....................................................................... 18
2.1 O PROCESSO DE ESTIMATIVA DE SOFTWARE ........................................ 19
2.2 TIPOS DE ESTIMATIVA ................................................................................. 21
2.2.1 ESTIMATIVA DE TAMANHO .......................................................................... 21
2.2.2 ESTIMATIVA DE ESFORO .......................................................................... 22
2.2.3 ESTIMATIVA DE TEMPO ............................................................................... 24
2.2.4 ESTIMATIVA DE CUSTO ............................................................................... 25
2.3 TCNICAS DE ESTIMATIVAS DE TAMANHO .............................................. 26
2.3.1 Linhas de Cdigo ............................................................................................ 26
2.3.2 Padro ISO de Medio Funcional ................................................................. 27
2.3.3 Anlise de Pontos de Funo ......................................................................... 28
2.3.4 Mark II ............................................................................................................. 30
2.3.5 COSMIC FFP .................................................................................................. 31
2.3.6 UCP ................................................................................................................ 32
2.3.7 Planning Poker ............................................................................................... 34
3 ANLISE DE PONTOS DE FUNO ............................................................ 37
3.1 OBJETIVOS DA APF ...................................................................................... 38
3.2 ALGUMAS RAZES PARA UTILIZAR APF ................................................... 39
3.3 DEFINIO DE TERMOS .............................................................................. 42
3.3.1 Usurio ........................................................................................................... 42
3.3.2 Lgico ............................................................................................................. 43
3.3.3 Aplicativo ........................................................................................................ 43
3.3.4 Projeto ............................................................................................................ 45
3.3.5 Arquivo............................................................................................................ 45
3.4 PROCESSO DE CONTAGEM ........................................................................ 46
3.4.1 TIPO DE CONTAGEM .................................................................................... 47
3.4.2 FRONTEIRA DA APLICAO E O ESCOPO DA CONTAGEM..................... 49
3.4.3 CONTAGEM DAS FUNES DO TIPO DADOS ........................................... 51
3.4.4 CONTAGEM DAS FUNES DO TIPO TRANSAO ................................. 55
3.4.5 CONTAGEM DE PONTOS DE FUNO NO AJUSTADOS ........................ 59
3.4.6 DETERMINAR O VALOR DO FATOR DE AJUSTE ....................................... 60
3.4.7 CALCULAR OS PONTOS DE FUNO AJUSTADOS .................................. 64
4 ESTUDO DE CASO........................................................................................ 69
4.1 LOCAL DO ESTUDO ...................................................................................... 69
4.2 TIPO DE PESQUISA OU TCNICAS DE PESQUISA.................................... 70
4.3 COLETA DOS DADOS ................................................................................... 70
4.4 ANLISE DOS DADOS .................................................................................. 75
5 RESULTADOS E DISCUSSO ..................................................................... 76
6 CONSIDERAES FINAIS ........................................................................... 82
6.1 CONCLUSES ............................................................................................... 82
6.2 TRABALHOS FUTUROS/CONTINUAO DO TRABALHO .......................... 83
REFERNCIAS ......................................................................................................... 84
13

1 INTRODUO

Atualmente, o sucesso das organizaes de desenvolvimento de software no


mercado globalizado e competitivo que o da rea de Tecnologia de Informao
(TI), est diretamente ligado ao nvel da qualidade do produto final, baseado na
eficincia, entrega do produto no prazo estabelecido e dentro do oramento previsto
(MONTEIRO, 2005).
Uma das maiores dificuldades encontradas no gerenciamento de projetos de
informtica saber a dimenso do que est sendo gerenciado. Muitas aplicaes
que a princpio parecem pequenas, ao longo do desenvolvimento mostram-se muitas
vezes maiores do que o previsto inicialmente ou, em alguns casos, torna-se to
complexas e grandes, que se perde o controle. Devido a isso os mecanismos de
acompanhamento e avaliao do progresso do processo, projeto e produto,
geralmente baseados em informaes qualitativas e quantitativas, coletadas atravs
de medies, so recursos essenciais e cada vez mais importantes na gesto do
desenvolvimento de software (SIMES, 2004; MONTEIRO, 2005).
Segundo Barcellos (2010), a medio de software considerada uma das
atividades mais importantes para a gerncia e melhoria de processos e produtos de
software, uma vez que ao serem coletadas e armazenadas, podem ser analisadas
atravs de mtodos e fornecem informaes importantes para a tomada de deciso,
servindo tambm como subsdios para a elaborao de planos mais realistas para
os projetos.
Para o gerente do projeto, essas medidas, tambm conhecidas como
mtricas permitem um melhor entendimento do processo de produo e do controle
do projeto de software e so de extrema importncia para gerar o produto final com
a mxima qualidade. Exatamente essa necessidade de medidas que retratem a
eficincia do desenvolvimento e minimizem os fracassos de projetos, principalmente
em relao a falhas no cronograma e em estimativas realizadas, que demandaram a
realizao de estudos na rea de estimativas de software (MONTEIRO, 2005).
Os atos de medir e de estimar esto entre as partes mais importantes de um
projeto de sistema bem-sucedido e alguns fatos como: a falta de maturidade, o
desinteresse das empresas de desenvolvimento de sistemas e a baixa popularidade
deste assunto entre os profissionais da rea de informtica so algumas das
14

principais causas para o insucesso e o alto custo dos sistemas de informao


(GOMES, 2003).
Para Gomes (2003) o termo mtrica de software refere-se mensurao dos
indicadores quantitativos do tamanho e complexidade de um sistema utilizados para
comparar contra os desempenhos observados (qualitativos) no passado a fim de
derivar previses de desempenho futuro.
Segundo Hazan (2009) e Freire (2008), as estimativas de tamanho, esforo,
prazo e custo constituem o primeiro tipo de anlise quantitativa que deve ser
executado para melhorar o planejamento e o acompanhamento de projetos de
software, pois so as estimativas de m qualidade que constituem uma das
principais causas dos projetos cancelados. J as estimativas inadequadas podem
levar a prazos no cumpridos, custos excessivos com horas extras e m qualidade
do software.
Este trabalho abranger o estudo de estimativa de tamanho de software, que
segundo Vazquez et al. (2010) uma das propriedades mais importantes do
desenvolvimento de software a ser medida, com foco para a tcnica de Anlise de
Pontos de Funo.

1.1 OBJETIVO GERAL

Demonstrar o funcionamento e a aplicabilidade da tcnica de Anlise de


Pontos de Funo como um meio de estimar tamanho de software.

1.2 OBJETIVOS ESPECFICOS

Compreender os conceitos, os tipos e as tcnicas de estimativa de


software;
15

Compreender a tcnica de Anlise de Pontos de Funo, identificando sua


aplicabilidade.
Obter a estimativa de tamanho de um sistema aplicando a tcnica de
Anlise de Pontos de Funo.

1.3 JUSTIFICATIVA

Segundo Barcellos (2010), os avanos tecnolgicos e a alta competitividade


do mercado esto continuamente aumentando a demanda por softwares cada vez
melhores e que sejam produzidos em projetos aderentes aos custos e prazos
planejados. Porm, a tendncia de projetos de TI, voltados a desenvolvimento de
software, apresentarem falha nas estimativas de tempo e esforo e principalmente
custo, ou seja, projetos com atraso na entrega ou que estejam fora do oramento
inicial (TORRES, 2004; GERMANO, 2008). Segundo Santana; Gusmo (2010) esta
caracterstica j vem de longa data, apresentada por Pressman (2006) apud Hazan
(2009) como um dos trs sintomas da Crise de Software, por volta da dcada de 80,
quando os nmeros eram ainda piores (conforme Figura 1). Foi a partir deste
momento que surgiu a preocupao em identificar as causas e obter melhores
resultados nos projetos de desenvolvimento de software.

Figura 1 - Anlise de Projetos de Softwares


Fonte: SANTANA e GUSMO (2010)

Para Torres (2004) essa caracterstica apresentada por projetos de softwares


de falharem em estimativas de tempo, esforo e custo so resultado de previses
16

baseadas apenas em parmetros qualitativos que acabam sendo mal gerenciados, e


diz:

Se compararmos com projetos de Engenharia Civil, seria como se soubssemos o


que deve ser feito em uma casa a ser construda (como ser o acabamento e o piso, quais
sero as cores das paredes, se ser um sobrado ou uma casa trrea, se ter piscina ou no,
se ter quartos e sutes, etc.), porm no saberamos que tamanho ter cada cmodo e
conseqentemente, qual ser o tamanho total em metros quadrados da casa construda.
Somente saberamos ao final do projeto qual o tamanho do software (TORRES, 2004).

A falta de um parmetro quantitativo que diga o tamanho do software a ser


construdo gerou a necessidade de se estabelecer um sistema de medio para
prover um mecanismo de quantificao do que acontece no processo de
desenvolvimento de software, possibilitando a analogia com outros softwares
anteriormente desenvolvidos (TORRES, 2004). Esta necessidade foi formalizada por
De Marco (DEMARCO, 1982 apud SANTANA e GUSMO, 2010) atravs da frase:
No podemos controlar aquilo que no podemos medir. Assim, baseado no
tamanho de um software e no tempo que foi gasto para sua concluso, possvel
estimar mais precisamente quanto tempo ser preciso para desenvolver um novo,
com caractersticas ou cenrios idnticos, da a grande importncia em se estudar e
entender estimativa de software.
Para saber o custo de um projeto de software preciso saber o esforo
necessrio para desenvolv-lo e para determinar o esforo preciso mensurar o
tamanho do projeto de software. Desta forma, determinar o tamanho de um projeto
de software uma das primeiras e principais atividades relacionadas a estimativas a
serem efetuadas durante o clico de vida do projeto (MACORATTI, 2005).
Alm disso, a falta de previsibilidade de custo e prazo de projetos de software
pode levar a conseqncias desastrosas, tais como: conflitos entre o gerente do
projeto e a equipe, baixa estima da equipe, entrega de software de baixa qualidade,
perda de imagem da organizao, e at mesmo o cancelamento do projeto. Assim,
torna-se importante o investimento na implantao de um processo de estimativas
efetivo, visando melhoria da previsibilidade de custo, prazo e esforo (HAZAN,
2009).
17

1.4 ESTRUTURA DO TRABALHO

Para facilitar a compreenso do estudo, esse trabalho est organizado em


seis captulos. O primeiro apresenta uma introduo ao conceito de mtricas de
software e porque houve a necessidade de se realizar estimativas de software.
Tambm apresenta os objetivos gerais e especficos do presente trabalho, bem
como a justificativa deste trabalho e uma breve apresentao do tema a ser tratado
nos demais captulos.
O captulo II apresenta o conceito, os tipos e tcnicas de estimativa de
software.
No capitulo III ser abordada a tcnica de Anlise de Pontos de Funo.
No captulo IV feito um estudo de um sistema para a aplicao da tcnica
de APF na realizao da estimativa de tamanho deste software.
O captulo V apresenta os resultados e discusso da aplicao da tcnica de
contagem de PF.
No captulo VI so relatadas as consideraes finais sobre o desenvolvimento
do presente trabalho e as sugestes para trabalhos futuros relacionados ao tema.
18

2 ESTIMATIVA DE SOFTWARE

Realizar estimativas uma das atividades mais desafiadoras e importantes


em um projeto de software. O planejamento e controle de um projeto no seria
possvel sem a realizao de estimativas confiveis, que apiam principalmente as
atividades de gesto de projetos de software (DEMARCO, 1991 apud MACORATTI,
2005; MONTEIRO, 2005).
O propsito principal de um processo de estimativa disponibilizar
informaes que beneficiem o planejamento e o controle dos projetos de software o
mais cedo possvel durante seu ciclo de vida (VAZQUEZ et al., 2010). Se bem
elaboradas permitem a verificao da viabilidade do projeto, a elaborao de
propostas tcnicas e comerciais, a confeco de planos e cronogramas detalhados e
o acompanhamento efetivo de projetos (MONTEIRO, 2005).
Silveira (2000) define o termo estimativa como sendo a medida aproximada
de tamanho, esforo, durao e equipe necessria para o desenvolvimento de um
projeto.
Antes de iniciar um projeto, deve-se estimar o trabalho a ser realizado
(tamanho/esforo), os recursos necessrios, o tempo de durao (cronograma) e,
por fim, o custo do projeto. Apesar da realizao de estimativa ser uma tarefa trivial,
muitas vezes, um pouco arte, um pouco cincia, uma atividade muito importante
que no deve ser conduzida desordenadamente (CARVALHO et al., 2006).
Cada projeto de software tende a se constituir em uma experincia nica
devido a particularidades em relao aos seus requisitos, tecnologia empregada e a
equipe de trabalho. Diante desta realidade, definir com exatido o custo final e a
data de concluso de um projeto de software somente possvel quando o projeto
estiver finalizado. Toda a atividade e clculo feito durante o ciclo de vida do projeto
so estimativas. Contudo as informaes obtidas atravs de estimativas, mesmo no
sendo totalmente precisas, so de grande valia para constituir uma coleo de
dados histricos que pode ser usada para extrair indicadores de produtividade e
qualidade cada vez mais prximos da realidade e cada vez mais confiveis
(VAZQUEZ et al., 2010).
19

2.1 O PROCESSO DE ESTIMATIVA DE SOFTWARE

Segundo Vazquez et al. (2010), o processo de estimativa de um projeto de


software envolve basicamente quatro atividades:
1. Estimar o tamanho do produto a ser gerado;
2. Estimar o esforo empregado na execuo do projeto;
3. Estimar a durao do projeto;
4. Estimar o custo do projeto.
Determinar o tamanho do produto de software tem sido tomado como o ponto
de partida para a realizao de estimativas, pois com base nas estimativas de
tamanho, possvel chegar estimativa de esforo e, a partir dessas, fica mais fcil
estimar recursos, tempo e custo (CARVALHO et al., 2006). Porm, antes de iniciar o
processo de estimativa de tamanho, necessrio decidir a unidade de medida a ser
utilizada (VAZQUEZ et al., 2010).
Aps a definio da unidade de medida de tamanho a ser utilizado, o
processo de estimativa conforme mostra a Figura 2, tem incio com a estimativa de
tamanho do projeto tendo como base a declarao do escopo do sistema. Como as
estimativas devem ser realizadas no incio do processo de desenvolvimento de
software, ento, o principal insumo ou artefato de entrada a ser utilizado
frequentemente um documento inicial de requisitos ou at mesmo um documento do
prprio cliente (HAZAN, 2009; MACAROTTI, 2005).
20

Figura 2 - Processo de Estimativas de Projetos de Software


Fonte: HAZAN (2009)

O responsvel pelas estimativas deve analisar os requisitos para garantir a


qualidade e ento estimar o tamanho do projeto de software de acordo com a
unidade de medida escolhida. O prximo passo a derivao das estimativas de
esforo, prazo (cronograma) e custo (oramento). Para que as estimativas sejam
completas e eficientes, devem ser feitas com base na estimativa de tamanho e levar
em considerao as experincias e os dados histricos de projetos passados, os
recursos disponveis dentro e fora da organizao, os dados de custo e os fatores de
riscos que envolvem os projetos (HAZAN, 2009; VAZQUEZ et al., 2010).
A cada etapa realizada, as estimativas obtidas devem passar por um
processo de aprovao, antes de serem registradas na base histrica. Alm de
poderem ser utilizadas como fonte de informao para projetos futuros, servir como
insumos para as estimativas das etapas seguintes (VAZQUEZ et al., 2010).
21

No decorrer do processo de desenvolvimento, as estimativas devem ser


acompanhadas conforme o refinamento dos requisitos. Conforme mais informaes
forem sendo obtidas, as estimativas iniciais podem e devem ser refeitas e refinadas.
Re-estimar deve ser uma atividade constante durante todo o ciclo de vida do
desenvolvimento do software, principalmente se ocorrerem mudanas significativas
nos requisitos funcionais ou no funcionais (HAZAN, 2009; MACORATTI, 2005).
Quando o projeto concludo, devem-se documentar as medidas reais de
tamanho, prazo, custo, esforo e recursos utilizados, assim como outros atributos
relevantes do projeto, visando coleta de dados para a melhoria do processo de
estimativas (VAZQUEZ et al., 2010).

2.2 TIPOS DE ESTIMATIVA

As sees seguintes abrangero as principais formas de estimativas de


software: tamanho, esforo, tempo e custo.

2.2.1 ESTIMATIVA DE TAMANHO

Estimativa de tamanho de software um processo pelo qual uma pessoa ou


um grupo de pessoas estima o tamanho de um produto de software (McPHEE, 1999
apud ANDRADE, 2004).
O tamanho do produto de software o ponto de partida para a realizao de
estimativas, pois so as estimativas de tamanho que constituem o insumo principal
para a maioria dos modelos usados para estimar custo, esforo e cronograma e
conseqentemente a preciso da estimativa de tamanho fundamental (FIORINI et
al., 1998 apud CARVALHO et al., 2006; STAA; HAZAN, 2005).
O tamanho do software significa a quantidade de trabalho a ser executado no
desenvolvimento de um projeto em uma unidade de medida especificada. Cada
projeto pode ser estimado de acordo com o tamanho fsico (geralmente medidos de
acordo com os requisitos do usurio); com base nas funes que o usurio obtm,
22

na complexidade do problema que o software ir resolver e no reuso do projeto, que


mede o quanto o produto ser copiado ou modificado a partir de outro produto
existente (MONTEIRO, 2005; ANDRADE, 2004)
Segundo Ross (S.d.) apud Freire (2008), determinar o tamanho de um projeto
de software uma das primeiras e principais atividades relacionadas s estimativas
a serem efetuadas durante o ciclo de vida do projeto, alm de ser uma das
atividades mais difceis de serem realizadas em uma organizao de
desenvolvimento de software, principalmente quando realizada no incio do projeto
Quanto maior for o conhecimento e o detalhamento das informaes sobre o
projeto melhor sero os subsdios para a elaborao da estimativa de tamanho. As
estimativas geralmente acontecem em fases iniciais de um projeto, quando o
entendimento sobre o que deve ser desenvolvido ainda incipiente. Por isso, em
fases posteriores, a estimativa deve ser refeita quando mais informaes sobre o
projeto tornarem-se disponveis (MONTEIRO, 2005)
As primeiras mtricas de estimativa de tamanho de software surgiram em
1950/1960 e se basearam no tamanho fsico de linhas de cdigo como o Lines of
Code (LOC). Esta mtrica considera o software sob a perspectiva da estrutura
interna e aplicada nas fases finais do projeto (ANDRADE, 2004).
Atualmente, existem diversas mtricas de estimativa de tamanho de projetos
de software, e h dificuldade para selecionar a mais apropriada para o tamanho de
um projeto de software de uma organizao. As mtricas mais conhecidas e
utilizadas foram desenvolvidas com base nas funes de software tais como:
Function Point Analysis (Anlise por Pontos de Funo); COSMIC Full Function
Point, Internet Points, Domino Points, Use Case Points (Pontos de Caso de Uso)
(ANDRADE, 2004; MONTEIRO, 2005). Essas mtricas sero apresentadas no
decorrer deste captulo.

2.2.2 ESTIMATIVA DE ESFORO

O esforo para desenvolver um novo sistema pode ser definido como a


quantidade de trabalho necessria para completar uma atividade ou outro elemento
23

de um projeto e geralmente expresso como um total de horas, dias, meses ou


semanas gastos por um grupo de pessoas na realizao de suas atividades
(FREIRE, 2008; HAZAN, 2009). Freire (2008) ressalta que o esforo no deve ser
confundido com durao, que pode ser definida como o tempo necessrio para
completar uma atividade ou outro elemento de um projeto.
O esforo estimado para o projeto geralmente obtido a partir do clculo da
estimativa de tamanho do produto. O esforo total de um projeto calculado com
base em seu processo de desenvolvimento, que envolve no somente a atividade de
codificao do software, mas tambm de elaborao de documentos,
implementao de prottipos, projeto do produto a ser entregue, reviso e teste do
cdigo (PETERS, 1999 apud MONTEIRO, 2005).
Segundo Gomes (2003) e Silveira (2000), uma tcnica para auxiliar na melhor
preciso da estimativa de esforo necessrio para o desenvolvimento do produto,
realizar esta estimativa para o maior nvel de detalhamento das fases do projeto, ou
seja, se possvel aplicada a cada tarefa do projeto para cada funo de software.
Para estimar o esforo e prazo, preciso que seja selecionada uma
abordagem para a obteno da estimativa (modelos paramtricos, analogia,
julgamento de especialistas, modelo de estimativas baseado em atividades, relaes
simples de estimativas) (FREIRE, 2008). Segundo Vazquez et al. (2010), a melhor
maneira de se chegar estimativa de esforo a partir da estimativa de tamanho do
projeto utilizar-se de dados internos da prpria organizao, como o nmero de
horas alocadas em projetos passados, conjuntamente com o tamanho do projeto,
dimensionado em suas diversas fases.
A estimativa de esforo de extrema importncia, pois com ela j definida
torna-se muito mais fcil a realizao da estimativa de prazo de um projeto. Alm
disso, a falta de estimativas de esforo e do tempo necessrio para executar um
projeto pode tornar invivel o planejamento e o gerenciamento de um projeto de
software, pois sem essas estimativas no se pode saber se o projeto est atrasado
ou se seu custo foi maior do que o estimado (MONTEIRO, 2005).
24

2.2.3 ESTIMATIVA DE TEMPO

Com as estimativas de tamanho e esforo calculadas para um projeto de


software podem-se, ento, determinar as estimativas de prazo. Isto geralmente
demanda estimativa de quantas pessoas estaro envolvidas no projeto, que
atividades sero executadas, e quando essas atividades iniciaro e sero
finalizadas. Tanto dados histricos quanto modelos de dados da indstria podem ser
usados para predizer o nmero de pessoas necessrias para um tamanho de projeto
e como o trabalho pode ser dividido dentro do prazo previsto. Para isso, geralmente
so utilizadas ferramentas de planejamento de projeto que contenham cronograma
(MONTEIRO, 2005).
A estimativa de prazo de maneira simplificada pode ser dada pela razo entre
o esforo previsto (geralmente em nmero de horas trabalhadas) e a quantidade de
recursos alocada na execuo do projeto, conforme equao (1) (FREIRE, 2008;
MONTEIRO, 2005):

(1)

Porm, Gomes (2003) ressalta a importncia de ao estimar o tempo de


durao do projeto tomar cuidado com a relao tempo/pessoas, pois se um projeto
for estimado em dez pessoas-ms e h cinco pessoas disponveis, no
necessariamente ele levar dois meses para ser concludo. necessrio realizar
anlise da produtividade da equipe, distribuio das tarefas, verificarem a
disponibilidade dos integrantes, entre outras atividades geralmente sob
responsabilidade do gerente de projeto e em sua maioria controladas por
cronogramas. Outro exemplo que gerentes devem tomar cuidado com a
duplicao do nmero de pessoas em um projeto, que no reduz necessariamente a
durao do projeto pela metade (muito pelo contrrio, colocar mais pessoas num
projeto em andamento apenas retardar ainda mais o processo, uma vez que estas
pessoas devero receber treinamento adequado e "aprender" todo o projeto desde
seu incio at a fase atual, o que consome muito tempo).
25

Segundo Bassi (2009), estimar durao corresponde precisamente em dizer


quanto tempo a equipe levar para concluir o trabalho. Deve-se tomar cuidado, pois
para a mesma tarefa, o tempo para a sua realizao pode variar, por exemplo,
conforme o tamanho da equipe e a disponibilidade de seus membros, pois esses
fatores influem na velocidade de desenvolvimento.

2.2.4 ESTIMATIVA DE CUSTO

O objetivo das estimativas de custo calcular de maneira antecipada todo e


qualquer custo que esteja associado ao sistema, tais como recursos necessrios
humanos, tecnolgicos, burocrticos e de infra-estrutura, ao longo de todo processo
de desenvolvimento do produto: fases de construo, instalao, operao, melhoria
e manuteno (LEITE, 2006; GOMES, 2003; SIMOES, 2004).
Segundo Freire (2008), em projetos de software, o custo geralmente
proporcional ao esforo despendido para sua construo, onde o trabalho humano
o principal recurso a ser consumido. Conseqentemente, o custo com freqncia
associado a homens-ms ou homens-hora.
Porm, existem muitos fatores a ser considerados quando se est estimando
o custo total de um projeto de software, como por exemplo: horas trabalhadas
(salrios e encargos); aquisio ou aluguel de hardware e software; viagens com
reunies e testes no cliente; contas telefnicas (ligaes de longas distncias, vdeo-
conferncia, linhas dedicadas para testes, etc.), treinamentos: cursos, livros e
manuais, infraestrutura: salas de trabalho, energia aquecimento/refrigerao, redes e
Internet, entre outros custos (FREIRE, 2008; LEITE, 2006).
Segundo Monteiro (2005), uma forma de obter o custo total das horas
trabalhadas pelo produto da estimativa de esforo do projeto (em horas) e valor de
uma hora trabalhada (R$ por hora). Um custo total mais preciso pode ser obtido por
meio do valor das horas trabalhadas especficas de cada recurso utilizado no projeto
(recursos tcnicos, recursos de suporte, gerente de projeto, etc.), ou por meio da
26

determinao do percentual de esforo total do projeto a ser realizado em cada


etapa do processo pelos recursos do projeto.

2.3 TCNICAS DE ESTIMATIVAS DE TAMANHO

Tendo em vista que o foco deste trabalho est voltado anlise de


estimativas de tamanho de software, as sees seguintes apresentaro alguns dos
principais mtodos de medio funcionais desenvolvidos e muito utilizados ao longo
da histria de desenvolvimento de software, como: Linhas de Cdigo (LOC), Mark II,
COSMIC-FFP, Use Case Points (UCP) e Anlise de Pontos de Funo.

2.3.1 Linhas de Cdigo

A indstria de software surgiu por volta da dcada de 40 e seus 10 primeiros


anos, entre 1947 e 1957, representaram a fabricao de software muito pequena,
raro eram os programas que ultrapassavam 1000 declaraes em seu cdigo fonte.
Todos estes eram escritos em linguagens de baixo nvel, seja assembly1 ou
linguagem de mquina (SANTANA; GUSMO, 2010).
As primeiras tentativas de se medir tamanho de software, em cerca de 1950,
utilizou a tcnica de mensurao por Linhas de Cdigo, muito utilizada at meados
da dcada de 70. Ela consiste em definir que o tamanho de um sistema deve ser
medido pela contagem do nmero de linhas do cdigo fonte do seu programa. Essa
mtrica considera o software sob a perspectiva de sua estrutura interna e aplicada
nas fases finais do projeto, uma vez que a quantidade exata de linhas de cdigo s
conhecida aps a concluso do sistema (MACORATTI, 2005; MONTEIRO, 2005).
As linhas de cdigo apresentam um resultado imediato da atividade de
desenvolvimento do produto final, porm, no considera diretamente, diversas outras
atividades envolvidas, como: requisitos, arquitetura, testes e outras. Alguns autores

1
Assembly uma linguagem de programao, provavelmente a primeira da histria, surgida na
dcada de 50, quando os computadores ainda usavam vlvulas. A idia do Assembly usar um
comando em substituio a cada instruo de mquina (MORIMOTO, 2005)
27

consideram que estas atividades esto implicitamente consideradas, ou seja, para


se produzir certo nmero de LOC, livre de defeitos, utilizando certo processo de
software, necessrio especificar os requisitos, projetar e modelar a arquitetura e
testar o cdigo, por exemplo (LEITE, 2009b).
Apesar da mtrica de LOC ser muito simples e ser muito fcil automatizar sua
implementao, percebe-se que uma mtrica muito frgil e imprecisa, por
apresentar algumas desvantagens, como (MONTEIRO, 2005; MACORATTI, 2005;
HAZAN, 2009):
Definio de linha de cdigo ser subjetiva, sem padres para contagem,
no estando claro se deve incluir ou no na contagem linhas em branco,
linhas de comentrio, declarao de dados e linhas de instrues, etc;
uma medida tcnica, sem significado para o usurio;
No consistente, pois algumas linhas de cdigo so mais trabalhosas que
outras;
Dependncia do grau de reuso;
O tamanho de um software em linhas de cdigo varia de uma linguagem de
programao para outra;
Apresenta problemas de definio para linguagens no procedurais;
Penaliza programas pequenos e bem projetados;
Ser bastante complicado e subjetivo aplicar esta mtrica em um processo
de estimativas cujo insumo um documento inicial de requisitos.

2.3.2 Padro ISO de Medio Funcional

Medio funcional o termo referente a mtodos que dimensionam o


tamanho do software a partir das funes requisitadas pelo usurio. No comeo da
dcada de 90 diante do grande nmero de mtodos de Medio Funcional de
tamanho (Functional Size Measurement - FSM), surgidos a partir da Anlise de
Pontos de Funo proposto por Albrecht e com o objetivo de acabar com a
inconsistncia existente entre esses mtodos e criar um mtodo mais rigoroso de
medio funcional, grupos de trabalho de mtricas de software da Austrlia, Reino
28

Unido, Holanda e Estados Unidos formaram um grupo de trabalho denominado


WG12 (Working Group 12), subordinado ao SC7 Sub-Committee Seven do JTC1
Joint Technical Committee One estabelecido pela ISO International Organization
for Standardization em conjunto com o IEC International Engineering Consortium
(VAZQUEZ et al., 2010; ASMA, 1999).
Como resultado dos trabalhos do WG12, foi estabelecido um conjunto de
padres internacional chamado de norma 14143 (ISO/IEC 14143). A norma ISO/IEC
14143 foi estabelecida para garantir que todos os mtodos de medio funcional
sejam baseados em conceitos semelhantes, e possam ser testados para assegurar
o comportamento similar e da forma esperada pelo mtodo, dependendo dos
domnios funcionais a que se aplicam (VAZQUEZ et al., 2010).
No fim de 2002 a tcnica de Anlise de Pontos de Funo mantida pelo
IFPUG, foi aprovado como um mtodo de medio funcional dentro dos padres
exigidos pela norma ISO/IEC 14143 sob a denominao ISO/IEC 20926:2002.
Porm, essa tcnica contemplada apenas at a determinao dos pontos de
funo no ajustados. As caractersticas gerais do manual de contagem do IFPUG,
que so utilizadas para estabelecer o fator de ajuste, possuem requisitos
tecnolgicos e de qualidade o que tornam essa parte do processo excluda do
padro de medio funcional da ISO.
Segundo VAZQUEZ et al. (2010), atualmente so cinco os mtodos de
medio funcional que so aderentes ao ISO/IEC 14143:
IFPUG CPM 4.3 (ISO/IEC 20926);
NESMA CPM 2.1 (ISO/IEC 24570);
Mark II (ou MK II) CPM 1.3.1 (ISO/IEC 20968);
COSMIC-FFP Measurement Manual 2.2 (ISO/IEC 19761);
FISMA 1.1 (ISO/IEC 29881).

2.3.3 Anlise de Pontos de Funo

A Anlise de Pontos de Funo (APF) uma tcnica para medir o


desenvolvimento do software do ponto de vista do usurio, pela quantificao das
29

funcionalidades a ele oferecidas. A unidade de medida desta tcnica Ponto de


Funo (VAZQUEZ et al., 2010).
A tcnica da Anlise de Pontos de Funo surgiu na International Business
Machines (IBM), no incio da dcada de 1970, como alternativa s mtricas
baseadas em linhas de cdigo. Na poca, Allan Albrecht foi encarregado de medir a
produtividade de vrios projetos de software desenvolvidos por uma unidade da IBM.
Esses projetos tinham sido desenvolvidos em vrias linguagens de programao
distintas, tornando invivel uma anlise conjunta de produtividade usando a mtrica
de linhas de cdigo. Isso motivou a busca por uma medida que fosse independente
da linguagem de programao utilizada, criando ento a tcnica de Anlise de
Pontos de Funo. Os conceitos desta tcnica foram introduzidos por Allan J.
Albrecth, em uma conferncia do GUIDE Grupo de Usurios IBM, em 1979
(VAZQUEZ et al., 2010; MACORATI, 2005).
A tcnica foi refinada por Albert em 1984, a partir de ento houve um aumento
considervel na sua utilizao, o que levou a necessidade de definir um padro para
aplicao da tcnica. Com este objetivo foi criado em 1986 o International Function
Point Users Group (IFPUG) que passou a ser responsvel, entre outros, pela
elaborao, manuteno e divulgao de um manual de prticas de contagem (COM
Counting Practices Manual), alm de realizar treinamentos e manter um programa
de certificao para profissionais especializados em aplicar a tcnica de APF (CFPS
Certified Function Point Specialist). Essa organizao foi originada em Toronto e
hoje se encontra nos Estados Unidos contendo pouco mais de 3000 afiliados de
vinte pases diferentes (VAZQUEZ et al., 2010; PARO, 2005; SANTANA; GUSMO,
2010).
Em 1990 foi lanada a primeira verso do Manual de Prticas de Contagem
com o objetivo de padronizar a tcnica. Em Fevereiro de 2012, o manual est na
verso 4.3 (VAZQUEZ et al., 2010; IFPUG, 2011).
Segundo Macoratti (2005) a APF a tcnica mais usada para estimativa de
tamanho de software. Em 1998, foi constitudo o BFPUG Brazilian Function Point
Users Group o representante do IFPUG no Brasil.
A APF tem como objetivo medir o tamanho do projeto de software a partir do
ponto de vista do usurio do software, levando em conta basicamente as
30

caractersticas do sistema do ponto de vista da sua fronteira com o usurio


independente da metodologia de desenvolvimento, da plataforma e da tecnologia
utilizadas no desenvolvimento da aplicao. Ou seja, a APF busca medir o que o
software faz, e no como ele foi construdo (MACORATI, 2005; HAZAN, 2009;
VAZQUEZ et al., 2010).
importante destacar que pontos de funo no medem diretamente esforo,
produtividade ou custo, pois exclusivamente uma medida de tamanho funcional do
software. Este tamanho em conjunto com outras variveis que pode ser usado
para derivar produtividade, estimar esforo e custo (VAZQUEZ et al., 2010). O
captulo 3 apresentar maiores informaes a respeito desta tcnica.

2.3.4 Mark II

A tcnica Mark II, ou simplesmente MK II, foi criada por Charles Symons,
inspirado na proposta de Albrecht, como um mtodo proprietrio da empresa KPMG
nos anos de 1985/86. Visa melhorar a escala de tamanho funcional, contando mais
apuradamente a complexidade de processamento interno de Sistemas de
Informaes Gerenciais (VAZQUEZ et al., 2010; PARO, 2005).
Uma das diferenas principais entre APF e MK II que a primeira tcnica
conta Arquivos Lgicos uma vez para cada parte de software sendo mensurada,
enquanto que a MK II conta tipos de entidade toda vez que elas so referenciadas
em cada transao lgica. Segundo o manual do MK II, as duas mtricas pontuam
similarmente os projetos com at 400 pontos de funo. Ultrapassando esse valor, a
tendncia que a mtrica MK II pontue valores maiores que a APF (PARO, 2005).
Segundo Vazquez et al. (2010) a disseminao da tcnica foi dificultada
inicialmente, pelo fato de ser um mtodo proprietrio de uma empresa de consultoria
(a KPMG). Mas atualmente o mtodo de domnio pblico e a associao
responsvel por manter o padro da tcnica a associao de mtricas do Reino
Unido UKSMA (United Kingdom Software Metrics Association), que tambm possui
31

aes e objetivos similares ao do IFPUG. No entanto, um mtodo de aplicao


restrita no Reino Unido.

2.3.5 COSMIC FFP

O mtodo COSMIC Full Function Points (COSMIC FFP) uma das


abordagens de medio funcional de tamanho de software mais atuais. Foi proposta
em 1997 com o nome de Full Function Points v.1, como uma adaptao da mtrica
FPA/IFPUG, para sistemas real time. Em 1999 o grupo Common Software
Measurement International Consortium COSMIC props a abordagem COSMIC
FFP V.2.1 (Cosmic Ponto de funo cheio V.2.1) como uma mtrica totalmente
independente de outras mtricas, projetada para trabalhar tanto com aplicaes de
negcio como com softwares em tempo real (CALAZANS, 2003; MONTEIRO, 2005).
Essa tcnica foi criada para medir o tamanho de um software baseado em
suas funcionalidades. Foi proposta para tratar tanto requisitos de softwares
embarcados como de tempo real e surgiu como uma alternativa de mensurao
mais exata (de forma a no gerar dvidas, no sendo ambgua), com independncia
de domnio e propondo diferentes medidas para diferentes propsitos (considerando
a viso do usurio e do desenvolvedor) (CALAZANS, 2003; MONTEIRO, 2005).
A mtrica COSMIC possui vrias caractersticas que a diferenciam das
mtricas j existentes, tais como (CALAZANS, 2003):
A possibilidade de aplicar a viso do usurio final e do desenvolvedor
(todas as mtricas desconsideram a viso do desenvolvedor e em muitos
processos a viso do desenvolvedor responsvel por uma mensurao
mais acurada do produto);
A identificao de camadas (considerando que a maioria das tecnologias
existentes trabalha com este paradigma);
A flexibilidade (utilizando a abordagem FPA uma EE Entrada Externa -
pode ter no mximo de 3 a 6 pontos, no COSMIC depende de quantos
movimento efetua);
32

E a aplicabilidade de forma mais simples e menos ambgua.


Segundo Cappelli (2009), a vantagem de utilizao da tcnica de COSMIC -
FFP o fato de ser possvel realizar estimativas de tamanho, em fases iniciais de
projeto, porm apresenta como grande ponto negativo o fato de possuir pouco relato
de experincia prtica usando essa tcnica.

2.3.6 UCP

A tcnica de estimativa por Pontos de Caso de Uso foi proposta em 1993 por
Gustav Karner, da Objectory (atual, Rational Software) para medir o tamanho de
projetos de software orientados a objeto, com base nas especificaes de Casos de
uso. Uma tcnica baseada em dois mtodos muito utilizados: o mecanismo de Anlise
de Pontos de Funo e na metodologia conhecida como Mk II, uma adaptao da
tcnica de PFs, bastante utilizada na Inglaterra. A forma de lanar uma estimativa o
principal diferencial da mtrica por Casos de Uso: o mtodo trata de estimar o
tamanho de um sistema de acordo com o modo como os usurios o utilizaro, a
complexidade de aes requerida por cada tipo de usurio e uma anlise em alto nvel
dos passos necessrios para a realizao de cada tarefa, em um nvel muito mais
abstrato que a tcnica de Pontos de Funo (FREIRE, 2003b; MACORATI, 2005;
MONTEIRO, 2005; SOUSA, 2009).
A tcnica de UCP explora o modelo e a descrio de casos de uso, substitui
algumas caractersticas tcnicas propostas pela APF, cria os fatores ambientais e
prope uma estimativa de produtividade. O processo de contagem da tcnica
composto basicamente por seis etapas (PARO, 2005; MONTEIRO, 2005):
Classificao dos atores;
Classificao dos casos de uso;
Clculo dos pontos de casos de uso no justados;
Clculo dos fatores tcnicos;
Clculo dos fatores ambientais; e
Clculo dos pontos de caso de uso.
33

A UCP tem contribudo para diminuir algumas dificuldades encontradas pelo


mercado em relao resistncia de adoo de mtodos de estimativas, porque
uma tcnica simples, fcil de usar e rpida de aplicar, quando se tm as informaes
necessrias para realizar as estimativas. No entanto, a UCP conta com algumas
desvantagens: somente pode ser aplicado em projetos de software cuja
especificao tenha sido expressa em casos de uso. Sendo assim, sua eficcia
depende de uma padronizao de todos os casos de uso de uma instituio, pois
um dos passos para a obteno das mtricas a contagem de transaes por caso
de uso (MONTEIRO, 2005; HAZAN, 2009).
Alm disso, como no existe um padro nico para a escrita de uma
especificao de caso de uso, diferentes estilos na escrita do caso de uso ou na sua
granularidade podem levar a resultados diferentes na medio por PCU. Assim, a
mtrica se torna subjetiva. E ainda, devido ao processo de medio do PCU ser
baseado em casos de uso, o mtodo no pode ser empregado antes de concluda a
anlise de requisitos do projeto. Na maioria das vezes existe a necessidade de se
obter uma estimativa antes da finalizao desta etapa (HAZAN, 2009; PARO, 2005).
Segundo Paro (2005), a tcnica de UCP est sendo pouco utilizado se comparado
com a APF.
Segundo Aguiar (2003) se comparar a utilizao de Pontos por Caso de Uso
com Pontos de Funo para realizao de estimativas de tamanho de software, ele
afirma que mais conveniente utilizar Pontos de Funo, devido:
Os Pontos de Funo so mantidos por uma organizao internacional
sem fins lucrativos, o IFPUG, desde 1986;
Os Pontos de Funo possuem suporte no Brasil, o BFPUG, alm de
empresas especializadas;
O IFPUG mantm um programa mundial de certificao profissional em
Pontos de Funo, o qual confere aos aprovados o ttulo de Certified
Function Point Specialist (CFPS), programa esse realizado no Brasil pelo
BFPUG;
Os Pontos de Funo so padronizados internacionalmente pela ISO,
atravs da norma ISO/IEC 20926, possibilitando a uniformidade na
aplicao;
34

Os Pontos de Funo modelam os requisitos a um nvel de abstrao mais


elevado e independente dos artefatos do que os UCP, podendo ser
utilizados por organizaes que utilizem qualquer forma de representao
dos requisitos, casos de uso ou outras;
A existncia de grande acervo de dados sobre Pontos de Funo
armazenados por diversas organizaes possibilita a realizao de estudos
e comparaes;
A Utilizao dos Pontos de Funo em contratos e licitaes uma
realidade no Brasil, tendo surgido a partir da iniciativa de organizaes
governamentais e rapidamente alcanado o mercado em geral.

2.3.7 Planning Poker

Projetos cujo desenvolvimento utilizem metodologias geis tambm


necessitam de estimativas, sejam elas de tamanho, custo, esforo ou durao.
Nestes casos tambm necessrio mensurar o tamanho de cada tarefa com uma
boa preciso, e, conseqentemente, conseguir prever quando determinado recurso
dever ser concludo. Segundo Cunha (2009), a metodologia de trabalho mais
utilizada por equipes que empregam metodologias geis (ex: Scrum ou Extreme
Programming - XP) no desenvolvimento de software : o Planning Poker.
O Planning poker uma tcnica de estimativa criada por James Grenning em
2002, cuja contribuio decisiva para difundir essa tcnica entre os praticantes de
mtodos geis foi de Mike Cohn. Esta tcnica usa o conhecimento dos
desenvolvedores para chegar s estimativas. As suas regras estimulam a interao
entre os membros da equipe e permitem que todos expressem as suas opinies, ao
mesmo tempo em que participam do planejamento do projeto e aumentam o seu
entendimento sobre o sistema que iro desenvolver. Para chegar a estimativas
realistas e razoveis, as prprias pessoas que participaro da implementao usam
a estratgia de diviso e conquista junto com o dimensionamento por analogia
(BASSI, 2009).
35

De forma simplificada, o funcionamento do Planning Poker : uma tcnica de


estimativa baseada no consenso de toda a equipe, onde utilizado um conjunto de
cartas com valores especficos (na maioria das vezes esses valores seguem a
Seqncia de Fibonacci2) que representam a escala (ou unidade de medida
adotada) e praticado como se fosse um jogo. Um participante apresenta a tarefa
ou estria para o time, e, aps uma breve discusso, cada um escolhe uma carta e
coloca virada para baixo sobre uma mesa. Quando todas as cartas estiverem
lanadas, elas so viradas e caso no haja consenso nos valores escolhidos, as
diferenas so discutidas de forma breve, e uma nova rodada acontece at que haja
a convergncia (CUNHA, 2009).
Se no desenvolvimento de software utilizando metodologias tradicionais
necessrio uma unidade de medida padro para realizar a estimativa de software,
utilizando metodologias geis isso no diferente. Segundo BASSI (2009) para
comear a usar Planning poker, preciso definir alguns conceitos e fazer alguns
preparativos sendo que o mais importante para a estimativa de tamanho a
definio de uma escala. Esta escala ir medir a unidade de medida padro
adotada. Boas escalas podem ser criadas usando nmeros de Fibonacci (1, 2, 3, 5,
8, 13,...), potncias de 2 (1, 2, 4, 8, 16, 32,...) ou (1, 5, 10, 20, 40, 80,...), pois so
seqncias exponenciais que iro absorver parte do erro associado s estimativas
de funcionalidades grandes.
Existem duas medidas de tamanho que podem ser utilizadas no
desenvolvimento de software: pontos de estria (story points) e dia ideal (ideal time).
Os pontos so medidas abstratas com tamanho definido pela equipe. Um dia ideal
o quanto seria produzido em um dia de trabalho se 100% do tempo fosse dedicado a
uma atividade, sem interrupes ou distraes. Para este caso, a equipe precisa
determinar a porcentagem de seu tempo que ela dedica ao projeto. Este percentual
servir para fazer a converso entre dias ideais e dias de trabalho (BASSI, 2009;
CUNHA, 2009b).
Bassi (2009) tambm afirma que os pontos e os dias ideais fornecem
estimativas de tamanho, que so medidas sobre o volume de trabalho, mas que

2
Sequncia de Fibonacci uma seqncia numrica criada pelo matemtico Leonardo Pisa, que tem
a seguinte lei de formao: cada elemento, a partir do terceiro, obtido somando-se os dois
anteriores (RIBEIRO, 2008).
36

alm dessas, interessante obter estimativas de durao, como por exemplo, horas
de trabalho ou dias de trabalho, que prevem a quantidade de tempo necessria
para cumprir a estimativa de tamanho. Contudo, importante que medidas de
tamanho e durao fiquem separadas, pois a velocidade da equipe pode variar
durante o projeto. Assim, quando a velocidade de desenvolvimento mudar, basta
identificar a nova velocidade e derivar as novas estimativas de durao.
37

3 ANLISE DE PONTOS DE FUNO

Segundo Albrecht (1983) apud Macoratti (2005) a tcnica de Anlise de


Pontos de Funo foi criada com o intuito de medir a complexidade do produto pela
quantificao de funcionalidade expressa pela viso que o usurio tem do software.
O modelo mede o que o sistema, o seu tamanho funcional e no como este ser,
alm, de medir a relao do sistema com usurios e outros sistemas. A tcnica pode
ser aplicada para qualquer software, independente da tecnologia usada e mede uma
aplicao pelas funes desempenhadas para/e por solicitao do usurio final.
A APF uma das mtricas de estimativa de tamanho mais sedimentadas no
mercado e que proporciona resultados cada vez mais precisos medida que
artefatos da fase de anlise e projeto so gerados (MACORATTI, 2005). Pois, esta
tcnica permite uma contagem indicativa no incio do projeto, quando no se
conhece os detalhes do modelo de dados; podendo ser definida na fase de projeto
quando se tm um maior conhecimento das funes do software, gerando uma
estimativa; at o trmino do desenvolvimento quando se efetua uma contagem
detalhada com base no conhecimento das funes levantadas durante todo o
processo de desenvolvimento do software (IFPUG, 1999 apud MACORATTI, 2005).
Segundo Santana e Gusmo (2010), devido grande aceitao e
padronizao do mtodo de estimativa de APF, o mesmo acabou tornando-se uma
norma ISO (ISO 20926) em 2002. Alm disso, segundo publicaes da Fatto (2011)
a Anlise de Pontos de Funo atualmente um instrumento utilizado por
profissionais da rea de sistemas e em empresas de todos os portes e segmentos
da economia brasileira. No incio o foco principal de sua aplicao eram as
estimativas. Atualmente alm de ser uma ferramenta importante em estimativas, tem
sido aplicada cada vez com mais sucesso como unidade de medio de contratos de
desenvolvimento de software e como ferramenta na gerncia de projetos. Boa parte
deste sucesso caracterizado como resultado da comunidade bem ativa de usurios
de pontos de funo no Brasil por meio do BFPUG.
38

3.1 OBJETIVOS DA APF

A Anlise de Pontos de Funo um mtodo-padro para a medio do


desenvolvimento de software, visando estabelecer uma medida de tamanho do
software em Pontos de Funo, com base na funcionalidade a ser implementada,
sob o ponto de vista do usurio. Seus principais objetivos so (HAZAN, 2009;
SANTANA; GUSMAO, 2010, MACORATI, 2005):
Medir funcionalidades do sistema requisitadas e recebidas pelo usurio;
Medir o tamanho do desenvolvimento de software e da manuteno de
forma independente de tecnologia usada para o desenvolvimento;
Prover uma unidade de medio normalizada entre projetos e
organizaes.
Prover uma mtrica de medio para apoiar a anlise de produtividade e
qualidade;
Prover um fator de normalizao para comparao de software.
Embora o objetivo principal da Anlise de Pontos de Funo ser usada para
medir o tamanho de um projeto de software, a APF pode ser usada para (NESMA,
2009; MONTEIRO, 2005):
Descrever o escopo de um sistema e medir o seu tamanho funcional,
independentemente da tecnologia que ser usada no sistema;
Derivar a produtividade e mtricas (indicadores) de desempenho do
processo, estimativa das necessidades de recursos e auxiliar no
gerenciamento de projetos;
Avaliar os fatores em um ambiente de desenvolvimento que influenciam a
produtividade e oferecer uma base para melhorar os processos de
desenvolvimento e manuteno;
Determinar o escopo e tamanho da melhoria em um sistema e auxiliar na
gesto de suas mudanas;
Fornecer suporte para planejamento e controle de projetos de software;
Apoiar a anlise de produtividade e qualidade do processo de
desenvolvimento de sistemas;
39

Servir-se como ferramenta de comunicao com os usurios;


Realizar estudos de benchmark3;
Facilitar a negociao nos contratos de software; e
Medir artefatos de um sistema.
Segundo Hazan (2001b), na prtica a tcnica Anlise de Pontos por Funo
tem demonstrado grande utilidade na garantia de que a especificao de requisitos
esteja bem elaborada e completa. Uma contagem de Pontos de Funo realizada
usando uma descrio suficientemente formal das necessidades do negcio na
linguagem do usurio. Assim, a contagem pode servir tambm como uma reviso
dos requisitos do sistema com o usurio. Alm disso, quando usada em combinao
com outras medidas, a APF pode ser usada para determinar (MACORATTI, 2005):
O nvel de produtividade da equipe;
Esforo de desenvolvimento de software;
O custo de software;
Taxa de produo de software;
Taxa de manuteno de software.
Alm destes objetivos, Macoratti (2005) afirma que o processo de contagem
de Pontos de Funo deve ser:
Simples para minimizar o trabalho adicional do processo de medio;
Conciso para permitir consistncia, ao longo do tempo, dos projetos, e
entre os usurios da tcnica.

3.2 ALGUMAS RAZES PARA UTILIZAR APF

A APF surgiu para quebrar o paradigma de mensurao do tamanho do


produto pela quantidade de linhas de cdigo, bem como a dependncia de
tecnologia a ser empregada e difundiu-se no mercado proporcionando um processo

3
Benchmarking um processo ou tcnica de gesto atravs do qual as empresas ou organizaes
avaliam o desempenho dos seus processos, sistemas e procedimentos de gesto comparando-o com
os melhores desempenhos encontrados noutras organizaes (NUNES, 2008).
40

maduro para avaliar o tamanho lgico do software com base em requisitos


funcionais dos usurios. O foco da metodologia da APF compreende na mensurao
da aplicao pelo que ela faz, pela perspectiva do usurio e no como a aplicao
foi construda. A contagem dos pontos por funo baseada na avaliao dos
requisitos do usurio, sendo que ela representa exclusivamente o tamanho funcional
da aplicao. O ponto por funo (unidade de medida da APF) por sua vez serve de
base para que com outras variveis possa ser calculado o esforo, prazo e o custo
(FABIAN, 2008; MACORATTI, 2005).
Na parte de projetos a APF pode servir de suporte na anlise de
produtividade e qualidade, em conjunto com mtricas de esforo, defeitos e custo. A
utilizao da APF em projetos de software apresenta benefcios como (SIMOES,
2004; MACORATTI, 2005; PARO, 2005; FABIAN, 2008):
A estimativa feita em funo da viso do usurio;
Facilidade de aprendizagem e aplicao da tcnica;
Permite dimensionar o tamanho de um software a ser desenvolvimento;
Permite realizar estimativas de custo, cronograma e recursos para o
desenvolvimento e manuteno de softwares;
Independncia de tecnologia;
Pode ser usada como uma ferramenta de auxlio gerencial, pois possibilita
a coleta de dados para obteno de diversos indicadores de
acompanhamento;
Pode ser usada como uma ferramenta para auxiliar a deciso entre a
compra de um pacote ou o desenvolvimento do aplicativo da empresa;
Representa uma forma de normalizao para comparao de software, ou
ainda comparao de produtividade na utilizao de tecnologias diferentes;
Pode medir o tamanho em qualquer fase do ciclo de vida do
desenvolvimento de sistema;
Promove benchmarking entre vrias organizaes;
Manuteno de dados histricos;
Complementa o gerenciamento de requisitos, ao analisar a qualidade do
levantamento de requisitos;
41

Uma forma para fundamentar a negociao de contratos, estabelecendo


uma unidade tangvel para o cliente, o ponto por funo, estabelecendo um
preo por esta unidade;
Possui certificao ISO que uma garantia consistente de que esta
metodologia eficaz e totalmente madura para ser adotada pelas
empresas.
Segundo Aguiar (2003) apud Macoratti (2005), dentre as principais razes
para a utilizao da APF como mtrica esto os seguintes motivos:
O fato dos Pontos de Funo serem mantidos por uma organizao
internacional sem fins lucrativos, o IFPUG , desde 1986;
Os PF possurem suporte no Brasil atravs do chapter BFPUG;
Os PF serem padronizados pela ISO atravs da norma ISO/IEC 20296;
Existir um grande acervo de informaes sobre PF armazenados em
diversas organizaes o que permite estudos e comparaes;
Os PF modelarem os requisitos a um nvel de abstrao mais alto e
independente dos artefatos e poderem ser usados por organizaes que
usam qualquer forma de representao de requisitos;
Os PF serem usados em contratos e licitaes no Brasil em organizaes
governamentais e pelo mercado em geral.
Segundo Paro (2005), a APF tambm apresenta algumas desvantagens,
entre elas: a necessidade de um bom nvel de experincia no assunto para efetuar
uma contagem acurada; a incapacidade de automao do processo de contagem
(contagem manual); a necessidade significativa de um nvel de detalhe de
informaes do software para uma medio mais confivel (entradas, sadas,
consultas, registros, bases, etc). Alm disso, Dekkers (1998) aponta um dos desafios
na implementao da anlise de Pontos de Funo: tornar o mtodo compreensvel
para os desenvolvedores. Devido ao fato de serem baseados em requisitos
funcionais dos usurios (o que o software faz), independentemente da
implementao fsica (como o software faz o que faz), pontos de funo foram os
desenvolvedores a pensarem em termos lgicos.
42

3.3 DEFINIO DE TERMOS

Antes de iniciar o estudo sobre a tcnica de APF e qual seu processo de


contagem de Pontos de Funo, importante reavaliar alguns conceitos muito
utilizados quando se trata de Tecnologia de Informao, mas que no processo de
contagem da APF causam algumas confuses, porque sua utilizao genrica na TI
frequentemente possui um significado diferente daquele utilizado na contagem de
PF (DEKKERS, 1998). Os termos a seguir so usados tanto na metodologia de
pontos de funo, quanto na tecnologia da informao, porm com caractersticas
particulares:
Usurio
Lgico
Aplicativo (sistema)
Projeto
Arquivo

3.3.1 Usurio

O termo usurio tem um significado mais amplo para a anlise de pontos de


funo do que o usual. Em tecnologia da informao, refere-se a uma pessoa fsica
que utiliza o software. Na terminologia de Pontos de Funo, usurio qualquer
pessoa ou coisa que interaja (envia ou receba dados) com a aplicao. Exemplos de
usurio: pessoa fsica, outra aplicao, um hardware, um ator em um caso de uso,
agentes governamentais (exigncias regulatrias do governo normalmente
abrangem boa parte dos requisitos de um software), gestores do negcio que o
software vai atender (na medida em que quem especifica os requisitos do software,
com ele tambm interage) (VAZQUEZ et al., 2010).
Essa diferena no significado pode fazer com que algumas funes contveis
sejam esquecidas pelos desenvolvedores, por no parecem requisitos definidos por
ou para um usurio fsico". Alm disso, se a contagem de pontos de funo fosse
43

baseada apenas no conceito de usurio como sendo uma pessoa, no seria


possvel medir sistemas que no tm interface com o usurio final. Porm, a APF
pode ser aplicada tambm nestas situaes (DEKKERS, 1998; VAZQUEZ et al.,
2010).

3.3.2 Lgico

O termo lgico em tecnologia da informao geralmente refere-se a layouts


de bases de dados ou modelos lgicos de dados. Porm quando o termo lgico
utilizado na contagem de pontos de funo, refere-se aos requisitos conceituais ou
funcionais dos usurios, excluindo a implementao fsica ou os requisitos de projeto
(DEKKERS, 1998).
Segundo Dekkers (1998) os requisitos lgicos dos usurios so aqueles que
um usurio experiente no assunto identificaria como requisitos do software. Os
requisitos lgicos ou funcionais dos usurios descrevem o que o software deve
fazer, sem dizer como o software executar as funes. Os pontos de funo
medem o tamanho desses requisitos funcionais dos usurios, apenas.
Consideraes sobre o projeto e a qualidade, embora importantes para a construo
do software, no so parte do tamanho lgico do software, no sendo, portanto,
contados em pontos de funo. Todas as contagens de pontos de funo so
realizadas a partir da perspectiva lgica do usurio, e os contadores iniciantes
precisam pensar logicamente ao contar pontos de funo.

3.3.3 Aplicativo

Os termos aplicativo e sistema geralmente so utilizados de forma


intercambivel em processamento de dados e esto diretamente ligados diviso
fsica do software. Alguns exemplos de como os aplicativos ou sistemas podem ser
divididos pelos desenvolvedores, so (DEKKERS, 1998):
44

Com base nas funes executadas em modo batch ou on-line. s vezes,


cada modalidade de implementao fsica de um nico conjunto de funes
cooperativas pode ser considerada um sistema separado pelos
desenvolvedores: por exemplo, o sistema batch de contas a receber e o
sistema on-line de contas a receber;
Com base na plataforma fsica na qual um subconjunto das funes (ou
subfunes) reside: por exemplo, o sistema de folha de pagamento
mainframe e o sistema de folha de pagamento PC;
Com base nos pacotes fsicos que compreendem um conjunto de funes:
por exemplo, o aplicativo de banco de dados Access ou o aplicativo de
entrada de dados.
No contexto da contagem de pontos de funo, o termo aplicativo definido
pelo IFPUG como uma coleo coesa de dados e procedimentos automatizados que
suportam um objetivo de negcio, podendo consistir de um ou mais componentes,
mdulos ou subsistemas. Frequentemente, o termo aplicao utilizado como
sinnimo para sistema, sistema aplicativo ou sistema de informao. A aplicao
deve ser definida segundo a viso do usurio e de acordo com consideraes de
negcio e no com base em questes tcnicas como arquitetura do software ou
plataforma tecnolgica (VAZQUEZ et al., 2010).
Estas diferenas na definio e utilizao da palavra aplicativo podem resultar
em excesso de contagem, como por exemplo: baseado no primeiro exemplo citado
acima, o aplicativo ter seus PF contados como dois, uma contagem on-line e outra
batch, porm se levar em considerao o significado de aplicativo na contagem de
pontos de funo os sistemas batch e on-line seriam um nico aplicativo
(DEKKERS, 1998).
Segundo DEKKERS (1998), importante lembrar que na contagem de pontos
de funo, um aplicativo representa a forma segundo a qual um usurio v
logicamente o sistema, enquanto na tecnologia da informao um aplicativo
geralmente representa como o sistema fisicamente implementado.
45

3.3.4 Projeto

Segundo Dekkers (1998) o termo projeto quando utilizado no


desenvolvimento de sistemas, pode descrever:
Escopo de trabalho que inclui a melhoria ou o desenvolvimento de vrios
aplicativos de software;
O escopo de trabalho incluindo consertos/manuteno de funes
existentes, alm da melhoria de outras funes em um nico aplicativo de
software;
Acertos no software em operao ou upgrades no software existente;
Qualquer combinao dos itens acima.
Porm, na contagem de pontos de funo, projeto refere-se ao produto do
trabalho relacionado ao desenvolvimento ou melhoria de um nico aplicativo
(sistema). O que projeto em termos de TI pode conter diversos projetos de
pontos de funo e, dessa forma, necessitar de diversas contagens de PF. O
Manual de Prticas de Contagem do IFPUG define projeto de desenvolvimento e de
melhoria como (DEKKERS, 1998):
Desenvolvimento: A especificao, construo, teste e entrega de um novo
sistema de informaes.
Melhoria: A modificao de um aplicativo existente.

3.3.5 Arquivo

O termo arquivo, em TI geralmente lembra o processamento de mainframe,


orientado a transaes, sendo usado como sinnimo de dataset. Termos
relacionados, como 'arquivos de pesquisa, 'arquivos de sada, 'arquivos batch',
'arquivos excel' e 'arquivos de transao' ainda so muito usados hoje em dia
(DEKKERS, 1998).
Na contagem de pontos de funo, arquivo um agrupamento lgico de
dados requerido pelos usurios. O CPM define arquivo como (DEKKERS, 1998):
46

Arquivo: Para os tipos de funes de dados, um grupo de dados


logicamente relacionados, no a implementao fsica desse grupo de
dados.
A seguir, alguns exemplos de arquivos fsicos/datasets em TI que no seriam
Arquivos (entidades) em pontos de funo (DEKKERS, 1998):
Um dataset de entrada poderia conter transaes que causariam
atualizaes em cadastros no aplicativo. (Para PF seria contado como uma
ou mais Entradas Externas, uma vez que esse o requisito lgico do usurio.
O local fsico de armazenamento desses processos por acaso um dataset).
Um arquivo de sada poderia conter a verso eletrnica de diversos
relatrios ou grupos de dados (por exemplo, vrios formulrios diferentes de
imposto de renda poderiam estar todos gravados em uma nica fita fsica de
sada). Em PF isto seria contado com vrias Sadas Externas (uma para cada
um dos requisitos funcionais distintos do usurio). Para os usurios, no
importa se h uma ou vrias fitas fsicas - desde que eles recebam a
funcionalidade.
A confuso pode surgir porque um Arquivo Lgico Interno (ALI) e um Arquivo
Lgico Externo (AIE) em termos de pontos de funo referem-se a uma entidade
persistente de dados, no um arquivo fsico ou dataset. Vale ressaltar que arquivo
em pontos de funo refere-se a um agrupamento lgico de dados relacionados
(DEKKERS, 1998).

3.4 PROCESSO DE CONTAGEM

O processo de contagem dos pontos de funo pode ser dividido em sete


etapas, conforme ilustra a Figura 3 (HAZAN, 2001b):
Determinar o tipo de contagem de pontos de funo;
Identificar o escopo de contagem e a fronteira da aplicao;
Contagem das funes de dados;
Contagem das funes transacionais;
47

Determinar a contagem de pontos de funo no ajustados;


Determinar o valor do fator de ajuste;
Calcular os pontos de funo ajustados.

Figura 3 - Processo de Contagem de Pontos de Funo


Fonte: FATTO (2011)

3.4.1 TIPO DE CONTAGEM

O primeiro passo a ser seguido para a contagem de PF de um projeto de


software determinar o tipo de contagem (O que de fato deve ser contado?). Neste
passo os responsveis pela medio devem estabelecer o tipo de contagem que
ser usado para medir o projeto de software. O tipo de contagem no altera a
aplicao das regras de contagem, mas pode influenciar no Clculo do tamanho no
final na contagem. Antes de iniciar uma contagem de pontos de funo deve-se
identificar qual o tipo de contagem que se vai efetuar dentro dos trs (3) definidos
pelo CPM do IFPUG (CAMPOS, 2010; IFPUG, 1999 apud MACORATTI, 2005b).
Os trs tipos de contagem podem ser classificados dentro de dois grupos de
contagem. Um deles a contagem da aplicao existente onde se podem contar
todas as funcionalidades oferecidas pela aplicao ou contar somente um subgrupo
48

das existentes (visando atender a um propsito). E, existe o outro grupo que o que
envolve a criao ou manuteno de funcionalidades que esto no escopo de um
projeto; seja ele de desenvolvimento ou de melhoria (CAMPOS, 2010b).
Os trs tipos de contagem possveis so:
Contagem de pontos de funo de projeto de desenvolvimento:
Projeto de desenvolvimento aquele que tem como objetivo desenvolver e
fornecer a primeira verso de uma aplicao, a criao de uma aplicao. O
nmero de pontos por funo de um projeto de desenvolvimento mede a
funcionalidade do projeto a ser entregue. Neste caso, a contagem no
compreende apenas o software em si, mas tambm outras aes a serem
feitas durante a sua execuo tambm devem ser contadas, como uma
migrao de base de dados, por exemplo. O tamanho funcional deste tipo de
projeto uma medida de funcionalidade que oferecida aos usurios com a
criao da aplicao medida a partir das funes fornecidas ao usurio na
primeira instalao da aplicao (quando o projeto concludo) (CAMPOS,
2010b; FABIAN, 2008).
importante destacar que qualquer contagem realizada antes do trmino de
um projeto na verdade uma estimativa da funcionalidade que ser entregue ao seu
final. Conforme os requisitos vo ficando mais claros durante o projeto e as funes
vo sendo desenvolvidas, bastante natural encontrar funcionalidades no medidas
no planejamento do projeto (VAZQUEZ et al., 2010).
Contagem de pontos de funo de projeto de melhoria: O projeto de
melhoria, diferente do projeto de desenvolvimento, parte de um software j
produzido e tem por objetivo efetuar e entregar uma manuteno adaptativa
de uma aplicao j existente. O nmero de pontos de funo de um projeto
de melhoria mede as funes adicionadas, modificadas ou eliminadas do
sistema pelo projeto, e tambm as eventuais funes de converso de dados.
Neste caso, o tamanho funcional de um projeto de melhoria uma medida
das funcionalidades que so oferecidas aos usurios com a implantao do
respectivo projeto (CAMPOS, 2010b; VAZQUEZ et al., 2010).
Contagem de pontos de funo de aplicao: A contagem de pontos de
funo de uma aplicao, tambm conhecida por pontos de funo instalados
49

ou baseline, refere-se a uma aplicao j instalada e mede a funcionalidade


fornecida ao usurio pela aplicao instalada. O tamanho da aplicao deve
iniciar quando da finalizao do projeto de desenvolvimento e, deve ser
atualizada toda a vez que um projeto de melhoria alterar as funes da
aplicao. Esta contagem fornece uma medida das funes que a aplicao
oferece atualmente ao usurio (VAZQUEZ et al., 2010; CAMPOS, 2010b).

3.4.2 FRONTEIRA DA APLICAO E O ESCOPO DA CONTAGEM

O segundo passo do Processo de Contagem a identificao da fronteira da


aplicao e o escopo da contagem. Para realizar uma contagem de pontos de
funo necessrio definir determinados contextos, entre eles identificar qual o
escopo para o tipo de contagem definida. O escopo da contagem no altera a
aplicao das regras de contagem, mas influencia no tamanho da contagem e deve
ser identificado depois que foi definido o tipo de contagem de pontos de funo a ser
realizada (CAMPOS, 2010c).
O objetivo da identificao do escopo de contagem consiste em definir quais
funes sero includas na contagem: se abrange um ou mais sistemas, se abrange
apenas uma parte do sistema e se compreender todas as funcionalidades; apenas
as funcionalidades em uso pelo usurio ou funcionalidades especficas (FABIAN,
2008; VASQUEZ et al., 2010).
Para Vazquez et al. (2010) o conceito de escopo mais utilizado para a
contagem de projetos de melhoria. E neste tipo de contagem onde ocorrem mais
erros, pois se realiza a contagem de funes da aplicao sem que elas tenham sido
alteradas pela melhoria.
Quanto atividade de estabelecer a fronteira da aplicao, esta tem como
objetivo delimitar onde comea e onde termina a medio dos pontos por funo. A
fronteira separa a aplicao que esta sendo contada das aplicaes externas
indicando o limite entre a aplicao e os demais usurios. A fronteira definida
estabelecendo uma interface conceitual (um limite lgico) entre a aplicao que esta
sendo contada o usurio e as outras aplicaes (MACORATTI, 2005b).
50

Para identificar a fronteira do processo de contagem, devem ser adotadas as


seguintes regras (MACORATTI, 2005b; VAZQUEZ et al., 2010):
Deve ser considerado o ponto de vista do usurio, ou seja, o que o usurio
pode entender e descrever como funo da aplicao.
A fronteira entre aplicaes relacionadas deve considerar a funcionalidade
das aplicaes em termos das funes de negcio identificadas pelo usurio,
e no sob o ponto de vista das interfaces necessrias.
Em projetos de melhoria, a fronteira estabelecida no incio do projeto deve
estar de acordo com a fronteira j estabelecida para a aplicao sendo
modificada.
Segundo Vazquez et al. (2010), as seguintes dicas auxiliam na identificao
da fronteira da aplicao:
Obter uma documentao do fluxo de dados no sistema e desenhar uma
fronteira em volta para destacar quais partes so internas e externas
aplicao
Identificar reas funcionais como entidades e processos;
Verificar como o grupo de dados so mantidos;
Verificar como a aplicao gerenciada; se desenvolvida ou mantida na
sua totalidade por uma equipe distinta.
Comparar os critrios utilizados em outras mtricas como esforo, durao,
custo e defeitos. As fronteiras para efeito da anlise de pontos de funo e as
outras mtricas devem ser as mesmas.
Verificar se o software possui ordens de servio especficas e
independentes.
A fronteira da aplicao determinada com base na viso do usurio, est
baseada no funcional como pode ou visto pelo usurio da aplicao, no em
consideraes tcnicas. Ela atua como uma membrana imaginria por onde os
dados, processados por transaes atravessam, entrando e saindo da aplicao
(CAMPOS, 2010d).
Segundo Vazquez et al. (2010), a etapa de estabelecer a fronteira da
aplicao considerada uma das mais importantes do processo de contagem. Se a
fronteira de aplicao no estiver bem definida, h risco do restante da contagem
51

no refletir o real tamanho da aplicao, comprometendo todo o trabalho. Alm


disso, o posicionamento incorreto da fronteira pode alterar a perspectiva da
contagem de uma viso lgica (princpio da anlise de pontos de funo) para uma
viso fsica, gerando conseqncias, como as seguintes:
Contagem duplicada da mesma transao por vrias "aplicaes", uma vez
que cada uma delas contribui com um subprocessamento para a transao do
negcio.
Contagem de funes de transferncia de dados entre plataformas/
"aplicaes". Por exemplo, a carga diria de uma tabela do servidor para uma
aplicao cliente poderia ser contada como uma Sada Externa (servidor) e
uma Entrada Externa (cliente), alm de dois arquivos (a verso servidor e
cliente da tabela). No entanto, o requisito poderia ser simplesmente o de
validar as transaes contra essa tabela.
Dificuldade na determinao do tipo de transao. Como uma "aplicao"
prov somente parte do processamento de uma transao do negcio, esse
processamento pode no satisfazer as regras do IFPUG para determinao
do tipo da transao.
Duplicidade na contagem de arquivos. Por exemplo, um mesmo arquivo
poderia ser contado como um Arquivo Lgico Interno para uma "aplicao" e
um Arquivo de Interface Externa para outra "aplicao".

3.4.3 CONTAGEM DAS FUNES DO TIPO DADOS

A terceira etapa do processo de contagem realizar a contagem das funes


do tipo dados, que representam as funcionalidades fornecidas ao usurio para
atender os requisitos de armazenamento de dados internos e externos aplicao.
So funes do tipo dados: Arquivos Lgicos Internos e Arquivos de Interface
Externa (HAZAN, 2001b; VAZQUEZ et al., 2010). Segundo Hazan (2001b), ambas
as funes de tipos de dados so grupos de dados logicamente relacionados ou
informaes de controle identificadas pelo usurio. O que difere essas funes o
52

local de armazenamento de seus dados perante a aplicao a ser contada, pois um


ALI mantido dentro da fronteira da aplicao, enquanto que o AIE apenas
referenciado pela aplicao, mas mantido dentro da fronteira de outra aplicao.
Portanto:
Arquivo Lgico Interno (ALI): um grupo de dados ou informaes de
controle logicamente relacionados e identificados pelo usurio que so
mantidos (adicionados, alterados ou excludos) atravs de um ou mais
processos elementares da aplicao sendo contada.
Arquivo de Interface Externa (AIE): um grupo de dados ou informaes
de controle logicamente relacionados e identificados pelo usurio que so
referenciados (lidos) por meio de um ou mais processos elementares dentro
da fronteira da aplicao sendo contada. O AIE de uma aplicao
obrigatoriamente um ALI de outra aplicao.
Um grupo de dados logicamente relacionado refere-se a dados relacionados
em um nvel que o usurio consegue perceber como sendo de extrema importncia
para permitir que a aplicao realize uma atividade definida (IFPUG apud
MACORATTI, 2005b). J as informaes de controle, so dados usados pela
aplicao para garantir total conformidade com os requisitos das funes do negcio
definidas pelo usurio. Elas especificam o que, quando e como os dados devem ser
processados e influenciam um processo elementar da aplicao sendo contada
(MACORATTI, 2005b; VAZQUEZ et al., 2010).
Um processo elementar a menor unidade de alguma atividade significativa
para o usurio final. Ele deve ser autocontido e deixar a aplicao em um estado
consistente. Em resumo, uma transao completa (VAZQUEZ et al., 2010).

3.4.3.1 Determinao da Complexidade

Para a etapa de contagem de Funes do tipo dado o primeiro passo a ser


realizado a identificao dos arquivos lgicos internos e arquivos de interface
externa. Aps a identificao ser realizada, cada uma dessas funes de dados
53

deve ser classificada segundo sua complexidade funcional baseada no nmero de


Tipo de Dados (TD) e no nmero de Tipo de Registros (TR) (HAZAN, 2001b;
VAZQUEZ et al., 2010).
A complexidade funcional est dividida em trs tipos: alta, mdia e baixa
conforme a Figura 4, apresentada a seguir (IFPUG apud FABIAN, 2008):

Tipos de dados

< 20 20 50 > 50
registros
Tipos de

1 Baixa Baixa Mdia

25 Baixa Mdia Alta

>5 Mdia Alta Alta


Figura 4 - Complexidade funcional de ALI e AIE
Fonte: IFPUG(s.d) apud FABIAN (2008)

3.4.3.2 Regras de Contagem de Tipos de Dados

Um tipo de Dado significa ser um campo nico, no repetitivo e reconhecido


pelo usurio. Representa um campo de dados que formula uma ocorrncia de
informao completa. Para contagem de um tipo de dado devem ser observadas as
seguintes regras (VAZQUEZ et al., 2010; FABIAN, 2008):

Conte um tipo de dado para cada campo nico reconhecido pelo usurio
e no repetido, utilizado por um ALI ou AIE por meio de um processo
elementar;

Quando duas aplicaes mantm ou referenciam o mesmo ALI ou AIE


conte apenas os campos utilizados pela aplicao sendo contada;

Dever ser considerado um tipo de dado para cada campo solicitado pela
aplicao para estabelecer um relacionamento com outro ALI ou AIE.
54

3.4.3.3 Regras de Contagem de Tipos de Registros

Um tipo de registro representa um subgrupo de dados reconhecido pelo


usurio, dentro de um ALI ou AIE. Existem dois tipos de subgrupo que podem ser
identificados como registros (VAZQUEZ et al., 2010; MACORATTI, 2005b):
Opcionais: So subgrupos de dados que o usurio tem a opo de no
informar no processo elementar que cria ou adiciona dados ao arquivo.
Obrigatrios: So subgrupos de dados que o usurio deve utilizar pelo
menos uma vez durante o processo elementar que cria ou adiciona dados ao
arquivo.
As regras que devem ser utilizadas para determinar o nmero de tipos de
registros tanto em ALI como em AIE so (VAZQUEZ et al., 2010; FABIAN, 2008):
Deve ser considerado um tipo de registro para cada subgrupos de dados
de um ALI ou AIE (Cada funo de dado tem um subgrupo de TD a ser
contado com um TR);
Conte um TR adicional para cada um dos seguintes subgrupos lgicos de
TDs que contm mais de um TD: Entidade associativa com atributos no
chave; Subtipo (outro que no o primeiro subtipo); e entidade atributiva em
um relacionamento que no seja mandatrio.
Caso no identificado nenhum subgrupo de dados, deve ser considerado
um tipo de registro para cada ALI ou AIE.

3.4.3.4 Determinao da Contribuio

Aps a determinao da complexidade dos arquivos (ALI e AIE), deve-se


calcular sua contribuio de acordo com a Figura 5:
55

TIPO DE FUNO Baixa Mdia Alta

ALI 7 PF 10 PF 15 PF

AIE 5 PF 7 PF 10 PF

Figura 5 - Contribuio do ponto por funo das funes do tipo dado


Fonte: IFPUG(S.d.) apud FABIAN (2008)

3.4.4 CONTAGEM DAS FUNES DO TIPO TRANSAO

A prxima etapa do Processo de Contagem a contabilizao das funes do


tipo Transao que por sua vez representam as funcionalidades de processamento
de dados do sistema fornecidas para o usurio. So funes do tipo transao
(HAZAN, 2001b; VAZQUEZ et al., 2010):
Entradas Externas (EEs): so processos elementares (transaes) que
processam dados ou informaes de controle que entram pela fronteira da
aplicao. O objetivo principal de uma EE manter um ou mais ALIs e/ou
alterar o comportamento do sistema. Ex: Incluir Cliente; Alterar Funcionrios;
Excluir Pedido.
Sadas Externas (SEs): so processos elementares que enviam dados ou
informaes de controle para fora da fronteira da aplicao. Seu objetivo
apresentar informaes ao usurio que foram recuperadas atravs de um
processamento lgico e no apenas uma simples recuperao de dados.
Uma SE deve envolver clculos ou criao de dados derivados ou tambm,
pode manter um ALI ou alterar o comportamento do sistema. Ex: Relatrio do
total de vendas por funcionrio, tela de Login (com criptografia).
Consulta Externa (CE): assim como uma SE, um processo elementar
que envia dados (ou informaes de controle) para fora da fronteira da
aplicao. Porm, seu objetivo apresentar informao para o usurio, por
meio apenas de uma recuperao das informaes, sem a realizao de
nenhum clculo nem a criao de dados derivados. Nenhum ALI mantido
56

durante sua realizao, nem o comportamento do sistema alterado. Ex:


Consulta de Clientes, Drop-Downs desde que recuperem dados de arquivos
lgicos (ALIs e/ou AIEs). Os Drop-Downs estticos, com valores codificados
diretamente no programa-fonte, no so contados.

3.4.4.1 Determinao da Complexidade

Assim como nas funes do tipo dado, deve-se tambm classificar as


funes do tipo transao quanto a sua complexidade funcional na aplicao. Cada
EE, SE e CE deve ser classificada com relao a sua complexidade funcional em
alta, mdia ou baixa, de acordo com o nmero de arquivo referenciado (AR) e
quanto ao nmero de tipo de dado (IFPUG apud FABIAN, 2008).
Concludo o levantamento do nmero de arquivos referenciados e tipos de
dados de cada EE, SE e CE, deve-se classific-los conforme as figuras 6 e 7:

Tipos de dados
referenciados

<5 5 15 > 15
Arquivos

<2 Baixa Baixa Mdia

2 Baixa Mdia Alta

>2 Mdia Alta Alta


Figura 6 - Complexidade para entradas externas
Fonte: IFPUG(S.d.) apud FABIAN (2008).

Tipos de dados
referenciados

<6 6 19 > 19
Arquivos

<2 Baixa Baixa Mdia

23 Baixa Mdia Alta

>3 Mdia Alta Alta


Figura 7 - Complexidade para sadas externas e consultas externas
Fonte: IFPUG(S.d.) apud FABIAN (2008).
57

3.4.4.2 Regras de Contagem para Arquivo Referenciado

Um arquivo referenciado refere-se a um ALI lido ou atualizado pela funo


do tipo transao ou ento pode ser um AIE lido pela funo do tipo transao
(VAZQUEZ et al., 2010; FABIAN, 2008). As regras para contagem de um arquivo
referenciado so:
Contar um arquivo referenciado para cada ALI mantido (no aplicvel em
para transaes do tipo CE);
Contar apenas um arquivo referenciado para cada ALI que mantido e
lido (no aplicvel em transaes do tipo CE);
Contar um arquivo referenciado para cada ALI ou AIE lido durante o
processamento. Mesmo que o ALI e/ou AIE processar mais de um tipo de
registro, dever ser contado apenas uma vez.
importante ressaltar que no processo de contagem para arquivos
referenciados no podero ser contados outros tipos de arquivos que no sejam ALI
ou AIE. Alm disso, no vlido contar o mesmo arquivo mais de uma vez, mesmo
que a transao faa vrias leituras ou atualizaes nele.

3.4.4.3 Regras de Contagem de Tipos de Dados

Conforme vimos anteriormente, um tipo de dado um campo nico, no


repetido e reconhecido pelo usurio. As regras para contagem de tipos de dados
para funes transacionais so (FABIAN, 2008; VAZQUEZ et al., 2010):
Contar um tipo de dado para cada campo no repetido e reconhecido pelo
usurio, que atravessa a fronteira de aplicao (entrando e/ou saindo) e
utilizado no processo. Independente de quantas vezes o campo entra ou sai
da fronteira da aplicao, ele deve ser contado apenas uma vez;
58

Contar um nico tipo de dado quando uma mensagem enviada para fora
da fronteira da aplicao, como tratamento de excees, mensagem de
trmino de processamento, confirmao da concluso de uma transao;
Contar um tipo de dado para a forma de acionar uma ao a ser tomada.
Mesmo que hajam vrias formas de ativar o mesmo processo, deve ser
contado apenas um tipo de dado.
No so considerados tipos de dados:
Dados Literais;
Variveis de paginao ou campos automticos gerados pela aplicao;
Auxlios de navegao.
Atributos gerados dentro da fronteira da aplicao por uma funo
transacional e salvos em um ALI sem sair da fronteira.
Atributos recuperados de um AIE ou ALI para participar no processamento
sem sair da fronteira.

3.4.4.4 Determinao da Contribuio

Aps a concluso da etapa de determinao da complexidade das funes do


tipo transao, deve ser calculada sua contribuio utilizando os seguintes critrios:

Tipo de funo Baixa Mdia Alta

EE 3 PF 4 PF 6 PF

SE 4 PF 5 PF 7 PF

CE 3 PF 4 PF 6 PF

Figura 8 - Contribuio dos pontos por funo das funes de transao


Fonte: IFPUG apud FABIAN(2008)
59

3.4.5 CONTAGEM DE PONTOS DE FUNO NO AJUSTADOS

Uma vez contadas s funes de dados e as funes transacionais, a


prxima etapa do processo de contagem calcular os PFs no ajustados de uma
aplicao. Os pontos de funo no ajustados medem os requisitos especficos do
usurio, permitindo assim apontar um requisito (um relatrio, um grfico, uma
transao de entrada de dados, etc) e dizer o seu valor em PF (VAZQUEZ et al.,
2010).
Segundo o IFPUG a contagem do tamanho funcional, mesmo de pontos de
funo no ajustados feita com base no clculo a partir dos trs tipos de
contagem: projeto de desenvolvimento, de melhoria e aplicao (VAZQUEZ et al.,
2010). Porm, Hazan (2001b) apresenta uma maneira simples para o clculo dos
pontos de funo no ajustados que pode ser feita da seguinte forma:
Para cada um dos cinco tipos de funo (ALI, AIE, EE, SE e CE), so
computados os totais de pontos de funo (NPFi), segundo a equao (2):

NPFi = NCi,j * Ci,j (2)


j=1

Onde NCi,j representa o nmero funes do tipo i (i variando de 1 a 5,


segundo os tipos de funo existentes: ALI, AIE, EE, SE e CE) que foram
classificados na complexidade j (j variando de 1 a 3, segundo os valores de
complexidade: simples, mdia e complexa).
Ci,j = valor da contribuio da complexidade j no clculo dos pontos da
funo i, de acordo com as figuras 5 e 8 apresentadas anteriormente.
O total de pontos de funo no ajustados (PFNA) dado pelo somatrio
dos pontos das tabelas de funo, conforme a equao (3):
5
PFNA = NPFi (3)
i=1
60

Sendo que i varia de 1 a 5, segundo os tipos de funo existentes (ALI, AIE,


EE, SE e CE).

3.4.6 DETERMINAR O VALOR DO FATOR DE AJUSTE

A tcnica de Anlise por Pontos de Funo considera que outros fatores


afetam o tamanho funcional de um sistema. Fatores estes, que esto relacionados
com caractersticas da aplicao. No clculo dos PF brutos no levada em conta a
tecnologia usada nem os requisitos no funcionais do sistema. Por este motivo, esta
etapa tem por objetivo estabelecer um fator de ajuste para a soma dos pontos de
funo no-ajustados. Ele ajusta os pontos de funo em +/- 35% de acordo com a
influncia de 14 caractersticas definidas pelo IFPUG (MACORATTI, 2005b; FABIAN,
2008).
Para adequar-se norma do padro ISO/IEC de medio funcional que no
compreende esta fase, o IFPUG tornou este passo opcional na APF (FABIAN, 2008).
Para a determinao do Valor do Fator de Ajuste (VAF) deve-se considerar 14
Caractersticas Gerais de Sistema (CGS) determinadas pelo IFPUG. Para cada
caracterstica preciso determinar um nvel de influncia na aplicao de acordo
com a Figura 9 (FABIAN, 2008).

Figura 9 - Grau de Influencia para as CGS


Fonte: HAZAN (2001b)
61

As caractersticas gerais de sistema para determinao do valor do fator de


ajuste dos pontos por funo no-ajustados so (FABIAN, 2008; VAZQUEZ et al.,
2010; HAZAN, 2001b):
Comunicao de dados: Refere-se ao nvel em que a aplicao
comunica-se diretamente com o processador. Os dados so enviados e
recebidos por meio de recursos de comunicao, como terminais
conectados localmente unidade de controle e protocolo de comunicao.
Descrever se a aplicao utiliza protocolos diferentes para
recebimento/envio das informaes do sistema;
Processamento distribudo: Representa o nvel de transferncia de
dados que a aplicao faz entre seus componentes dentro da fronteira de
aplicao;
Performance: Refere-se ao nvel de tempo de resposta e taxa de
transaes que influenciam o desenvolvimento da aplicao. A pergunta que
deve ser avaliada para essa CGS : Quo rpida deve ser a aplicao e o
quanto isto influencia o projeto?;
Configurao altamente utilizada: Refere-se ao nvel que restries de
recursos computacionais influenciam no desenvolvimento da aplicao. A
questo a ser avaliada para essa CGS : O quanto a infraestrutura influencia
o projeto?;
Volume de transaes: Descreve o nvel que o alto volume de
transaes influencia o projeto, desenvolvimento, instalao e suporte da
aplicao;
Entrada de dados on-line: Descreve em que nvel so efetuadas
entradas de dados na aplicao atravs de transaes interativas;
Eficincia do usurio final: Refere-se ao nvel de consideraes sobre
fatores humanos e facilidade de uso pelo usurio final influenciam o
desenvolvimento da aplicao. As funes interativas fornecidas pela
aplicao enfatizam um projeto para o aumento da eficincia do usurio
final, tais como:
Auxlio navegao (teclas de funo, acesso direto e menus
dinmicos);
62

Menus Documentao e help on-line;


Movimento automtico do cursor;
Movimento horizontal e vertical de tela;
Impresso remota (via transaes on-line);
Teclas de funo preestabelecidas;
Processos batch submetidos a partir de transaes on-line;
Utilizao intensa de campos com vdeo reverso, intensificados,
sublinhados, coloridos e outros indicadores;
Impresso da documentao das transaes on-line atravs de hard
copy;
Utilizao de mouse;
Menus pop-up;
O menor nmero possvel de telas para executar as funes de
negcio;
Suporte bilnge;
Suporte multilnge.
Atualizao on-line: Refere-se ao nvel em que os arquivos lgicos
internos so atualizados de forma on-line;
Complexidade de processamento: Refere-se ao nvel em que o
processamento lgico e/ou matemtico influencia o desenvolvimento da
aplicao;
Reusabilidade: Descreve em que nvel a aplicao e seu cdigo foram
projetados, desenvolvidos e suportados para serem utilizados em outras
aplicaes;
Facilidade de instalao: Refere-se ao nvel em que a converso de
ambientes preexistentes influencia o desenvolvimento da aplicao. Um plano
e/ou ferramentas de converso e instalao foram fornecidos e testados
durante a fase de teste do sistema;
Facilidade de operao: Mede o nvel em que a aplicao atende a
alguns aspectos operacionais como inicializao, segurana e recuperao. A
aplicao minimiza a necessidade de atividades manuais como montagem de
fitas, manipulao de papel e interveno manual do operador;
63

Mltiplos locais: Refere-se ao nvel em que a aplicao foi projetada,


desenvolvida e suportada para diferentes ambientes de hardware e software;
Facilidade de mudanas: Refere-se ao nvel em que a aplicao foi
desenvolvida para facilitar a mudana de sua lgica e/ou estrutura de dados.
As seguintes caractersticas podem ser vlidas para a aplicao:
So fornecidos mecanismos de consulta flexvel, para atender
necessidades simples; por exemplo, lgica de e/ou aplicada a apenas
um arquivo lgico;
So fornecidos mecanismos de consulta flexvel, para atender
necessidades de complexidade mdia; por exemplo, lgica de e/ou
aplicada a mais de um arquivo lgico;
So fornecidos mecanismos de consulta flexvel, para atender
necessidades de complexidade alta; por exemplo, lgica de e/ou
combinadas em um ou mais arquivos lgicos;
Dados de controle de negcio so armazenados em tabelas que so
mantidas pelo usurio atravs de processos on-line, mas mudanas
tm efeitos somente no dia seguinte;
Dados de controle de negcio so armazenados em tabelas que so
mantidas pelo usurio atravs de processos on-line, as mudanas tm
efeito imediatamente.
Aps atribuir um valor de influncia para cada uma das 14 caractersticas
gerais do sistema, estes valores devem ento ser somados o que resultar no Grau
de Influncia Total (GIT), conforme a equao (4) (MACORATTI, 2005b):
14
GIT = S GIi (4)
i=1

O valor do fator de ajuste calculado de acordo com a equao (5):


VFA = (GIT * 0,01) + 0,65 (5)

Se o fator de ajuste de valor igual a 1,00, a influncia total das


caractersticas gerais do sistema neutra. Nesta situao, a contagem dos pontos
64

de funo ajustados equivale a contagem de pontos de funo no ajustados


(MACORATTI, 2005b).

3.4.7 CALCULAR OS PONTOS DE FUNO AJUSTADOS

A ltima etapa da APF calcular os pontos de funo ajustados, o qual em


posse dos pontos por funo no-ajustados e o fator de ajuste definido, aplicada
uma forma matemtica, especfica para cada tipo de contagem: projeto de
desenvolvimento, de melhoria e aplicao. Nesta etapa so usados trs tipos de
frmulas matemticas diferentes para chegar ao resultado final, apresentadas a
seguir como descritas no manual do IFPUG, dependendo do tipo de clculo que se
deseja realizar (VAZQUEZ et al., 2010).

3.4.7.1 Projeto de Desenvolvimento

Antes de iniciar o clculo do nmero de Pontos de Funo Ajustados de um


projeto de Desenvolvimento necessrio compreender dois componentes
fundamentais:
Funcionalidade da aplicao requisitada pelo usurio para o projeto:
Compreendem as funes usadas depois da instalao do sistema. Elas
existem para satisfazer as necessidades de sada do negcio do usurio
(IFPUG, 1999 apud MACORATTI, 2005b; VAZQUEZ et al., 2010);
Funcionalidade de converso includas pelos usurios como requisitos:
Compreendem funcionalidades disponveis somente na instalao do sistema.
Elas existem para converter dados ou proporcionar outros requisitos
estabelecidos pelo usurio e necessrios converso. Aps a instalao
estas funes so descartadas por no serem mais necessrias (IFPUG,
1999 apud MACORATTI, 2005b; VAZQUEZ et al., 2010).
65

A frmula a ser aplicada nos projetos de desenvolvimento apresentada pela


equao (6) (VAZQUEZ et al., 2010):
DFP = (UFP + CFP) (6)
Onde:
DFP: Representa o tamanho (Nmero de pontos por funo) do projeto de
desenvolvimento;
UFP: Nmero de pontos de funo no-ajustados das funes disponveis
aps a instalao da aplicao, exceto as funes de converso (contagem
final do projeto, o realizado - entregue);
CFP: Nmero de pontos de funo das funes de converso;
Para obter os pontos de funo ajustados, basta ento multiplicar o resultado
pelo fator de ajuste (VAF = Valor do fator de ajuste), conforme a equao (7)
(FABIAN, 2008):
DFP = (UFP + CFP) x VAF (7)

Segundo Fabian (2008) a frmula aplicada para estimativa em projetos no


complexa, o que determinar o sucesso da estimativa est realmente nas fases
iniciais do processo de contagem.

3.4.7.2 Projeto de Melhoria

Segundo o IFPUG o conceito de melhoria envolve apenas manutenes


evolutivas na aplicao, ou seja, alteraes feitas na aplicao para atender aos
novos requisitos de negcio do usurio. No devem ser levadas em conta
manutenes corretivas e preventivas (VAZQUEZ et al., 2010).
A diretriz bsica para considerar que uma funo do tipo dado (ALI ou AIE) foi
alterada quando ela foi modificada em sua estrutura com alguma incluso,
alterao ou excluso de campos ou atributos. Neste caso deve-se contar a
funcionalidade toda no projeto de melhoria, no apenas os campos afetados pela
manuteno (VAZQUEZ et al., 2010).
66

Uma funo do tipo transao considerada alterada quando h alterao


em um dos seguintes itens (VAZQUEZ et al., 2010; MACORATTI, 2005b):
Tipos de dados Se houve incluso, alterao ou excluso da funo.
Arquivos referenciados Se foram includos, excludos ou alterados da
funo.
Lgica de processamento Se qualquer lgica for includa, alterada ou
excluda.
Os componentes para o clculo dos pontos de funo de um projeto de
melhoria so:
Funcionalidade da aplicao requisitada pelo usurio para o projeto:
funes adicionadas, alteradas ou excludas da aplicao pelo projeto de
melhoria (VAZQUEZ et al., 2010).
Funcionalidade de converso: Consiste dos pontos de funo entregues
por causa de qualquer funcionalidade de converso requerida pelo usurio
(IFPUG, 1999 apud MACORATTI, 2005b).
A frmula a ser aplicada nos projetos de melhoria apresentada pela
equao (8) (VAZQUEZ et al., 2010):

EFP = (ADD + CHGA + CFP + DEL) (8)

Os termos da frmula so:


EFP: Nmero de pontos de funo do projeto de melhoria;
ADD: Nmero de pontos de funo no-ajustados das novas funes;
CHGA: Nmero de pontos de funo no-ajustados das funes
modificadas, levando em considerao o funcionamento aps a alterao;
CFP: Nmero de pontos de funo no-ajustados de funes de
converso;
DEL: Nmero de pontos de funo no-ajustados das funes excludas da
aplicao.
Para obter o valor dos pontos de funo ajustados, a frmula a ser aplicada
adiciona o valor do fator de ajuste antes do incio do projeto (VAFB) e o valor do fator
67

de ajuste depois da concluso do projeto de melhoria (VAFA) conforme mostra a


equao (9) (MACORATTI, 2005b):
EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB) (9)

3.4.7.3 Aplicao

Para aplicaes existem duas frmulas matemticas para calcular o nmero


de pontos de funo. Uma para a primeira contagem dos pontos de funo da
aplicao, onde so contadas todas as funcionalidades requeridas pelo usurio de
uma aplicao instalada. As funes da converso de dados no devem ser
computadas no tamanho da aplicao entregue, pois elas existiro somente para o
processo de implantao do aplicativo. A segunda para recalcular o seu tamanho
aps um projeto de melhoria ter alterado suas funcionalidades (VAZQUEZ et al.,
2010; FABIAN, 2008).
A primeira frmula apresentada pela equao (10):
AFP = ADD (10)
Onde:
AFP: Tamanho da Aplicao;
ADD: Nmero de pontos de funo no-ajustados das funes.
Para o valor dos pontos de funo ajustados, deve-se utilizar a equao (11):
AFP = ADD * VAF (11)
Onde:
VAF: Valor do fator de ajuste da aplicao.
Aps o projeto de melhoria, deve-se aplicar a frmula apresentada pela
equao (12):
AFPA = (AFPB + ADD + CHGA) (CHGB + DEL) (12)
Os termos da frmula so:
AFPA: Nmero de pontos de funo ajustados da aplicao;
AFPB: Nmero de pontos de funo no-ajustados antes do projeto de
melhoria;
68

ADD: Nmero de pontos de funo no-ajustados das funes includas no


projeto;
CHGA: Nmero de pontos de funo no-ajustados das funes alteradas
depois do trmino do projeto;
CHGB: Nmero de pontos de funo no-ajustados das funes alteradas
antes do incio do projeto;
DEL: Nmero de pontos de funo no-ajustados das funes excludas
pelo projeto;
Para obter os pontos de funo ajustados, deve-se multiplicar o resultado pelo
VAFA ( Valor do fator de ajuste depois do projeto), conforme a equao (13):
AFPA = [(AFPB + ADD + CHGA) (CHGB + DEL)] x VAFA (13)
Quando um projeto de melhoria concludo, o nmero de pontos de funo
da aplicao deve ser atualizado para refletir as modificaes na aplicao
(VAZQUEZ et al., 2010).
69

4 ESTUDO DE CASO

4.1 LOCAL DO ESTUDO

O estudo foi aplicado na empresa Logic Tecnologia da Informao (Logic TI)


localizada na cidade de Foz do Iguau. Inserida no Espao de Desenvolvimento
Empresarial do Parque tecnolgico Itaipu em Foz do Iguau - PR, a Logic TI surgiu
no incio de 2005, com o objetivo de desenvolver o parque de software regional,
criando uma empresa de desenvolvimento de software de qualidade, aplicando
modelos de qualidade consagrados, as mais modernas tecnologias e programa
contnuo de treinamento.
A empresa atua no modelo de Fbrica de Software, buscando prover,
principalmente a clientes com extensa estrutura de Tecnologia da Informao, o
servio de desenvolvimento e manuteno de software sob encomenda, ou seja,
que apresentam caractersticas especficas e totalmente adaptadas s necessidades
e modelo de negcio do cliente, organizando, controlando, agregando valor,
minimizando custos e maximizando lucros.
Para empresas de mdio e grande porte, com setores prprios de Informtica,
a Logic TI busca permitir a essas empresas, reduzir custos de contratao e suprir a
deficincia de mo-de-obra qualificada e especializada, terceirizando o processo de
desenvolvimento de software como um todo ou em suas fases de Especificao,
Projeto, Implementao, Testes e Manuteno individualmente. O contrato de
servio firmado entre as empresas contratante e a Logic TI em geral realizado em
Pontos de Funo, pois ao medir o tamanho do software a empresa Logic TI
consegue determinar custos e estimar prazo de entrega do produto final.
70

4.2 TIPO DE PESQUISA OU TCNICAS DE PESQUISA

O trabalho proposto seguiu a metodologia de realizao de uma aplicao


prtica posterior anlise de tcnicas de medio de tamanho de software, em que
se optou pela Anlise de Pontos de Funo. Neste contexto, o estudo de caso
consistiu em estimar o tamanho de um projeto de desenvolvimento de software a ser
construdo pela empresa Logic TI para um de seus clientes.

4.3 COLETA DOS DADOS

O projeto utilizado como case foi o projeto de desenvolvimento de um Sistema


de Controle de Bens Patrimoniais (CBP) para a empresa X4. O escopo do projeto foi
definido em: O CBP ser um sistema criado para registrar os Bens Patrimoniais e
automatizar as movimentaes, transferncias e o inventrio dos mesmos.
O processo do sistema de controle de Bens Patrimoniais consiste do
Administrador do sistema cadastrar os Bens Patrimoniais com suas informaes
especficas adicionais, como: classificao e rea que este patrimnio pertence e
quem ser seu usurio e responsvel.
O sistema permitir controlar tanto as movimentaes, como as
transferncias dos Bens Patrimoniais. A movimentao consistir na troca de
usurio, rea e localizao, j na transferncia podem ser alterados os dados do
usurio, responsvel, rea e a localizao do Patrimnio.
O sistema tambm ter a funcionalidade de realizar o inventrio dos bens
patrimoniais de determinado escritrio, rea, classificao e/ou por usurio e
nacionalidade do usurio. O sistema disponibilizar a relao de bens que esto sob
responsabilidade de um determinado usurio, para que ele possa visualiz-las,
verificar e informar quais bens patrimoniais ainda esto e, os que j no esto mais

4
Empresa X Por questes legais, o real nome da empresa cliente foi omitido e ser considerado o
nome X.
71

sob sua responsabilidade. Alm disso, o usurio ainda tem a opo de informar o
estado dos bens que ainda lhe pertencem e justificar a falta dos demais.
O CBP dever interagir com outros sistemas j existentes na empresa X. A
interface ser realizada com:
Sistema RHI Sistema que disponibilizar as informaes/lista de
colaboradores ativos na empresa X, para que no CBP seja possvel definir
responsvel e/ou o usurio dos Bens Patrimoniais;
Sistema TGI Sistema que disponibilizar as informaes/lista das reas
(divises departamentais) da empresa X, para que no CBP seja possvel
informar a qual rea pertence cada Bem Patrimonial.
Os requisitos preliminares que descrevem o escopo do projeto CBP utilizado
no processo de contagem de Pontos de Funo foram divididos em duas categorias:
Funcionais e No Funcionais, sendo que os requisitos funcionais so:
RF-01 Manter o cadastro de Classificao dos Bens Patrimoniais: O
sistema dever manter interface para incluso, excluso, alterao e consulta
de Classificaes dos Bens Patrimoniais. A consulta das classificaes
dever estar ordenada por Nome;
RF-02 Manter cadastro de Terceirizado: O sistema mantm interface
para incluso, excluso, alterao e consulta de Terceirizados. Os
Terceirizados so utilizados no cadastro de Bem Patrimonial e nas
movimentaes dos Patrimnios;
RF-03 Manter cadastro de Bens Patrimoniais: O sistema deve permitir a
incluso, atualizao, excluso e consulta de formulrios de cadastro de Bem
Patrimonial. Nas consultas de Bens Patrimoniais, os mesmos devem ser
agrupados por Responsvel e Status e sero ordenados por nmero do BPM;
RF-04 Consultar Colaborador do RHI: O sistema obtm automaticamente
a lista de Colaboradores ativos, gerada pelo sistema RHI, a fim de definir
quem ser o responsvel e/ou usurio do Bem Patrimonial. Na consulta, o
sistema disponibiliza filtro por Nome e/ou Matrcula. O sistema dever
recuperar os campos: Nome, Matrcula, rea e Ramal;
RF-05 Consultar rea do TGI: O sistema obtm automaticamente a lista
de reas, gerada pelo sistema TGI, a fim de definir a rea da Localizao do
72

Bem Patrimonial. Na consulta, o sistema disponibiliza filtro por Descrio e/ou


Sigla e mostra uma lista com os mesmos campos;
RF-06 Consultar Arquivos em Disco: O sistema mantm interface para
consulta de arquivos armazenados em disco, para que o ator escolha qual
arquivo poder ser anexado ao Bem Patrimonial ou a Transferncia;
RF-07 Associar anexos de TBPM (Transferncia de Bens Patrimoniais
Mvel): O sistema dever manter interface para que o administrador faa a
consulta [RF-06], associao e dissociao de arquivos ao Bem Patrimonial
ou Transferncia de Bens Patrimoniais. Ser feito o upload dos arquivos
associados solicitao para um servidor e, posteriormente, esses arquivos
ficaro disponveis para download. So dados dos Anexos: Nome do Anexo,
Caminho Fsico;
RF-08 Gerar impresso da consulta de Bens Patrimoniais: O sistema
disponibiliza a opo de impresso para a consulta de Bens Patrimoniais;
RF-09 Disponibilizar Consulta de Movimentaes dos Bens
Patrimoniais: O sistema dever manter interface para consulta dos Bens
Patrimoniais, e assim poder visualizar suas movimentaes. Os Bens
Patrimoniais sero agrupados por Responsvel e Status. Ao selecionar um
Bem Patrimonial e acionar a visualizao do mesmo, o sistema dever exibir
as movimentaes do mesmo;
RF-10 Manter registro de Movimentaes de Bens Patrimoniais: O
sistema permite o registro de movimentao e consulta de formulrios de
registro de movimentaes de bens patrimoniais.
RF-11 Associar Bem Patrimonial ao Formulrio de Registro de
Movimentao de Bens Patrimoniais: O sistema dever manter interface
para associao e dissociao de Bens Patrimoniais ao Formulrio Registro
de Movimentao de Bens Patrimoniais.
RF-12 Disponibilizar Consulta de Transferncias dos Bens
Patrimoniais: O sistema dever manter interface para consulta das
transferncias dos bens patrimoniais. As transferncias sero agrupadas por
Cdigo da Transferncia e Data.
73

RF-13 Manter registro de Transferncia de Bens Patrimoniais: O


sistema permite o registro de transferncias e consulta de formulrios de
registro de Transferncias de bens patrimoniais.
RF-14 Associar Bem Patrimonial ao Formulrio de Registro de
Transferncia de Bens Patrimoniais: O sistema dever manter interface
para associao e dissociao de Bens Patrimoniais ao Formulrio Registro
de Transferncia de Bens Patrimoniais.
RF-15 Disponibilizar Consulta de Inventrios de Bens Patrimoniais: O
sistema dever manter interface para consulta dos inventrios de Bens
Patrimoniais, trazendo somente os inventrios solicitados para o usurio
logado. Os inventrios sero agrupados por Solicitante e Data da Solicitao
e sero ordenados por Nmero do Inventrio.
RF-16 Registrar Inventrio de Bens Patrimoniais: O sistema permite o
registro de inventrio e consulta de formulrios de registro de inventrios de
bens patrimoniais.
RF-17 Disponibilizar Consulta de Solicitaes de Inventrio: O sistema
dever manter interface para consulta das solicitaes de inventrios de Bens
Patrimoniais. As solicitaes so ordenadas por Nmero do Inventrio.
RF-18 Solicitar Inventrio de Bens Patrimoniais: O sistema permite
solicitar inventrios de bens patrimoniais. O sistema gera inventrio por
colaboradores, envia uma notificao a cada colaborador e bloqueia as aes
a serem tomadas com algum Bem Patrimonial envolvido neste Inventrio.
RF-19 Associar Usurio ao Formulrio de Solicitao de Inventrios
de Bens Patrimoniais: O sistema mantm interface para associao e
dissociao de Usurios ao Formulrio de Solicitao de Inventrios de Bens
Patrimoniais.
RF-20 Disponibilizar Visualizao da Solicitao de Inventrio de Bens
Patrimoniais: O sistema mantm interface para visualizao da Solicitao
de Inventrio de Bens Patrimoniais e permitir consultar os inventrios j
finalizados.
RF-21 Permitir Notificar Inventrio Pendente ao usurio: Quando o
Administrador/Gestor visualiza suas solicitaes de inventrio e a presena
74

de inventrios pendentes, o sistema permite enviar uma notificao ao


usurio que tenha inventrio pendente, para que este preencha o mais rpido
possvel seu inventrio.
RF-22 Disponibilizar opo para justificar situao do Bem
Patrimonial no Inventrio: Quando o Usurio altera a situao de um item
do seu inventrio para uma situao diferente de Indefinido, o sistema
disponibiliza uma opo para o usurio justificar a falta do patrimnio ou
mesmo informar as condies do patrimnio caso este esteja em sua posse.
RF-23 Gerar impresso dos dados do inventrio por Usurio: O
sistema disponibiliza a opo de impresso do detalhe dos dados do
inventrio de um Usurio.
RF-24 Gerar impresso dos dados do registro de Transferncia: O
sistema disponibiliza a opo de impresso dos dados do registro de
Transferncia.
RF-25 Permitir Cancelar Inventrio Pendente ao usurio: Quando o
Administrador/Gestor visualiza suas solicitaes de inventrio e a presena
de inventrios pendentes, o sistema permite cancelar um inventrio pendente,
para que seja permitido realizar aes (como Movimentao e Transferncia)
dos Bens Patrimoniais envolvidos no Inventrio corrente.
RF-26 Registrar Histrico do Bem Patrimonial: Sempre que um Bem
Patrimonial cadastrado, movimentado ou transferido, o sistema registra
histrico, armazenando a data, hora, nome do Bem Patrimonial, rea, nome
do responsvel e usurio, e o status.
RF-27 Notificar Envio de Inventrio aos usurios: Quando o
Administrador solicita um novo inventrio, o sistema notifica, via correio
eletrnico, todos os usurios dos Bens Patrimoniais indicados na Solicitao,
que o Inventrio encontra-se disponvel para sua anlise e preenchimento.
Alm destes requisitos funcionais, foram identificados os seguintes requisitos
no funcionais:
RNF-01 - O sistema dever apresentar a interface tanto no idioma
portugus, quanto espanhol. A definio ser realizada no momento do login;
75

RNF-02 - O sistema dever manter um padro de desenvolvimento de


cdigo, o qual dever estar todo comentado.
Alm dos requisitos identificados tem-se tambm a estrutura dos dados
identificada para o sistema de Controle de Bens Patrimonais, conforme ilustra a
Figura 10.

Figura 10 - Modelo de Dados do sistema CBP


Fonte: LOGIC TI (2011)

4.4 ANLISE DOS DADOS

Os dados utilizados no presente estudo de caso foram obtidos por meio de


procedimentos internos (reunies, anlise de documentos da empresa e por meio de
prottipos de tela) da empresa Logic TI. A empresa segue a metodologia do
Processo Unificado de Software e a coleta de dados foi realizada durante a fase de
concepo do sistema de Controle de Bens Patrimoniais.
76

5 RESULTADOS E DISCUSSO

Seguindo a metodologia de contagem de Pontos de Funo, a estimativa de


tamanho realizada no presente estudo de caso foi de um projeto de
Desenvolvimento. Com base no escopo do projeto apresentado anteriormente no
captulo 4, foram identificadas as funes de dados e a quantidade de Tipo de
Dados e Tipo de Registro conforme a Tabela 1:
Tabela 1 - Funes de Dados do sistema CBP
Descrio da Funo Tipo de Funo Tipo de Tipo de
de Dados Dado Registro
AREA AIE 3 1
(TGI Tabela: rea)
COLABORADOR AIE 4 2
(RHI Tabela: Cadastro Pessoal e Ramal)
PATRIMNIO ALI 16 2
(CBP - Tabela: Patrimnio, Classificao)
TERCEIRIZADO ALI 4 1
(CBP Tabela: Terceirizado)
HISTRICO ALI 18 2
(CBP Tabela: Movimento_Patrimonio, Anexo)
INVENTARIO ALI 11 2
(CBP Tabela: Inventario)
TRANSFERENCIA ALI 5 1
(CBP Tabela: Inventario)

Depois de identificadas as funes de dados, seguiu-se para a etapa de


determinao da complexidade e da contribuio destas funes para a contagem
de Pontos de Funo deste projeto segundo as regras descritas nas Figuras 4 e 5
do captulo 3. Para as funes levantadas segundo a Tabela 1, tem-se a
contribuio apresentada na Tabela 2.

Tabela 2 - Contribuio das Funes de Dados


Descrio da Funo Tipo de Funo Complexidade Tamanho (PF)
de Dados
AREA AIE Baixa 5
COLABORADOR AIE Baixa 5
PATRIMNIO ALI Baixa 7
TERCEIRIZADO ALI Baixa 7
HISTRICO ALI Baixa 7
INVENTARIO ALI Baixa 7
TRANSFERENCIA ALI Baixa 7
77

Alm das funes de dados, foram identificadas para o sistema CBP as


funes transacionais e suas respectivas informaes quanto ao
a tipo de funo,
quantidade de dados e quantidade
qua de arquivos referenciados. Para a contagem da
quantidade de dados de cada funo foram utilizados os prottipos de tela de cada
funcionalidade do sistema CBP. Como exemplo, tem-se
tem se a transao de Inserir Bem
Patrimonial e sua respectiva tela (prottipo)) conforme ilustra a figura 11; para esta
funcionalidade tem-se
se 16 tipos de dados.
dado

Figura 11 Tela de Cadastro de Bem Patrimonial


Fonte: LOGIC TI (2011)

A tabela 3 apresenta as demais funes transacionais identificadas e suas


su
respectivas informaes necessrias para o processo de contagem.

Tabela 3 - Funes Transacionais do sistema CBP


Descrio da Funo Tipo de Funo Tipo de Tipo de
de Dados Dado Registro
Cadastrar Terceirizado EE 4 1
(Tabela: Terceirizado)
Excluir Terceirizado EE 3 1
(Tabela: Terceirizado)
Editar Terceirizado EE 3 1
(Tabela: Terceirizado)
78

Descrio da Funo Tipo de Funo Tipo de Tipo de


de Dados Dado Registro
Visualizar Detalhe Terceirizado CE 4 1
(Tabela: Terceirizado)
Listar Terceirizado CE 4 1
(Tabela: Terceirizado)
Cadastrar Patrimnio EE 16 5
(Tabela: rea, Colaborador, Patrimnio, Anexo,
Terceirizado)
Excluir Patrimnio EE 4 2
(Tabela: Patrimnio, Anexo)
Editar Patrimnio EE 15 5
(Tabela: rea, Colaborador, Patrimnio, Anexo,
Terceirizado)
Visualizar Detalhe Patrimnio CE 23 5
(Tabela: rea, Colaborador, Patrimnio, Anexo,
Terceirizado, Histrico)
Listar Patrimnio CE 12 4
(Tabela: rea, Colaborador, Patrimnio,
Terceirizado)
Relatrio Patrimnio SE 10 4
(Tabela: rea, Colaborador, Patrimnio,
Terceirizado)
Registrar Movimentao EE 19 4
(Tabela: rea, Colaborador, Patrimnio,
Histrico)
Visualizar Detalhe Movimentao CE 18 4
(Tabela: rea, Colaborador, Patrimnio,
Histrico)
Listar Movimentao CE 12 4
(Tabela: rea, Colaborador, Patrimnio,
Terceirizado)
Registrar Transferncia EE 20 5
(Tabela: rea, Colaborador, Patrimnio,
Histrico, Transferncia, Anexo)
Visualizar Detalhe Transferncia CE 19 5
(Tabela: rea, Colaborador, Patrimnio,
Histrico, Transferncia, Anexo)
Listar Transferncia CE 11 4
(Tabela: Colaborador, Patrimnio, Transferncia,
Terceirizado)
Relatrio Transferncia SE 19 5
(Tabela: rea, Colaborador, Patrimnio,
Histrico, Transferncia, Anexo)
Registrar Inventrio EE 10 5
(Tabela: rea, Colaborador, Patrimnio,
Histrico, Inventrio)
Visualizar Detalhe Inventrio EE 9 5
(Tabela: rea, Colaborador, Patrimnio,
Histrico, Inventrio)
Listar Inventrio CE 9 4
(Tabela: Colaborador, Patrimnio, Inventrio,
Terceirizado)
Relatrio Inventrio SE 9 5
(Tabela: rea, Colaborador, Patrimnio,
Histrico, Inventrio)
79

Descrio da Funo Tipo de Funo Tipo de Tipo de


de Dados Dado Registro
Solicitar Inventrio EE 8 4
(Tabela:rea,Colaborador,Patrimnio, Inventrio)
Visualizar Detalhe Solicitao CE 9 5
(Tabela: rea, Colaborador, Patrimnio,
Histrico, Inventrio)
Listar Solicitaes CE 14 4
(Tabela: rea, Colaborador, Patrimnio,
Inventrio)
Listar Colaboradores (RHI) CE 2 1
(Tabela: Cadastro)
Listar reas (TGI) CE 2 1
(Tabela: rea)

Para as funes transacionais identificadas para o projeto de Controle de


Bens Patrimoniais, a complexidade e a contribuio destas funes segundo as
regras da contagem descritas nas figuras 6, 7 e 8, so as apresentadas na Tabela 4.

Tabela 4 - Contribuio Funes de Transao


Descrio da Funo Tipo de Funo Complexidade Tamanho
de Dados (PF)
Cadastrar Terceirizado EE Baixa 3
Excluir Terceirizado EE Baixa 3
Editar Terceirizado EE Baixa 3
Visualizar Detalhe Terceirizado CE Baixa 3
Listar Terceirizado CE Baixa 3
Cadastrar Patrimnio EE Alta 6
Excluir Patrimnio EE Baixa 3
Editar Patrimnio EE Alta 6
Visualizar Detalhe Patrimnio CE Alta 6
Listar Patrimnio CE Alta 6
Relatrio Patrimnio SE Alta 7
Registrar Movimentao EE Alta 6
Visualizar Detalhe Movimentao CE Alta 6
Visualizar Detalhe Transferncia CE Alta 6
Listar Transferncia CE Alta 6
Relatrio Transferncia SE Alta 7
Registrar Inventrio EE Alta 6
Visualizar Detalhe Inventrio EE Alta 6
Listar Inventrio CE Alta 6
Relatrio Inventrio SE Alta 7
Solicitar Inventrio EE Alta 6
Visualizar Detalhe Solicitao CE Alta 6
Listar Solicitaes CE Alta 6
Listar Colaboradores (RHI) CE Baixa 3
Listar reas (TGI) CE Baixa 3
80

Totalizando o tamanho em Pontos de Funo no ajustados das


funcionalidades descritas na Tabela 2 e 4 (funes de dados e transacionais)
atravs da frmula: DFP=(UFP+CFP), obteve-se:
DFP = (186 + 0)
DFP = 186 pontos de funo no ajustados
Obs: O projeto de Controle de Bens Patrimoniais no possui funes de converso de dados.
Quadro 1 Aplicao da frmula de Contagem de PF no ajustado para o Projeto de
Desenvolvimento CBP

Neste estudo aplicou-se tambm o fator de ajuste baseado nos seguintes


nveis de influencia para cada uma das Caractersticas Gerais do Sistema(Tabela 5):
Tabela 5 - Influncia das CGS no sistema CBP
Caractersticas Gerais do Influncia
Sistema
01 - Comunicao de Dados 5
02 - Processamento Distribudo 5
03 - Performance 1
04 - Configurao Altamente 1
Utilizada
05 - Volume de Transaes 0
06 - Entrada de Dados On-line 5
07 - Eficincia do Usurio Final 4
08 - Atualizao On-Line 4
09 Complexidade de 1
Processamento
10 - Reusabilidade 4
11 - Facilidade de Instalao 0
12 - Facilidade de Operao 4
13 - Mltiplos Locais 2
14 - Facilidade de Mudana 2
Fonte: LOGIC TI (2011)

O somatrio das influncias das CGS foi de 38 pontos. Assim sendo, o valor
do fator de ajuste (VFA) para a Contagem final dos pontos de funo encontrado foi:
VFA = (38 * 0,01) + 0,65
VFA = 1,03
Quadro 2 Aplicao da Frmula de Fator de Ajuste para o projeto CBP

Seguindo a ltima etapa do processo de contagem de pontos de funo de


um projeto, tem-se que calcular pontos de funo ajustados; baseado nas
81

informaes coletadas at o momento e seguindo a frmula padro de contagem de


Pontos de Funo ajustados de um projeto de desenvolvimento, obteve-se:
DFP = (186 + 0) x 1,03
DFP = 191,58 pontos de funo.
Quadro 3 - Aplicao da frmula de Contagem de PF Ajustado para o Projeto de
Desenvolvimento CBP

Desta forma, segundo o processo de contagem de Pontos de Funo


apresentado neste trabalho e considerando o arredondamento (para mais aps
passar de 0,5 ponto) dos pontos de funo, o projeto do sistema de Controle de
Bens Patrimoniais foi estimado no tamanho de Cento e Noventa e Dois (192) pontos
de funo.
Esta estimativa de tamanho do sistema de Controle de Bens Patrimoniais
realizada na fase inicial do Projeto utilizada no contrato de servio realizada entre
as partes (Empresa desenvolvedora de sistemas Logic TI e sua cliente, empresa X),
ou seja, a contratante X contrata o desenvolvimento de 192 pontos de funo de um
sistema (no caso o CBP) e em contrapartida a empresa Logic TI precisa desenvolver
e entregar o sistema equivalente a 192 pontos de funo. Alm disso, com base
nesta estimativa de tamanho a empresa Logic TI realiza o restante do procedimento
de estimar software para assim acordar com a contratante o tempo de entrega e o
custo deste projeto; bem como realiza o planejamento do processo de
desenvolvimento deste sistema e utiliza estas informaes como
mtricas/indicadores para projetos futuros.
82

6 CONSIDERAES FINAIS

6.1 CONCLUSES

Com base no presente estudo, conclui-se que a necessidade de gerenciar


projetos e entregar o produto final com qualidade atualmente o maior objetivo do
processo de desenvolvimento de software. Para que isto seja possvel torna-se
obrigatrio o melhor planejamento das atividades do processo de desenvolvimento
de sistemas. Porm, s podemos planejar o que nos conhecido, portanto a fase
inicial (de concepo) dos projetos est ganhando fora cada vez maior perante o
mercado.
Este trabalho mostra que o planejamento eficiente consiste em estimar o
tempo de desenvolvimento, o custo do projeto, bem como o esforo necessrio para
sua concluso e isto somente possvel sabendo o quanto ser preciso produzir, ou
seja, conhecendo o tamanho do projeto baseado em uma unidade de medida.
Como o planejamento nasce junto com o incio do projeto, neste momento
que o primeiro passo para o bom planejamento deve ser tomado, atravs da
estimativa de tamanho do software. O real tamanho de um sistema somente
conhecido ao fim do projeto, porm atravs da estimativa possvel dimensionar o
tamanho e realizar o planejamento e gerenciamento necessrio.
Entre as tcnicas de estimar tamanho de software vistas no presente trabalho
percebe-se que a APF a tcnica mais madura e abrangente do mercado. Ela no
apresenta restries quanto tecnologia, paradigma de desenvolvimento ou
artefatos a serem utilizados, pois se baseia somente na viso do usurio e tem-se
apresentado fortemente no mercado como meio de formalizar contrataes, alm de
possuir rgos mantenedores por diversos pases do mundo, inclusive no Brasil
atravs do BFPUG com forte atuao no mercado e por possuir certificao ISO que
garante sua eficcia e maturidade.
83

O estudo de caso comprovou que o procedimento de contagem de pontos de


funo (unidade de medida do software da APF) simples, prtico e completo,
bastando seguir as regras de contagem.

6.2 TRABALHOS FUTUROS/CONTINUAO DO TRABALHO

Como sugesto de trabalho futuro, pode-se realizar um estudo aprofundado


sobre a tcnica de Contagem de Pontos por Casos de Uso para Projetos Orientados
a Objetos, ou ento realizar um comparativo entre a APF e UCP, as duas principais
tcnicas de estimativa de tamanho utilizadas hoje no mercado, visando identificar as
vantagens de cada uma delas ou sua aplicabilidade para diferentes paradigmas de
desenvolvimento de software.
84

REFERNCIAS

AGUIAR, M. Pontos de Funo ou Pontos por Caso de Uso? Como Estimar


Projetos Orientados a Objetos, 2003. Disponivel em:
<http://www.bfpug.com.br/Artigos/UCP/Aguiar-
Pontos_de_Funcao_ou_Pontos_por_Caso_de_Uso.pdf>. Acesso em: 31 Outubro
2011.

ANDRADE, E. L. P. D. Pontos de Caso de Uso e Pontos de Funo na Gesto de


Estimativa de Tamanho de Projetos de Software Orientados a Objeto, 2004.
Disponivel em: <http://www.bfpug.com.br/>. Acesso em: 03 Maro 2012.

ASMA. O Padro ISO de Medio Funcional de Tamanho, 1999. Disponivel em:


<http://www.bfpug.com.br/>. Acesso em: 06 Novembro 2011.

BARCELLOS, M. P. Medicao de Software - Um importante pilar da melhoria de


processos de software. Engenharia de Software Magazine, n. 24, p. 64, 2010.
ISSN 1983127-7.

BASSI, D. Estimativas Agis com Planning Poker. Engenharia de Software


Magazine, n. 9, p. 60, 2009. ISSN 1983127-7.

CALAZANS, A. T. S. A utilizao do COSMIC Full Function Points para


estimativa de tamanho de software, 2003. Disponivel em:
<http://www.angelicatoffano.pro.br/upload_arquivos/pt/Artigo%20ASSE%202005_2.p
df>. Acesso em: 23 Outubro 2011.

CAMPOS, C. Tipos de Contagem, 2010. Disponivel em:


<http://carloscamposinfo.com/cjec/?p=97>. Acesso em: 11 Janeiro 2012.

CAMPOS, C. Tipo de Contagem, 2010. Disponivel em:


<http://carloscamposinfo.com/mundoapf/?p=163>. Acesso em: 23 Janeiro 2012b.

CAMPOS, C. Escopo da Contagem, 2010. Disponivel em:


<http://carloscamposinfo.com/mundoapf/?p=192>. Acesso em: 02 Fevereiro 2012c.
85

CAMPOS, C. Fronteira da Aplicao, 2010. Disponivel em:


<http://carloscamposinfo.com/mundoapf/?p=180>. Acesso em: 02 Fevereiro 2012d.

CAPPELLI, C. et al. Pesquisa em Estimativas em Projetos de Modelagem de


Processos, 2009. Disponivel em:
<http://www.seer.unirio.br/index.php/monografiasppgi/article/viewFile/504/717>.
Acesso em: 23 Outubro 2011.

CARVALHO, V. A. D.; ARANTES, L. O.; FALBO, R. D. A. EstimaODE: Apoio a


Estimativas de Tamanho e Esforo no Ambiente de Desenvolvimento de Software
ODE, 2006. Disponivel em: <http://paa1.googlecode.com/svn-
history/r106/trunk/seminario/EstimaODE.pdf>. Acesso em: 26 Agosto 2011.

CUNHA, D. Mais Agilidade em suas estimativas com o Planning Poker, 2009.


Disponivel em: <http://www.brasiltech.net/agilez/2009/12/13/mais-agilidade-em-suas-
estimativas-com-o-planning-poker/>. Acesso em: 24 Outubro 2011.

CUNHA, D. Estimando pelo tamanho e no pela durao, 2009. Disponivel em:


<http://www.brasiltech.net/agilez/2009/09/22/estimando-pelo-tamanho-e-no-pela-
durao/>. Acesso em: 24 Outubro 2011b.

DEKKERS, C. A. Desmistificando Pontos de Funo: Entendendo a Terminologia,


1998. Disponivel em:
<http://www.bfpug.com.br/Artigos/Desmistificando%20Pontos%20de%20Fun%C3%A
7%C3%A3o.pdf>. Acesso em: 03 Novembro 2011.

FABIAN, C. M. SICLA-APF Ferramenta de Anlise de Pontos Por Funo, 2008.


Disponivel em:
<http://www.google.com.br/url?sa=t&rct=j&q=Ivan%2BMecenas%2BFPA&source=we
b&cd=7&ved=0CEwQFjAG&url=http%3A%2F%2Ftconline.feevale.br%2Ftc%2Ffiles
%2F0001_1535.doc&ei=Fcq-
Tp9LzO6CB4mblLkH&usg=AFQjCNELrjl8vuX968aLb5wUNVeeyLqhTw&sig2=-
SgMZCYMyiIy9-kRUx1UFw&cad=r>. Acesso em: 12 Novembro 2011.

FATTO. www.fattocs.com.br. Fatto Cs, 2011. Disponivel em:


<www.fattocs.com.br/download/fpa-m2-sw.ppt>. Acesso em: 25 Fevereiro 2011.

FREIRE, Y. M. A. TUCP-M Pontos de Casos de Uso Tcnicos para


Manuteno de Software, 2008. Disponivel em:
<https://uol01.unifor.br/oul/conteudosite/F1066345165/Dissertacao.pdf>. Acesso em:
15 Agosto 2011.
86

FREIRE, H. Calculando Estimativas: o Mtodo de Pontos de Caso de Uso, 2003.


Disponivel em: <http://pt.scribd.com/doc/4484908/Pontos-de-Caso-de-Uso>. Acesso
em: 30 Outubro 2011b.

GERMANO, V. H. Por que Projetos de software falham?, 07 Outubro 2008.


Disponivel em: <http://malditacomedia.blogspot.com/2008/10/por-que-projetos-de-
software-falham.html>. Acesso em: 16 Agosto 2011.

GOMES, A. E. Mtricas e Estimativas de Software: O nicio de um rally de


regularidade, 2003. Disponivel em:
<http://www.linhadecodigo.com.br/artigo/102/M%C3%A9tricas-e-Estimativas-de-
SoftwareO-in%C3%ADcio-de-um-rally-de-regularidade.aspx>. Acesso em: 15 Agosto
2011.

HAZAN, C. Analise de Pontos de Funo - Uma aplicao nas estimativas de


tamanho de Projetos de Software. Engenharia de Software Magazine, n. 02, p. 60,
2009. ISSN 1983127-7.

HAZAN, C. Anlise de Pontos de Funo, 2001. Disponivel em:


<www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf>. Acesso em: 02
Fevereiro 2012b.

IFPUG. International Fuction Point Users Group, 2011. Disponivel em:


<http://www.ifpug.org/>. Acesso em: 06 Novembro 2011.

LEITE, J. C. Custos do Software, 2006. Disponivel em:


<http://www.dimap.ufrn.br/~jair/ES/slides/Custos.pdf>. Acesso em: 31 Agosto 2011.

LEITE, J. C. Engenharia de Software, 2009. Disponivel em:


<http://engenhariadesoftware.blogspot.com/2007/04/mtricas.html>. Acesso em: 22
Outubro 2011b.

MACORATTI, J. C. Estimativas de tamanho de software e APF, 2005. Disponivel


em: <http://www.macoratti.net/net_est1.htm>. Acesso em: 15 Agosto 2011.
87

MACORATTI, J. C. Anlise de Pontos por Funo - O Processo de contagem,


2005. Disponivel em: <http://www.macoratti.net/apf_pcta.htm>. Acesso em: 10
Fevereiro 2012b.

MARCIO, S. Estimando Projetos de TI: Arte ou Cincia, 2000. Disponivel em:


<http://www.bfpug.com.br/Artigos/EstimandoProjetosDeTI.htm>. Acesso em: 27
Agosto 2011.

MONTEIRO, T. C. Pontos de Caso de Uso Tcnicos (TUCP): Uma Extenso da


UCP, 2005. Disponivel em:
<www.cipedya.com/web/FileDownload.aspx?IDFile=156445>. Acesso em: 15 Agosto
2011.

MORIMOTO, C. E. Assembly. www.hardware.com.br, 2005. Disponivel em:


<http://www.hardware.com.br/termos/assembly>. Acesso em: 26 Fevereiro 2012.

NESMA. Anlise de Pontos de Funo para Melhoria de Software, 2009.


Disponivel em:
<http://www.portaisgoverno.pe.gov.br/c/document_library/get_file?uuid=066903b6-
39e9-44c4-833f-e7155a1c68c9&groupId=335215>. Acesso em: 06 Novembro 2011.

NUNES, P. Conceito de Benchmarking, 2008. Disponivel em:


<http://www.knoow.net/cienceconempr/gestao/benchmarking.htm>. Acesso em: 26
Fevereiro 2012.

PARO, C. J. Medidas de tamanho de desenvolvimento e de melhorias de


software, 2005. Disponivel em:
<http://www.bfpug.com.br/Artigos/Medidas%20de%20tamanho%20de%20desenvolvi
mento%20e%20de%20melhorias%20de%20software.doc>. Acesso em: 30 Outubro
2011.

RIBEIRO, T. Sequncia de Fibonacci, 2008. Disponivel em:


<http://www.infoescola.com/matematica/sequencia-de-fibonacci/>. Acesso em: 26
Fevereiro 2012.

SANTANA, C.; GUSMO, C. Uso de Anlise de Pontos de Funo em Ambientes


geis. Engenharia de Software Magazine, n. 20, p. 60, 2010. ISSN 1983127-7.
88

SILVEIRA, M. Estimando Projetos de TI: Arte ou Cincia, 2000. Disponivel em:


<http://www.bfpug.com.br/Artigos/EstimandoProjetosDeTI.htm>. Acesso em: 2012
Janeiro 26.

SIMES, C. A Difcil Arte de Estimar Tempo para Implementao de Sistemas


de informao, 2004. Disponivel em: <www.bfpug.com.br/Artigos/Monografia%20-
%20Mtricas%20v3.doc>. Acesso em: 16 Agosto 2011.

SOUSA, D. J. D. Uma abordagem sobre custo de software, 2009. Disponivel em:


<http://www.webartigos.com/artigos/uma-abordagem-sobre-custo-de-
software/65926/>. Acesso em: 31 Outubro 2011.

STAA, A. V.; HAZAN, C. Anlise e Melhoria de um Processo de Estimativas de


Tamanho de Projetos de Software, 2005. Disponivel em: <http://www.dbd.puc-
rio.br/depto_informatica/05_04_hazan.pdf>. Acesso em: 20 Setembro 2011.

TORRES, M. B. Anlise de Pontos de Funo: Estimativa Qualitativa x


Estimativa Quantitativa, 12 Fevereiro 2004. Disponivel em:
<http://www.bfpug.com.br/Artigos/APF%20-
%20Qualitativo%20x%20Quantitativo.pdf>. Acesso em: 16 Agosto 2011.

VAZQUEZ, C. E.; SIMES, G. S.; ALBERT, R. M. Anlise de Pontos de Funo -


Medio, Estimativas e Gerenciamento de Projetos de Software. 9. ed. So
Paulo: rica, 2010.