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