Guia de Contagem APF Versão 1 - compras.pe.gov.br · Cadastro de usuários e grupos ......

Guia de Contagem APF

Versão 1.00


Guia de Contagem APF ATI – www.ati.pe.gov.br Pág. 2 de 65

HISTÓRICO DE REVISÕES

Data Versão Descrição Autor

20/11/2010 1.00 Criação do Guia de Contagem APF Célio Santana / Gustavo Santos



SUMÁRIO

1. INTRODUÇÃO ............................................................................................................................................. 5

1.1. Definições, Acrônimos e Abreviações ............................................................................................. 5

2. OBJETIVOS DO DOCUMENTO .................................................................................................................. 6

3. ESTIMATIVAS DE PROJETO DE SOFTWARE .......................................................................................... 6

3.1. DETALHAMENTO DO PROCESSO DE ESTIMATIVA ................................................................. 10

3.2. PAGAMENTO BASEADO NO CICLO DE VIDA DA ENTREGA ................................................... 16

3.3. ESTIMATIVA DE PRAZO .............................................................................................................. 17

3.4. ESTIMATIVA DE CUSTO .............................................................................................................. 19

4. CONTAGEM DE PONTOS DE FUNÇÃO PARA PROJETOS DE MANUTENÇÃO .................................. 19

4.1. PROJETOS DE MELHORIA ......................................................................................................... 19

4.2. PROJETOS DE MANUTENÇÃO CORRETIVA ............................................................................ 23

4.3. MANUTENÇÃO COSMÉTICA ....................................................................................................... 24

4.4. MANUTENÇÃO ADAPTATIVA EM REQUISITOS NÃO FUNCIONAIS ........................................ 25

4.4.1. REDESENVOLVIMENTO DE PROJETOS EM OUTRA PLATAFORMA ............................. 25

4.4.2. ATUALIZAÇÃO DE PLATAFORMA...................................................................................... 25

4.4.3. ADEQUAÇÃO DE FUNCIONALIDADES ÀS MUDANÇAS DE NEGÓCIO .......................... 26

4.4.4. APURAÇÃO ESPECIAL ....................................................................................................... 27

4.4.5. MANUTENÇÃO EM PÁGINAS ESTÁTICAS DE INTRANET, INTERNET OU PORTAL ..... 28

4.4.6. MANUTENÇÃO DE DOCUMENTAÇÃO DE SISTEMAS LEGADOS .................................. 29

4.4.7. VERIFICAÇÃO DE ERROS .................................................................................................. 30

4.4.8. FATOR DE CRITICIDADE DE SOLICITAÇÃO DE SERVIÇO ............................................. 30

4.4.9. PONTOS DE FUNÇÃO DE TESTE ...................................................................................... 30

5. ITENS NÃO MENSURÁVEIS ..................................................................................................................... 31

6. ASPECTOS NÃO CONSIDERADOS PELO IFPUG CONSIDERADOS PELA ATI ................................... 33

6.1. MÚLTIPLAS MÍDIAS ..................................................................................................................... 33

6.1.1. MÚLTIPLAS MÍDIAS ............................................................................................................. 35

6.1.2. MESMOS DADOS DE SAÍDA COMO DADOS EM ARQUIVOS E RELATÓRIOS IMPRESSO 35

6.1.3. MESMOS DADOS DE ENTRADA BATCH E ON-LINE ........................................................ 35

6.1.4. MÚLTIPLOS CANAIS DE ENTREGA DA MESMA FUNCIONALIDADE ............................. 36

6.1.5. RELATÓRIOS EM MÚLTIPLOS FORMATOS ..................................................................... 36

6.2. DATA WAREHOUSE ..................................................................................................................... 36

6.3. AUTOMAÇÃO DE PROCESSOS DE NEGÓCIO (BPM) .............................................................. 46

6.3.1. FRONTEIRA DA APLICAÇÃO .............................................................................................. 47

6.3.2. Situação acesso ao BPMS: .................................................................................................. 47



6.3.3. Cadastro de usuários e grupos organizacionais: .................................................................. 47

6.3.4. Funcionalidades da aplicação Ágiles .................................................................................... 48

6.3.5. Recebimento de dados de outras aplicações utilizando interface de integração ................. 48

6.3.6. Atualização de dados em outras aplicações utilizando interface de integração .................. 49

6.3.7. Dados de Código .................................................................................................................. 49

6.3.8. Processo Elementar .............................................................................................................. 49

6.3.9. Atividade com prazos ............................................................................................................ 51

7. LIÇÕES APRENDIDAS .............................................................................................................................. 52

7.1. REQUISITOS ................................................................................................................................. 52

7.1.1. GRANULARIDADE X QUANTIDADE DE REQUISITOS...................................................... 52

7.1.2. ATENÇÃO A REQUISITOS NÃO FUNCIONAIS .................................................................. 52

7.1.3. ATENÇÃO A RELATÓRIOS ................................................................................................. 53

7.2. DICAS NA DEFINIÇÃO DA FRONTEIRA ..................................................................................... 53

7.3. DICAS NA IMPLANTAÇÃO DO PROCESSO ............................................................................... 54

8. CONSIDERAÇÕES SOBRE A CONTAGEM DE PONTOS DE FUNÇÃO ................................................ 55

8.1. CONSIDERAÇÃO SOBRE MUDANÇAS DE REQUISITOS ......................................................... 55

8.2. CONSIDERAÇÃO SOBRE PROJETOS CANCELADOS ............................................................. 56

8.3. CONSIDERAÇÕES SOBRE REDUÇÃO DE CRONOGRAMA..................................................... 57

8.4. CONSIDERAÇÕES SOBRE A PRECIFICAÇÃO .......................................................................... 57

8.4.1. Tamanho Funcional x Esforço de Desenvolvimento ............................................................ 58

8.4.2. Valor do Ponto de Função .................................................................................................... 58

8.4.3. Preço Ideal do Ponto de Função na APE ............................................................................. 59

8.4.4. Considerações ...................................................................................................................... 61

8.5. CONSIDERAÇÕES SOBRE CICLO DE VIDA ITERATIVO INCREMENTAL ............................... 62

8.6. COMO UMA EMPRESA PÚBLICA PODE SE FILIAR AO IFPUG. ............................................... 62

8.7. CERTIFICAÇÃO CFPS ................................................................................................................. 63

9. PROCESSO DE REVISÃO DO GUIA DE CONTAGEM ............................................................................ 64

9.1. REVISÃO PARA CORREÇÃO DE INCONSISTÊNCIAS E SITUAÇÕES NÃO PREVISTAS ...... 64

9.2. REVISÃO PARA ADOÇÃO DE NOVAS VERSÕES DO CPM...................................................... 64

10. CONCLUSÃO ........................................................................................................................................... 64

REFERÊNCIAS BIBLIOGRAFIAS ................................................................................................................. 64



1. INTRODUÇÃO

A Agência Estadual de Tecnologia da Informação do Estado de Pernambuco (ATI-PE) seguindo o

caminho de muitas empresas governamentais brasileiras têm iniciado a utilização da métrica de Pontos de

Função (PF) nas estimativas e dimensionamento de tamanho funcional de projetos de software, devido aos

diversos benefícios de utilização da métrica tais como a independência da solução tecnológica utilizada e às

recomendações dos órgãos de controle do governo federal brasileiro.

O Manual de Práticas de Contagem de Pontos de Função ou (CPM) que hoje se apresenta na

versão 4.3, publicado pela International Function Point User Group (IFPUG) em 201, define as regras de

contagem de Pontos de Função. No entanto, a contagem de Pontos de Função é baseada no projeto lógico

da aplicação e nas fases iniciais do ciclo de vida do software, o documento de requisitos para a estimativa e

elaboração do plano do projeto é um documento inicial de requisitos, por exemplo: Documento de Visão,

Formalização Simples de Requisitos ou algum outro tipo de especificação elaborada pelo analista de

negócios. Assim, torna-se importante o estabelecimento de métodos para estimar o tamanho funcional dos

projetos de software nas fases iniciais do ciclo de vida.

Outro ponto a ser destacado é a importância da definição de métodos para geração de estimativas

de prazo, esforço, custo e recursos computacionais dos projetos de software da empresa, visando melhorar

o gerenciamento dos projetos. Além disso, é importante ressaltar que a métrica de Pontos de Função foi

concebida como uma medida de tamanho funcional para projetos de desenvolvimento e de manutenção

evolutiva de software. No entanto, os projetos de software não estão limitados a projetos de

desenvolvimento e projetos de manutenção evolutiva ou Melhoria (enhancement), admitindo normalmente

manutenções corretivas e perfectivas, bem como os projetos com características diferentes dos sistemas de

informações tradicionais, como projetos de BI, automação de processos e portais WEB, por exemplo.

Assim, torna-se essencial a definição de métodos para dimensionar o tamanho de projetos

manutenção (maintenance) e demais projetos cujas características não estejam cobertas pelo manual do

IFPUG, baseados em Pontos de Função, para que estes projetos possam ser avaliados e gerenciados com

base em uma métrica. Observe que a INSTRUÇÃO NORMATIVA Nº 4 DE 12 DE NOVEMBRO DE 2010,

publicada pela SLTI/ MPOG, preconiza a utilização de métricas em contratos de software. Os Acórdãos do

Tribunal de Contas da União (TCU) recomendam a utilização da métrica Pontos de Função Não Ajustados.

A versão 4.3 do CPM também reconhece o PF Não Ajustado como método padrão do IFPUG.

1.1. Definições, Acrônimos e Abreviações

APF: Análise de Pontos de Função;

CMMI-Acq: Capability Maturity Model Integration for Aquisition

CPM: Manual de Práticas de Contagens do IFPUG;



MPS.BR: Melhoria de Processo do Software Brasileiro

IFPUG: International Function Points Group User (www.ifpug.org);

PF: Pontos de Função.

2. OBJETIVOS DO DOCUMENTO

Este documento tem como propósito apresentar um roteiro contagem de Pontos de Função

aderente ao Manual de Práticas de Contagem (CPM 4.3) e definir os tipos de projetos de manutenção e

uma sistemática para dimensionar o tamanho de tais projetos, utilizando a métrica Pontos de Função. Além

da contagem de Pontos de Função, este roteiro apresenta um processo de estimativas com base na métrica

Pontos de Função, proposto por Cláudia Hazan (2008).

Além disto, estará contido neste manual um conjunto de práticas de contagens que são

institucionalizadas pela ATI. Outra seção deste mesmo manual será destinada a documentar as lições

aprendidas da ATI durante o contínuo aprendizado da utilização da técnica.

Alem destas seções introdutórias, este documento encontra-se organizado da seguinte maneira: A

Seção 3 define o processo de estimativas de projetos de software integrado ao processo de

acompanhamento de contratos de fornecedores da ATI, indicando o momento de realização das estimativas

e as análises a serem realizadas; A Seção 4 apresenta diretrizes para a estimativa e a contagem de Pontos

de Função de todos os tipos de projetos de manutenção de software; A Seção 5 descreve as atividades

associadas ao processo de contratação cujos itens não são mensuráveis pela IFPUG em Pontos de

Função; A Seção 6 apresenta alguns aspectos que não estão presentes no Manual de Práticas de

Contagem do IFPUG e como a ATI considera tais aspectos; A Seção 7 apresenta as lições aprendidas pela

ATI na utilização de pontos por função. Estas lições podem ser dirigidas as práticas de contagens ou até

mesmo a forma de escrever os requisitos; A Seção 8 apresenta algumas considerações importantes sobre a

utilização de métricas para dimensionar as mudanças de requisitos, redução de cronograma e atividades de

negócio. Também apresenta considerações sobre o preço do ponto de função, certificação CTFP e filiação

ao IFPUG; A Seção 9 apresenta o processo de revisão deste guia de contagem; Finalmente, a Seção 10

conclui o documento apresentando sugestões para trabalhos futuros.

3. ESTIMATIVAS DE PROJETO DE SOFTWARE

Este Capítulo tem como propósito descrever um processo de estimativas de projetos de software

aderente ao modelo Capability Maturity Model Integration for Aquisition (CMMI-Acq), ao modelo de Melhoria

de Processo do Software Brasileiro (MPS.BR) e baseado no modelo proposto por Hazan (2008). Neste

contexto, são apresentados os sete níveis de métodos Contagem de Pontos de Função e quando cada um

deles deve ser utilizado para estimar o tamanho dos projetos de software em PF, alguns modelos

simplificados de estimativas para estimar o esforço dos projetos em homem_hora (HH), a fórmula de Capers

http://www.ifpug.org/



Jones para estimar os prazos dos projetos. Será apresentada também nesta seção a integração do modelo

de contagem da ATI ao seu processo de desenvolvimento.

A Figura 1 ilustra um processo de Estimativas de Projetos de Software aderente à área de processo

de Planejamento do Projeto de Aquisição do nível 2 do CMMI-ACq. Este processo é baseado no modelo da

Cláudia Hazan (2008) e será descrito em linhas gerais nos parágrafos seguintes.

Identificar a necessidade de contagem para contrato em APF

Identificar usuários, reunir documentação e

levantar requisitos iniciais da solução.

Determinar escopo da contagem, fronteiras e identificar requisitos funcionais do usuário

Identificar demandas que serão implementadas na

Sprint

Agrupar demandas ligadas ao mesmo

requisito funcional.

Realizar contagem estimativa de tamanho

funcional da Sprint

Derivar Custo e Prazo da entrega baseado no tamanho funcional.

Realizar contagem funcional da entrega

realizada pelo fornecedor

Reavaliar Custo e Prazo da entrega realizada pelo

fornecedor

Atualizar Base Histórica do Projeto baseado na

diferenças entre a estimativa e a Medição

Base Histórica

Base Histórica

Legenda

Etapas antes do inicio da Sprint.

Etapas antes do inicio da Sprint.

Etapas Durante a Sprint

Etapas Durante a Sprint

Etapas Após Recebimento da Sprint

Etapas Após Recebimento da Sprint

Etapas durante a transação entre Sprints

Etapas durante a transação entre Sprints

Figura 1: Processo de Estimativas de Projetos de Software

Este processo está inserido no contexto do processo “Scrum” da ATI. As três primeiras etapas

acontecem no momento de planejar a contratação. Neste momento em que são verificadas soluções

existentes no mercado, busca por propostas e levantamento das principais características da solução, é o

momento de se dimensionar uma contagem estimativa (o processo de contagem estimativa será detalhado

mais a frente).

As etapas na Sprint (vermelho) tem como principal insumo (artefato de entrada) um documento de

requisitos. Como as estimativas devem ser realizadas no início do processo de desenvolvimento de

software, ou mesmo da Sprint então, o artefato utilizado é um documento inicial de requisitos, por exemplo:

Documento de Visão ou Formalização Simples de Requisitos utilizados no Mantis da própria ATI.



O estimador deve analisar os requisitos para garantir a qualidade bem como agrupar as demandas

no mesmo requisito para evitar a contagens múltiplas da mesma função para só assim estimar o tamanho

do projeto de software. Embora nas etapas iniciais possa existir a contagem estimada do sistema, a mesma

só serve para dimensionamento do contrato e não para acompanhamento de projeto.

Assim, o próximo passo é a derivação das estimativas de prazo (cronograma) e (orçamento) da

demanda com base na estimativa de tamanho e nos dados históricos de projetos concluídos da

organização. Neste ponto, as principais estimativas foram geradas e precisam ser documentadas. As

premissas e suposições utilizadas na geração das estimativas, dentre outras: complexidade do projeto,

plataforma de desenvolvimento, tipo do projeto, percentual de evolução de requisitos, também devem ser

documentadas.

A realização das estimativas por um analista de métricas que não atue na equipe do projeto

constitui uma prática recomendada. O analista de métricas deve analisar também a consistência da

documentação utilizada na estimativa. No decorrer do processo de desenvolvimento, as estimativas devem

ser acompanhadas conforme o refinamento dos requisitos. O projeto deve ser reestimado após a fase de

requisitos, quando for gerada a especificação de casos de uso, e sempre que ocorrerem mudanças

significativas nos requisitos funcionais ou não funcionais.

Quando o projeto ou Sprint for concluído, deve-se novamente aferir e documentar o tamanho, prazo

e custo, assim como outros atributos relevantes do projeto, visando a coleta de dados para a melhoria do

processo de estimativas. As lições aprendidas também devem ser documentadas e incorporadas a este

guia, bem como a base histórica.

A alimentação contínua desta base histórica (Última atividade) é que irá garantir a ATI uma melhoria

das estimativas ao longo do projeto.

Desta forma, para os contratos de projetos de software baseados na métrica Pontos de Função as

estimativas devem ser realizadas em três marcos do processo de desenvolvimento, a saber:

Estimativa inicial: Realizada após o fechamento do escopo do projeto. Geralmente, é baseada em

um documento inicial de requisitos, por exemplo: o Documento de Visão. Constitui uma boa prática a

previsão de evolução de requisitos, especialmente em projetos de desenvolvimento de médio ou grande

porte. Seu objetivo é quantificar uma ordem de grandeza para o total de pontos por função que serão

empregados para construir determinada solução.

Nessa etapa é importante destacar os seguintes conceitos na área de estimativas: Uma Estimativa

é obtida por meio de uma atividade técnica, utilizando métodos de estimativas. Não deve sofrer

interferências políticas. A Meta é um desejo, em função de necessidades de negócio, estabelecida

politicamente.



Em um cenário ideal os resultados da estimativa atendem as metas de negócio. Quando este

cenário não é real, é fundamental a redução de escopo do projeto, de modo que a meta se adapte aos

resultados da estimativa. Neste momento, dependendo do detalhe da documentação, serão permitidos 04

(quatro) níveis de detalhamento de contagem dos 06 (seis) apresentados pela totalmetrics (2004).

O Nível menos detalhado é conhecido por se basear apenas na base histórica. Considere a Figura 2

como um exemplo hipotético de base histórica.

Figura 2: Base histórica do ISBSG e do Meu projeto

O sexto nível de contagem é dado pela estimativa mais estável desta base histórica. Suponha que o

elemento que menos varia nas contagens históricas da ATI seja a pontuação dos ALIs em relação ao

projeto todo. Considerando o projeto acima, os ALIs representam cerca de 27% da pontuação total do

projeto. Então neste caso é apenas desejado se calcular a pontuação de todos os ALIS e aplicar a regra de

três.

Vale ressaltar que é importante escolher a estrutura que menos varia no processo. Suponha que

para o caso anterior as saídas externas, que representam em média 12% do total de pontuação dos

projetos da ATI, variem entre 0% e 40%, então, não é um elemento confiável para a escolha da regra de

três.



O quinto nível é conhecido como contagem indicativa, onde é necessário apenas identificar os ALIs

e AIEs da aplicação. Não é necessário detalhar as funções de dados, nem identificar as funções de

transação. Uma vez identificadas as funções de dados é utilizada a fórmula a seguir:

PF = 35*N° de ALIs + 15*N° de AIEs

Estes números de 35 e 15 podem ser calibrados para melhor representar as necessidades da

organização e devem ser guiados pela base histórica da mesma.

O quarto nível é conhecido como contagem estimativa da NESMA. Nesta contagem é necessário

identificar todas as funções de dados e todas as funções de transação. Para realizar esta contagem é

necessário considerar todas as funções de dados simples e todas as funções transacionais médias.

Vale ressaltar que estas contagens não devem ser utilizadas em conjunto com o fornecedor, estas

contagens são apenas para dimensionar um valor de pontos de função que um contrato pode precisar.

O segundo marco de contagem é a contagem intermediária que deve ser realizada antes da

execução de cada demanda. Neste marco já deve existir documentação dos requisitos suficientes para a

realização de uma contagem detalhada que é o 3° Nível de detalhamento proposto pela totalmetrics (2004)

e que coincide com a contagem IFPUG considerando as faixas de contagem.

Neste momento também pode ser realizada a contagem interligada e anotada (1° Nível) que tem

toda rastreabilidade da contagem bem como o detalhamento dos itens de dados.

O terceiro marco de contagem é a contagem final que deve ser realizada ao final da execução.

Este marco deve ser utilizado para emissão de fatura e pagamento ao fornecedor. Para tal deve-se utilizar

os níveis de detalhamento de contagem do 3 até o 1. Para fins de faturamento, que é realizado durante o

desenvolvimento, deve-se considerar a Contagem de Referência e posteriormente considerar os ajustes no

faturamento após a Contagem Final. É importante ressaltar que as mudanças de requisitos também serão

consideradas no tamanho projeto a ser faturado. Além disso, se estas mudanças forem significativas,

maiores que a evolução de requisitos prevista na estimativa inicial, o prazo do projeto deve ser reestimado.

Toda mudança de requisito deve passar por uma análise de impacto da ATI e ser aprovada pelo cliente.

3.1. DETALHAMENTO DO PROCESSO DE ESTIMATIVA

O processo de estimativa utilizado visa aferir o tamanho em PF podendo ser de maneira

simplificada para os níveis de detalhamento 4, 5 e 6. Estas contagens simplificadas são baseadas no

conhecimento dos requisitos iniciais do projeto e na documentação do contrato. Inicialmente, os requisitos

funcionais iniciais documentados nas propostas comerciais, nos documentos de visão, formalização simples

de requisitos ou em qualquer especificação inicial do sistema do usuário são mapeados nos tipos funcionais



da Análise de Pontos de Função: Arquivo Lógico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada

Externa (EE), Consulta Externa (CE) e Saída Externa (SE).

Posteriormente, os Pontos de Função são associados a cada função identificada, baseando-se nas

tabelas de complexidade e de contribuição funcional do CPM (Figura 3).

Figura 3: Modelo Lógico da Análise de Pontos de Função [SERPRO 2010]

O estimador deve realizar uma leitura no documento inicial de requisitos, buscando informações

relevantes para a identificação de processos elementares. O processo elementar é definido como a menor

unidade de atividade significativa para o usuário. O processo elementar deve ser completo em si mesmo,

independente e deixar a aplicação em um estado consistente [IFPUG, 2010]. Em outras palavras, os

processos elementares são funções transacionais independentes, isto é, funções seqüenciais pertencem a

um mesmo processo elementar e funções independentes constituem processos elementares diferentes.

Uma vez identificado o processo elementar, o estimador deve buscar o entendimento deste para

classificá-lo em Entrada Externa (EE), Consulta Externa (CE) ou Saída Externa (SE). Adicionalmente, o

estimador deve descobrir os dados associados ao processo elementar, visando a determinação da

complexidade funcional da função identificada. Na análise do processo elementar também são identificados

os grupos de dados lógicos da aplicação, que são classificados como Arquivos Lógicos Internos (ALI) ou

Arquivos de Interface Externa (AIE).



A determinação do nível de detalhamento da contagem depende da documentação obtida. Caso

seja possível identificar todas as funções de AIE e ALI o ideal é utilizar o 5° Nível de detalhamento (AIE * 35

+ AIE * 15). Quando não existe detalhamento suficiente sobre alguma das informações como ALI, AIE é

mais difícil encontrar EE, SE e CE nestas condições, pois elas dependem do ALI e AIE. Neste caso, deve-

se utilizar o 6º nível de detalhamento.

Caso não seja possível a identificação da complexidade das funcionalidades é melhor usar o

método da Nesma, ou 4° nível de detalhe em questão, recomenda-se a utilização da complexidade Média.

Na análise do processo elementar também são identificados, os grupos de dados lógicos da aplicação, que

são classificados como Arquivos Lógicos Internos ou Arquivos de Interface Externa. Caso não seja possível

a identificação da complexidade da função de dados em questão, recomenda-se a utilização da

complexidade Simples. É importante ressaltar que se o estimador identificar mais de um Registro Lógico no

Arquivo Lógico Interno,recomenda-se utilizar a complexidade Média.

A seguir são apresentadas dicas para ajudar no mapeamento dos requisitos funcionais da aplicação

nos tipos funcionais da APF. As necessidades e funcionalidades especificadas para o projeto, contidas no

documento inicial de requisitos, devem ser enquadradas em uma das seguintes categorias:

Arquivos Lógicos Internos (ALI): Banco de Dados Lógico da Aplicação (tabelas e arquivos

mantidos pela aplicação).

Considerações: Identifique os grupos de dados lógicos de aplicação nos modelos de dados ou

diagrama de classes ou a partir dos requisitos funcionais, descritos nos documentos de requisitos

(Documento de Visão, Relação de Casos de Uso, etc.). Não considere arquivos físicos, arquivos de índices,

arquivos de trabalho e tabelas de relacionamento sem atributos próprios (tabelas que existem para quebrar

o relacionamento nxn e apenas transportam as chaves estrangeiras).

As entidades fracas também não são consideradas um ALI. Se possível, tente descobrir os atributos

lógicos, campos reconhecidos pelo usuário, e subgrupos de dados existentes para obter a complexidade

funcional, segundo as regras de contagem do CPM. Caso não seja possível, a experiência tem mostrado

que a maioria dos ALIs dos sistemas são de complexidade Simples.

A pontuação destes elementos segundo o IFPUG está descrita na Tabela 1

Tabela 1: Pontuação dos Arquivos Lógicos Internos [IFPUG 2010]



Arquivos de Interface Externa (AIE): Banco de Dados de outras Aplicações, apenas referenciados

pela aplicação que está sendo estimada (tabelas e arquivos mantidos por outra aplicação).

Considerações: Identifique os grupos de dados lógicos de outras aplicações referenciados pela

aplicação que está sendo estimada. Freqüentemente, a referência de dados ocorre para a validação de

informações em cadastros ou consultas. Algumas vezes, relatórios ou consultas referenciam dados

externos de outras aplicações, também considerados AIEs. Não são considerados arquivos físicos, arquivos

de índice, arquivos de trabalho, tabelas de relacionamento sem atributos próprios e entidades fracas.

Geralmente, os AIEs dos sistemas possuem a classificação de complexidade Simples. Porque, são

considerados para a determinação da complexidade funcional do AIE apenas os atributos referenciados

pela aplicação que está sendo contada.


Tabela 2: Pontuação dos Arquivos de Interface Externa [IFPUG 2010]

Entradas Externas (EE): Funcionalidades que mantêm os Arquivos Lógicos Internos (ALIs) ou

alteram o comportamento da aplicação.

Considerações: Identifique as funcionalidades de manutenção de dados. Conte separadamente a

inclusão, alteração e exclusão de dados, isto é, cada função independente de inclusão ou alteração ou

exclusão deve ser contada separadamente. A aplicação possui funções de entrada de dados que alteram o

comportamento dela, por exemplo: processamentos batch, ou processamento de informações de controle?

Caso positivo, estas funções também devem ser identificadas como Entradas Externas. Se você

não possui conhecimento sobre o processo elementar (funcionalidade analisada), considere as Entrada

Externa identificada com complexidade Média.


Tabela 3: Pontuação das Entradas Externas [IFPUG 2010]



Consultas Externas (CE): funcionalidades que apresentam informações para o usuário sem a

utilização de cálculos ou algoritmos. São os processos elementares do tipo “lê - imprime”, “lê - apresenta

dados”, incluindo consultas, relatórios, geração de arquivos pdf, xls, downloads, entre outros.

Considerações: Uma funcionalidade é desenvolvida para apresentar informações para o usuário:

uma consulta, relatório, browse, listbox, download, geração de um arquivo, geração de arquivo psd, xls?

Esta função não possui cálculos ou algoritmos para derivação dos dados referenciados nem altera um

Arquivo Lógico Interno, nem muda o comportamento do sistema? Caso positivo, estas funções devem ser

identificadas como Consultas Externas.

Se você não possui conhecimento sobre o processo elementar (funcionalidade analisada),

considere as Consultas Externas com complexidade Média.


Tabela 4: Pontuação das Consultas Externas [IFPUG 2010]

Saídas Externas (SE): Funcionalidades que apresentam informações para o usuário com utilização

de cálculos ou algoritmos para derivação de dados ou atualização de Arquivos Lógicos Internos ou

mudança de comportamento da aplicação. São as consultas ou relatórios com totalização de dados,

relatórios estatísticos, gráficos, geração de arquivos com atualização log, downloads com cálculo de

percentual, entre outros.

Considerações: Uma funcionalidade é desenvolvida para apresentar informações para o usuário:

uma consulta ou relatório com totalização de dados, etiquetas de código de barras, gráficos, relatórios

estatísticos, download com percentual calculado, geração de arquivo com atualização de log? Caso

positivo, estas funções devem ser identificadas como Saídas Externas. Observe que esta função deve ter

cálculos ou algoritmos para processar os dados referenciados nos arquivos lógicos ou atualizar campos

(normalmente indicadores) nos arquivos ou mudar o comportamento da aplicação.



Caso não haja conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade

analisada), considere as Saídas Externas com complexidade Média.


Tabela 5: Pontuação das Consultas Externas [IFPUG 2010]

A Estimativa de tamanho do projeto em PFs deve ser gerada totalizando-se os PFs obtidos nas

Tabelas 1, 2, 3, 4, e 5.

A fórmula de contagem ou de estimativa de Pontos de Função para Projetos de Desenvolvimento é

a seguinte:

Quadro 1: Totalização da Pontuação em Desenvolvimento de Software [IFPUG 2010]

A fórmula de contagem ou de estimativa de Pontos de Função para Softwares Prontos é a seguinte:



Quadro 2: Totalização da Pontuação para Aplicações Prontas [IFPUG 2010]

A fórmula de contagem ou de estimativa de Pontos de Função para Projetos de Melhoria é a

seguinte:

Quadro 3: Totalização da Pontuação para Aplicações Prontas [IFPUG 2010]

3.2. PAGAMENTO BASEADO NO CICLO DE VIDA DA ENTREGA

O próximo passo é a definição da forma de pagamento baseado pelas entregas, visando remunerar

o fornecedor pelos produtos liberados em cada entrega, tornando o processo menos oneroso para o mesmo

e incentivando a cumprir resultados. Está facultado a ATI decidir se irá utilizar este tipo de pagamento e em

qualquer granularidade, tais como editais ou contratos.

Assim a ATI pode inclusive pagar apenas uma porcentagem do valor cheio de uma determinada

demanda se “partes” das entregas não forem necessárias naquele contrato. Atualmente a ATI utiliza a

seguinte distribuição (Tabela 6).

Tabela 6: Remuneração da ATI por fase de Ciclo de Vida



3.3. ESTIMATIVA DE PRAZO

As estimativas de prazo não são lineares com o tamanho do projeto. O melhor tempo de

desenvolvimento, no qual há uma melhor relação custo x benefício de alocação de recursos e menor prazo

de desenvolvimento, dado o tamanho de um projeto específico, é sugerido e utilizado nas estimativas de

prazo deste manual. Jones [Jones, 2007] propõe uma fórmula para o cálculo do melhor tempo de

desenvolvimento, denominado Td e de Região Impossível (RI) de desenvolvimento (Figura 4).

Na Região Impossível (RI), a adição de mais recursos ao projeto não implicará em redução no

prazo. Note que a curva mostra que quanto menor o prazo almejado para a conclusão do projeto, maior

será o esforço requerido e consequentemente maior o custo do projeto. O aumento do esforço para reduzir

o prazo acontece através da realização de horas extras e da inclusão de pessoal adicional, gerando

retrabalho. No entanto, a redução de prazo tem um limite, como demonstra a região impossível.

O método utilizado para estimar o prazo dos projetos (Td) é baseado na fórmula de Capers Jones

[Jones, 2007]. A fórmula de Capers Jones estima o prazo, baseando-se no tamanho do projeto em Pontos

de Função, da seguinte maneira:

Td = V t

Td: prazo de desenvolvimento V: tamanho do projeto em Pontos de Função t: o expoente t é definido de acordo com a Tabela 7



Figura 4: Relação entre a Estimativa de Prazo e de Esforço [Jones 2007]

Tabela 7: Expoente t por tipo de Projeto

Tipo de Sistema Expoente t Sistema Comum – Mainframe (desenvolvimento de sistema com alto grau de reuso ou manutenção evolutiva)

0,32 a 0,33

Sistema Comum – Web ou Cliente Servidor 0,34 a 0,35

Sistema OO (se o projeto OO não for novidade para equipe, não tiver o desenvolvimento de componentes reusáveis, considerar sistema comum)

0,36

Sistema Cliente/Servidor (com alta complexidade arquitetural e integração com outros sistemas)

0,37

Sistemas Gerenciais complexos com muitas integrações, Datawarehousing, Geoprocessamento, Workflow

0,39

Software Básico, Frameworks, Sistemas Comerciais 0,40

É importante destacar que o método só funciona para projetos com mais de 100 PFs. Caso o

projeto seja menor, o prazo deve ser obtido por meio de WBS. O prazo calculado considera todo o ciclo de

vida do projeto, desde a fase de requisitos até a implantação. Assim, caso a estimativa tenha sido realizada

ao final da fase de requisitos, descontar do prazo restante, o tempo gasto com a fase de requisitos.

Caso seja necessário receber o projeto em um prazo menor que o tudo calculado, recomenda-se

propor um processo de desenvolvimento incremental, priorizando funcionalidades em cada iteração de

acordo com a necessidade dele. Caso, ainda assim, a estimativa não atenda às necessidades do cliente,

então pode-se reduzir o Td em até 25%, observando-se a Região Impossível. No entanto, quanto mais perto

da Região Impossível, o esforço e o custo do projeto aumentam de maneira exponencial. Assim, de um



modo geral, a redução de prazo de 10 % implica no aumento de esforço de 25%; a redução de prazo de

20% implica no aumento de esforço de 50% ; a redução de prazo de 25% implica em um aumento de

esforço de 60%.

Não é recomendada a redução de prazo em mais de 20%.

Os percentuais de aumento de esforço são estimados, podendo ser reajustados conforme

avaliação da base histórica dos serviços realizados no órgão.

3.4. ESTIMATIVA DE CUSTO

A estimativa de custo do projeto deve levar em consideração o custo de um ponto de função. A

contratada já deverá considerar o custo da hora de todos os profissionais envolvidos no desenvolvimento da

solução de software. O cálculo do custo do projeto (CP) será então da seguinte forma:

CP = QPF x CPF

Onde:

QPF: Tamanho do Projeto em PF CPF: Custo para implementar um Ponto de Função na plataforma em questão

4. CONTAGEM DE PONTOS DE FUNÇÃO PARA PROJETOS DE MANUTENÇÃO

Esta seção tem como propósito descrever os diversos tipos de projetos de manutenção e mostrar

uma solução para o seu dimensionamento em Pontos de Função, visto que o manual de práticas de

contagem – CPM não contempla projetos de manutenção (maintenance) apenas o de Melhoria

(enhancement).

Quanto à documentação de projetos de manutenção pequenos (menores que 100 PF), deve-se

registrar a solicitação e documentar os requisitos da aplicação impactada pela demanda, de forma

detalhada, visando apoiar a contagem de Pontos de Função da demanda. É importante também

documentar as estimativas e a contagem de Pontos de Função.

4.1. PROJETOS DE MELHORIA

O Projeto de Melhoria (enhancement), também denominada de projeto de melhoria funcional, ou

manutenção evolutiva, está associado às mudanças em requisitos funcionais da aplicação, ou seja, a

inclusão de novas funcionalidades, alteração ou exclusão de funcionalidades em aplicações implantadas.



Segundo o padrão IEEE Std 1229 [IEEE 1998], esta manutenção seria um tipo de manutenção

adaptativa, definida como: modificação de um produto de software concluído após a entrega para mantê-lo

funcionando adequadamente em um ambiente com mudanças. O projeto de melhoria é considerado um tipo

de projeto de manutenção adaptativa com mudanças em requisitos funcionais da aplicação, ou seja, com

funcionalidades incluídas, alteradas ou excluídas na aplicação, segundo o CPM 4.3.

Este documento separa o projeto de melhoria, quando as mudanças são associadas aos requisitos

funcionais e a manutenção adaptativa quando as mudanças estão associadas aos requisitos não funcionais

da aplicação.

Um projeto de melhoria consiste em demandas de criação de novas funcionalidades (grupos de

dados ou processos elementares), demandas de exclusão de funcionalidades (grupos de dados ou

processos elementares) e demandas de alteração de funcionalidades (grupos de dados ou processos

elementares) em aplicações implantadas em produção.

Uma função de dados (Arquivo Lógico Interno ou Arquivo de Interface Externa) é considerada

alterada, quando a alteração contemplar mudanças de item de dados, inclusão ou exclusão de item de

dados. Ou mudança de tamanho (número de posições) ou tipo de campo (por exemplo: mudança de

numérico ou alfanumérico), sendo que esta ocorre por mudança de regra de negócio do usuário.

Uma função transacional (Entrada Externa, Consulta Externa e Saída Externa) é considerada

alterada, quando a alteração contemplar:

Mudança de itens de dados em uma função existente;

Mudança de arquivos referenciados;

Mudança de lógica de processamento, segundo as ações das lógicas e processamento do CPM 4.3

A Lógica de Processamento é definida como requisitos especificamente solicitados pelo usuário

para completar um processo elementar. Esses requisitos devem incluir as seguintes ações:

Validações são executadas

Fórmulas matemáticas e cálculos são executados

Valores equivalentes são convertidos

Dados são filtrados e selecionados através da utilização de critérios

Condições são analisadas para verificar quais são aplicáveis

Um ou mais ALIs são atualizados

Um ou mais ALIs e AIEs são referenciados

Dados ou informações de controle são recuperados

Dados derivados são criados através da transformação de dados existentes, para criar dados adicionais

O comportamento do sistema é alterado

Preparar e apresentar informações para fora da fronteira

Receber dados ou informações de controle que entram pela fronteira da aplicação



Dados são reordenados

A contagem ou estimativa de Pontos de Função de projetos de manutenção evolutiva (projetos de

melhoria) seguirá conforme preconizada pela publicação "Function Point Analysis for Software

Enhancement Guidelines" da Nesma – Netherlands Software Metrics Users Association [NESMA, 2009],

entidade que aprofunda o tema e apresenta alternativas técnicas à proposta original do IFPUG. Contudo é

recomendado que para contratações sejam apenas definidas o padrões do IFPUG e que caso sejam

necessárias a adoção da NESMA (2009) como boas práticas de projetos de melhoria, que ela seja escrita

no edital e não citada como NESMA para que não haja confusão do fornecedor sobre quando usar NESMA

ou quando usar o IFPUG.

Pela NESMA temos:

TAMANHO EM PF = (PF INCLUIDO + PF EXCLUIDO + PF ALTERADO + PF CONVERSÃO)

Definições:

PF_INCLUÍDO = Pontos de Função associados às novas funcionalidades que farão parte da

aplicação.

PF_ALTERADO = Pontos de Função associados às funcionalidades existentes na aplicação que

serão alteradas no projeto de manutenção, incluso o fator de impacto conforme preconizada pela [NESMA,

2009].

PF_EXCLUÍDO = Pontos de Função associados às funcionalidades existentes na aplicação que

serão excluídas no projeto de manutenção, incluso o fator de impacto conforme preconizada pela [NESMA,

2009].

PF_CONVERSÃO = Pontos de Função associados às funcionalidades de conversão de dados dos

projetos de melhoria. Exemplos de funções de conversão incluem: migração ou carga inicial de dados para

popular as novas tabelas criadas e relatórios associados à migração de dados. Importante ressaltar que a

contagem dos PF_Conversão são efetuadas de forma separada da contagem dos PF_Não_Ajustados, por

serem de produtividades diferentes, ou seja, ao contar os PF_Conversão utilizar produtividade própria,

quando for o caso.

Na maioria casos, as operações de alteração e inclusão possuem um tratamento diferenciado em

relação à inclusão, alguns pesos podem ser atribuídos a tais tarefas como forma de compensar o esforço e

custo associado a tais tarefas. Esta prática é comum no mercado e conhecida como Deflator. A sugestão

da NESMA para tal aplicação e a que será seguida pela ATI é:



PF_INCLUIDO = QPI;

PF_EXCLUIDO = QPE x 0.40;

PF_FD_ALTERADO = FD-QPA x FFD, sendo FFD entre 0,25 e 1,00, conforme Tabela 7 (para

funções de dados);

PF_FT_ALTERADO = FT-QPA x FFT, sendo FFT entre 0,25 e 1,50, conforme Tabela 8 (para

funções transacionais);

PF_ALTERADO = PF_FD_ALTERADO + PF_FT_ALTERADO.

Onde:

QPI = Quantidade de Pontos de Função incluídos;

QPE = Quantidade de Pontos de Função excluídos;

PF_FD_ALTERADO = Pontos de Função alterados para Funções de Dados;

PF_FT_ALTERADO = Pontos de Função alterados para Funções Transacionais;

FD-QPA = Quantidade de Pontos de Função alterados em funções de dados;

FT-QPA = Quantidade de Pontos de Função alterados em funções transacionais;

FFD = Fator de impacto de alterações em funções de dados;

FFT = Fator de impacto de alterações em funções transacionais

O cálculo dos fatores de impacto é obtido através dos percentuais de alterações conforme abaixo:

Funções de Dados:

Percentual de alterações em funções de dados (PFD) = QTDEA / (QTDET x 100)

QTDEA = Quantidade de Tipos de Dados Elementares Alterados

QTDET = Quantidade de Tipos de Dados Elementares Totais

Com o valor obtido em PFD, procura-se na tabela qual o valor do fator de impacto:

Tabela 7: Calculo do PFD para função de Dados [NESMA 2009]

Fator de Impacto em Funções de Dados Alteradas (FFD)

PFD Entre 0 e 33% Entre 33% e

66%

Entre 66% e

100%

Maior que

100%

Fator de

Impacto (FFD) 0,25 0,5 0,75 1

Funções Transacionais:

Percentual de alterações em funções transacionais (PFT1) = QTDEA / QTDET x 100



Percentual de alterações em funções transacionais (PFT2) = QFDLA / QFDLT x 100

QTDEA = Quantidade de Tipos de Dados Elementares Alterados

QTDET = Quantidade de Tipos de Dados Elementares Totais

QFDLA = Quantidade de Funções de Dados Lógicos Alterados

QFDLT = Quantidade de Funções de Dados Lógicos Totais

Tabela 8: Calculo do FFT para função de Dados [NESMA 2009]

Fator de Impacto em Funções Transacionais Alteradas (FFT)

PFT2 / PFT1 Entre 0 e 66% Entre 66% e

100%

Maior que 100%

Entre 0% e 33% 0,25 0,5 0,75

Entre 33% e 66% 0,5 0,75 1

Entre 66% e 100% 0,75 1 1,25

Maior que 100% 1 1,25 1,5

Caso FFT seja maior que 1, recomenda-se reconsiderar a melhoria.

4.2. PROJETOS DE MANUTENÇÃO CORRETIVA

Mesmo com a execução de atividades de garantia da qualidade, pode-se identificar defeitos na

aplicação entregue. A manutenção corretiva altera o software para correção dos defeitos. Encontra-se nesta

categoria, as demandas de correção de erros (bugs) em funcionalidades de sistemas em produção.

É importante destacar que as demandas de manutenção corretiva freqüentemente precisam ser

atendidas com urgência. Assim, o grau de criticidade do projeto poderá trazer impacto nas estimativas de

custo e esforço. O padrão IEEE [IEEE,1998] define um tipo de manutenção corretiva, denominado de

Manutenção Emergencial como “manutenção corretiva não programada executada para manter o sistema

em estado operacional”.

Quando o sistema em produção tiver sido desenvolvido pela contratada, a manutenção

corretiva será do tipo Garantia, conforme prazos e demais cláusulas do contrato em questão.

Quando o sistema não tiver sido desenvolvido pela contratada, deverá ser estimado e calculado o tamanho

do projeto de manutenção corretiva. A estimativa e dimensionamento de tamanho de projetos de

manutenção corretiva em Pontos de Função devem levar em consideração a documentação do sistema

disponível e os artefatos a serem mantidos sendo aplicados alguns deflatores. Seguem as fórmulas a serem

consideradas:



a) Aplicação sem documentação ou com documentação desatualizada ou documentação

incompleta e sem redocumentação de requisitos

Nestes casos, a aferição do tamanho em Pontos de Função da funcionalidade ou das

funcionalidades corrigidas considera 70% do PF_Alterado, observando os conceitos do CPM 4.3,

apresentados na seção 4.1.

PF = PF_ALTERADO x 0,70

b) Aplicação sem documentação ou com documentação desatualizada ou incompleta ou

completa e com redocumentação de requisitos


funcionalidades corrigidas considera 80% do PF_Alterado, seguindo os conceitos do CPM 4.3,

apresentados na seção 4.1.

Deve-se destacar que além da correção as funcionalidades em questão e da documentação do

projeto de manutenção corretiva realizado, a documentação das funcionalidades deve ser atualizada pela

contratada.


c) Aplicação com documentação completa


funcionalidades corrigidas considera 60% do PF_Alterado, seguindo os conceitos do CPM 4.3, mostrados

na seção 4.1. Deve-se ressaltar que não há necessidade de correção da documentação do sistema, apenas

dos artefatos associados à correção do código.


Em todos os três itens acima, os percentuais de multiplicação são estimados, podendo ser

reajustados conforme avaliação da base histórica dos serviços realizados no órgão.

4.3. MANUTENÇÃO COSMÉTICA

São consideradas manutenções cosméticas ou Adaptativas – Mudança de Interface, as demandas

associadas à alterações de interface, por exemplo, fonte de letra, cores de telas, logotipos, mudança de

botões na tela, mudança de posição de campos ou texto na tela.


funcionalidades corrigidas considera 10% do PF_Alterado, seguindo os conceitos do CPM 4.3. Não será



contemplada a redocumentação das funcionalidades da aplicação impactadas pela manutenção nas

demandas desta categoria.


4.4. MANUTENÇÃO ADAPTATIVA EM REQUISITOS NÃO FUNCIONAIS

Seguindo os conceitos da IEEE, existem vários tipos de Manutenção Adaptativa. Quando há

mudança em requisitos funcionais, estes projetos são denominados de projetos de Melhoria, descritos na

seção 4.1. Quando há mudança em requisitos não funcionais de interface, estes projetos são denominados

de Manutenção Cosmética ou Manutenção Adaptativa – Mudança de Interface.

Esta seção visa apresentar alguns tipos de manutenções adaptativas associadas às mudanças em

requisitos não funcionais da aplicação, a saber: Redesenvolvimento de projetos em outra plataforma,

Atualização de plataforma, Adequação de funcionalidades às mudanças de negócio. Caso sejam

identificados outros tipos de projetos de manutenção adaptativa em requisitos não funcionais, estes devem

ser definidos e incorporados nesse Manual de Contagem.

4.4.1. REDESENVOLVIMENTO DE PROJETOS EM OUTRA PLATAFORMA

São considerados nesta categoria, projetos que precisam ser migrados para outra plataforma. Por

exemplo, um sistema legado em COBOL precisa ser redesenvolvido em JAVA.

Como estes projetos legados, freqüentemente, encontram-se sem documentação, então serão

considerados como novos projetos de desenvolvimento. Assim, será utilizada a fórmula de Projetos de

Desenvolvimento do CPM 4.3.

PF = PF_NÃO_AJUSTADO + PF_CONVERSÃO

PF_CONVERSÃO = Pontos de Função associados às funcionalidades de conversão de dados dos

projetos de desenvolvimento. Exemplos de funções de conversão incluem: migração ou carga inicial de

dados para popular as novas tabelas criadas e relatórios associados à migração de dados. Importante

ressaltar que a contagem dos PF_Conversão são efetuadas de forma separada da contagem dos

PF_Não_Ajustado, por serem de produtividades diferentes, ou seja, ao contar os PF_Conversão utilizar

produtividade própria, quando for o caso.

Neste caso, poderá ser criado um multiplicador conforme avaliação da base histórica dos serviços

realizados no órgão.

4.4.2. ATUALIZAÇÃO DE PLATAFORMA

São consideradas nesta categoria, demandas para uma aplicação existente ou parte de uma

aplicação existente executar em versões mais atuais de browsers (ex: versão atual do Internet Explorer,



Mozila, Firefox,...) ou de linguagens de programação (ex: versão mais atual do JAVA ou do Banco de

Dados). Também são consideradas nesta categoria aplicações Web desenvolvidas para executar em

Internet Explorer que precisam executar também em browser em software livre. Nesta categoria foram

observadas demandas dos seguintes tipos:

a) Atualização de Plataforma com necessidade de redocumentação de requisitos

Nestes casos, a aferição do tamanho em Pontos de Função da aplicação ou da parte da aplicação

que sofreu impacto considera 50% dos PFs, seguindo a fórmula de projetos de desenvolvimento do CPM

4.3 e as funções de conversão de dados, se aplicável. Deve-se destacar que além da adequação as

funcionalidades em questão e da documentação do projeto de manutenção adaptativa realizado, a

documentação das funcionalidades deve ser atualizada.

PF = (PF_NÃO_AJUSTADO x 0,50) + PF_CONVERSÃO

b) Atualização de Plataforma sem necessidade de redocumentação de requisitos

Nestes casos, a aferição do tamanho em Pontos de Função da aplicação ou da parte da aplicação

que sofreu impacto considera 40% dos PFs, seguindo a fórmula de desenvolvimento do CPM 4.3 e as

funções de conversão de dados, se aplicável.

PF = (PF_NÃO_AJUSTADO x 0,40) + PF_CONVERSÃO

Nos dois itens acima, os percentuais de multiplicação são estimados, podendo ser reajustados

conforme avaliação da base histórica dos serviços realizados no órgão.

4.4.3. ADEQUAÇÃO DE FUNCIONALIDADES ÀS MUDANÇAS DE NEGÓCIO

São consideradas nesta categoria as demandas de manutenção adaptativa associadas à

adequação de funcionalidades às mudanças de regras de negócio ou de Legislação ou requisitos de

usabilidade que não se enquadram nas funções alteradas do Projeto de Melhoria, seguindo as regras de

contagem do CPM. Observe que tais solicitações envolvem aspectos não funcionais, sem alteração em

requisitos funcionais.

Por exemplo: replicação de funcionalidade (chamar uma consulta existente na aplicação de outra

tela, por demanda do usuário); replicação de base de dados ou criação de base temporária para resolver

problemas de performance ou segurança; Alteração no software para adaptação às alterações realizadas

em rotinas de integração com outros software (ex: alteração em sub-rotinas chamadas por este software).

Nesta categoria foram observadas demandas dos seguintes tipos:

a) Adequação de funcionalidades com necessidade de redocumentação




funcionalidades que sofreram impacto deve considerar 80% do PF_Alterado, seguindo os conceitos do CPM

4.3, apresentados na seção 4.1. Deve-se destacar que além da adequação das funcionalidades em questão

e da documentação do projeto de manutenção adaptativa realizado, a documentação das funcionalidades

deve ser atualizada.


b) Adequação de funcionalidades sem necessidade de redocumentação de requisitos


funcionalidades que sofreram impacto deve considerar 70% do PF_Alterado, seguindo os conceitos do CPM

4.3, apresentados na seção 4.1. Não será contemplada a documentação das funcionalidades nas

demandas desta categoria.


Nos dois itens acima, os percentuais de multiplicação são estimados, podendo ser reajustados

conforme avaliação da base histórica dos serviços realizados no órgão.

Para outros tipos de projetos de manutenção adaptativa não definidos neste documento,

considerar um percentual do PF_Alterado, variando de 30% a 80%, de acordo com as características

do requisito não funcional alterado. Versões futuras deste Manual devem contemplar os novos tipos

não definidos neste documento.

4.4.4. APURAÇÃO ESPECIAL

São funcionalidades executadas apenas uma vez para: corrigir problemas de dados incorretos na

base dados das aplicações ou atualizar dados em bases de dados de aplicações, detalhado no item 4.3.4.1;

gerar um relatório específico ou arquivo para o usuário por meio de recuperação de informações nas bases

da aplicação.

Caso a apuração seja de correção de dados, devido a erros de funcionalidades de aplicações

desenvolvidas pela contratada, observar as cláusulas contratuais com relação a garantias e prazos de

correção.

4.3.4.1 APURAÇÃO ESPECIAL – BASE DE DADOS

Uma apuração especial é um projeto que inclui a geração de procedimentos para atualização da

base de dados. Deve-se destacar que estas funções são executadas apenas uma vez, não fazendo parte

da aplicação, visando a correção de dados incorretos na base de dados da aplicação ou atualização em



função de modificação da estrutura de dados, por exemplo inclusão do indicador de matriz – sim ou não

para um CNPJ. Nestes casos, a contagem de Pontos de Função das funcionalidades desenvolvidas.

Geralmente, estas funcionalidades são classificadas como Entradas Externas.

PF = PF_NÃO_AJUSTADO

Deve-se ressaltar que as funções de conversão de dados (carga inicial de dados que ocorre na

implantação de projetos de desenvolvimento ou de melhoria) não são apurações especiais. Estas funções

fazem parte do projeto de desenvolvimento ou de melhoria em questão, portanto devem ser contadas junto

com estes projetos e não como apuração especial. Assim, nestes casos, considera-se as fórmulas de

contagem de Pontos de Função dos projetos em questão. Em alguns casos de Apuração Especial –

Atualização de dados, o usuário solicita uma consulta prévia das informações atualizadas para validação.

De fato, é uma prática interessante para evitar informações errôneas na base de produção dos sistemas.

Esta Consulta Prévia, classificada como Consulta Externa ou Saída Externa deve ser dimensionada,

considerando-se 60% do tamanho da funcionalidade em questão, conforme a fórmula abaixo:

PF = PF_NÃO_AJUSTADO x 0,60

4.3.4.2 APURAÇÃO ESPECIAL – GERAÇÃO DE RELATÓRIOS

Uma apuração especial é um projeto que inclui a geração de relatórios em uma ou mais mídias para

o usuário. Em alguns casos, são solicitadas extrações de dados e envio dos dados para outros sistemas.

Caso neste envio de dados sejam requisitadas atualizações no sistema de origem, então estas funções são

Saídas Externas, devido à atualização do Arquivo Lógico Interno.

Deve-se destacar que estas funções são executadas apenas uma vez, não fazendo parte da

aplicação. Nestes casos, considera-se contagem de Pontos de Função das funcionalidades desenvolvidas.

Freqüentemente, estas funcionalidades são classificadas como Saídas Externas. Também podem ser

classificadas como Consultas Externas, caso não possuam cálculos ou criação de dados derivados.

PF = PF_NÃO_AJUSTADO

4.4.5. MANUTENÇÃO EM PÁGINAS ESTÁTICAS DE INTRANET, INTERNET OU PORTAL

Nesta seção são tratadas manutenções específicas em páginas estáticas de Portais, Intranets ou

Websites. A demanda consiste na publicação de páginas HTML. Estas demandas são consideradas como

desenvolvimento de consultas com a utilização de ferramentas para apoiar a publicação. Nestes casos,



considera-se 50% dos Pontos de Função das consultas desenvolvidas. Cada página é contada como uma

consulta. As consultas são consideradas Consultas Externas Simples (3 PF).

QTD_SIMPLES: Quantidade de Páginas com complexidade Simples

PF_SIMPLES: QTD_SIMPLES X 0,5

QTD_INTERMEDIARIA: Quantidade de Páginas com complexidade Intermediária

PF_ INTERMEDIARIA: QTD_ INTERMEDIARIA X 0,8

QTD_COMPLEXAS: Quantidade de Páginas com complexidade Complexa

PF_ COMPLEXAS: QTD_ COMPLEXAS X 1,2

PF_TOTAL = PF_SIMPLES + PF_INTERMEDIARIA + PF_ COMPLEXAS

* Deve ser definido de forma clara como classificar cada página em uma das categorias.

Exemplo:

O Portal XXX será desenvolvido e foi verificado que o mesmo é composto de:

50 páginas simples

20 páginas intermediárias

10 páginas complexas

PF_SIMPLES = 50 * 0,5 = 25

PF_INTERMEDIARIA = 20 * 0,8 = 16

PF_COMPLEXA = 10 * 1,2 = 12

PF_TOTAL = 25 + 16 + 12 = 53

4.4.6. MANUTENÇÃO DE DOCUMENTAÇÃO DE SISTEMAS LEGADOS

Nesta seção são tratadas demandas de documentação ou atualização de documentação de

sistemas legados. Observe que o desenvolvedor deve realizar uma Engenharia Reversa da aplicação para

gerar a documentação. Para este tipo de projeto, caso a demanda seja apenas a documentação de

requisitos, devem ser considerados 20% dos Pontos de Função da aplicação em questão, conforme a

fórmula abaixo.




Caso a demanda seja a geração de artefatos de documentação de todas as fases do processo de

desenvolvimento, deve-se considerar um percentual mais alto de 30% a 50%, dependendo dos artefatos a

serem gerados. As premissas utilizadas devem ser conforme cláusulas contratuais e documentadas no

documento de estimativas do projeto.

4.4.7. VERIFICAÇÃO DE ERROS

São consideradas verificações de erro ou análise e solução de problemas as demandas referentes a

todo comportamento anormal ou indevido apontado pelo cliente nos sistemas aplicativos. Neste caso, a

equipe de desenvolvimento da ATI se mobilizará para encontrar a(s) causa(s) do problema ocorrido. Se for

constatado erro de sistema, a demanda será atendida como manutenção corretiva.

Entretanto, uma vez não constatado o problema apontado pelo cliente ou o mesmo for decorrente

de regras de negócio implementadas ou utilização incorreta das funcionalidades, será realizada a aferição

do tamanho em Pontos de Função das funcionalidades verificadas, e será considerado 25%.


4.4.8. FATOR DE CRITICIDADE DE SOLICITAÇÃO DE SERVIÇO

Em função da criticidade e da necessidade de alocação de recursos extras para atendimento da

demanda no prazo estipulado pelo cliente, poderá ser adotado um Fator de Criticidade de 1,35 (um vírgula

trinta e cinco), que deverá ser multiplicado pelo tamanho funcional da demanda considerada crítica, de

modo a remunerar adequadamente o aumento do esforço de atendimento.

Este fator é considerado para demandas que devem ser atendidas em finais de semana, feriados e

fora do horário comercial. Entende-se como horário comercial o horário local.

4.4.9. PONTOS DE FUNÇÃO DE TESTE

Muitas vezes, em projetos de manutenção o conjunto de funções de dados e funções transacionais

a serem testadas é maior do que a quantidade de funções a serem implementadas, i.e., além das

funcionalidades que são afetadas diretamente pelo projeto de manutenção, outras precisam ser testadas

[NESMA, 2009]. O tamanho das funções a serem testadas deve ser aferido em Pontos de Função de Teste

(PFT). Não considerar as funcionalidades incluídas, alteradas ou excluídas do projeto de manutenção na

contagem de Pontos de Função de Teste.

A contagem de PFT deve considerar o seguinte [NESMA, 2009]:



Determinar o tamanho em Pontos de Função de cada função de dados ou transacional envolvida no teste.

Calcular o tamanho em Pontos de Função de todas as funções de dados ou transacionais envolvidas no teste.

A conversão do PFT em Ponto de Função deve ser feita de acordo com a fórmula abaixo:

PF = PFT x 0,20

É importante ressaltar que as funções testadas consideradas no PFT devem estar documentadas.

Observe que estas funções farão parte do escopo do projeto de manutenção.

Nos itens da seção 4 acima, os percentuais são estimados, podendo ser reajustados

conforme avaliação da base histórica dos serviços realizados no órgão. Em casos onde não há

percentuais, pode-se aplicar algum percentual, também conforme avaliação da base histórica dos

serviços realizados no órgão.

5. ITENS NÃO MENSURÁVEIS

Deve-se ressaltar que o processo de desenvolvimento de soluções possui várias atividades que

devem ser consideradas como um projeto separado, levando-se em conta as horas realizadas, dentre

outras:

Treinamentos em Tecnologia, Metodologias, Métricas, etc. encontram-se nesta categoria as

demandas de treinamentos em linguagens de programação, ferramentas de gestão, processos, modelos da

qualidade, métricas, etc. Estes serviços são executados por consultores de terceiros, especialistas no

assunto em questão. Assim, devem ser consideradas as horas de consultoria para preparação e execução

do curso e o custo do deslocamento do instrutor, se for o caso.

Mapeamento de Processos de Negócio: Encontram–se nesta categoria as demandas de

elaboração e levantamento de documentação contendo o mapeamento de processos de negócio de uma

organização ou de parte de uma organização. Estes serviços são executados por consultores da ATI ou

terceiros, especialistas em BPM (Business Process Modeling).

Elaboração de Plano Diretor de Tecnologia da Informação (PDTI): encontram-se nesta categoria

demandas para elaboração de PDTIs para clientes. Estes serviços são executados por consultores do ATI

ou terceiros com o apoio dos funcionários da ATI especialistas nas atividades associadas à elaboração de

um PDTI.

Definição de Processo de Desenvolvimento de Soluções: Encontram-se nesta categoria

demandas para definição de Processos de Software aderentes às necessidades da ATI e observando as

boas práticas de modelos como CMMI, Scrum ou normas como a IN 04. Estes serviços são executados por



consultores da ATI ou terceiros, especialistas nas atividades de processos de software e na customização

de ferramentas para facilitação do processo.

Outros serviços prestados que também não possuem Pontos de Função associados são os

seguintes:

Administração de Dados: Este serviço requer uma equipe de ADs com um número de

profissionais definido junto ao Cliente/Fornecedor, dedicada para atender as demandas associadas à

definição e manutenção do modelo de dados de negócio. Esta equipe fica disponível em horário comercial

para atendimento das demandas. Assim, estes serviços não possuem contagem de PF associada.

É importante ressaltar que as atividades de banco de dados associadas ao projeto de

desenvolvimento ou de manutenção, por exemplo, preparação de ambiente (testes, homologação,

implantação), desempenhadas pelos DBAs da equipe de desenvolvimento, já estão consideradas dentro do

projeto de software, não cabendo cobrança adicional.

Análise de Solução: Serviço de apoio destinado à análise de regras de negócio implementadas em

soluções de TI. Estas demandas não possuem contagem de PF associada.

Consultoria: Serviço de apoio destinado à análise de regras de negócio a serem implementadas

em soluções de TI realizado por consultores especialistas da ATI. As demais modalidades de consultoria

também podem ser enquadradas neste item, por exemplo, Consultoria em Métricas. Estas demandas não

possuem contagem de PF associada. Outras atividades contidas em um processo de software devem ser

gerenciadas dentro do projeto de desenvolvimento ou de manutenção, no entanto o esforço deve ser

considerado separadamente da estimativa de esforço derivado da contagem de Pontos de Função.

Estas atividades também devem ser precificadas a parte. São elas:

Treinamento para Implantação: São demandas de treinamentos sobre utilização do sistema a ser

implantado para os gestores de solução do cliente e usuários. O esforço deste serviço deve ser considerado

separadamente da estimativa de esforço derivada da contagem de PF. O preço deste serviço deve ser

calculado, levando-se em conta o preço da hora dos consultores de terceiros que estarão realizando

atividades de preparação de treinamento e de instrutoria. Em alguns casos, pode ocorrer também o

deslocamento do instrutor, que também deve ser cobrado do cliente.

Especificação de Negócio: Esta atividade é a primeira atividade a ser executada em uma

demanda de projeto de desenvolvimento e/ou de manutenção. O objetivo desta atividade é gerar a

Especificação da demanda. O principal produto gerado nesta atividade é o artefato: Documento de Visão do

Projeto (DV), que deve ser validado pelo cliente, por meio da assinatura do termo de aceite. Além do DV

podem ser gerados outros documentos, tais como: atas de reunião, documento de requisitos não funcionais

e glossário da especificação de negócio. O esforço desta atividade deve ser considerado separadamente da



estimativa de esforço derivada da contagem de PF. É importante ressaltar que esta atividade é de

responsabilidade dos Analistas de Negócios da empresa contratante, de acordo com as legislações em

vigor da ATI. Portanto. Caso o cliente demande para terceiros a realização desta atividade, esta deve ser

cobrada em horas de consultoria. Observe que o Documento de Visão gerado nessa atividade é o insumo

para o planejamento (estimativas) e a atividade de Engenharia de Requisitos do processo de

desenvolvimento de software.

Suporte: Esta atividade é realizada sob demanda para solucionar diversos tipos de problemas que

em sua maioria são com infra-estrutura ou de apoio a informação (suporte a usuário). A natureza destes

serviços não é o desenvolvimento de software não cabendo de forma alguma a aferição por ponto de

função.

Help Desk: Esta atividade é realizada com a alocação de pessoas cujo objetivo é atender seja por

telefone, internet ou presencialmente informações a respeito de determinados serviços da ATI. A forma

mais comum de pagamento por este serviço é por profissional contratado. E mesmo assim, a natureza

desse serviço também não é de desenvolvimento de software assim não cabendo pontos por função.

6. ASPECTOS NÃO CONSIDERADOS PELO IFPUG CONSIDERADOS PELA ATI

Algumas atividades que não estão presentes no Manual de Práticas de Contagem (CPM 4.3.1) do

IFPUG já estão resolvidas dentro do âmbito da ATI. Nesta seção iremos apresentar como a ATI considera

tais aspectos.

6.1. MÚLTIPLAS MÍDIAS

Esta subseção tem como propósito apresentar as diretrizes de Contagem de Pontos de Função

utilizadas na ATI em relação ao tema Múltiplas Mídias. Esta abordagem é reconhecida pelo IFPUG. As

definições apresentadas têm como base o artigo “Considerations for Counting with Multiple Midia” Release

1.0 publicado pelo IFPUG [IFPUG, 2009] e pelo Serpro (2010).

Considerando-se a contagem de PF de funcionalidades entregues em mais de uma mídia, a

aplicação das regras de contagem de Pontos de Função definidas no CPM tem levado a duas abordagens

alternativas, a saber: single instance e multiple instance.

A abordagem single instance considera que a entrega de uma função transacional em múltiplas

mídias não deve ser utilizada na identificação da unicidade da função.

A abordagem multiple instance leva em consideração que a mídia utilizada na entrega da

funcionalidade é uma característica de identificação da unicidade da função. Assim, funcionalidades únicas

são reconhecidas no contexto da mídia na qual elas são requisitadas para operar.



É importante enfatizar que o IFPUG reconhece ambas abordagens single instance e multiple

instance para a aplicação das regras definidas no CPM. A determinação da contagem de PF seguindo a

abordagem multiple instance ou single instance depende do gestor do contrato ou gestor do produto que

está relacionado com aquela contagem.

As estimativas e contagens de PF realizadas pelo ATI serão baseadas na abordagem multiple

instance, com exceção dos casos de consultas em .pdf, .doc, .xls e consultas idênticas em tela e papel, que

serão consideradas uma única funcionalidade.

A seguir são descritos os termos comuns definidos pelo IFPUG [IFPUG, 2009]:

Canal: também refere-se a mídia. Múltiplos canais é sinônimo de múltiplas mídias.

Mídia: descreve a maneira que os dados ou informações se movimentam para dentro e para fora de

uma fronteira de aplicação, por exemplo, apresentação de dados em tela, impressora, arquivo, voz. Este

termo é utilizado para incluir, dentre outros: diferentes plataformas técnicas e formatos de arquivos como

diferentes mídias.

Múltiplas Mídias: quando a mesma funcionalidade é entregue em mais de uma mídia.

Freqüentemente, somente uma mídia é requisitada para um usuário específico em um determinado

momento, por exemplo consulta de extrato bancário via internet como oposto a consulta de extrato bancário

via terminal do banco.

Multi-Midia: quando mais de uma mídia é necessária para entregar a função, por exemplo, uma

nova notícia publicada na Internet que é apresentada em vídeo e texto. Observe que a notícia completa só é

apresentada para o usuário se ele ler o texto e assistir o vídeo.

Abordagem Single Instance: esta abordagem não reconhece que a mídia utilizada na entrega da

função transacional é uma característica de diferenciação na identificação da unicidade da função

transacional. Se duas funções entregam a mesma funcionalidade usando mídias diferentes, elas são

consideradas a mesma funcionalidade em uma contagem de Pontos de Função.

Abordagem Multiple Instance: esta abordagem especifica que o tamanho funcional é obtido no

contexto de objetivo da contagem, permitindo uma função de negócio ser reconhecida no contexto das

mídias que são requisitadas para a funcionalidade ser entregue. A abordagem multiple instance reconhece

que a mídia para entrega constitui uma característica de diferenciação na identificação da unicidade da

função transacional.

Os cenários descritos nas seções seguintes não representam uma lista completa de situações de

múltiplas mídias. O entendimento destes exemplos facilitará o entendimento de outros cenários envolvendo



múltiplas mídias. Este Roteiro deve ser atualizado considerando a publicação de novas diretrizes do IFPUG

e novos cenários que emergirão nas contagens de PFs dos projetos dos clientes do ATI.

Os cenários descritos nas seções seguintes não representam uma lista completa de situações de

múltiplas mídias. O entendimento destes exemplos facilitará o entendimento de outros cenários envolvendo

múltiplas mídias. Este Roteiro deve ser atualizado considerando a publicação de novas diretrizes do IFPUG

e novos cenários que emergirão nas contagens de PFs dos projetos dos clientes do ATI.

6.1.1. MÚLTIPLAS MÍDIAS

Neste cenário, uma aplicação apresenta uma informação em uma consulta em tela. A mesma

informação pode ser impressa caso requisitado pelo usuário na tela em questão. Nesses casos, a ATI utiliza

a abordagem single instance, considerando que dados idênticos sendo apresentados em tela e relatório

impresso devem ser contados como uma única função.

Caso as lógicas de processamento da consulta em tela e do relatório em papel sejam distintas, o

processo elementar não é único e, portanto, a funcionalidade será contada duas vezes. Observe que a

abordagem multiple instance considera que a contagem de PF de dados idênticos sendo apresentados

usando mais de um tipo de mídia deve incluir toda instância da função em cada tipo de mídia. Neste

exemplo, duas funções são contadas – apresentação de dados em tela; apresentação de dados impressos.

6.1.2. MESMOS DADOS DE SAÍDA COMO DADOS EM ARQUIVOS E RELATÓRIOS IMPRESSO

Uma aplicação grava dados em um arquivo de saída e imprime um relatório com informações

idênticas as gravadas no arquivo. Nesses casos, a ATI utiliza a abordagem single instance considerando

que os dados impressos e os dados apresentados no arquivo de saída sejam idênticos.

Assim, apenas uma funcionalidade será incluída na contagem de Pontos de Função. Caso as

lógicas de processamento da geração do arquivo de saída e do relatório em papel sejam distintas, o

processo elementar não é único e, portanto a funcionalidade será contada duas vezes.

Observe que a abordagem multiple instance considera que dados idênticos estão sendo entregues

em mais de um tipo de mídia e a contagem de PF incluirá todas as instâncias de tipos de mídia. Neste

cenário, duas funções são contadas – geração arquivo e apresentação dos dados impressos.

6.1.3. MESMOS DADOS DE ENTRADA BATCH E ON-LINE

Uma informação pode ser carregada na aplicação por meio de dois métodos: arquivo batch e

entrada on-line. O processamento do arquivo batch executa validações durante o processamento. O

processamento on-line também executa validações das informações.



A abordagem utilizada pela ATI é a single instance conta apenas uma funcionalidade. Na ATI,

porém pode ser considerada a abordagem multiple instance que conta duas funcionalidades: a entrada de

dados batch e a entrada de dados on-line quando a lógica de processamento utilizada nas validações em

modo batch é diferente da lógica de processamento das validações nas entradas de dados on-line.

Portanto, fica a cargo do gestor de contrato ou produto da ATI definir se será uma ou duas funcionalidades.

6.1.4. MÚLTIPLOS CANAIS DE ENTREGA DA MESMA FUNCIONALIDADE

Uma funcionalidade deve ser disponibilizada em múltiplos canais, por exemplo, consulta de dados

em página Web e consulta de dados no telefone celular. A abordagem single instance conta apenas uma

funcionalidade. Na ATI novamente pode ser utilizada a abordagem multiple instance que conta duas

funcionalidades: a consulta de dados na Web e a consulta de dados via celular.

Considera-se que esta solução é justa quando a funcionalidade é desenvolvida duas vezes para os

dois canais. Algumas vezes, são até projetos de desenvolvimento distintos, um projeto relativo ao sistema

Web e outro para o sistema via celular. Portanto, nestes casos a ATI contará duas funcionalidades.

6.1.5. RELATÓRIOS EM MÚLTIPLOS FORMATOS

Um relatório deve ser entregue em diferentes formatos, por exemplo, em um arquivo html e um

formato de valores separados por vírgula. Nestes casos, conforme sugerido na abordagem multiple

instance, a ATI considera a ferramenta utilizada na geração dos relatórios. Se a equipe de desenvolvimento

precisar desenvolver o relatório nos dois formatos na ferramenta em questão, serão contadas duas

funcionalidades.

Isso porque a lógica de processamento de análise de condições para verificar quais são aplicáveis é

identificada. No entanto, se a ferramenta de desenvolvimento suportar um gerador de relatórios que o

usuário visualize o relatório em tela e o gerador permita ao usuário imprimir o relatório, salvar em html ou

salvar no formado de valores separados por vírgula, então a ATI contará apenas uma vez, observando que

a funcionalidade será da ferramenta e não da aplicação.

6.2. DATA WAREHOUSE


utilizadas na ATI em relação ao tema Data Warehouse. Esta abordagem é reconhecida pelo IFPUG. As

definições apresentadas têm como base o artigo “Function Points & Counting Enterprise Data Warehouses”

Release 1.0 publicado pelo IFPUG [IFPUG, 2007].

Um aspecto crucial da contagem de Data Warehouses que apresentou desafios significativos dos

contadores de ponto de função está em definir a fronteira da aplicação. Uma fronteira impropriamente

definida pode distorcer de forma considerável os resultados da análise de ponto de função. Com base

nessas regras de definição de fronteira, o que segue abaixo deve ser excluído dos limites da aplicação:



Arquivos lógicos mantidos pelo(s) sistema(s) de origem, exceto se eles são referenciados durante o processamento dos arquivos de chegada com os dados.

Tabelas Temporárias,

Staging Areas,

Tabelas de códigos

Data Marts. Estes podem ser contados como fronteiras de aplicações separadas.

Algumas considerações incluem:

O propósito da contagem,

Os usuários são um grupo distinto; ex.: um departamento específico como marketing, diferente grupo de usuários do Data Warehouse e;

A existência de dados externos além daquele disponível dentro do Data Warehouse.

Figura 5 é uma representação gráfica de como a fronteira de um Data Warehouse pode ser definida.

Figura 5: Figura Ilustrativa de um Fronteira de DW

A Figura 5 esta mostrando um limite em volta das Staging Areas/Depósito de Dados

Operacionais/Data Warehouses e limites em torno de Data Marts específicos. É uma representação gráfica



de como as fronteiras podem ser definidas. Embora este diagrama mostre todos os três Data Marts fora da

fronteira, esse nem sempre pode ser o caso.

Acrônimos comuns:

ETL = Extrair, Transformar & Carregar

ODS = Depósito de Dados Operacionais

EDW = Enterprise Data Warehouse

BO = Business Objects Funcionalidade física

Muitos sistemas de Data Warehouse contêm várias áreas físicas onde os dados são armazenados

antes, durante e depois que os dados são recebidos do sistema de origem e são processados. Nesse

contexto, é importante diferenciar a funcionalidade do negócio das funções físicas e técnicas.

Os Data Warehouses geralmente usam tecnologia da web para tornar as suas informações mais

acessíveis aos usuários. Esses Websites podem incorporar informações nos relatórios ou consultas;

informação de metadados; dicionários de dados; ferramentas de Consulta; treinamento; e membros de

grupos de projetos em um local conveniente.

Quando esses Websites existem, o Analista do Ponto de Função precisa determinar se a fronteira

do Data Warehouse inclui ou exclui o Website que fornece acesso a ele. Segue algumas dicas para ajudar

nessa decisão:

Se um Website central é usado para acessar vários Data Warehouses dentro da empresa, e este é mantido por uma equipe específica e não pela equipe que mantém os Data Warehouses, essa é uma boa indicação que o Website é uma aplicação separada cuja função primária é fornecer acesso aos Data Warehouses.

Se um serviço web foi construído para fornecer capacidades de relatório para um Data Warehouse específico, e é mantido por esta equipe de Data Warehouse, provavelmente seria contado como parte do aplicativo de Data Warehouse.

Observação: A fronteira do aplicativo não se baseia necessariamente em como a organização do

software é gerenciada. Porém, conhecer quem desenvolveu o Website que fornece acesso a um Data

Warehouse em particular pode ser útil quando se define a fronteira da aplicação.

Anatomia Física de uma Data Warehouse

Tipicamente, existem três segmentos físicos dentro do Data Warehouse; Staging Areas, o depósito

de dados operacionais e o Data Warehouse. Staging Areas. Essa Staging Area é usada para armazenar

uma versão atual do Data Warehouse que existe no sistema original. Esta cópia física é criada por várias

razões, inclusive:



Desempenho – O sistema operacional pode reduzir a carga de processamento imposta pelas leituras requeridas antes que a transformação dos dados comece.

Segurança – Sistemas origem podem controlar o que os programas têm acesso em suas áreas. Ao fornecer uma exportação, o sistema de origem mantém controle sobre o que é enviado.

Os dados armazenados nas Staging Areas são os mesmos ou muito similares aos do sistema

original, em suas estruturas e valores de dados. A Staging Area raramente é vista ou descrita por um

usuário do negócio ou um usuário administrador.

Depósito de Dados Operacionais (ODS)

O ODS contém dados transacionais detalhados que são (tipicamente), de alguma forma,

modificados. A fonte original desses dados é o sistema de origem via a área de etapas. Considere como os

dados podem ser modificados quando determinam se é um armazenamento de dados e o tipo de função de

dados (ALI ou AIE). Os dados nesse segmento do Data Warehouse podem ser descritos como:

Integrados

Validados

Freqüentemente atualizados

Detalhados

Voláteis

O segmento ODS suporta a habilidade para, via data mining, buscar informações sumarizadas para

as informações de nível transacional, detalhadas e atuais.

O Data Warehouse é a última área de acomodação (dentro do limite do aplicativo de Data

Warehouse) para os dados transformados. Quando dados são armazenados aqui, eles passaram por um

processamento via ETL (Extrair, Transformar e Carregar). Exemplos desse processamento incluem:

Validação

Integração

Limpeza

Verificações de qualidade

Sumarização

Projetos de Data Warehouse contêm muitos documentos que o Analista do Ponto de Função pode

usar para auxiliar na contagem do ponto de função. Alguns dos documentos mais úteis são os diagramas de

modelo de dados, que ajudar a determinar dados e funções transacionais para a contagem. Os diagramas

de modelo de dados incluem:

Tabelas Fato

Tabelas Agregadas

Tabelas de existência

Dimensões



Tabelas de Visualização

Metadados

Tabela Fato

A tabela fato é a principal tabela de interesse em um modelo dimensional. Uma tabela fato contém

medidas relacionadas a negócios e cada tabela fato pode ser conectada a tabelas dimensionais ou a outras

tabelas fato. Os dados da fato no Data Warehouse se parecem tipicamente com aqueles contidos no

sistema de origem ou ODS, mas foram submetidas ao processo ETL e portanto seu significado pode ter

sido mudado drasticamente.

A estrutura de chave estrangeira na tabela fato permite que os campos definidos em entidades

dimensionais acessem informações adicionais. Uma contagem de DET (TDs) tipicamente incluirá campos

da entidade da tabela fato e da entidade dimensional.

Dependendo da abordagem de modelagem usada pela equipe do projeto, o esquema de estrela

representado pode incluir só os campos que são requeridos para definir a informação da entidade, do fato

ou pode incluir todos os campos que são definidos para a entidade dimensional, mas são requeridos para

uso em outras entidades do fato.

Em resumo, tabelas fato contêm agrupamentos identificáveis do usuário de dados e são geralmente

mantidos por um ou mais processos de ETL (processos elementares). Como tais, eles são contados como

Arquivos Lógicos Internos. Uma palavra final de advertência sobre contagem dos tipos de dados (DETs ou

TDs) – certifique-se de contar somente os requeridos para a entidade fato em análise.

Tabelas Agregadas

Tabelas Agregadas é um tipo especial de tabela fato. Tabelas Agregadas deveriam ser contadas?

Depende da razão para a existência da tabela agregada, que pode existir por razões de desempenho ou

negócios.

Razões de Desempenho

Um conjunto de medidas pode ser criado à medida que os dados são carregados, pois do tempo

requerido para que tais cálculos sejam feitos nos relatórios é muito grande. Nesse caso, estas tabelas

agregadas não devem ser contadas como ALIs ou AIEs.

Propósitos de Negócio

Os usuários podem requerer que as tabelas agregadas sejam construídas para satisfazer um

propósito funcional de negócios. Por exemplo, informações da fato nem sempre podem ser expressáveis no



mesmo nível de detalhe; ou custos de remessa podem ser disponíveis ao nível de cliente da fatura de envio,

mas não no nível da linha da fatura ou o nível do produto.

Tabelas de Existência de Fato (Factless Fact Existence Table)

Esse tipo especial de tabela fato não contém medidas numéricas de negócio, mas ela documenta a

existência de um evento. Para determinar se deve ser incluído na contagem de pontos de função, faça a

análise funcional conforme esboçado nas regras do Manual de Práticas de Contagem. Vejamos um

exemplo na Figura 6.

Figura 6: Exemplo de Tabelas de Existência de Fatos

Essa tabela fato da Figura 6 é usada para definir quais produtos serão oferecidos, a quais

estabelecimentos e durante quais promoções. Essa tabela ajudará o analista na avaliação da eficácia de

promoções ao identificar os estabelecimentos e produtos participantes. Similar a tabelas associativas

encontradas no modelo relacional normalizado, tabelas de existência gerenciam exceções – onde certos

exemplos de uma tabela se relacionam a um ou mais outras tabelas.



Nesse exemplo, a entidade “Promotion Products” é uma tabela contável. A exigência em permitir

rastrear promoções fica satisfeita com essa entidade. Isso define que produtos serão oferecidos ou foram

oferecidos em quais estabelecimentos durante as promoções. A contagem resultante é um arquivo de baixa

complexidade – geralmente um ALI.

Tabelas dimensionais

Tabelas dimensionais contêm as informações descritivas necessárias para permitir uma análise da

informação relacionada a fato e contêm informações para permitir a verificação do carregamento dos dados.

Tipicamente, uma tabela fato só conterá DETs que permitam uma medição em particular (na tabela fato)

para ser considerada pelos campos nas tabelas dimensionais.

Dimensões e Fatos – Como eles Coexistem? Fisicamente, tabelas fato contêm só os DETs

requeridos para representar alguma medida de negócios e são rodeadas pela mesma tabela física por

DETs do tipo chave estrangeiras que conectam a dimensões de forma a permitir mais descrição de

qualquer evento em particular. Ao contar os elementos dos dados para a inclusão da tabela fato todos os

elementos de dados identificáveis do usuário na tabela de fato e os dados elementares das tabelas

dimensionais que são requeridos para definir o registro da tabela de fatos.

Tabelas de visualização

Como as tabelas de visualização podem ser contadas? Basicamente, existem duas formas em que

as tabelas de visualização podem ser “contadas” durante a análise do ponto de função.

Processos elementares – Se uma tabela de visualização é criada e enviada para fora do Data Warehouse para consumo de outro aplicativo (fronteira diferente de aplicativo) assim a transação pode ser contada como uma saída externa ou consulta externa para o aplicativo do Data Warehouse.

Parte de um ou mais processos elementares – Se a tabela de visualização é criada para uso do Data Warehouse então ela não deve ser contada como uma única função (processo elementar). A tabela de visualização deve ser analisada para determinar a fonte desses dados. As funções de dados usados para criar a tabela de visualização devem ser consideradas como um FTRs em potencial para determinar a complexidade das funções transacionais, que acessam aqueles dados em particular.

Metadados

A forma mais simples, talvez não a mais clara, de descrever metadados é: Dados sobre dados. Os

metadados proporcionam mais informação sobre o objeto que está sendo analisado. Os metadados são

usados por dois grupos de pessoas em uma organização: usuários que desempenham análise relacionada

a negócios e aqueles que desempenham análises relacionadas à técnica. Cada conjunto de usuários tem

diferentes necessidades desde a configuração da aplicação até a definição de campos usados em um

relatório específico.

Metadados técnicos incluem:



Descrição de tabelas

Descrição de atributos

Relações da entidade

Regras de processamento de dados

Relacionamento de chaves

Categorias de metadados de negócios incluem:

Dicionário de dados

Proprietários de dados

Informação assuntos da área

Um dos elementos-chave, para ter em mente ao analisar os tipos de metadados para incluir em sua

análise é quem foi definido como os “usuários” do aplicativo. Isso afeta a quantidade de arquivos que

poderão existir.

Funções de Transação

Existem quatro categorias de transações/funções que são usados num Data Warehouse típico. São

eles:

Extrair, Transformar e Carregar dados

Relatórios

Funções Administrativas

Funções de Metadados.

ETL, ou Extrair Transformar e Carregar (ETL) é o conjunto de transações de banco de dados usado

para extrair informações de um banco de dados, transformá-los e carregá-los em um segundo banco de

dados. As fontes de dados para o Data Warehouse estão em aplicativos ou sistemas que são externos ao

Data Warehouse (fora da fronteira). Dados de origem são extraídos ou recuperados de bancos de dados

externos por processos no Data Warehouse.

Uma vez que os dados são buscados da origem, são transformados usando regras de negócios

fornecidas pelo usuário bem como pelo administrador do armazém de dados (Transform). Depois que os

dados são transformados, eles são então carregados no Data Warehouse (Carrega ou Transporta).

Conta-se uma EE para cada Carregamento/Transporte de dados de aplicativo de origem que mantém um ou mais ALIs no Data Warehouse. Lembre-se que a intenção primeira dessas transações é manter dados lógicos no Data Warehouse ou alterar o comportamento do sistema. A lógica especial de processamento se aplica na transformação e carregamento de dados.

Não conte três EEs separadas para cada passo do processo (ex.: uma EE de Extração, uma EE de Transformação, e uma EE de Carregamento), uma vez que todos os três são requeridos para completar o processo elementar.

Conta um Arquivo referenciado (FTR) para cada ALI mantido.

Conte um Arquivo referenciado (FTR) para cada leitura de ALI ou AIE durante o processamento da entrada externa.

Conte só um Arquivo referenciado (FTR) para cada ALI que é mantido e lido.

Conte um AIE para cada grupo lógico de dados que é copiado de um sistema de origem para o Data Warehouse sem nenhuma lógica especial de processamento. Nesse caso, também não conte uma EE para a extração de dados. (A exigência lógica é referenciar os



dados. Os dados existem no Data Warehouse devido ao desempenho ou outras considerações de design/arquitetura do que uma necessidade do usuário de negócios.)

Relatório / Consulta

Consultar e fazer relatórios sobre os dados contidos no Data Warehouse são importantes funções

de negócios. O analista do ponto de função, precisa determinar quais funções de relatório ou consulta

fazem parte do Data Warehouse e quais são considerados fora da fronteira. Existem pelo menos duas

categorias de relatórios: relatórios adhoc e programados. Relatórios adhoc representam uma solicitação a

cada vez com parâmetros diferentes selecionados pelo usuário, enquanto relatórios programados são

criados periodicamente (diariamente, semanalmente, mensalmente) e, tipicamente, não podem ser

modificados pelos usuários.

Relatórios programados geralmente requerem uma análise formalizada e um ciclo de vida de

desenvolvimento. Como tal, relatórios programados são geralmente contados pelo contador do ponto de

função enquanto relatórios adhoc, criados por um usuário final, não podem ser contados. Uma exceção a

essa orientação seria contar a funcionalidade oferecida ao usuário para criar seus próprios relatórios adhoc.

Os dois exemplos seguintes de ferramentas de relatório podem ser usados para criar relatórios

adhoc e padrão.

1. Ferramenta de Relatório internamente desenvolvida: Essa ferramenta é criada por

desenvolvedores para suportar usuários do Data Warehouse.

A fronteira de contagem determina se a ferramenta de relatório desenvolvida é contada como um

componente do Data Warehouse ou um aplicativo separado. Se os usuários vêem a ferramenta como parte

do Data Warehouse, deve ser considerada estando dentro da fronteira do Data Warehouse. Outras áreas

que podem influenciar a decisão de incluir a ferramenta como componente do Data Warehouse são a lógica

de processamento e localização/manutenção dos dados lógicos que suportam os relatórios.

Supondo que a ferramenta de relatório desenvolvida se estabelece dentro dos limites do Data

Warehouse, conte pelo menos uma SE (EO) ou CE (EQ) para cada relatório ou consulta desenvolvida e/ou

suportada para satisfazer as necessidades do usuário. Siga as orientações CPM para determinar se o

relatório ou consulta é um processo elementar único.

2. Software Comercial de prateleira (COTS)/Ferramenta de Relatório Comprada (ex.:. Relatórios

Crystal, Cognos, Business Objects, etc): Para contagens de desenvolvimento e melhoria, um contador do



ponto de função deve contar só as funções que foram personalizadas ou feitas para o usuário de negócios

ou administrativo.

Se há uma necessidade ou solicitação de negócios para contar todo o portfólio de funções do

software, (por exemplo, para avaliar as características ou funções proporcionadas pelo COTS), COTS e as

funções personalizadas podem ser contados, mas o portfólio deve ser considerado um limite de aplicativo

separado do Data Warehouse, contado como um aplicativo separado, e categorizado de acordo. Conte um

SE (EO) ou CE (EQ) para cada relatório ou consulta desenvolvida e/ou suportada para satisfazer as

necessidades do usuário. Siga as orientações CPM para determinar se o relatório ou consulta é um

processo elementar único.

Funções Administrativas

Data Warehouses possuem inúmeras funções administrativas. Enquanto muitas são técnicas por

natureza e requeridas para manter o Data Warehouse ativo e operante; algumas são de natureza de

negócios e podem ser contadas. Perguntas que o contador pode fazer para ajudar a determinar se uma

função administrativa é de lógica técnica ou de negócios incluem:

• As funções foram desenvolvidas para suportar um usuário do aplicativo (ex.: administrador do

sistema, arquiteto de dados)?

• Existem exigências únicas de segurança (ex.: logins, segmentação de acesso por permissões,

senhas)? Supondo que o contador possa responder as questões acima afirmativamente:

• Conte um EE (EI) para cada função única administrativa (ex.: segurança, questões do usuário) que

mantém um ALI ou modifica o comportamento do sistema

• Conte uma SE (EO) ou CE (EQ) para relatórios produzidos para suportar essas funções. Use

regras de CPM para determinar os tipos de transação

Metadados

Metadados são geralmente definidos como dados sobre dados. Em um Data Warehouse pode

haver pelo menos dois tipos:

• Informação que suporta as características, funções e dados de negócios (ex.: dicionário de dados)

• Informação que suporta as funções técnicas do Data Warehouse (ex.: programações para backups

ou ajustes de desempenho).

É importante revisar e entender o propósito e objetivos da Contagem do Ponto de Função, na

medida em que isso irá clarear quem são os usuários e que funcionalidade de usuário pode ser

considerada. Ambos os tipos de metadados exigem a assistência de um administrador. A partir de uma



perspectiva de dados de negócios, pode-se incluir um arquiteto de dados. A partir de uma perspectiva

técnica que poderia incluir um administrador do sistema. Ao tentar analisar quais características e funções

desempenhadas nessas capacidades administrativas são contadas, é útil fazer as seguintes questões.

1. As funções de metadados foram desenvolvidas para apoiar um usuário do aplicativo? Se a

resposta é “sim”, conte um EE (EI) para cada função única mantendo os metadados, e conte uma SE (EO)

ou CE (EQ) para os relatórios de metadados produzidos.

2. As funções metadados foram desenvolvidas para suportar funções ou características técnicas

opostas à lógica de negócios?

Se a resposta é “sim”, essas funções não são contadas. Elas foram criadas por propósitos técnicos.

Conclusão

A única natureza dos Data Warehouses apresenta o Analista do Ponto de Função com um número

de desafios a fornecer essas empresas dados de tamanhos precisos e métricas relacionadas que podem

ser usados para tomar as melhores decisões possíveis.

6.3. AUTOMAÇÃO DE PROCESSOS DE NEGÓCIO (BPM)


utilizadas na ATI em relação ao contexto de processos automatizados em um ambiente BPMS. O principal

objetivo é fornecer uma referência comum que torne mais prática a contagem e aplicação dos conceitos e

regras definidos pelo IFPUG, com exemplos de situações particulares de processos automatizados em um

ambiente BPMS.

Visão Geral de Processos Automatizados em um Ambiente BPMS típico.

BPMS

Sistema Legado Aplicação Externa

Sistema Legado Aplicação Externa

Sistema Legado

Aplicação Externa

Processo automatizado



Interface de

Integração

Interface de Integração

Interface de

Integração

Interface de

Integração



Figura 7: Visão Geral de Processos Automatizados em um Ambiente

Definições:

Um BPMS (Business Process Management System) é um Sistema no qual se pode

desenvolver aplicativos integrados para gerenciamento de processos de negócios

contemplando recursos como: documentação de processos, execução automatizada de

processos, possibilidade de criação de indicadores gerenciais de processos em painéis de

controle, upload e trâmite de documentos eletrônicos, com possibilidade de certificação

digital e integração com sistemas legados através da filosofia SOA (Service Oriented

Architecture).

Os processos organizacionais automatizados são executados dentro do ambiente BPMS.

Na ATI este ambiente é proporcionado pela ferramenta ÁGILES.

Interface de integração é a tecnologia utilizada para integrar aplicações possibilitando a

troca e atualização de dados. Exemplos dessas tecnologias são: webservice, broker ou

view, etc.

6.3.1. FRONTEIRA DA APLICAÇÃO

Na contagem de pontos de função um dos passos iniciais da análise é a determinação da fronteira

da aplicação. Para a contagem de pontos de função de automação de processos deve-se considerar como

fronteira da aplicação, apenas a interface conceitual do processo de negócio que será automatizado. Tendo

o cuidado para não considerar na contagem, as funcionalidades que já integram e fazem parte do ambiente

BPMS, no qual o mesmo será desenvolvido. Ou seja, as funcionalidades pertinentes à ferramenta BPMS

estão fora da aplicação a ser desenvolvida (aqui o processo de negócio a ser automatizado).

6.3.2. Situação acesso ao BPMS:

Para acessar as atividades de um processo automatizado o usuário deve se logar no ambiente

BPMS. Como a funcionalidade de login é uma característica do ambiente BPMS, essa NÃO deve ser

contada como função nos projetos de automação de processos de negócio.

6.3.3. Cadastro de usuários e grupos organizacionais:

O ambiente BPMS-Agiles disponibiliza algumas funcionalidades de cadastro como por exemplo:

usuários e grupos organizacionais. Onde os usuários podem ser alocados aos grupos organizacionais. Os

projetos de automação processos devem considerar essas funcionalidades de cadastro como um AIE que é

mantido pela aplicação Ágiles, e os processos automatizados acessarão seus dados, contando estes como

Tipos de Dados.



6.3.4. Funcionalidades da aplicação Ágiles

A ferramenta BPMS-Agiles disponibiliza de várias funcionalidades para a execução dos processos

automatizados dentro do seu ambiente de trabalho. Apesar de poderem ser utilizadas na automação de

processos NÃO devem ser contadas, pois fazem parte do escopo da aplicação Ágiles.

Exemplos:

Consulta: Minhas atividades, Meus Processos, Monitoramento de Processos

Entrada: Iniciar algum processo de negócio

6.3.5. Recebimento de dados de outras aplicações utilizando interface de integração

Em projetos de automação de processos que realizam integração e troca de informações com

outras aplicações externas, é comum se deparar com algumas situações durante a análise de pontos de

função:

Cenário 1:

O primeiro caso são situações onde o processo automatizado precisa ler/consultar um arquivo

mantido por uma aplicação externa. Exemplo: Um processo X precisa consultar os dados de um funcionário

através de sua matrícula que são mantidos num sistema de RH. O entendimento para esse cenário é de

contagem de um AIE no processo automatizado referente aos dados consultados e mantidos no sistema de

RH e tantos Tipos de Dados que foram consultados. Nesta situação o arquivo consultado já é contado como

um ALI na aplicação externa.

Acentuando que a interface de integração utilizada nessa transação é apenas a tecnologia para

acessar os dados mantidos em outras aplicações, assim não afetam a contagem.

Cenário 2:

O segundo caso são situações onde o processo automatizado necessita verificar ou consistir

alguma informação em uma aplicação externa que possui total domínio da regra de negócio envolvida na

transação. Exemplo: Um processo X necessita verificar se um determinado funcionário pode solicitar uma

licença sem vencimento. Toda regra envolvida para essa verificação é de responsabilidade e realizada na

aplicação externa, onde o processo X solicita essa verificação na aplicação externa. Para esse cenário onde

toda a regra de negócio esta fora do processo X não se justifica nenhuma contagem de pontos de função.



6.3.6. Atualização de dados em outras aplicações utilizando interface de integração

Os processos automatizados que necessitem manter dados em outra aplicação onde as regras de

negócio relativas à essa manutenção, estão presentes fora da fronteira, ou se seja, estão presentes na

interface de integração e/ou em outras aplicações externas (como por exemplo no banco de dados ou

sistema legado, no que se refere a contagem não deve ser considerado um ALI para o processo

automatizado. Os dados de entrada utilizados nessa transação que foram atualizados na aplicação externa

serão considerados Tipos de Dados.

Acentuando que a interface de integração utilizada nessa transação é apenas a tecnologia para

acessar os dados mantidos em outras aplicações, assim não afetam a contagem.

6.3.7. Dados de Código

Os dados de código são uma implementação de requisitos técnicos e não devem influenciar o

tamanho funcional da aplicação, apesar de poderem representar até metade do modelo de dados em

terceira forma normal, assim não devem ser contados.

As funcionalidades que existam exclusivamente para a manutenção de dados de código não devem

ser consideradas processos elementares, assim como os dados de código não devem ser considerados

como arquivos referenciados nos processos elementares que os leiam e/ou atualizem. Observação: essas

tabelas só serão contadas se possuírem atributos que são determinantes na definição de regras de negócio.

Para tal, essas regras de negócio, não devem basear-se apenas no código do registro.

6.3.8. Processo Elementar

Algumas atividades modeladas em BPMN, apesar de se apresentarem distintas no modelo, podem

constituir apenas uma transação completa para o negócio, com sentido de completude de determinado

requisito funcional para o usuário. Assim, devem ser contadas como apenas uma transação. Assim sendo, é

factível que se tenha na modelagem BPMN mais de uma atividade ou mesmo um conjunto de atividades

que sejam correspondentes a um único requisito funcional, sendo portanto considerado na contagem como

uma única transação

Atenção: Alguns modelos BPMN podem apresentar atividades que foram modeladas apenas para

melhor entendimento do negócio e, que não constitui um processo elementar para o sistema. Assim não

devem ser levadas em consideração na contagem.

Exemplo1:

Na figura 8 abaixo foram incluídas no modelo as atividades “Vistar Documentação e Pendências“ e

“Solicitar Resolução de Pendências”. Apesar de serem duas atividades no modelo, para o negócio elas

constituem apenas um processo elementar, individualmente elas não constituem uma transação completa.



A atividade “Vistar Documentação e Pendências” sem a “Solicitação de Resolução das Pendências” não é

considerado um processo completo para o usuário.

Figura 8: Exemplo de atividades distintas que compõem um único processo elementar

Exemplo2:

Uma mesma atividade que pode ser realizada por pessoas/entidades diferentes deve ser contada

apenas uma vez. Na Figura 9 abaixo a atividade “Resolver Pendência” constitui uma transação completa,

tem significado para o usuário, é autocontida e deixa o negócio da aplicação em um estado consistente.

Isso independente da entidade que a realiza. O mesmo ocorre com a atividade “Assinar Contrato”, conforme

podemos observar na Figura 10.



Figuras 9 e 10: Exemplos de atividades distintas que compõem um único processo elementar

6.3.9. Atividade com prazos

Atividades que tenham um prazo para serem realizadas, onde após a expiração do prazo uma

notificação/lembrete é disparada, essa notificação seja por e-mail, sms ou outro meio, não deve ser

contada, pois faz parte do negócio da atividade.

Exemplo:

Na figura 11 abaixo a atividade “Assinar Contrato” tem um prazo de 01 (um) dia para ser realizada.

Se o prazo expirar primeiro do que a conclusão da atividade, então será disparada uma atividade para

notificar o responsável avisando do ocorrido e solicitando a sua realização. A notificação em si seja por

email, sms ou algum outro meio, não tem sentido completo de negócio para o usuário, é apenas um

procedimento integrante deste.

Figura 11: Exemplo de atividade de notificação que não representa um processo elementar



7. LIÇÕES APRENDIDAS

7.1. REQUISITOS

É primordial que os requisitos de software sejam escritos de forma coerente com a nova forma de

medição, que é Pontos de Função. Embora a engenharia de requisitos tradicional não aconselhe, o que

vemos na prática é que os requisitos devem ser fracionados de forma tal a representar a mínima unidade

funcional que seja compreendida pelo usuário e que seja testável pelo desenvolvedor.

Este fracionamento traz a organização e o controle dos requisitos de forma tal a conhecer o produto

da melhor maneira possível, além de que é mais fácil gerenciar mudanças em requisitos menores. O

Capability Maturity Model Integration (CMMI) não trata da forma como os requisitos serão escritos, mas

ainda assim, quando se trata de APF algumas observações devem ser consideradas.

7.1.1. GRANULARIDADE X QUANTIDADE DE REQUISITOS

Ponto de função aponta claramente o conceito de processo elementar que representa um “requisito”

do usuário. Isso quer dizer que ele é completo do ponto de vista de usuário, deixa o sistema consistente e a

funcionalidade entregue é reconhecida pelo usuário.

Desta forma, ao fracionar demais os requisitos várias funcionalidades são quebradas em partes que

sozinhas não tem valor de negócio algum, o que pode levar a um desentendimento sobre o “processo

elementar”.

Por exemplo, uma funcionalidade solicitada pelo usuário que é composta por 3 passos, realizadas

em momentos diferentes por pessoas diferentes, provavelmente será um ÚNICO requisito pois se mostra

como um único processo elementar que só faz sentido se os 3 passos forem dados. Assim, tanto faz

realizar 0, 1 ou 2 passos, para o usuário aquela parte não concluída é irrelevante.

Seguindo o exemplo anterior, suponha que a função é uma SE complexa (Que custa 7 PF) poderia

ser quebrada em 2 EE simples (3 pontos cada uma) e 1 SE simples (4 Pontos) o que levaria ao total de 10

PF, 3 Pontos mais caro em uma única funcionalidade. Então identificar o processo elementar é um passo

mais importante do que identificar requisitos e fluxo de serviços.

7.1.2. ATENÇÃO A REQUISITOS NÃO FUNCIONAIS

O Ponto por Função mede software de acordo com seu tamanho funcional (Requisitos funcionais) e

os requisitos não funcionais estão com preço “embutido” dentro do ponto de função (Ver a parte de

precificação na seção de considerações para a contagem). Então certos cuidados ao solicitar melhorias não

funcionais devem ser observados.



Por exemplo, um caso recente que houve na ATI, se tratava de um sistema que criava e gerenciava

documentos. Só que para motivos de usabilidade, foi solicitado que dois tipos especiais de documentos

fossem criados e gerenciados (Atas de Registro de Preço e Licitações). Esta solicitação visou o ganho de

tempo da criação de atas e licitações bem como preparar o sistema para trabalhar com estes dois modelos.

Desta forma, os dois tipos de documentos solicitados foram a criação do produto final do sistema,

criação de documentos, e não novas funcionalidades. Ou seja, um usuário do sistema poderia ter criado o

documento tipo Ata e o documento tipo Licitações e disponibilizar para o estado sem o ônus.

Parece pouca coisa, mas a interferência no sistema, uma vez que as atas e licitações eram

gerenciadas como quaisquer documentos, mas em locais específicos, o que tornou o sistema 40% maior do

que o necessário, implicando em aumento nos custos.

Então é pedido atenção neste aspecto, e alguns cuidados como solicitar as melhorias não

funcionais para TODO o sistema. Ou seja, se é necessário que um requisito de segurança seja aplicado em

uma transação, solicitar que este requisito seja estendido a todo sistema. Isso pode baratear o produto.

7.1.3. ATENÇÃO A RELATÓRIOS

Os relatórios são um dos pontos mais problemáticos em pontos de função uma vez que é

relativamente comum aparecer em um sistema relatórios parecidos, mas que são “diferentes” nos dados em

que apresentam. Isso significa que novas funcionalidades (Consultas ou Saídas Externas) surgem a cada

novo relatório e que relatórios parecidos significam funcionalidades diferentes embora parecidas.

Então neste ponto é recomendada a junção de vários relatórios parecidos em um único relatório que

atende a todas as demandas. Isto significa uma redução não só do pagamento, mas do tamanho do sistema

uma vez que manutenções no sistema ocorrerão uma vez só.

7.2. DICAS NA DEFINIÇÃO DA FRONTEIRA

A fronteira determina o que é interno e externo para uma aplicação, de acordo com a visão do

usuário, sendo de fundamental importância na medição funcional. Um erro nesta atividade pode ocasionar

duplicidade na identificação de funções, identificação incorreta ou até sua omissão. Em muitos casos isto

reflete no aumento da contagem, trazendo prejuízo para a instituição.

Seguem algumas dicas que podem auxiliar na identificação da fronteira:

• A fronteira deve ser delineada de uma perspectiva de negócio, não devendo levar em

consideração detalhes técnicos ou de implementação.



• Obtenha uma documentação do fluxo de dados do sistema e desenhe uma fronteira em

volta para destacar quais partes são internas e externas à aplicação.

• Verifique como a aplicação é gerenciada; se é desenvolvida ou mantida em sua totalidade

ou em partes por equipes distintas.

• Verifique se há usuários distintos especificando requisitos para cada parte do software. Isto

pode representar fronteiras entre os sistemas.

• Identifique áreas funcionais atribuindo propriedade a certos tipos de objetos, como

entidades e processos.

• Documente previamente as fronteiras de todas as aplicações que poderão ser objeto de medição.

7.3. DICAS NA IMPLANTAÇÃO DO PROCESSO

A utilização de pontos de função na contratação de desenvolvimento de software têm crescido

bastante no mercado brasileiro. Entretanto este processo ainda não atingiu sua total maturidade. Por isso,

algumas empresas encontram dificuldade na utilização da técnica e acabam sendo mal sucedidas em seus

projetos. Seguem algumas dicas que podem minimizar ou até evitar problemas na implantação deste

processo:

• Capacitação: conhecer corretamente a técnica de pontos de função é fundamental. Embora

seja óbvio, observa-se que muitas organizações erram neste passo básico.

• Estabelecer objetivos iniciais modestos: começar com um projeto piloto em um sistema

simples. Avaliar os resultados, efetuar as correções necessárias, revisar os objetivos e

seguir em frente.

• Esteja ciente das limitações da técnica: Existem domínios de problema em que a APF

não é indicada. Por exemplo, em sistemas de otimização a técnica não é adequada para

medir as partes com alta complexidade algorítmica. A técnica também não é recomendada

para estimativa de projetos muito pequenos (< 100) ou atividades pontuais, pois pode haver

distorções significativas.

• Busque ajuda se necessário: Uma consultoria externa pode evitar "cabeçadas

desnecessárias" e agilizar o processo, trazendo experiências e ajudando a corrigir rumos.

Também existe um grupo de usuários muito ativo no Brasil, o BFPUG (Brazilian Function

Point Users Group) que possui um fórum de discussão ideal para este objetivo.



• Cuidado com os conflitos de interesse: a medição do serviço em pontos de função nunca

deve ser realizada somente pelo fornecedor, pois ele será remunerado justamente pelo

resultado da medição! Observa-se esta prática indesejável em algumas organizações

(inclusive públicas). Pode-se utilizar pessoal interno para realizar a medição, ou na pior das

hipóteses validar por amostragem as medições realizadas. Outra opção é contratar uma

empresa externa para este serviço.

• Esteja atento ao preço do ponto de função: este item é tão importante que vale abordá-lo

em mais detalhes.

8. CONSIDERAÇÕES SOBRE A CONTAGEM DE PONTOS DE FUNÇÃO

Esta seção apresenta considerações especiais sobre o dimensionamento em Pontos de Função de

mudança de requisitos, projetos cancelados e redução de cronograma. E sugere métricas para o

dimensionamento de atividades de negócio.

8.1. CONSIDERAÇÃO SOBRE MUDANÇAS DE REQUISITOS

Em projetos de desenvolvimento e manutenção de software é bastante comum as mudanças de

requisitos no decorrer do projeto, conforme o usuário e o desenvolvedor adquirem mais conhecimento sobre

o negócio [Sommerville, 2007]. O CPM denomina este fenômeno de Scope Creep. Como os requisitos não

podem ser congelados, então temos que gerenciá-los de forma efetiva.

Nas estimativas iniciais de tamanho de projetos de desenvolvimento, após a fase de especificação,

considerando-se o documento de visão inicial do projeto, recomenda-se utilizar um percentual para

evolução de requisitos de 30% a 40%. Nas estimativas, após a fase de requisitos, utilizando-se como

insumo as especificações de casos de uso, deve-se considerar um percentual de 20% a 30%.

Por exemplo, suponha que após a análise do Documento de Visão de um Projeto, aplicando-se a

CEPF, foi obtido o tamanho de 200 PFs, então o tamanho estimado do projeto considerado é de 270 PFs

(200 + 35%), utilizando-se a premissa de evolução de requisitos em 35%. Esta premissa deve ser

documentada.

Uma mudança de requisito gera retrabalho da equipe de desenvolvimento, aumentando assim o

esforço e o custo do projeto. Por exemplo, suponha um relatório de clientes em que no final da fase de

implementação foi solicitada a exibição de uma nova informação. A equipe de desenvolvimento terá um

retrabalho de várias fases do ciclo de vida. Para tratar o dimensionamento das mudanças de requisitos

torna-se importante definir a distribuição de esforço pelas macroatividades do projeto, visando definir o valor

agregado ao projeto após cada fase do ciclo de vida.



A Tabela 6 na Seção 3.2 estabelece os percentuais por atividade de forma a permitir a contagem de

mudança conforme o estágio do projeto. Esta distribuição percentual de pagamento deve ser definida no

contrato de software.

Por exemplo, suponha um relatório de clientes em que no final da fase de implementação foi

solicitada a exibição de uma nova informação. A equipe de desenvolvimento terá um retrabalho de várias

fases do ciclo de vida. Assim, o tamanho dessa mudança deve ser calculado da seguinte maneira:

Tamanho do relatório de clientes (original) – SE – M – 5 PF

Tamanho do relatório de clientes (alterado) – SE – M- 5 PF

O requisito alterado será considerado 100% do PF, supondo que este será entregue ao cliente sem

passar por novas alterações. Para o requisito original será considerado o seguinte:

Engenharia de Requisitos 25%

Design, Arquitetura 15%

Implementação 40%

Assim, o tamanho da mudança é de 4 PFs (5 PF x 80% = 4 PFs).

É importante alertar o cliente sobre o impacto das solicitações de mudança no esforço, prazo e

custo do projeto. Uma boa forma de apresentar esses valores é fazer uma nova estimativa com base nas

alterações e verificar a variação em termos percentuais (estimativa inicial x nova estimativa). Assim o cliente

ficará ciente e poderá adequar suas expectativas de prazo e custo, ou então, poderá reavaliar as alterações

solicitadas de acordo com as reais necessidades do negócio.

8.2. CONSIDERAÇÃO SOBRE PROJETOS CANCELADOS

Em alguns casos, devido às mudanças no ambiente do cliente, uma demanda ou parte de um

projeto de desenvolvimento ou manutenção pode ser cancelado pelo cliente ou fornecedor. Nestes casos, o

tamanho funcional do que foi cancelado será aferido por meio da contagem de Pontos de Função das

funcionalidades canceladas e um Fator de Impacto.

O Fator de Impacto é definido com base no percentual de esforço alocado a construção da

funcionalidade em questão, observando as tabelas de distribuição de esforço contidas na Seção 3.2 ou

alguma diretriz específica de distribuição de esforço do contrato em questão.

O Fator de Impacto deve ser aplicado na contagem de Pontos de Função das funcionalidades em

questão. É importante ressaltar que em um processo de desenvolvimento incremental uma funcionalidade

pode, por exemplo, estar em fase de requisitos e de testes, porque o plano de testes é construído na fase



de requisitos. O Progresso das atividades executadas em cada funcionalidade do projeto deve ser obtido

por meio do acompanhamento do plano do projeto.

Este fator de impacto pode ser desconsiderado quando o cancelamento vem por parte do

fornecedor, sendo assim não será pago o que não foi entregue, e vale lembrar que este fator de impacto

pode ser substituído por multas em SLAs no edital.

8.3. CONSIDERAÇÕES SOBRE REDUÇÃO DE CRONOGRAMA

As estimativas de prazo não são lineares com o tamanho do projeto, assim pretende-se pesquisar

mais sobre o melhor tempo desenvolvimento (onde há uma melhor relação custo x benefício de alocação de

recursos e menor prazo de desenvolvimento), dado o tamanho de um projeto específico. Jones [Jones,

2007] propõe uma fórmula para o cálculo do melhor tempo de desenvolvimento, descrita na seção 3.3.

Alguns projetos devido à legislação e a outros fatores externos a ATI possuem um prazo imposto

pelo cliente. Se este prazo for igual ou superior ao prazo calculado pela Fórmula de Capers Jones (2007)

(expoente t) ou em caso de projetos pequenos (menores que 100 PF) ainda se faz necessário calcular o

prazo Máximo de entrega.

No entanto, se o projeto tiver um prazo imposto pelo cliente inferior ao prazo calculado, então se

deve considerar como risco de projeto.

Deve-se ressaltar que não é possível uma redução de prazo maior que 25 %, devido aos cálculos

de Região Impossível e ainda conforme nos aproximamos da região impossível, o esforço e o custo do

projeto aumentam de maneira exponencial.

Como os riscos da redução de cronograma também são altos, não é recomendada a redução de

cronograma. Deve-se tentar priorizar funcionalidades trabalhando com o ciclo de vida incremental. Caso o

contrato seja baseado em preço por Pontos de Função, este aumento de esforço será refletido na contagem

de PF.

8.4. CONSIDERAÇÕES SOBRE A PRECIFICAÇÃO

Nesta seção serão tratados aspectos referentes a precificação do ponto de função, apresentando os

fatores que influenciam no preço e que devem ser considerados na definição dos critérios de contratação

dos serviços de desenvolvimento e manutenção de software. Também serão apresentados alguns

exemplos onde os requisitos não funcionais e as características do projeto podem aumentar

significativamente o esforço de desenvolvimento, elevando assim os custos e o preço médio do ponto de

função.



8.4.1. Tamanho Funcional x Esforço de Desenvolvimento

Embora exista uma forte relação entre o tamanho funcional de um software (medido em Pontos de

Função) e o esforço gasto no seu desenvolvimento (medido em pessoas-hora), os Pontos de Função não

medem diretamente o esforço de desenvolvimento. Nesse sentido, os Pontos de Função são semelhantes

ao metro quadrado na construção civil: embora o metro quadrado influa consideravelmente no esforço de

construção e no custo de um imóvel, outros fatores poderão contribuir tanto ou mais quanto o metro

quadrado.

Exemplos de fatores são a localização do imóvel, a idade, o material utilizado na construção e

acabamento, o prestígio do arquiteto, etc. Da mesma forma, dois sistemas podem ter a mesma medida em

Pontos de Função e preços totalmente diferentes. Por exemplo, um sistema pode ser monousuário,

implementado em uma ferramenta como o Access; o outro pode ser uma aplicação web com várias

camadas, envolvendo um mainframe e sofisticados dispositivos de segurança. Neste caso, certamente a

quantidade de horas e o preço de cada um desses sistemas será completamente diferente.

A conclusão é que o tamanho em Pontos de Função é apenas um dos fatores que influem sobre o

esforço de desenvolvimento e sobre o custo de um sistema. Outros fatores importantes são a confiabilidade

desejada para o software, a metodologia de desenvolvimento utilizada, o nível de testes requerido, a

complexidade dos algoritmos, a dificuldade da plataforma computacional, o estilo de interface com o

usuário, o grau de reutilização desejado, a capacidade e experiência da equipe, a disponibilidade de

ferramentas de software adequadas e outros.

8.4.2. Valor do Ponto de Função

O valor R$/PF irá variar de acordo com o trabalho exigido para a entrega das funcionalidades do

software levando em consideração o padrão técnico e de qualidade solicitada pelo cliente, como também a

quantidade de entregáveis (artefatos, documentos, modelos, etc) exigidos. Em resumo, tudo aquilo que

afeta custo de forma significativa, mas que não tem relação direta com o tamanho medido pela APF acaba

sendo computado no preço do ponto de função.

Exemplo 1: ao se contratar uma empresa apenas para o trabalho de codificação e testes de um

sistema espera-se que o preço do ponto de função seja inferior ao caso da contratação da mesma empresa

para a realização de todo o ciclo de desenvolvimento do sistema, desde o levantamento de requisitos até a

implantação.

Exemplo 2: o preço do ponto de função para a entrega apenas do software certamente é inferior ao

preço do ponto de função onde, além do software, devem ser entregues vários documentos (subprodutos)

como: modelos da UML, manual de usuário, ajuda on-line, protótipos, casos e planos de testes, etc.

Exemplo 3: atualmente a gama de tecnologias disponíveis para desenvolvimento de sistemas é

enorme, cada uma delas podendo influenciar diretamente na produtividade (tanto positivamente quanto



negativamente) do trabalho a ser realizado. Sendo assim é bastante comum no mercado a a diferenciação

do R$/PF de acordo com a plataforma tecnológica (mainframe, web, cliente-servidor, etc) e/ou linguagem de

programação (cobol, C, java, .net, etc).

Exemplo 4: A APF, segundo o padrão IFPUG, mede manutenções desconsiderando o tamanho da

manutenção que a função sofrerá. Geralmente o esforço para se manter uma função costuma ser inferior ao

de se desenvolvê-la. Sendo assim, pode haver diferenciação de preço do ponto de função em projetos de

melhoria para funcionalidades novas, alteradas e excluídas.

Exemplo 5: ao se contratar uma empresa de desenvolvimento de sistemas estabelecendo SLAs

(acordos de níveis de serviços) muito rígidos, relacionados à produtividade da equipe e qualidade do

produto, é de se esperar um preço do ponto de função superior ao de um contrato com um menor nível de

exigências.

Em resumo, não existe um preço único para ponto de função bem como não há atualmente uma

tabela de preços disponível publicamente onde se possa consultar valores para o preço do ponto de função.

Até mesmo porque esta é uma informação considerada reservada ou estratégica para muitas organizações.

Porém é possível obter informações de preço dos contratos governamentais através de uma pesquisa nas

licitações ocorridas, no diário oficial ou diretamente com o órgão do governo.

Outra possibilidade para se obter essa tabela de preços é recorrer às organizações que mantém

base histórica de projetos de software (exemplo: ISBG - www.isbsg.or) e efetuar uma conversão dos

indicadores de taxa de entrega (H/PF) para preço (R$/PF). Porém mesmo que se consiga obter uma tabela

de valores R$/PF, a variação dos números é tão significativa que facilmente se encontra uma faixa de

valores cuja variação entre o mínimo e o máximo pode ser de até 10 vezes, por exemplo, de R$100/PF a

R$1.000/PF.

Para obter uma informação mais realista do preço (ou custo) do PF é melhor buscar isto

internamente nos projetos já realizados. Para projetos já concluídos uma informação certamente disponível

é o quanto se pagou ou se cobrou por cada projeto e quais atividades estavam compreendidas. Caso o

tamanho funcional (PF) dos projetos não esteja disponível, pode-se obtê-lo rapidamente através de uma

medição ou de uma estimativa; basta analisar seus requisitos. Tendo o preço do projeto e o seu tamanho

em pontos de função, obtém-se o seu preço por ponto de função (R$/PF). No entanto é provável que sua

organização empreenda projetos de diferentes tipos. Neste caso deve-se proceder a análise do R$/PF para

cada categoria de projetos, pois dificilmente um preço único será representativo para projetos de tipos

distintos.

8.4.3. Preço Ideal do Ponto de Função na APE

No contexto das instituições públicas encontramos um cenário onde é necessário contratar serviços

de desenvolvimento e manutenção para vários projetos, muitas vezes de naturezas diferentes, de acordo



com o planejamento estratégico e as diretrizes do governo. Porém, não é viável que as instituições realizem

uma contratação específica para cada projeto, devido aos altos custos de um processo licitatório, bem

como, a complexidade técnica de se gerenciar vários contratos de pequeno porte.

Por isso, uma boa prática que vem sendo adotada na APE é que projetos de características

semelhantes sejam atendidos por uma mesma contratação, salvo aqueles cuja natureza estratégica ou o

grande porte prescindam de uma contração específica. Desta forma, podemos obter alguns benefícios

como um maior controle dos projetos, através de uma gestão centralizada, e a redução de custos, através

de um maior volume de serviços contratados e também pela diminuição de processos licitatórios na APE.

Porém, é importante observar que, em se tratando de projetos de características diferentes,

dificilmente poderemos chegar a um preço ideal do ponto de função sem que haja grandes distorções. Isto

ocorre por conta do nível de esforço exigido em cada projeto, que acaba influenciando diretamente no preço

cobrado pelo fornecedor. Então, se não houver um planejamento eficaz da contratação, corremos o risco de

que os projetos mais simples saiam muito caros para a instituição, enquanto os projetos mais complexos

saiam de grande prejuízo para o fornecedor.

Para minimizar este problema, recomenda-se que os projetos de características similares (processo,

tecnologia, requisitos não funcionais, requisitos de qualidade, SLAs) sejam agrupados em categorias que

deverão ser licitadas separadamente (lotes diferentes de preço). Se observarmos estes projetos em um

nível macro perceberemos que as situações extremas se compensam e, em média, existe uma maior

linearidade na relação entre o esforço e o tamanho funcional, permitindo que o fornecedor estabeleça um

preço médio justo para ambas as partes.

O objetivo é manter o equilíbrio financeiro entre instituição x fornecedor num conjunto de projetos

realizados durante o período do contrato, numa relação que represente vantagem para ambos os lados.

Seguem alguns critérios de similaridade que causam impacto no esforço e podem ser utilizados para

categorização de projetos:

Aspectos não funcionais;

Complexidade e lógica de processamento;

Requisitos de disponibilidade e performance;

Mix de tecnologias envolvidas;

Processo de desenvolvimento utilizado;

Tamanho – ordem de grandeza – do projeto;

Artefatos construídos;

Nível de exigência dos Acordos de Níveis de Serviço;

Além de categorizar os projetos é importante manter uma base histórica de indicadores de esforço e

custo. Os indicadores devem estar associados aos objetivos estratégicos da instituição e devem ser

coletados e acompanhados de forma sistemática. Podemos citar como exemplo a taxa de entrega (H/PF) e



o preço (R$/PF), que podem ser obtidos através de quanto se cobrou por cada projeto, a quantidade de

horas de trabalho reportada e quantos pontos de função foram entregues no período.

Estes números são de grande importância, pois refletem a experiência da própria organização nos

projetos medidos em pontos de função, podendo ser usados para acompanhamento dos contratos, melhoria

das estimativas, referências para futuras contratações e como base de comparação com outras instituições.

Desta forma, as instituições podem aproveitar as lições aprendidas para calibração do preço do ponto de

função, obtendo assim um valor mais adequado a sua realidade.

8.4.4. Considerações

Através dos exemplos podemos perceber o impacto direto do esforço de desenvolvimento sobre o

preço do ponto de função. Desta forma, é de extrema importância que os requisitos para contratação de

serviços sejam bem definidos, de acordo com as características dos projetos e baseados nas necessidades

dos clientes, para que a instituição não sobrecarregue o fornecedor com exigências que não agregarão

valor ao projeto e que, com certeza, irão aumentar o preço cobrado por ponto de função.

Por outro lado, a instituição não pode ser omissa na hora de estabelecer os critérios de contratação

buscando um menor preço, pois isso acarretará em baixa qualidade de serviços e insatisfação do cliente. A

melhor alternativa é buscar equilíbrio entre estes fatores, garantindo assim melhores contratações, bem

como, um melhor relacionamento entre contratante e contratada.

Uma iniciativa neste sentido foi a ata de registros de preço para desenvolvimento de sistemas em

pontos de função, elaborada pela ATI em outubro de 2010, cujos serviços foram divididos em lotes de

acordo com a tecnologia utilizada (JAVA Demoiselle, JAVA MakerAll e Dot Net).

Para esta contratação a ATI realizou um levantamento dos fatores necessários para a maioria dos

projetos de governo, como aderência a arquitetura padrão do estado, atividades do ciclo de vida de projetos

e SLAs de qualidade e produtividade. Estes fatores influenciam diretamente no esforço, por isso foram

incluídos no edital para formação do preço do ponto de função. Estima-se que esta primeira contratação

trouxe uma economia para a ATI algo em torno de 4.000.000 (Quatro Milhões) de R$

Desta forma, as instituições da APE que tiverem interesse poderão aderir a esta ata para

atendimento de suas demandas, garantindo assim os níveis de qualidade e produtividade padrão do

governo, desde que estes níveis atendam as necessidades de seus projetos. Além disso, estarão

respeitando os princípios da economicidade e eficiência, evitando os custos e a longa duração de um novo

processo licitatório, além da economia de escala no preço do ponto de função para um maior volume de

serviços.



Além disso, é fundamental que as instituições mantenham uma base histórica de indicadores dos

projetos para melhoria contínua das estimativas e controle das contratações. Isso vai refletir em resultados

positivos para a instituição e, conseqüentemente, melhores serviços para o cidadão.

8.5. CONSIDERAÇÕES SOBRE CICLO DE VIDA ITERATIVO INCREMENTAL

Segundo experiências obtidas pela própria ATI a soma das partes pode ser maior do que o todo. Ou

seja, se a ATI recebe de um fornecedor 3 Iterações de 300 Pontos não necessariamente o produto final

conterá 900 pontos.

Será necessário para a ATI identificar em cada um dos seus editais a compensação de ao fim das

iterações recuperar a diferença do tamanho do sistema (final) e da soma das partes que deve ser maior.

8.6. COMO UMA EMPRESA PÚBLICA PODE SE FILIAR AO IFPUG.

O que um órgão do governo deve fazer para obter a filiação ao IFPUG?

Normalmente as maiores dúvidas dizem respeito ao pagamento da filiação, que deve ser feito em

dólares no exterior. Contudo vários órgãos estaduais, federais e empresas estatais já se filiaram e

permanecem filiados. Os passos irão variar um pouco dependendo do órgão, mas basicamente são:

1. Dirigir-se à área de compras, suprimentos ou filiações a associações, com uma solicitação devidamente embasada, justificando a necessidade de filiação ao IFPUG. Ressaltar que o único fornecedor dos serviços almejados é o IFPUG (por exemplo, para ter acesso ao CPM e realizar o exame CFPS o IFPUG é a única fonte).

2. Aprovado o pedido, a área de compras provavelmente solicitará ao IFPUG uma invoice (fatura, ou

instrumento de cobrança) que servirá de base ao pagamento e especificará o valor a ser pago. A invoice pode ser solicitada via e-mail ao escritório do IFPUG, tendo-se o cuidado de enviar ao IFPUG todos os dados necessários à identificação do órgão: razão social, endereço, CNPJ, etc. Orientar o escritório do IFPUG sobre a necessidade de colocar todos os dados na invoice. Normalmente a invoice virá através de e-mail.

3. Recebida a invoice, a área de compras estará ciente do valor a ser pago (conforme o tipo de filiação

solicitado) e dos dados bancários do IFPUG para remessa do dinheiro. Nesta data (10 de Dezembro de 2010) esses dados são:

International Function Point Users Group 191 Clarksville Rd. Princeton Junction, NJ 08550 Sovereign Bank 44 Princeton Hightstown Rd Princeton Jct., NJ 08550 877-768-1145 ABA # 231372691 Account # 0741078090 Amount:______________ Swift Code: SVRNUS33



Notar que o campo Amount (valor) acima deve ser preenchido com o valor da filiação acrescido de US$ 50.00 (cinquenta dólares norte-americanos), correspondentes à taxa de remessa internacional cobrada pelo banco e repassada ao filiado pelo IFPUG.

4. De posse dos dados bancários acima, um funcionário do órgão deve ir a uma agência do Banco do

Brasil, que realizará o serviço de remessa eletrônica ao exterior. Este serviço é uma operação de câmbio, devendo existir uma taxa cobrada pelo BB e possivelmente impostos. Efetuada a remessa, o BB fornecerá um comprovante em reais, que será contabilizado pelo órgão. Dessa forma, não existirá contabilmente uma operação em dólar no órgão, mas sim um pagamento em reais ao BB (esta é uma dúvida que costuma surgir - alguns colegas dizem "Meu órgão não pode realizar pagamentos em dólares", mas isto não deve constituir impeditivo, já que o fato contábil será registrado em reais).

5. Realizada a transferência, uma cópia do comprovante fornecido pelo BB deverá ser enviada via fax

ou e-mail ao IFPUG, juntamente com o formulário de filiação que pode ser baixado de http://www.ifpug.org/membership/membershipApplication.pdf (ver http://www.ifpug.org/membership/). Notar que o nome do órgão deverá aparecer exatamente da mesma maneira no comprovante do BB e no formulário de filiação - não colocar, por exemplo, Agência Estadual de Tecnologia da Informação em um documento e ATI no outro, etc.).

6. Tudo isto feito, os contatos constantes do formulário de filiação receberão um e-mail de confirmação

com identificação de usuário e senha para acesso à área de filiados do site do IFPUG. Notar que este retorno pode levar mais de uma semana. Se demorar demais, enviar ao IFPUG uma mensagem em inglês solicitando explicação.

7. A filiação ao IFPUG vence sempre no dia 30 de junho de cada ano, independentemente da época da filiação. Um indivíduo ou organização que se filie ao IFPUG como Regular Member entre primeiro de maio e 30 de junho de qualquer ano pagará o preço normal da filiação. Contudo, tal indivíduo ou organização terá sua filiação estendida até 30 de junho do ano seguinte. Ou seja, é bom ter cuidado em quando realizar a filiação.

8.7. CERTIFICAÇÃO CFPS

O Exame CFPS - Administrado pela Prometric - acesse http://www.prometric.com,CFPS - Certified

Function Point Specialist - é a certificação conferida pelo International Function Point Users Group às

pessoas aprovadas no exame de certificação CFPS.

É necessário ser filiado ao IFPUG para obter e manter a certificação CFPS. A certificação CFPS é

reconhecida internacionalmente e é válida por até 3 (três) anos. A partir de julho de 2003, a certificação é

conferida por 1 (um) ano e revalidada anualmente, por até 3 anos, enquanto a pessoa permanecer filiada ao

IFPUG.

A interrupção da filiação implica na perda da certificação. Após 3 anos, é necessário fazer novo

exame (a menos que a pessoa utilize o programa de recertificação, ainda não implantado fora dos E.U.A.).

O custo do exame é U$250, pagos diretamente à Prometric, empresa que realiza o exame.

É possível confirmar se uma pessoa detém a certificação CFPS através de consulta ao IFPUG,

enviando um e-mail a [email protected]. ou consultando no site do IFPUG.

http://www.ifpug.org/membership/membershipApplication.pdf

mailto:[email protected]



A certificação é a garantia de que o profissional entende e utiliza corretamente as regras do IFPUG

para a contagem de pontos de função. Todos os profissionais de APF (Análise de Pontos de Função)

devem buscar a certificação.

9. PROCESSO DE REVISÃO DO GUIA DE CONTAGEM

9.1. REVISÃO PARA CORREÇÃO DE INCONSISTÊNCIAS E SITUAÇÕES NÃO PREVISTAS

A revisão deste guia será feita sempre que a ATI, clientes e fornecedores verificarem

inconsistências entre uma definição do CPM e uma regra constante deste documento e situações não

previstas neste guia. Para situações não previstas neste guia, dever-se-á recorrer à equipe de contagem do

cliente e a coordenação da área de métricas da USG-GND da ATI que decidirão pela atualização deste guia

ou do contrato.

9.2. REVISÃO PARA ADOÇÃO DE NOVAS VERSÕES DO CPM

A adoção de nova versão do CPM como referência para este Guia de Contagem não será imediata

à sua publicação. Nesse caso deverá haver uma avaliação da nova versão pela ATI para se decidir sobre a

atualização do guia.

10. CONCLUSÃO

Este documento apresentou um guia para o dimensionamento de tamanho de todos os tipos de

projetos de software desenvolvidos pela ATI seguindo as diretrizes da Instrução Normativa – IN04. A

estimativa de tamanho utiliza a métrica de Pontos de Função Não Ajustados como unidade de medida,

conforme recomendado nos Acórdãos do Tribunal de Contas da União (TCU).

Como trabalho futuro recomenda-se a revisão e atualização deste roteiro sempre que se verificar

inconsistência entre alguma definição do IFPUG, seja publicada em versões futuras do CPM ou em White

Paper, ou quando for detectado um novo tipo de serviço associado ao desenvolvimento de software não

previsto neste trabalho.

REFERÊNCIAS BIBLIOGRAFIAS

[Hazan, 2008] HAZAN, C. Análise de Pontos de Função: Uma Aplicação nas Estimativas de

Tamanho de Projetos de Software. Engenharia de Software Magazine, Edição 2, Editora

Devmedia, pp.25-31. (2008).



[IEEE,1998] IEEE Computer Society. IEEE Standard for Software Maintenance. IEEE Std 1219,

(1998).

[IFPUG, 2007] IFPUG. Function Points & Counting Enterprise Data Warehouses. Release 1.0,

September, (2009).

[IFPUG, 2009] IFPUG. Considerations for Counting with Multiple Media. Release 1.0,

September, (2009).

[IFPUG, 2010] IFPUG. Counting Practices Manual. Version 4.3, January, (2010).

[Jones, 2007] JONES, C. Estimating Software Costs. Second Edition, McGraw Hill, (2007).

[NESMA, 2009] NESMA. Function Point Analysis for Software Enhancement Guidelines.

Version 2.2.1, (2009).

[Serpro, 2010] SERPRO. Roteiro de Contagem de Pontos de Função. (2010).

[Sommerville, 2007] SOMMERVILLE, I. Software Engineering. Pearson Education Limited, 8th

Edition, (2007).

[TotalMetrics, 2004] TotalMetrics. Levels of Function Point Counting. (2004).

Guia de Contagem APF Versão 1 - compras.pe.gov.br · Cadastro de usuários e grupos ......

Documents

Transcript of Guia de Contagem APF Versão 1 - compras.pe.gov.br · Cadastro de usuários e grupos ......