Guia de Contagem APF Versão 1.00 - RedeCompras

Transcrição

Guia de Contagem APF
Versão 1.00
HISTÓRICO DE REVISÕES
Data
20/11/2010
Versão
1.00
Descrição
Criação do Guia de Contagem APF
Guia de Contagem APF ATI – www.ati.pe.gov.br
Autor
Célio Santana / Gustavo
Santos
Pág. 2 de 65
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
Pág. 3 de 65
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
Pág. 4 de 65
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;
Pág. 5 de 65
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
Pág. 6 de 65
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.
Legenda
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
Etapas
Etapas antes
antes do
do
inicio
inicio da
da Sprint.
Sprint.
Etapas
Etapas Durante
Durante aa
Sprint
Sprint
Identificar demandas que
serão implementadas na
Sprint
Agrupar demandas
ligadas ao mesmo
requisito funcional.
Derivar Custo e Prazo da
entrega baseado no
tamanho funcional.
Realizar contagem
funcional da entrega
realizada pelo fornecedor
Realizar contagem
estimativa de tamanho
funcional da Sprint
Etapas
Etapas Após
Após
Recebimento
Recebimento da
da
Sprint
Sprint
Etapas
Etapas durante
durante aa
transação
transação entre
entre
Sprints
Sprints
Reavaliar Custo e Prazo
da entrega realizada pelo
fornecedor
Base Histórica
Atualizar Base Histórica
do Projeto baseado na
diferenças entre a
estimativa e a Medição
Base Histórica
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.
Pág. 7 de 65
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.
Pág. 8 de 65
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.
Pág. 9 de 65
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
Pág. 10 de 65
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).
Pág. 11 de 65
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, devese 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]
Pág. 12 de 65
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]
Pág. 13 de 65
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.
Pág. 14 de 65
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:
Pág. 15 de 65
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
Pág. 16 de 65
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
Pág. 17 de 65
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)
Sistema Comum – Web ou Cliente Servidor
Sistema OO (se o projeto OO não for novidade para
equipe, não tiver o desenvolvimento de componentes
reusáveis, considerar sistema comum)
Sistema Cliente/Servidor (com alta complexidade
arquitetural e integração com outros sistemas)
Sistemas Gerenciais complexos com muitas integrações,
Datawarehousing, Geoprocessamento, Workflow
Software Básico, Frameworks, Sistemas Comerciais
0,32 a 0,33
0,34 a 0,35
0,36
0,37
0,39
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
Pág. 18 de 65
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.
Pág. 19 de 65
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
Pág. 20 de 65
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 é:
Pág. 21 de 65
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]
PFD
Fator de
Impacto (FFD)
Fator de Impacto em Funções de Dados Alteradas (FFD)
Entre 33% e
Entre 66% e
Entre 0 e 33%
66%
100%
0,25
0,5
Maior que
100%
0,75
1
Funções Transacionais:
Percentual de alterações em funções transacionais (PFT1) = QTDEA / QTDET x 100
Pág. 22 de 65
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
Maior que 100%
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:
Pág. 23 de 65
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á
Pág. 24 de 65
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,
Pág. 25 de 65
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
Pág. 26 de 65
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
Pág. 27 de 65
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,
Pág. 28 de 65
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.
Pág. 29 de 65
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]:
Pág. 30 de 65
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
Pág. 31 de 65
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
Pág. 32 de 65
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.
Pág. 33 de 65
É 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
Pág. 34 de 65
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.
Pág. 35 de 65
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:
Pág. 36 de 65
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
Pág. 37 de 65
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:
Pág. 38 de 65
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
Pág. 39 de 65
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
Pág. 40 de 65
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.
Pág. 41 de 65
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:
Pág. 42 de 65
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
Pág. 43 de 65
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
Pág. 44 de 65
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
Pág. 45 de 65
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.
Sistema Legado
Aplicação Externa
BPMS
Processo
automatizado
Interface de
Integração
Interface de
Integração
Sistema Legado
Aplicação Externa
Processo
automatizado
Processo
automatizado
Interface de
Integração
Interface de
Integração
Sistema Legado
Aplicação Externa
Pág. 46 de 65
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.
Pág. 47 de 65
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.
Pág. 48 de 65
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.
Pág. 49 de 65
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.
Pág. 50 de 65
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
Pág. 51 de 65
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.
Pág. 52 de 65
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.
Pág. 53 de 65
•
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.
Pág. 54 de 65
•
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.
Pág. 55 de 65
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
Pág. 56 de 65
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.
Pág. 57 de 65
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
Pág. 58 de 65
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
Pág. 59 de 65
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
Pág. 60 de 65
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.
Pág. 61 de 65
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
Pág. 62 de 65
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.
Pág. 63 de 65
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).
Pág. 64 de 65
[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).
Pág. 65 de 65

Guia de Contagem APF Versão 1.00 - RedeCompras

Transcrição

Documentos relacionados

Caso16_2003 # Fonte informação Al-Mashari, M. and Al

Mundo Seguinte - Informática, Lda. Comércio e Serviços

HEMOGRAMA COMPLETO

Regulamento: Comemore seu aniversário no Restaurante Paulista.

requerimento para contagem de tempo de serviço

TOTALIZADOR DIGITAL DE IMPULSO

inventário físico

Genérico Gradiente GX1 Strike, GX2 Concept

Prefeitura Municipal de Contagem

OFERTA PORTOGHESE HL45 dicembre 2012