UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
AVM FACULDADE INTEGRADA
MÉTRICA EM GERÊNCIA DE PROJETO DE SOFTWARE COM
FOCO EM ANÁLISE DE PONTOS DE FUNÇÃO
Por: Armando Duarte Thompson Filho
Orientador
Prof. Nelsom de Magalhães
Rio de Janeiro
2013
DOCU
MENTO
PRO
TEGID
O PEL
A LE
I DE D
IREIT
O AUTO
RAL
2
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
AVM FACULDADE INTEGRADA
MÉTRICA EM GERÊNCIA DE PROJETO DE SOFTWARE COM
FOCO EM ANÁLISE DE PONTOS DE FUNÇÃO
Apresentação de monografia à AVM Faculdade
Integrada como requisito parcial para obtenção do
grau de especialista em Gestão de Projetos.
Por: Armando Duarte Thompson Filho
3
AGRADECIMENTOS
Aos professores do curso de Gestão de
Projetos pelos conhecimentos que me
acrescentaram, aos colegas de
trabalho e a todas outras pessoas que,
de alguma forma, contribuíram para a
confecção deste trabalho.
4
DEDICATÓRIA
Dedico este trabalho a meu pai e minha
mãe (in memoriam) pelo apoio e liberdade
às minhas decisões durante minha vida e
aos meus filhos que são meu grande
incentivo a evoluir meus conhecimentos e
buscar novos horizontes. Também a
minha esposa e enteada pelo apoio e
compreensão no tempo investido neste
projeto.
5
RESUMO
O propósito deste trabalho é abordar uma metodologia que permite
estimar com melhor precisão o tamanho de programas de computador,
contribuindo para o aumento da eficácia do gerenciamento de projetos nessa
área.
O primeiro capítulo menciona algumas metodologias utilizadas para
medição funcional de softwares. O segundo capítulo aborda a metodologia
Análise de Pontos de Função, com a padronização do IFPUG (International
Function Point Users Group. A estimativa de projetos de desenvolvimento de
softwares é estudada no terceiro capítulo mostrando como utilizar pontos de
função para produzir estimativas confiáveis inclusive em fases iniciais de
projetos.
Para enriquecer o trabalho foi desenvolvido um exemplo prático,
colocado como apêndice, de forma a ajudar o entendimento da Análise de
Pontos de Função, praticando algumas das teorias abordadas nesta
monografia. Um interessante artigo sobre o assunto foi colocado em anexo,
sendo recomendável sua leitura.
6
METODOLOGIA
O presente trabalho foi desenvolvido a partir do conhecimento adquirido
em curso de Análise de Pontos de Função por Estimativas realizado na FATTO
Consultoria e Sistemas, leitura de livro especializado na área de métrica de
software com destaque na metodologia Análise de Pontos de Função, leitura
de livro especializado em Gerência de Projetos e pesquisas em sites confiáveis
da internet, como o BFPUG – Brazilian Function Point Users Group.
7
SUMÁRIO
INTRODUÇÃO 8
CAPÍTULO I
MÉTRICAS DE SOFTWARES 11
CAPÍTULO II
ANÁLISE DE PONTO DE FUNÇÃO 16
CAPÍTULO III
ESTIMATIVA DE SOFWARE USANDO APF 31
CONCLUSÃO 41
BIBLIOGRAFIA CONSULTADA 43
BIBLIOGRAFIA CITADA 44
APÊNDICE 45
ANEXO 50
ÍNDICE 57
ÍNDICE DE FIGURAS 59
ÍNDICE DE TABELAS 60
LISTA DE ABREVIATURAS E SIGLAS 61
8
INTRODUÇÃO
O gerenciamento de projetos é realizado através da aplicação e
integração de grupos de processos: Iniciação; Planejamento; Execução;
Monitoramento e Controle; Encerramento. Para gerenciar um projeto é
necessário identificar os requisitos, adaptar-se às diferentes necessidades,
preocupações e expectativas das partes interessadas à medida que o projeto é
planejado e realizado e balancear as restrições conflitantes do projeto, como
Escopo, Qualidade, Orçamento e Recursos, Cronograma e Riscos. Para
permitir um bom balanceamento entre estes fatores é muito importante que se
possa quantificar o esforço, o custo e as atividades necessárias para realização
de um projeto. Para permitir esse balanceamento com qualidade é necessário
que o produto a ser desenvolvido possa ser dimensionado de forma que as
estimativas sejam precisas.
Estimar o tamanho de um projeto é difícil porque significa descobrir
antes que o trabalho seja feito, quanto de trabalho demandará, quanto tempo
tomará, quantas pessoas serão necessárias e quanto custará.
A maioria dos projetos ou serviços de outras áreas, como de
conservação, limpeza, segurança, vigilância, manutenção ou construção civil,
equipamentos e instalações priorizam a contratação de mão de obra,
dimensionados por horas trabalhadas ou através de alocação de mão de obra.
Porém, por apresentar características próprias e complexas levando
frequentemente a alterações de escopo mesmo após a conclusão das
especificações funcionais e não funcionais do sistema, a área da Tecnologia de
Informação, cada vez mais, vem priorizando a contratação, mensuração e
pagamento por resultados, principalmente para projetos de desenvolvimento de
sistemas de softwares (programa de computador).
9
Essa necessidade, de mensurar o desenvolvimento de sistemas
para contratação, acompanhamento e pagamento por resultado, levou as
empresas a buscarem ferramentas ou métodos que permitissem a medição de
sistemas. Atualmente, a metodologia Análise de Pontos de Função (APF) vem
se tornando padrão no mercado, tanto na área pública como na privada, por
consequência.
Inclusive, o Tribunal de Contas da União, através de ementa em
Diário Oficial da União, acórdão 1999/2007 de 28/09/2007, manifestou-se no
sentido que os serviços de informática diferem dos demais serviços. Assim,
para realização de licitação e acompanhamento contratual na área de
informática, as empresas públicas devem priorizar a contratação, mensuração
e pagamento por resultado.
9.4.1.1. os serviços de informática diferem substancialmente dos demais serviços, continuados ou não, de conservação, limpeza, segurança, vigilância, transportes, copeiragem, recepção, reprografia, telecomunicações e manutenção de prédios, equipamentos e instalações, já que esses priorizam contratações de serviços terceirizados de mão-de-obra, mensurados, em grande parte das vezes, por horas trabalhadas ou por simples alocação de pessoal (postos de trabalho), enquanto os serviços de Tecnologia da Informação devem priorizar a contratação, mensuração e pagamento por resultados, razão pela qual apresentam-se mais específicos e complexos em termos de definição de especificações, modelagem, planejamento das necessidades, critérios e condições para realização de licitação e acompanhamento contratual. (TCU,2007a,p.137).
No mesmo DOU em acórdão envolvendo o Departamento de
Logística do Exército Brasileiro do Ministério de Defesa cita a metodologia APF,
conforme transcrição de parte do acórdão:
9.2.2.2. prever metodologias de mensuração de serviços prestados que privilegiem a remuneração da contratada mediante a mensuração de resultados, a exemplo da ANÁLISE POR PONTOS DE FUNÇÃO (método padronizado largamente utilizado no mercado nos dias de hoje para a mensuração de serviços de desenvolvimento e manutenção de sistemas,
10
considerando as funcionalidades implementadas, sob o ponto de vista do usuário), buscando eliminar a possibilidade de remunerar a contratada com base na quantidade de horas trabalhadas ou nos postos de trabalho disponibilizados ou, caso tal caminho não se mostre comprovadamente viável, restando como única opção a remuneração de serviços por horas trabalhadas, cuidar para que sejam previamente definidos e especificados os serviços a serem executados e estabelecidos, também de antemão, os valores máximos de horas aceitáveis para cada um desses serviços, assim como explicitada a metodologia a ser utilizada para a identificação desse quantitativo de horas. (TCU,2007b,p.145 - destaque do autor).
Os setores de Tecnologia da Informação veem sofrendo grande
impacto com os avanços tecnológicos que ocorreram nas últimas décadas e
que continuam ocorrendo. Esses setores, cada vez mais, veem ganhando
importância dentro das organizações que, naturalmente, ficam mais
dependentes das tecnologias, com estas tornando-se mais indispensáveis no
apoio aos negócios e tomadas de decisões. A área mais visível e, porque não
dizer, a mais importante é a de desenvolvimento de softwares que tem sofrido
grandes impactos com as novas tecnologias disponíveis. Diversas classes de
tecnologias envolvidas no desenvolvimento de sistemas apresentam uma
grande variedade de ferramentas que concorrem entre si no mercado, como
em Banco de Dados (exemplos: Oracle, Sybase, SQL Server) e linguagens de
programação (exemplos: PHP, JAVA, C++). Isso leva a considerar a
importância de desconsiderar a tecnologia na metrificação de programas de
computador, procurando dar ênfase a outros fatores.
Para o planejamento das estimativas de software o importante é
medir o que o programa fará e não como ele será construído.
11
CAPÍTULO I
MÉTRICAS DE SOFTWARES
Em 1970, na IBM, houve a necessidade de se medir a produtividade
de diversos projetos de softwares. Alguns desses projetos tinham sido
desenvolvidos em diferentes linguagens de programação, tornando inviável
uma análise conjunta da produtividade usando métricas de linha de código.
Essa necessidade motivou a busca de técnicas de medida que
fossem independentes da tecnologia utilizada, surgindo, então, a medição por
pontos de função. Com o crescente uso de pontos de função veio à
necessidade de padronizar essa técnica, que ocorreu em 1986 com a fundação
do IFPUG – International Function Point Users Group.
Posteriormente surgiram outras técnicas de medição funcional, mas
nenhuma delas alcançou a aceitação tão ampla pelo mercado quanto os
pontos de função do IFPUG.
Tabela 1.1 - Comparativa entre Técnicas de Métrica de Softwares
LOC Halstead PF PCU Independência de Tecnologia Não Sim Sim Não Produção de Resultados Consistentes Sim Sim Sim Sim Compreensível pelo Usuário Leigo em Informática Não Não Sim Sim Significância para o Usuário Final Não Não Sim Sim Utilizado em Estimativas Não Não Sim Sim
(Anselmo, 2010?,p.16 – adaptada pelo autor)
1.1. LOC – Linhas de Código
Primeira metodologia de métrica de software considerada, já que é
intuitiva e utilizada por estudantes da área ao ingressarem na prática de
12
programação, ao compararem entre si o número de linhas de código dos
programas desenvolvidos.
Porém a aparente facilidade de medir por linhas de códigos pode
levar a um peso e várias medidas se alguns pontos não forem esclarecidos
com antecedência, como:
Contabilizar ou não linhas em branco, linhas de comentários ou
comandos nulos;
Contabilizar ou não múltiplos comandos como várias linhas ou
somente uma linha;
Contabilizar apenas uma linha quando um único comando ou
declaração é expresso em múltiplas linhas
Contabilizar como linhas os delimitadores de blocos de
comandos obrigatórios ou opcionais
Nota-se que a contagem de linhas de códigos pode envolver
diversas regras para ser realizada e, de fato, não existe um padrão dessa
contagem. Soma-se a isso a total falta de significado para o cliente a
quantidade de linhas de código, a dependência da linguagem de programação
e, ainda por cima, da qualidade da programação do profissional envolvido.
Para que a estimativa por LOC seja confiável é necessário que o
desenvolvimento do sistema esteja em estágio avançado para que se obtenha
indicadores úteis para o gerenciamento do projeto. Inclusive, a própria
linguagem de programação empregada, fundamental para o processo de
contagem por linhas de código, muitas vezes não é decidida na fase inicial do
ciclo de vida.
Conclui-se que a contagem de linhas de código é de difícil
metrificação e muito dependente da tecnologia empregada, no caso, da
13
linguagem de programação, não sendo recomendado como metrificação de
software em qualquer projeto atual.
1.2. Sistema Halstead
Sistema métrico surgido em 1972, desenvolvido por Maurice
Halsead da Universidade de Purdue, baseado no conceito de que o tamanho e
a complexidade de um programa são definidos pela quantidade de operadores
(comandos e palavras reservadas da linguagem utilizada) e operandos (itens
de dados que o programa tratará), dando origem a um sistema que permite o
cálculo do tamanho do programa e do esforço de programação.
Quatro medidas são geradas após a análise e quantificação dos
operandos e operadores, segundo suas quantidades e ocorrências, para,
então, calcular o comprimento e volume do programa com aplicações de
fórmulas pré-definidas.
Essa metodologia é independente da linguagem de programação,
mas sendo baseada na sintaxe dos programas, não considerando seu
conteúdo. Também apresenta como desvantagem o fato de ser
incompreensível para o usuário e só ser aplicada após a codificação final do
programa, não servindo, portanto, para estimativas em projetos.
1.3. Pontos de Função
Pontos de Função é uma medida de dimensionamento de software
através da funcionalidade implementada em um sistema, sob o ponto de vista
do usuário. Visa medir a funcionalidade requisitada e recebida pelo usuário e
medir projetos de desenvolvimento e manutenção independentemente da
tecnologia utilizada.
14
A Análise de Pontos de Função (APF) quantifica as funções contidas
dentro de um software em termos entendidos pelo usuário, relata diretamente
os requisitos do negócio, é independente da tecnologia utilizada, torna possível
a estimativa nas fases iniciais do processo de desenvolvimento de software,
fornece facilidade para uma reestimativa, fornece suporte a orçamento de
software, tempo de duração e gerência do projeto e apoia a análise de
produtividade e qualidade.
A APF tornou-se a metodologia padrão de medição de software no
mercado brasileiro. Diversas variações da APF surgiram ao longo do tempo,
mas a mais utilizada pelo mercado é a padronizada mantida pela IFPUG. A
IFPUG é uma empresa sem fins lucrativo, composta por pessoas e empresas
em diversos países com a finalidade de promover um melhor gerenciamento
dos processos de desenvolvimento e manutenção de softwares com o uso de
pontos de função e outras técnicas de medição. No Brasil, o braço do IFPUG é
o BFPUG - Brazilian Function Point Users Group (www.bfpug.com.br).
A IFPUG mantém um Manual de Práticas de Contagem (CPM –
Counting Pratices Manual) com o objetivo de padronização da técnica. Essa
padronização, através do manual, fez com que fosse o padrão mais difundido
no mercado para pontos de função. Atualmente a versão mais recente do CPM
é a 4.3.1.
Após a primeira publicação do CPM surgiram outras técnicas de
medição funcional, como Mark II, COSMIC e NESMA, porém sem uma
aceitação considerável pelo mercado. A NESMA (Netherlands Software
Metrics Users Association), associação de usuários de métricas de software da
Holanda, baseada no manual do IFPUG, lançou sua própria versão em 1990,
estando, atualmente na versão 2.1. Mantém a mesma filosofia, conceitos,
termos e regras, com algumas diretrizes diferentes do IFPUG. Algumas das
propostas das NESMA são bastante utilizadas pelos usuários de pontos de
função do IFPUG.
15
1.4. Pontos por Casos de Uso (PCU)
Na década de 90, com a disseminação da programação orientada a
objetos, houve uma mudança na forma de especificar e modelar sistema.
Nesta época surgiu UML (Unified Modeling Language) que é uma linguagem de
modelagem de sistemas padronizada, permitindo a especificação,
documentação, estruturação, e maior visualização lógica do desenvolvimento
completo de um sistema de informação. Essa linguagem é baseada em
diversos artefatos gráficos como diagramas de atores, diagramas de classes,
diagramas de casos de uso, diagramas de atividades e outros diagramas.
Em 1993 surgiu a metodologia de Pontos de Casos de Uso com o
objetivo de estimar recursos para projetos de softwares baseados em objetos.
Este processo consiste, resumidamente, em contar atores e identificar sua
complexidade, contar casos de uso e identificar sua complexidade, calcular os
PCUs não ajustados, determinar o fator de complexidade técnica, determinar o
fator de complexidade ambiental e calcular os PCUs ajustados. Com o
resultado dessa medição e conhecendo a produtividade média da organização
para produzir um PCU, pode-se estimar o esforço total para o projeto.
Porém, esta técnica não permite que seja aplicada a qualquer tipo
de softwares, independente de como este será desenvolvido. O PCU só pode
ser aplicado a projetos de softwares que especifiquem requisitos através de
casos de uso, o que nem sempre ocorre.
19
2.2 Fronteira da Aplicação
Determinar a fronteira da aplicação é muito importante para evitar
que diversas funções sejam indevidamente medidas ou deixadas de fora da
medição. Essa fronteira delimita o software que será medido e o mundo
exterior. Com frequência várias aplicações estão envolvidas no escopo de
uma contagem levando que diversas fronteiras sejam identificadas.
Figura 2.4 - Fronteiras de Aplicações e Mundo Exterior (elaborado pela autor)
O IFPUG especifica as seguintes regras para determinação da fronteira da aplicação:
Sua determinação deve ser realizada com base no ponto de vista
do usuário. O foco deve estar no que ele pode entender e
descrever;
A Fronteira entre aplicações deve ser baseada na separação das
funções conforme estabelecidos pelos processos do negócio,
não em considerações tecnológicas;
Em projetos de melhoria a fronteira estabelecida no início do
projeto deve estar de acordo com a fronteira já estabelecida para
a aplicação sendo modificada.
RH (outra aplicação)
Arquivo Docente
Aplicação de Vendas (aplicação sendo contada)
Função Lançamento de Ocorrência
Arquivo Ocorrência
Docente (Mundo Exterior)
20
2.3. Escopo da Contagem
O escopo da contagem define quais funções serão contadas, se
abrangerá um ou mais sistemas ou apenas parte de um sistema. A definição
do escopo é mais trabalhosa em contagem de projetos de melhoria, de forma
que contenha somente as funções que sejam afetadas pelo projeto. O escopo
da contagem pode abranger:
Todas as funcionalidades disponíveis;
Apenas as funcionalidades efetivamente utilizadas pelo usuário;
Apenas algumas funcionalidades específicas (relatório,
transações cadastrais e etc.).
2.4. Funções do Tipo Dado
As funções do tipo dado representam a funcionalidade fornecida
pela aplicação ao usuário de forma a atender sua necessidade de
armazenamento de dados. São classificados em Arquivo Lógico Interno (ALI) e
Arquivo de Interface Externa (AIE). Na APF arquivo refere-se a um grupo de
dados logicamente relacionados e reconhecidos pelo usuário. A diferença
entre ALI e AIE é que um Arquivo Lógico Interno está dentro da fronteira da
aplicação sendo contada, enquanto que o Arquivo de Interface Externa está
conceitualmente fora da fronteira dessa aplicação. Um AIE é obrigatoriamente
um ALI de outra aplicação.
Um ALI é um grupo de dados ou informações de controle
logicamente relacionado, identificável pelo usuário e mantido na fronteira da
aplicação sendo contada. Objetiva armazenar dados mantidos por um ou mais
processos elementares da aplicação que está sendo contada.
21
Um AIE é um grupo de dados ou informações de controle
logicamente relacionado, identificável pelo usuário, referenciado pela aplicação
mas mantido fora da fronteira da aplicação sendo contada. Objetiva armazenar
dados de outra aplicação mantidos por um ou mais processos elementares da
aplicação que está sendo contada.
Processo elementar é a menor unidade de atividade significativa
para o usuário, constituído de uma transação completa, completo em si mesmo
e que deixa o negócio da aplicação em um estado consistente. Um cadastro
de pessoa costuma conter quatro processos elementares: Inclusão de Pessoa,
Consulta de Pessoa, Alteração de Pessoa e Exclusão de Pessoa.
Cada ALI ou AIE deve ter sua complexidade funcional determinada
em função da quantidade de Tipos de Dados (TD) e Tipos de Registros (TR)
que o compõe.
A tabela a seguir mostra a complexidade segundo a relação entre
TDs e TRs:
Tabela 2.1 - Complexidade Funcional dos ALI e AIE
Tipos de Dados Tipos de Registros menos que 20 20 a 50 mais que 50
1 Baixa Baixa Média 2 a 5 Baixa Média Alta
mais que 5 Média Alta Alta (Vasquez,2012,p.72)
Após determinar a complexidade dos arquivos calculam-se as
respectivas contribuições na contagem de pontos de função, segundo a tabela
a seguir:
22
Tabela 2.2 - Contribuição em Pontos de Função das Funções do Tipo Dado
Complexidade Tipo de Função Baixa Média Alta
ALI 7 PFs 10 PFs 15 PFs AIE 5 PFs 7 PFs 10 PFs
(Vasquez,2012,p.76)
2.4.1. Tipo de Dado
Tipo de Dado é um campo único, reconhecido pelo usuário e não
repetido. Para que um campo seja contado com um TD é necessário que se
enquadre nas regras de contagem abaixo:
Contar um TD para cada campo único reconhecido pelo usuário e
não repetido, mantido ou recuperado de um ALI ou AIE por meio
da execução de um processo elementar. Campo único deve ser
analisado pela visão do usuário, isto é, mesmo que os campos de
uma data estejam armazenados separadamente conta-se
somente um campo do TD, pois o mesmo é visto pelo usuário
como um campo data;
Quando duas aplicações mantêm ou referenciam o mesmo
ALI/AIE, conta-se somente os campos utilizados pela aplicação
em análise. Exemplo considerando um arquivo Pessoa com os
campos nome, CPF, logradouro, cidade, estado e CEP:
o Para uma aplicação que mantenha ou referencie os
campos nome e CPF conta-se 2 (dois) TDs;
o Para uma segunda aplicação que mantenha ou referencie
os campos nome, logradouro, cidade, estado e CEP do
mesmo arquivo conta-se 5 (cinco) TDs;
o Já para uma terceira aplicação de mala direta que além do
nome referencie os dados do endereço de forma
23
aglutinada (Rua Ernesto Barbosa 1050 ... RJ) conta-se
apenas 2 TDs, um para o nome e outro para o endereço.
Conta-se um TD para cada campo solicitado pelo usuário para
estabelecer um relacionamento com outro arquivo lógico (ALI ou
AIE). São as chamadas chaves estrangeiras em banco de dados.
Caso a chave seja composta por vários campos, todos eles
devem ser contados como tipos de dados. Quando um arquivo
lógico, isto é, na visão do usuário é composto por mais de uma
tabela no banco de dados a chave estrangeira usada para
estabelecer o relacionamento entre essas tabelas deve ser
contada apenas uma vez.
2.4.2. Tipo de Registro
Um tipo de registro é um subgrupo de dados reconhecido pelo
usuário e componente de um ALI ou AIE. Existem dois tipos de subgrupos:
Opcionais: quando o usuário tem a opção de não informar no
processo elementar que cria ou adiciona dados no arquivo ou
Obrigatórios: quando o usuário requer que sejam sempre
utilizados pelo processo elementar que cria ou adiciona dados ao
arquivo.
Para determinar o número de tipos de registros de um ALI ou AIE é
necessário seguir as seguintes regras:
Contar um TR para cada subgrupo obrigatório ou opcional de
cada ALI ou AIE;
Se não existir subgrupo então contar o próprio ALI/AIE como um
TR.
24
2.5. Funções do Tipo Transação
Funções do tipo transação são classificadas em Entradas Externas
(EE), Saídas Externas (SE) e Consultas Externas (CE) e representam a
funcionalidade fornecida ao usuário para atender às suas necessidades de
processamento de dados da aplicação.
Entrada Externa é um processo elementar que processa dados ou
informações de controle recebidos de fora da fronteira da aplicação. Objetiva
manter (incluir, alterar ou excluir dados de) um ou mais Arquivos Lógicos
Internos e/ou modificar o comportamento do sistema. São exemplos de EEs
transações que recebem dados externos utilizados na manutenção de ALIs,
janelas que permitem adicionar, excluir e alterar registros em ALIs (cada função
destas é uma entrada externa) e processamento em, lotes de atualização de
bases cadastrais a partir de arquivos de movimento. Não são exemplos de EE
telas de filtro de relatório e consultas (são parte do relatório ou consulta),
menus por ser um meio de agrupar e acionar transações e telas de login, cuja
principal intenção é dizer se o usuário tem ou não acesso.
Saída Externa é um processo elementar que envia dados ou
informações de controle para fora da fronteira da aplicação. Apresenta
informações ao usuário por meio de lógicas de processamento que não seja
apenas a recuperação de dados ou informações de controle. A lógica de
processamento sempre contém ao menos uma fórmula matemática ou cálculo,
criar dados derivados, manter um ou mais ALIs ou alterar o comportamento do
sistema. Exemplos de SE são relatórios com totalização de dados, relatórios
que atualizem arquivos, consultas com cálculos ou apresentação de dados
derivados, arquivo de movimento grado para outra aplicação, informações em
formato gráfico e telas de login com criptografia ou atualização de dados. Não
são exemplos telas de ajuda (geralmente é um requisito não funcional), drop-
25
downs ou combobox (geralmente são CEs, pois consistem em recuperação e
apresentação de dados) e consultas e relatórios sem nenhuma totalizador, que
não atualizam arquivos, não possuam dados derivados ou modifiquem o
comportamento do sistema.
Consulta Externa é um processo elementar que envia dados ou
informações de controle para fora da fronteira da aplicação. Objetiva
apresentar informação ao usuário por meio de uma simples recuperação de
dados ou informação de controle de ALIs e AIEs.Não pode conter fórmulas
matemáticas ou cálculo em criar dados derivados em sua lógica de
processamento. Exemplos de EEs são informações em formato gráfico, drop-
dows (desde que recuperem dados de ALIs ou AIEs - valores codificados
diretamente no programa fonte não são contados), telas de login sem
criptografia e menus gerados. Não são exemplos menus estáticos e relatórios
ou consultas que contenham cálculo ou gerem dados derivados.
As Entradas Externas, Saídas Externas e Consultas Externas são
classificadas com relação a sua complexidade funcional em relação ao número
de arquivos referenciados (ALIs/AIEs) e pelo número de tipos de dados
envolvidos, conforme as duas tabelas a seguir:
Tabela 2.3 - Complexidade para Entrada Externa
Tipos de Dados Arquivos Referenciados menos que 5 5 a 15 mais que 15
1 Baixa Baixa Média 2 Baixa Média Alta
mais que 2 Média Alta Alta (Vasquez,2012,p.10)
Tabela 2.4 - Complexidade para Saída Externa e Consulta Externa
Tipos de Dados Arquivos Referenciados menos que 6 6 a 19 Mais que
1 Baixa Baixa Média 2 ou 3 Baixa Média Alta
mais que 3 Média Alta Alta (Vasquez,2012,p.106)
26
Determinando os tipos de dados para função de transação:
Cada atributo que atravesse a fronteira da aplicação (entrando ou
saindo), reconhecido pelo usuário, único e não repetido;
Cada ação envolvida na função: seleção de checkbox, ação de
salvar os dados da tela e etc.
Após determinar a complexidade das funções do tipo transação
calculam-se as respectivas contribuições na contagem de pontos de função,
segundo a tabela a seguir:
Tabela 2.5 - Contribuição em Pontos de Função das Funções do Tipo Transação
Tipo de Função Baixa Média Alta Entrada Externa 3 PFs 4 PFs 6 PFs Saída Externa 4 PFs 5 PFs 7 PFs Consulta Externa 3 PFs 4 PFs 6 PFs
(Vasquez,2012,p.110)
2.6. Tamanho Funcional
O cálculo do tamanho funcional difere para cada um dos três tipos
de contagem: projeto de desenvolvimento, projeto de melhoria de um sistema e
de uma aplicação pronta.
2.6.1. Projeto de Desenvolvimento
Possui dois componentes em seu cálculo. O primeiro é o das
funcionalidades da aplicação requisitada pelo usuário, isto é, funções utilizadas
após a instalação do sistema de forma a atender as necessidades correntes do
negócio. O segundo é o das funcionalidades de conversão requisitas pelo
usuário, isto é, funções utilizadas somente no momento de instalar o novo
27
sistema, de forma a converter dados ou fornecer ferramentas de conversão
solicitadas pelo usuário, como relatórios de verificação de conversão. A
fórmula de cálculo é a seguinte:
DFP = ( ADD + CFP )
Onde:
DFP: tamanho do projeto de desenvolvimento;
ADD: tamanho das funções entregues;
CFP: tamanho das funções de conversão.
2.6.2. Projeto de Melhoria
Um projeto de melhoria pode envolver alterações de funções já
existentes, inclusão de novas funções e exclusão de novas funções. Pode,
também, necessitar de funções de conversão de dados ou fornecer outros
requisitos de conversão, como relatórios de conversão, que serão utilizados
somente no processo de instalação das melhorias, sendo descartadas após a
instalação. A fórmula de cálculo é a seguinte:
EFP = ADD + CHGA + DEL + CFP
Onde:
EFP: número de pontos de função do projeto de melhoria;
ADD: tamanho das funções incluídas pelo projeto de melhoria;
CHGA: tamanho das funções modificadas, refletindo as funções
após as modificações;
DEL: tamanho das funções excluídas pelo projeto de melhoria;
28
CFP: tamanho das funções de conversão.
Não é necessário que se tenha conhecimento prévio dos pontos de
função da aplicação, pois apenas as funções que serão afetadas pela melhoria
serão contadas. Neste caso contam-se os pontos de função das funções
adicionadas, contam-se as funções alteradas após as modificações e contam-
se os pontos de função das funções que serão excluídas. Caso a aplicação já
tivesse seus pontos de função contados não seria necessário recontar os das
funções excluídas.
Alterações em Arquivos Lógicos são consideradas na contagem
quando existe a inclusão ou exclusão de atributo, ou utilização de um atributo
já existente no arquivo, mas não utilizado pela aplicação, e que venha a ser
utilizado pela aplicação sendo contada. Um atributo novo em um arquivo lógico
que não afete a aplicação não é contado, pois não afeta nenhuma
funcionalidade da aplicação.
Mudanças em transações são consideradas quando ocorre inclusão,
alteração ou exclusão de Tipos de Dados, quando Arquivos Referenciados são
alterados, adicionados ou exclusão na função ou ocorra alterações em Lógicas
de Processamento. A alteração em uma lógica de processamento pode afetar
diversas funções que a utilize, dessa forma, todas essas funções deverão ser
contempladas na contagem.
2.6.3. Aplicação
A contagem dos Pontos de Função de uma aplicação já pronta pode
ocorrer de duas formas. Inicialmente pela necessidade de metrificar o tamanho
desta aplicação. Depois pela necessidade de atualizar os Pontos de Função
da aplicação após um projeto de melhoria ser concluído.
29
A seguir é mostrada a fórmula de contagem inicial da aplicação:
APF = ADD
Onde:
APF: tamanho da aplicação;
ADD: tamanho das funções da aplicação.
Para atualizar os Pontos de Função após a conclusão de um projeto
de melhoria a fórmula é a seguinte:
AFPA = ( AFPB + ADD + CHGA ) – ( CHGB + DEL )
Onde:
AFPA: tamanho da aplicação após a melhoria;
AFPB: tamanho da aplicação antes da melhoria;
ADD: tamanho das funções incluídas pelo projeto de melhoria;
CHGA: tamanho das funções alteradas pelo projeto de melhoria
após seu término;
CHGB: tamanho das funções alteradas pelo projeto de melhoria
antes de sua alteração;
DEL: tamanho das funções excluídas pelo projeto de melhoria
Deve-se observar que funções de conversão de dados não fazem
parte da aplicação, logo não entram no cálculo do tamanho da aplicação.
30
2.7. Documentação
Ao final do processo de contagem é importante que todas as
funcionalidades tenham seus respectivos tamanhos documentados, de forma a
guardar toda a memória de cálculo realizado. Essa memória de cálculo
facilitará que todo o processo de análise seja verificado, caso se faça
necessário.
Essa documentação pode ser registrada conforme Tabela A2 do
exemplo prático embutido como apêndice neste trabalho.
31
CAPÍTULO III
ESTIMATIVA DE SOFTWARE USANDO APF
Estimar o tamanho de um projeto é importante para que se possa
conhecer com precisão qual será o tempo necessário para concluí-lo e quanto
o mesmo custará. O processo de estimativa deve fornecer indicadores que
permitam o planejamento e controle já nas fases iniciais do projeto.
A utilização de Pontos de Função como unidade de medida permite
a obtenção dos indicadores necessários para a estimativa, já que essa
metodologia depende somente da funcionalidade requerida pelo programa a
ser desenvolvido. Assim, a utilização por Pontos de Função permite que as
quatro atividades abaixo sejam estimadas para um projeto de software:
1. Estimar o tamanho do produto a ser gerado;
2. Estimar o esforço empregado na execução do projeto;
3. Estimar o custo do projeto.
4. Estimar a duração do projeto;
Uma técnica simples para estimar projetos por Pontos de Função é a
utilização de bases históricas. Partindo do conhecimento do tamanho de
projeto similar estima-se o tamanho do novo projeto como um percentual do
tamanho daquele. Porém a precisão dessa técnica depende da qualidade do
valor do tamanho do projeto similar e o grau da própria similaridade entre os
projetos.
32
3.1. Estimativa do Tamanho do Produto
A contagem detalhada dos PFs de um sistema certamente seria a
fórmula mais precisa para se obter o tamanho do produto a ser desenvolvido.
Porém essa técnica requer maior tempo para ser realizado e depende de
especificações mais detalhadas sobre os requisitos do sistema.
Pela necessidade de se obter estimativas já nas fases iniciais do
projeto é necessário realizar uma contagem indicativa, quando se tem uma
visão superficial do projeto com um bom grau de fidelidade do resultado.
Conforme o levantamento dos requisitos é realizado outras estimativas mais
precisas são realizadas, aumentando a qualidade do planejamento do projeto.
3.1.1. Contagem Indicativa
Técnica mais simples que considera a contagem de dois
componentes da análise de pontos de função: quantidade de Arquivos Lógicos
Internos e quantidade de Arquivos de Interfaces Externos. Após identificar as
quantidades de ALIs e AIEs é necessário aplicar a fórmula abaixo para
determinar a estimativa do tamanho do produto em PFs:
TPF = qALIs * 35 + qAIEs * 15
Onde:
TPF: total de pontos de função estimados;
qALIs: quantidade de Arquivos Lógicos Internos;
qAIEs: quantidade de Arquivos de Interfaces Externos.
Os multiplicadores 35 e 15 representam as médias de pontos de função supondo a média abaixo para cada tipo de arquivo:
33
Para cada ALI: média de três Entradas Externas, duas Saídas
Externas e uma Consulta Externa;
Para cada AIE: uma Saída Externa e uma Consulta Externa.
Essa é a primeira estimativa, considerando os requisitos iniciais
levantados com o usuário, que pode ser determinada permitindo o início do
planejamento do projeto. Com frequência o modelo de dados está disponível
ou é possível levantar os ALIs e AIEs com certa facilidade, permitindo aplicar
esta técnica da Contagem Indicativa de Pontos de Função.
3.1.2. Complexidade Média
Essa técnica é um aperfeiçoamento da técnica acima dependendo
da definição da quantidade de Entradas Externas, Saídas Externas e Consultas
Externas do produto. Após essa definição aplica-se a fórmula a seguir:
TPF = qALIs * 7,4 + qAIEs * 5,5 + qEEs * 4,3 + qSEs * 5,4 + qCEs * 3,8
Onde:
TPF: total de pontos de função estimados;
qALIs: quantidade de Arquivos Lógicos Internos;
qAIEs: quantidade de Arquivos de Interfaces Externos.
qEEs: quantidade de Entradas Externas
qSEs: quantidade de Saídas Externas
qCEs: quantidade de Consultas Externas
34
Os multiplicadores de cada quantidade foram determinados através
de uma média de complexidade para projetos de desenvolvimentos,
distribuídos por tipos de função.
Essa metodologia pode ser aplicada após uma segunda fase do
levantamento dos requisitos, isto é, após o levantamento de todas as funções
de transações necessárias para atender o sistema solicitado pelo usuário.
Como sua fórmula utilizada todos os elementos da contagem da APF (ALIs,
AIEs, EEs, SEs e CEs) seu resultado costuma ser mais preciso do que o da
Contagem Indicativa.
3.1.3. Contagem Detalhada
A Contagem Detalhada ocorre quando todos os Tipos de Dados,
tanto das funções de dados como das funções de transações, tenham sido
levantados. Essa etapa permite que a complexidade de cada função seja
determinada e, por consequência, seu respectivo tamanho em Pontos de
Função. A soma de todos os PFs de cada função será o tamanho do produto
em Pontos de Função.
Para um aplicativo novo o tamanho calculado poderá conter o
tamanho da aplicação em PFs mais o tamanho, também em PFs, das funções
de conversão de dados. O tamanho calculado neste passo será o tamanho
final do sistema a ser considerado no planejamento do projeto, exceto se
ocorrer alteração de seu escopo.
35
3.2. Estimativa de Esforço
Estimativa de esforço indica quanto tempo os membros do projeto
gastarão para desenvolver o produto. Para isso precisa-se conhecer a
produtividade da equipe do projeto e o tamanho do produto.
E = P * PFs
Onde:
E: esforço necessário para desenvolver o produto;
P: produtividade média da equipe, geralmente em homem/hora;
PFs: tamanho do projeto em pontos de função.
Diversos fatores influenciam no valor da produtividade, como a
linguagem de programação, a experiência da equipe com essa linguagem de
programação e demais ferramentas utilizadas no desenvolvimento do produto.
Inicialmente pode-se utilizar uma tabela de produtividade externa ou
a experiência da equipe para determinar o valor da produtividade. O melhor é
que a organização procure montar um histórico de produtividade próprio, como
exemplificado na tabela:
Tabela 3.1 - Produtividade por Linguagem de Programação
Produtividade (horas / PF) Produtividade (PF / hora) Linguagem Baixa Média Alta Baixa Média Alta
Java 17 hs 15 hs 12 hs 0,0588 0,0667 0,0833 SQL 9 hs 6 hs 4,5 hs 0,1111 0,1667 0,2222
HTML 8,5 6 4,5 hs 0,1176 0,1667 0,2222 PHP 15 hs 11 hs 8 hs 0,0667 0,0909 0,1250
(elaborada pelo autor)
A produtividade varia de uma empresa para outra, em função de
diversas características como conhecimento, gerenciamento, uso de
36
metodologias de desenvolvimento e reutilização de artefatos, mostrando a
importância de cada organização manter sua própria tabela de base histórica.
O nível de produtividade (baixa, média e alta) a ser utilizado
depende da complexidade da aplicação a ser desenvolvida e a experiência da
equipe na plataforma utilizada. Para sistema desenvolvido em uma linguagem
nova deve-se utilizar como base a linguagem da base histórica mais similar.
3.3. Estimativa de Custo do Produto
A estimativa de custo do desenvolvimento de um sistema não deve
considerar somente o gasto com sua implementação, devendo fazer parte do
cálculo os gastos envolvidos em outras etapas, como levantamento de
requisitos, arquitetura, homologação, testes e implantação. Assim como outros
custos inerentes ao projeto como gastos com equipamentos e licença de
softwares, local de trabalho, viagens, treinamento, consultoria e outros gastos.
Caso a instituição não esteja desenvolvendo um software para uso próprio e
sim para venda ainda deve incluir nos cálculos o lucro pretendido.
Desse modo cada instituição pode formar sua fórmula de cálculo do
custo de projeto considerando o tamanho do produto por Pontos de Função.
Outros fatores que influenciam o preço final é o conceito utilizado para incluir o
lucro (margem bruta, margem líquida ou mark-up), assim como a influência da
legislação em vigor que diferencia os impostos relativos a programas vendidos
em larga escala que são considerados mercadoria com incidência de ICMS, de
programas desenvolvidos especificamente para um cliente que é considerado
prestação de serviço, quando incide o ISS.
Um exemplo de fórmula para cálculo do custo final do produto é
mostrado a seguir:
37
CP = ∑¹ (qHP * vHP) + ∑² (qPFs * vHPi * EPF) + OC
Onde:
CP: custo do projeto;
∑¹: somatório do custo com demais profissionais envolvidos;
qHP: quantidade de horas do profissional;
vHP: valor da hora do profissional;
∑²: somatório do custo de implementação por linguagem utilizada
no desenvolvimento do produto;
qPFs: tamanho da parte do projeto em Pontos de Função
referente à linguagem utilizada;
vHPi: valor da hora do desenvolvedor na linguagem em questão;
EPF: produtividade na implementação de um Ponto de Função
na linguagem em questão;
OC: outros custos (equipamentos, insumos, impostos, viagens,
treinamento, entre outros).
Determinado o custo do projeto é possível calcular o valor final de
um Ponto de Função, dividindo o Custo do Projeto pela quantidade de Pontos
de Função:
vPF = CP / qPFs
Onde:
vPF: valor de um Ponto de Função do projeto em questão
CP: custo do projeto;
qPFs: tamanho do projeto em Pontos de Função;
Esse valor final de um Ponto de Função é um valor tangível tanto
para o cliente quanto para empresa da área da tecnologia da informação,
38
sendo utilizado como base em contratos em geral e, cada vez mais, utilizado
em concorrências públicas.
A tabela a seguir extraída de http://www.fattocs.com.br/editais.asp,
baseada em editais públicos e adaptada para o exemplo pretendido, mostra o
valor de cada Ponto de Função em relação a diversos contratos
governamentais.
Tabela 3.2 - Contratos Públicos para Desenvolvimento de Software por PF
Organização Ano Referência Tamanho (PF)
Preço (R$/PF)
ADASA 2010 Concorrência 001/2010. 5mil 289,43 ANCINE 2008 Concorrência 1/2008. 5mil 552,08 ANCINE 2011 Pregão 20/2011. 5mil 899,90 ANEEL 2009 Pregão 71/2008. 10mil 297,50 ANTAQ 2009 Pregão 02/2009. 4,18mil 421,05 ANTT 2009 Pregão 77/2009. 9,3mil 359,81 CEF 2010 Pregão 042/7033-2010. 3,6mil 248,33 INCRA 2009 Pregão 60/2009. 10mil 348,00 INEP 2009 Pregão 11/2010. 20mil 349,23 IPLANRIO 2011 Pregão 63/2011. 30mil 308,00 Ministério da Agricultura 2009 Pregão 15/2009. 15mil 676,67 Ministério da Educação 2010 Pregão 26/2010. 31,20mil 352,49 Ministério da Fazenda 2010 Pregão 28/2010. 14,50mil 217,00 Ministério da Justiça 2009 Pregão 005/2009. 21,4mil 476,55 Ministério da Saúde 2010 Pregão 154/2010. 30mil 609,83
SETC-DF 2011 Pregão 21/2011. 1,0mil 297,70 SETC-DF 2011 Pregão 307/2011. 1,2mil 200,00 STF 2009 Pregão 167/2009. 11mil 398,00 Telebrás 2011 Pregão 24/2011. 5mil 355,90
TRT2 2009 Pregão 111/2009. 15,25mil 204,00 TRT2 2010 Pregão 114/2009. 7,2mil 268,23 TRT12 2010 Pregão 10896/2010. 2mil 430,00
(elaborado pelo autor)
Analisando a tabela anterior é possível observar variações
significativas no preço final de um Ponto de Função. Essa diferença é
consequente das diferenças técnicas e da complexidade de cada contrato.
39
O preço do Ponto de Função somente para o trabalho de codificação
e testes de um programa de computador certamente é inferior ao preço para
contratação do projeto que envolva todo o seu ciclo de desenvolvimento, desde
o levantamento de requisitos até a implementação do sistema. Também influi
nesse valor a inclusão de outros produtos que devam ser entregues, como
manual do usuário e modelos da UML. As diversas plataformas tecnológicas e
linguagens de programação contribuem consideravelmente para variação do
preço do Ponto de Função pelas influências diretas que exercem na
produtividade do trabalho a ser realizado.
3.4. Estimativa de Duração do Projeto
A partir do esforço estimado é possível obter a estimativa de
duração do projeto uma vez que se defina a equipe necessária. Uma fórmula
simplista é a razão do esforço necessário pela quantidade de recursos
utilizados pelo projeto, como mostrado na fórmula a seguir:
D = E / R
Onde:
D: duração do projeto;
E: esforço necessário para desenvolver o produto;
R: quantidade de recursos envolvidos.
Na realidade essa relação linear entre prazo e recurso não costuma
ser tão simples como exemplificada acima. Essa relação prescinde de diversas
características inerentes ao planejamento das atividades, como a relação de
precedência estabelecida entre as atividades e, principalmente, para o
chamado caminho crítico, que será aquela relação de dependência obrigatória
40
entre atividades que determinará o tempo mínimo do projeto
independentemente da quantidade de recursos alocados.
Diversas técnicas de simulação de duração das atividades podem
ser empregadas para estimar o tempo que um projeto levará para ser
realizado, como as técnicas de Simulação Monte Carlos, PERT e CPM². Essas
técnicas não serão detalhadas por não estarem no foco do estudo deste
trabalho.
41
CONCLUSÃO
A Análise de Pontos de Função inicialmente tinha como objetivo
disponibilizar uma metodologia para verificar a produtividade do
desenvolvimento de software. Porém mostrou-se capaz de ser aplicada no
planejamento de projetos por permitir a estimativa de unidades de tamanho, a
partir dos quais se estima o esforço e custo.
A atividade da APF demanda um custo adicional pela participação de
um analista especialista em métricas para a correta interpretação e análise dos
requisitos do usuário. Essa demanda é compensada por um melhor
planejamento e acompanhamento do projeto. Permite acompanhar o aumento
do escopo com a realização de estimativas e medições dos pontos de função
em cada fase do ciclo de vida do projeto, determinando se os requisitos
funcionais aumentaram ou diminuíram, e se essa variação corresponde a
novos requisitos ou ao melhor detalhamento de requisitos já existentes.
A APF passou a ser usada para medir os resultados entregues por uma
empresa produtora de software com o intuito de determinar o valor a ser pago a
mesma. Na visão da empresa contratante do software a ideia da metodologia
não é estimar custo ou esforço, mas controlar o valor das entregas,
independentemente de quanto custo ou esforço efetivamente tenham sido
empregados. Permite contratos a preço unitário tendo como base a unidade
Ponto de Função que representa um bem tangível para o cliente, possibilitando
uma melhor distribuição de riscos entre cliente e fornecedor. Passou a
fundamentar a negociação de contratos, possibilitando utilizar os pontos de
função para controlar níveis de serviço em contratos de desenvolvimento,
manutenção ou migração de aplicação.
42
O dimensionamento ou a estimativa da quantidade de pontos de um
projeto auxilia na análise do make or buy, após o usuário avaliar o custo do
pacote, o tamanho das funções e a produtividade e custo da própria equipe.
Essa utilização cada vez mais expressiva da APF ocorre por esta ser
orientada pela visão do usuário, sendo uma definição formal das necessidades
de negócio do cliente em sua própria linguagem. A contagem de pontos de
função é obtida pelo uso da informação em uma linguagem comum a usuários
e especialistas da informática. Os desenvolvedores que traduzem essa
informação para a linguagem da tecnologia da informação.
43
BIBLIOGRAFIA CONSULTADA
Booch, Grady; Rumbaugh, James; Jacobson, Ivair. UML – Guia do Usuário. 8ª
Tiragem. Rio de Janeiro: Editora Campus Ltda, 2000.
Dinsmore, Paul Campbell; Cavalieri, Adriane. Como se tornar um
Profissional em Gerenciamento de Projetos. 4ª Ed. Rio de Janeiro:
Qualitymark Editora Ltda, 2011.
Hazan, Claudia; Staa, Arndt von. Análise e Melhoria de um Processo de
Estimativas de Tamanho de Projetos de Software. 37 folhas. Monografia
em Ciência da Computação, Pontifícia Universidade Católica do Rio de Janeiro,
Rio de Janeiro, 2005. Disponível em http://www.dbd.puc-
rio.br/depto_informatica/05_04_hazan.pdf. Último acesso: 20/04/2013.
Vasquez, Carlos Eduardo; Simões, Guilherme Siqueira; Albert, Renato
Machado. Análise de Pontos de Função: Medição, Estimativas e
Gerenciamento de Projetos de Softwares. 12ª Ed. São Paulo: Editora Érica
Ltda, 2012.
44
BIBLIOGRAFIA CITADA
(Anselmo, 2010?) Anselmo, Fernando. Análise de Ponto de Função. 33
slides. Disponível em:
http://www.fernandoans.site50.net/curso/curso03/Aula01-
APF.pdf. Último acesso: 11/05/2013.
(Hazan,2005) Hazan, Claudia; Staa, Arndt von. Análise e Melhoria de
um Processo de Estimativas de Tamanho de Projetos
de Software. 37 folhas. Monografia em Ciência da
Computação, Pontifícia Universidade Católica do Rio de
Janeiro, Rio de Janeiro, 2005. Disponível em
http://www.dbd.puc-
io.br/depto_informatica/05_04_hazan.pdf. Último acesso:
20/04/2013.
(TCU,2007a) Diário Oficial da União. Brasília. ACÓRDÃO Nº 1999/2007 -
TCU – PLENÁRIO. Edição de 28/09/2007.
(TCU,2007b) Diário Oficial da União. Brasília. ACÓRDÃO Nº 2024/2007 -
TCU – PLENÁRIO. Edição de 28/09/2007.
(Vasquez,2012) Vasquez, Carlos Eduardo; Simões, Guilherme Siqueira;
Albert, Renato Machado. Análise de Pontos de Função:
Medição, Estimativas e Gerenciamento de Projetos de
Softwares. 12ª Ed. São Paulo: Érica Ltda, 2012.
45
APÊNDICE
EXEMPLO PRÁTICO
Este exemplo foi desenvolvido com a finalidade de exemplificar
algumas das passagens avaliadas neste trabalho, sendo uma simplificação da
realidade, não possuindo a pretensão de especificar todas as regras,
necessidades e artefatos que estariam envolvidos em um sistema real. Sequer
foi considerada a funcionalidade de acesso. Portanto não cabe entrar no mérito
da análise do sistema ou do negócio.
Uma empresa de consultoria em informática foi contratada para
desenvolver um sistema acadêmico para um colégio de ensino fundamental e
médio. O sistema deverá aproveitar os cadastros do sistema central da
instituição com os dados de docentes e departamentos. O sistema será
desenvolvido em JAVA e utilizando o gerenciador de bancos de dados onde se
encontra os arquivos dos demais sistemas da instituição.
Após levantamento inicial foi constatado que o sistema possui 5
arquivos lógicos internos (Aluno, Histórico, Ocorrência, Disciplina e Turma) e 2
arquivos de interface externa (Docente e Departamento).
Nesse momento é possível realizar a primeira estimativa do tamanho
do sistema baseada no método da contagem indicativa, calculando que o
sistema possui o tamanho de 205 pontos de função:
TPF = qALIs * 35 + qAIEs * 15
TPF = 5* 35 + 2 * 15
TPF = 205 PFs
48
Tabela A2 – Documentação e Contagem Detalhada da Aplicação Exemplo
Aplicação: Sistema Acadêmico Função Tipo TD AR/TR Complexidade PF
Aluno ALI 24 3 Média 10 Inclusão de Aluno EE 30 4 Alta 6 Alteração de Aluno EE 30 4 Alta 6 Consulta de Aluno CE 24 2 Média 4 Exclusão de Aluno EE 5 1 Baixa 3 Ocorrência ALI 3 1 Baixa 7 Lançamento de Ocorrência EE 7 2 Média 4 Alteração de Ocorrência EE 7 2 Média 4 Consulta de Ocorrência CE 5 1 Baixa 3 Exclusão de Ocorrência EE 5 1 Baixa 3 Relação de Ocorrências SE 6 2 Média 5 Disciplina ALI 5 1 Baixa 7 Inclusão de Disciplina EE 8 2 Média 4 Alteração de Disciplina EE 8 2 Média 4 Consulta de Disciplina CE 14 3 Média 4 Exclusão de Disciplina EE 4 3 Média 4 Turma ALI 14 4 Baixa 7 Inclusão de Turma EE 10 2 Média 4 Alteração de Turma EE 10 2 Média 4 Consulta de Turma SE 13 3 Alta 7 Exclusão de Turma EE 4 2 Baixa 3 Quadro de Horário da Turma SE 10 3 Média 5 Diário de Turma SE 12 3 Média 5 Lançamento de Resultado EE 15 3 Alta 6 Alteração de Resultado EE 15 3 Alta 6 Consulta de Resultado SE 15 3 Média 5 Fechamento de Turma SE 35 2 Alta 7 Emissão de Boletim SE 30 3 Alta 7 Estatística por Faixa de Resultado SE 10 2 Média 5 Histórico ALI 19 2 Baixa 7 Inclusão de Histórico EE 22 3 Alta 6 Alteração de Histórico EE 22 3 Alta 6 Emissão de Histórico Escolar CE 30 3 Alta 6 Docente AIE 5 1 Baixa 5 Horários do Docente SE 10 3 Média 5 Relatório de Docentes SE 10 3 Média 5 Departamento AIE 2 1 Baixa 5
TOTAL de PFS: 194
(elaborada pelo autor)
Um exemplo de função do Tipo Transação é mostrado na Figura A3.
Essa EE para Lançamento de Ocorrência possui uma tela de filtro (não
ilustrada) para selecionar aluno mostrando a relação de todos os alunos
vinculados para seleção do aluno da ocorrência. Esta tela de filtro adiciona
apenas um dado à tela principal: a ação Selecionar Aluno. Os demais dados da
função também constam da tela principal: matrícula, nome e cancelar. Assim,
essa EE apresenta 7 tipos de dados envolvidos em sua transação: Selecionar
50
ANEXO
CONTAGEM ANTECIPADA DE PONTOS DE FUNÇÃO
http://www.fattocs.com.br/traduzido/earlyfpa.asp#bm_Indicative_function_point_count Último Acesso: 14/06/2013
(NESMA EARLY FPA COUNTING)
Esta é uma tradução do trabalho de autoria da NESMA, cuja versão original em inglês está disponível em http://www.nesma.nl/section/fpa/earlyfpa.htm. Share on facebook Share on twitter Share on email Share on print More Sharing Services 0
A NESMA reconhece três tipos de contagem de pontos de função:
contagem de pontos de função detalhada contagem de pontos de função estimativa contagem de pontos de função indicativa
Os métodos estimativo e indicativo para a contagem de pontos de função foram desenvolvidos pela NESMA para permitir que uma contagem de pontos de função seja feita nos momentos iniciais do ciclo de vida de um sistema. A contagem indicativa da NESMA é também conhecida no mundo como "método holandês".
Esta página discute os diferentes métodos para a contagem de pontos de função, sua aplicabilidade e resultados da pesquisa para determinação da exatidão de cada um dos métodos.
Você encontrará nesta página:
A contagem (detalhada) de pontos de função A contagem estimativa de pontos de função A contagem indicativa de pontos de função Exemplo das contagens detalhada, estimativa e indicativa Quando usar cada método para a contagem de pontos de função Resultados da pesquisa
A contagem (detalhada) de pontos de função
A contagem detalhada é a contagem usual de pontos de função e é realizada da seguinte forma:
determina-se todas as funções de todos os tipos (ALI, AIE, EE, SE, CE) determina-se a complexidade de cada função (Baixa, Média, Alta) calcula-se o total de pontos de função não ajustados
51
A contagem estimativa de pontos de função
A contagem estimativa é realizada da seguinte forma:
determina-se todas as funções de todos os tipos (ALI, AIE, EE, SE, CE) toda função do tipo dado (ALI, AIE) tem sua complexidade funcional avaliada como
Baixa, e toda função transacional (EE, SE, CE) é avaliada como de complexidade média
calcula-se o total de pontos de função não ajustados
Logo, a única diferença em relação à contagem usual de pontos de função é que a complexidade funcional não é determinada individualmente para cada função, mas pré-definida para todas elas.
A contagem indicativa de pontos de função
A contagem indicativa é realizada da seguinte forma:
determina-se a quantidade das funções do tipo dado (ALIs e AIEs) calcula-se o total total de pontos de função não ajustados da aplicação da seguinte
forma: tamanho indicativo (pf) = 35 x número de ALIs + 15 x número de AIEs
Portanto esta estimativa é baseada somente na quantidade de arquivos lógicos existentes (ALIs e AIEs)
A contagem indicativa é baseada na premissa de que existem aproximadamente três EEs (para adicionar, alterar, e excluir dados do ALI), duas SEs, e uma CE na média para cada ALI, e aproximadamente uma SE e uma CE para cada AIE.
Exemplo das contagens detalhada, estimativa e indicativa
Esta seção ilustra esses três tipo de contagem de pontos de função para um estudo de caso pequeno e simples: uma aplicação que mantém dados de Cliente e Produto, e referencia dados de Fornecedor.
Quanto mais exata se quer uma contagem de pontos de função, mais detalhados devem ser os requisitos do usuário. Esta é a razão pela qual esse estudo de caso apresenta os três métodos de contagem em ordem crescente de exatidão:
contagem indicativa de pontos de função contagem estimativa de pontos de função contagem (detalhada) de pontos de função.
52
Contagem indicativa de pontos de função
Requisitos do usuário:
o usuário deseja manter dados de Cliente e Produto e referenciar dados de Fornecedor.
Esta especificação (superficial) é o suficiente para uma contagem indicativa de pontos de função:
ALI: Cliente e Produto AIE: Fornecedor
Função do Tipo Dado Tipo de Função Pontos de Função (pré-definido)
Cliente ALI 35
Produto ALI 35
Fornecedor AIE 15
Indicativo do tamanho funcional 85 pf
Contagem estimativa de pontos de função
Para realizar uma contagem estimativa de pontos de função também são necessárias informações a respeito das funções transacionais, assim requisitos do usuário mais detalhados são necessários:
Requisitos do Usuário:
o usuário deseja adicionar, alterar, excluir e consultar dados de Cliente, e também necessita quatro diferentes tipos de relatórios sobre Cliente contendo dados calculados.
o usuário deseja adicionar, alterar, excluir e consultar dados de Produto, e também necessita de consultar o Fornecedor através de seu número e um relatório sobre Fornecedor com totalização de resultados.
Essa especificação mais detalhada dos requisitos do usuário mostra a real quantidade de funções do tipo transação, e torna possível uma contagem estimativa de pontos de função.
53
Função do tipo Dado ou Transação
Tipo de Função
Complexidade (pré-definida)
Pontos de Função (não ajustados)
Cliente ALI Baixa 7
Produto ALI Baixa 7
Fornecedor AIE Baixa 5
Incluir Cliente EE Média 4
Alterar Cliente EE Média 4
Excluir Cliente EE Média 4
Consultar Cliente CE Média 4
Relatório 1 de Cliente SE Média 5
Relatório 2 de Cliente SE Média 5
Relatório 3 de Cliente SE Média 5
Relatório 4 de Cliente SE Média 5
Incluir Produto EE Média 4
Alterar Produto EE Média 4
Excluir Produto EE Média 4
Consultar Produto CE Média 4
Relatório de Produto SE Média 5
Consulta de Fornecedor CE Média 4
Relatório de Fornecedor SE Média 5
Estimativa do tamanho funcional 85 fp
Contagem detalhada de pontos de função
Para se realizar uma contagem detalhada de pontos de função, somente o número de funções de cada tipo (EE, SE, CE, ALI, AIE) não é suficiente, também é necessário determinar a complexidade funcional (Baixa, Média, Alta) de cada função individualmente.
Na APF, a complexidade funcional de uma função (do tipo dado e do tipo transação) é determinada com base na quantidade do número de tipos de dados, tipos de registro e arquivos referenciados que são relevantes para a função. Esta é a razão pela qual os requisitos do usuário (como apresentados antes quando discutimos a contagem estimativa de pontos de função) precisam ser analisados com mais detalhes: quais
54
elementos de dados (DETs) e arquivos lógicos (FTR) são usados por cada função transacional (EE, SE, CE), e quais os grupo lógicos de dados (RETs) e elementos de dados (DETs) compõem a função do tipo dado (ALI, AIE).
Essa análise detalhada dos requisitos do usuário pode resultar na seguinte contagem de pontos de função:
Função do tipo Dado ou Transação
Tipo de função
Complexidade Pontos de Função (não ajustados)
Cliente ALI Média 10
Produto ALI Baixa 7
Fornecedor AIE Baixa 5
Incluir Cliente EE Alta 6
Alterar Cliente EE Média 4
Excluir Cliente EE Baixa 3
Consultar Cliente CE Baixa 3
Relatório 1 de Cliente SE Baixa 4
Relatório 2 de Cliente SE Média 5
Relatório 3 de Cliente SE Baixa 4
Relatório 4 de Cliente SE Alta 7
Incluir Produto EE Média 4
Alterar Produto EE Baixa 3
Excluir Produto EE Baixa 3
Consultar Produto CE Média 4
Relatório de Produto SE Média 5
Consulta de Fornecedor CE Baixa 3
Relatório de Fornecedor SE Média 5
Tamanho Funcional 85 pf
Conclusão
Neste estudo de caso em particular todos os três métodos apresentaram o mesmo resultado de 85 pontos de função para o tamanho funcional. Geralmente os resultados não são exatamente os mesmos, mas ainda assim são próximos entre si. Posteriormente nesta página serão apresentados os resultados da pesquisa da exatidão das contagens de pontos de função estimativa e indicativa.
55
Quando usar cada método para a contagem de pontos de função
A contagem detalhada de pontos de função é obviamente mais exata que a contagem estimativa e indicativa; mas em contrapartida consome mais tempo e necessita de especificações mais detalhadas. Cabe ao gerente do projeto e à fase do ciclo de vida em que se encontra o sistema para se decidir qual tipo de contagem de pontos de função pode ser usada. Em muitas aplicações uma contagem indicativa de pontos de função fornece surpreendentemente uma boa estimativa do tamanho da aplicação. Em muitas situações é relativamente fácil realizar uma contagem indicativa de pontos de função, pois o modelo de dados está disponível ou pode ser elaborado com pouco esforço.
Resultados da pesquisa feita com mais de 100 projetos
Usando um banco de dados com aproximadamente 100 aplicações desenvolvidas e implementadas, a NESMA pesquisou a exatidão das contagens estimativa e indicativa. A aplicações implementadas foram medidas usando os três tipos de contagem de pontos de função. Os resultados são apresentados em dois gráficos:
o tamanho calculado via contagem indicativa, versus o tamanho medido via contagem detalhada dos pontos de função
56
Observa-se uma boa correlação (linha reta) em ambos os casos. No gráfico da contagem indicativa, contudo, observa-se que há desvios consideráveis (em até 50%) em alguns casos. Isto mostra que deve-se usar a contagem indicativa com o devido cuidado. O ponto forte deste tipo de contagem é que é possível obter facilmente uma estimativa aproximada do tamanho de uma aplicação rapidamente.
Em uma aplicação com maior (ou com menor) número de saídas, talvez seja necessário alterar os multiplicadores de 35 e 15; mas a filosofia usada nessa abordagem pode ser usada de maneira geral.
O resultado da contagem estimativa e da contagem detalhada de pontos de função é muito próximo.
Página Inicial | Indique o Site | Fale Conosco | Política de Privacidade | Mapa do Site
FATTO Consultoria e Sistemas.
57
ÍNDICE
FOLHA DE ROSTO 2
AGRADECIMENTO 3
DEDICATÓRIA 4
RESUMO 5
METODOLOGIA 6
SUMÁRIO 7
INTRODUÇÃO 8
CAPÍTULO I
MÉTRICAS DE SOFTWARES 11
1.1. LOC – Linhas de Código 11
1.2. Sistema Halstead 13
1.3. Pontos de Função 13
1.4. Pontos por Casos de Uso (PCU) 15
CAPÍTULO II
ANÁLISE DE PONTO DE FUNÇÃO 16
2.1. Tipo de Contagem 18
2.2. Fronteira da Aplicação 19
2.3. Escopo da Contagem 20
2.4. Funções do Tipo Dado 20
2.4.1. Tipo de Dado 22
2.4.2. Tipo de Registro 23
2.5. Funções do Tipo Transação 24
2.6. Tamanho Funcional 26
58
2.6.1. Projeto de Desenvolvimento 26
2.6.2. Projeto de Melhoria 27
2.6.3. Aplicação 28
2.7. Documentação 30
CAPÍTULO III
ESTIMATIVA DE SOFWARE USANDO APF 31
3.1. Estimativa do Tamanho do Produto 32
3.1.1. Contagem Indicativa 32
3.1.2. Complexidade Média 33
3.1.3 Contagem Detalhada 34
3.2. Estimativa de Esforço 35
3.3. Estimativa de Custo do Produto 36
3.4. Estimativa de Duração do Projeto 39
CONCLUSÃO 41
BIBLIOGRAFIA CONSULTADA 43
BIBLIOGRAFIA CITADA 44
APÊNDICE
EXEMPLO PRÁTICO 45
ANEXO
CONTAGEM ANTECIPADA DE PONTOS DE FUNÇÃO 50
ÍNDICE 57
ÍNDICE DE FIGURAS 59
ÍNDICE DE TABELAS 60
LISTA DE ABREVIATURAS E SIGLAS 61
59
ÍNDICE DE FIGURAS
Figura 2.1 - Classificação dos Tipos de Dados 16
Figura 2.2 - Elementos da Contagem de Pontos de Função 17
Figura 2.3 - Modelo para Processo de Contagem 18
Figura 2.4 - Fronteiras de Aplicações e Mundo Exterior (vendedor) 19
Figura A1 - Figura A1 - Arquivos de Interfaces Externos do Exemplo 46
Figura A2 - Arquivos Lógicos Internos do Exemplo 47
Figura A3 - Tela Exemplo de Lançamento de Ocorrência 49
60
ÍNDICE DE TABELAS
Tabela 1.1 - Comparativa entre Técnicas de Métricas de Softwares 11
Tabela 2.1 - Complexidade Funcional dos ALI e AIE 21
Tabela 2.2 - Contribuição em Pontos de Função das Funções do Tipo
Dado
22
Tabela 2.3 - Complexidade para Entrada Externa 25
Tabela 2.4 - Complexidade para Saída Externa e Consulta Externa 25
Tabela 2.5 - Contribuição em Pontos de Função das Funções do Tipo
Transação
26
Tabela 3.1 - Produtividade por Linguagem de Programação 35
Tabela 3.2 - Contratos Públicos para Desenvolvimento de Software por
PF
38
Tabela A1 - Funcionalidades da Aplicação Exemplo 46
Tabela A2 - Documentação e Contagem Detalhada da Aplicação
Exemplo
48
61
LISTA DE ABREVIATURAS E SIGLAS
AIE Arquivo de Interface Externa
ALI Arquivo Lógico Interno
APF Análise de Pontos de Função
AR Arquivo Referenciado
BFPUG Brazilian Function Point Users Group
CE Consulta Externa
CGS Características Gerais do Sistema
COSMIC Common Software Measurement International Consortium
CPM Counting Pratices Manual
COM² Critical Path Method
DOU Diário Oficial da União
EE Entrada Externa
IFPUG International Function Point Users Group
LOC Lines of Code (Linhas de Códigos)
NESMA Netherlands Software Metrics Users Association
PCU Pontos por Casos de Uso
PERT Project Evaluation and Review Technique
PF Pontos de Função
SE Saída Externa
TCU Tribunal de Contas da União
TD Tipo de Dado
TR Tipo de Registro
UML Unified Modeling Language
Top Related