medida de esforço de software com análise de ponto de função

ANÁLISE DE PONTO DE FUNÇÃOMEDIDA DE ESFORÇO PARA

DESENVOLVIMENTO DE SOFTWARE

https://www.facebook.com/alvarofpinheiroaulas/br.linkedin.com/in/alvarofpinheiro/

http://www.alvarofpinheiro.eti.br

MEDIDA:A medição é a atividade básica de qualquer

engenharia e não seria diferente para a engenharia

de software, porém como esse campo é muito

ressente, está longe de desenvolver uma medição

padrão que seja amplamente aceita e

principalmente, tenha elementos para seus cálculos

que não sejam baseados em fatores subjetivos.

Conseqüentemente a comunidade de TIC possui

muitas críticas sobre as medições hoje utilizadas e

muita discordância sobre o que medir e como avaliar

os resultados obtidos dessas medições.


MÉTRICA:As métricas de software servem para realizar a

tarefa fundamental do gerenciamento de projetos

que é o planejamento.

É com uma métrica que se pode identificar a

quantidade de esforço necessário para o

desenvolvimento, o custo para tal e o prazo para

entrega dos artefatos.


MÉTRICA:As métricas de software sob o ponto de vista de MEDIÇÃO são divididas em duas categorias: medidas diretas e indiretas.

Medidas Diretas: são compostas por medições que objetivam descobrir o custo para produzir o software, o esforço necessário a ser aplicados ao desenvolvimento ou a manutenção do software, a quantidade de linhas de código produzidas e o total de bugsencontrados.Exemplos: Custo; Esforço; Linhas de Código; Velocidade de Execução; Memória; Número de Bugs; Complexidade Ciclomática.

Medidas Indiretas: utilizam medições mais complexas, pois objetivam verificar a qualidade do software, a funcionalidade, ou a sua capacidade de manutenção, sendo mais difíceis de serem percebidas e avaliadas.Exemplos: Funcionalidade; Qualidade; Complexidade; Eficiência; Confiabilidade; Manutenibilidade.


MÉTRICA:As métricas de software sob o ponto de vista de APLICAÇÃO são divididas em duas categorias: medidas produtividade e qualidade.

Medidas de Produtividade: verificam as saídas do processo de engenharia de software, e tem como objetivo de avaliar próprio processo de desenvolvimento.

Medidas de Qualidade: verificam o quanto o software atende aos requisitos definidos pelo usuário, isto é, a funcionalidade, assim permitem indicar o nível de resposta do software às exigências explícitas e implícitas do cliente, com relação ao que foi definido como qualidade.


TERMINOLOGIAS:MEDIDA: quantidade, dimensão, capacidade ou tamanho do software.

MEDIÇÃO: ato de medir.

INDICADOR: métrica que fornece compreensão dos resultados do software.

MÉTRICA: as técnicas utilizadas para verificar a funcionalidade, a modularidade, a manutenibilidade, etc, e podem ser subclassificadas como ORIENTADAS AO TAMANHO, ORIENTADAS À FUNÇÃO, ORIENTADAS A PESSOAS.


POR QUE MEDIR:Verificar a qualidade do software;

Avaliar a produtividade dos desenvolvedores;

Determinar as vantagens de novos métodos;

Analisar as vantagens de novas ferramentas;

Compor uma base para as estimativas;

Fomentar oportunidades por refatoração;

Justificar aquisições de recursos;

Prever o custo do desenvolvimento;

Estimar o prazo para entrega dos artefatos;

Apoiar o planejamento do escopo do software;

Mensurar os quantitativos de recursos; e

Obter a produtividade dos recursos.


Análise de Ponto de Função (APF):Serve para medir o tamanho funcional de um software dando subsídios para o cálculo da produtividade do desenvolvimento com base na funcionalidade, obrigatoriamente levando em consideração o ponto de vista do usuário e assim avaliando o tamanho e a complexidade do software. Com os pontos calculados pode-se obter as horas necessárias para construção e qual o custo de desenvolvimento.

Esta métrica é mantida pela International Function Point Users Group (IFPUG) que é representada no Brasil pelaBrazilian Function Point Users Group (BFPUG) e tem como uma das principais contribuidoras a Netherlands Software Metrics users Association (NESMA).


APF – O que mede?


Funcionalidade segundo a perspectiva do usuário;

A manutenção evolutiva, adaptativa e corretiva;

Implementação independentemente de tecnologia;

Comparar produtividade entre ambientes (P=PF/Esforço);

Melhorar as estimativas de projetos; e

Criar uma unidade padrão de medida de software.

APF – Como evoluiu?


1965 – Contagem de Linhas de Código Fonte (SLOC);

1979 – Análise de Ponto de Função (FPA);

1979, Allan Albrecht da IBM, conferência da Guide/Share;

1979, Publicação formal da metodologia;

1984, Guideline Productivity Measurement and Estimate;

1986, Grupo Internacional de Usuários de Pontos de Função;

1987, Manual de Práticas de Contagem (CPM);

1994, Grupo da ISO sobre Medidas Funcionais de Tamanho;

1999, Function Point Counting Practices Manual da IFPUG;

2002, Padrão Internacional ISO/IEC 20926;

1993 – Análise de Ponto de Casos de Uso (UCPA);

APF – Quem certifica?


A Certified Function Point Specialist (CFPS) é a certificação

conferida pelo International Function Point Users Group (IFPUG)

às pessoas aprovadas no exame de certificação.

APF – Qual a margem de erro?


Quanto melhor a qualidade da Engenharia de Requisitos

aplicada, isto é, quanto maior tempo for dedicado a elicitação

(levantamento de requisitos) menor será a margem de erros.

APF – Quais as vantagens?


Determinar o tamanho de um software independente que seja

desenvolvimento de um novo ou a compra de um pacote, pois

para saber seu custo e/ou prazo basta contar as funcionalidades;

Apoiar no entendimento dos benefícios de um software para a

organização contando as funcionalidades que especificamente

atendam aos requisitos desejados;

Medir a qualidade e a produtividade de um software;

Fator de normalização para comparação de softwares;

E o principal é calcular os custos dos recursos requeridos para

desenvolvimento ou manutenção do software.

APF – Quais as desvantagens?


É recomendável ter conhecimento aprofundado das

funcionalidades do software para estimar com maior

confiabilidade;

A utilização de pesos para questões subjetivas como os requisitos

não funcionais; e

Existir uma boa base histórica para melhor quantificar.

APF – Sopa de Letras:IFPUG – International Function Point Users GroupBFPUG – Brazilian Function Point Users GroupNESMA – Netherlands Software Metrics users AssociationRF – Requisitos FuncionaisRNF – Requisitos Não FuncionaisPF – Ponto de FunçãoPFNA – Ponto de Função Não AjustadoPFA – Ponto de Função AjustadoFD – Funções de DadosFT – Funções de TransaçãoNI – Nível de InfluênciaNIT – Nível de Influência TotalVFA – Valor do Fator de AjusteVNA – Valor Não Ajustado da ContagemVAC – Valor Ajustado da ContagemFP – Fator de Produtividade


APF – Ponto de Função (PF):É uma Unidade de Medida de Software que foi criada em 1977

por Alan Albrecht da IBM Corporation e posteriormente foi

reconhecida pela International Organization for Standardization

(ISO) para estimar o tamanho de um software se baseando nos

requisitos funcionais e não funcionais, isto é, na funcionalidade

percebida pelo usuário, independentemente da tecnologia usada

para implementá-lo.


Ponto de Função = Estimativa de Tamanho do Software

APF – Tamanho (T):Resultado da aplicação de contagens de pontos de função sobre

os requisitos funcionais e não funcionais de um software.


1.Requisitos Funcionais (RF) p/obter o Ponto de Função Não Ajustado (PFNA)1.1.Desmembrar os requisitos em Elementos Básicos (EB);1.2.Contar as Funções de Dados (FD) de cada elemento básico;1.3.Contar as Funções de Transação (FT) de cada elemento básico;1.4.Usar as tabelas do IFPUG para obter a complexidade e contribuição;1.5.Atribuir os pesos (contribuição) baseado na complexidade obdita;1.6.Somar os pesos atribuídos que é o resultado dos PFNA;

2.Requisitos Não Funcionais (RNF) p/obter o Ponto de Função Ajustado (PFA)2.1.Obter as 14 características não funcionais do IFPUG;2.2.Atribuir os Níveis de Influência (NI) para cada umas das características;2.3.Somar os NI obtendo-se o Nível de Influência Total (NIT);2.4.Aplicar a fórmula no NIT para obter o Valor do Fator de Ajuste (VFA);2.5.Usar a fórmula para o tipo de projeto para obter o TAMANHO;

APF – Produtividade (P):É a capacidade de produzir as melhores saídas baseadas nas

melhores entradas, objetivando a qualidade desejável e possível

do software, com o melhor aproveitamento dos recursos

essenciais e disponíveis para essa construção. Assim,

lucratividade e desempenho estão englobados em produtividade.

Uma forma de se obter a produtividade é utilizar a razão entre

Linhas de Código por Pontos de Função que dependem da

tecnologia utilizada, isto é, da linguagem de programação. A

Quantitative Software Management (QSM) oferece uma tabela

que pontua essa relação de produtividade que pode ser acessada

pelo site http://www.qsm.com/resources/function-point-languages-

table.


Produtividade = Linhas de Código / Pontos de Funçãoou

Produtividade = Homens / Hora

APF – Esforço (E):São as ações necessárias a serem aplicadas na construção de

um software. Em geral esse esforço é calculado em horas, pois

desta unidade pode-se chegar aos indicadores desejados para o

acompanhamento de um projeto de construção de software.

Uma forma de se obter o esforço de desenvolvimento é a

multiplicação da produtividade pelo tamanho do software, assim

se obtém a quantidade de horas necessárias para a referida

construção.


Esforço = Produtividade * Tamanho

APF – Escopo, Prazo e Custo:Trabalho é a quantidade de recursos alocados no

desenvolvimento multiplicado pela quantidade de horas

trabalhadas por dia. Escopo é o conjunto de requisitos que devem

ser desenvolvidos podendo ser classificado com escopo positivo

que é o que se pretende desenvolver e escopo negativo o que

não será desenvolvido no momento. Prazo é o tempo necessário

para desenvolver o escopo especificado. Custo é o valor na

moeda local correspondente ao esforço utilizado para

desenvolver o escopo especificado.


Custo = Esforço * Valor de 1 PF

Prazo = Esforço / Produtividade ou Trabalho

Trabalho = (Recursos * Horas Diárias)

Produtividade = (Linhas de Código / Ponto de Função)

APF – Resumo do Passo a Passo:1.Requisitos Funcionais (RF) p/obter Ponto de Função Não Ajustado (PFNA):

1.1.Desmembrar os requisitos em Elementos Básicos (EB);

1.2.Contar as Funções de Dados (FD) de cada elemento básico;

1.3.Contar as Funções de Transações (FT) de cada elemento básico;

1.4.Usar as tabelas do IFPUG para obter a complexidade e contribuição;

1.5.Atribuir os pesos (contribuição) baseado na complexidade obdita;

1.6.Somar os pesos atribuídos que é o resultado dos PFNA;

2.Requisitos Não Funcionais (RNF) p/obter Ponto de Função Ajustado (PFA):

2.1.Obter as 14 características não funcionais do IFPUG;

2.2.Atribuir os Níveis de Influência (NI) para cada umas das características;

2.3.Somar os NI obtendo-se o Valor de Influência (VI);

2.4.Aplicar a fórmula no VI para obter o Valor do Fator de Ajuste (VFA);

2.5.Usar a fórmula para o tipo de projeto para obter o TAMANHO;

3.Cálculos:

3.1.Obter a produtividade da equipe versus tecnologia usada;

3.2.Levantar o valor de 1 Ponto de Função com base nos custos e lucros;

3.3.Prever o Esforço de Desenvolvimento;

3.4.Calcular o Prazo de Entrega; e

3.5.Contabilizar o Custo do Desenvolvimento.


APF – Passo 1 de 13 :


Levantar os requisitos funcionais e não funcionais caso seja o

desenvolvimento de um novo software ou obter as

funcionalidades existentes caso seja uma manutenção evolutiva

ou adaptativa de um projeto ou sistema.



Determinar o tipo de contagem de Pontos de Função que pode

ser de três formas:

1. Projeto de Desenvolvimento (development project);

2. Manutenção (enhancement project); ou

3. Aplicação (application).



Identificar a fronteira da aplicação, isto é, o escopo da contagem,

definindo as funcionalidades que serão incluídas, alteradas,

excluídas, assim analisando o conjunto do software que será

medido, além de determinar o propósito da contagem, que pode

ser para obter o custo, o prazo, uma comparação. Visualizando o

que é pertinente ao software ou que é oriundo de outro software.



Desmembrar cada requisito em seus elementos básicos, por

exemplo:

Sendo o requisito funcional “Cadastrar o cpf, o nome e o telefone

de um contato”. Seu desmembramento em elementos básicos

seria:

Armazenamento dos contatos;

Inclusão dos contatos;

Alteração dos contatos;

Exclusão dos contatos; e

Consulta dos contatos.



Contar as Funções de Dados dos Elementos Básicos, sendo as funções as

seguintes

1. Arquivos Lógicos Internos (ALI) | Internal Logical File (ILF)

Entidade lógica e persistente

Mantido dentro da fronteira da aplicação

Equivale à um Repositório de Dados

2. Arquivos de Interface Externa (AIE) | External Interface File (EIF)

Entidade lógica e persistente

Mantido dentro da fronteira de outra aplicação

Equivale à um WebService, RPC, Orb, Visibroker, CORBA



Contar as Funções de Transação dos Elementos Básicos, sendo as funções as

seguintes:

1.Entrada Externa (EE) | External Input (EI)

Processo lógico do negócio que mantém os dados

Contada com base no número de campos de dados

2.Saída Externa (SE) | External Output (EO)

Processo lógico do negócio que gera dados

Exemplos típicos são relatórios

3.Consulta Externa (CE) | External Query (EQ)

O processamento sem cálculo



Descobrir as complexidades para os ALI, AIE, EE, SE e CE; baseadas nas

tabelas fornecidas pela IFPUG:



Descobrir as contribuições (pesos) baseados nas complexidades dos ALI, AIE,

EE, SE e CE; utilizando a tabela de contribuições do IFPUG:



Efetuar o somatório dos PF encontrados com base nas contribuições do

IFPUG:



Encontrar o Valor do Fator de Ajuste (VFA) que é o passo final na contagem de pontos de função. Este fator de ajuste consiste nas restrições de negócio adicionais do software não consideradas pelos cinco tipos de funções e são baseados no Nível de Influência (NI) sobre as 14 Características Gerais do Sistema ou Requisitos Não Funcionais (RNF).

Níveis de Influência (peso aplicado a cada uma das 14 características):0=Nenhuma influência; 1=Influência mínima; 2=Influência moderada; 3=Influência média; 4=Influência significante; e 5=Influência forte.

As 14 Características Gerais dos Sistemas (requisitos de qualidade):1=Comunicação de Dados; 2=Processamento de Dados Distribuído; 3=Desempenho; 4=Utilização do Equipamento (Restrições de Recursos Computacionais); 5=Volume de Transações; 6=Entrada de Dados On-line; 7=Eficiência do Usuário Final (Usabilidade); 8=Atualização On-line; 9=Processamento Complexo; 10=Reusabilidade; 11=Facilidade de Implantação; 12=Facilidade Operacional (Inicialização, Cópia, Recuperação, etc); 13=Múltiplos Locais e Organizações do Usuário; e 14=Facilidade de Mudanças (Manutenibilidade).



Depois de atribuir o Nível de Influência (NI) que varia de 0 (Nenhuma

Influência) a 5 (Influência Forte) para cada uma dessas 14 características

gerais de sistema, deve-se somar todos os NI aplicados para se obter o Nível

de Influência Total (NIT).

Para se obter o Valor do Fator de Ajuste (VFA) aplica-se a multiplicação de

0.01 sobre o Nível de Influência Total (NIT) e soma-se ao valor 0,65.

Valor do Fator de Ajuste = Nível de Influência Total * 0,01 + 0,65

APF – Passo 12 de 13:


O Valor de Ajuste da Contagem ou Ponto de Função Ajustado consiste na

multiplicação dos Pontos de Função Não Ajustados pelo Valor do Fator de

Ajuste.

Valor de Ajuste da Contagem = Ponto de Função Não Ajustado * Valor do Fator de Ajuste

APF – Passo 13 de 13:


Aplicar a fórmula de acordo com o tipo de desenvolvimento que pode ser um

novo projeto, um projeto em manutenção ou um sistema em produção.

Projeto de Desenvolvimento = Ponto de Função Não Ajustado * Valor do Fator de Ajuste

Manutenção = (Ponto de Função Não Ajustado + Ponto de Função Incluído + Ponto de Função Alterado Atual – Ponto de Função Alterado Anterior – Ponto de Função Excluído) * Valor do Fator

de Ajuste

Aplicação = Projeto de Desenvolvimento –(Ponto de Função Não Ajustado * Valor do Fator de Ajuste)

APF – Estimativas:


Imagine um novo projeto de desenvolvimento para o qual foram contados 100

PF e que a fase trabalhada corresponde a 20% do referido projeto. Para esse

desenvolvimento a equipe conta com 4 recursos e considerando que essa

equipe tem uma produtividade média de 20 horas por PF, trabalhando numa

jornada de 6 horas por dia e que o valor de de 1 hora de trabalho é de R$

35,00.

Quantidade de PF para 20% de 100 PF é igual a 20 PF;

Então o Esforço é 20h por PF * 20 PF = 400h;

E que o Prazo - 400h / (4 * 6) tem-se 16,7 dias; e

Que o Custo - 400h * R$ 35,00 = R$ 14.000,00.

APF – Técnicas:


Horas por PF = Linhas de Código / Ponto de Função

Trabalho = Quantidade Recursos * Horas Trabalho Diário

Produtividade = Horas por PF ou Trabalho

Esforço = Produtividade * Tamanho

Prazo = Esforço / Produtividade

Custo = Tamanho * Valor 1 PF

Taxa de Produção = (Tamanho / Mês) ou (Tamanho / Ano)

Taxa de Manutenção = Tamanho Manutenção / Tamanho Aplicativo

APF – Resumo:


APF – Exemplo: Requisito Funcional


Cadastrar acervo bibliotecário, informando dados como: Identificador, numeração automática;Tombamento, número da etiqueta impressa no livro; Título, nome do livro; Subtítulo, complemento do nome do livro; Autores, por ordem de prioridade; Edição; Volume; Ano de publicação; Gênero; Idioma; Tipo, se livro, revista, periódico; e ISBN, número sequêncial de publicação nacional. O cadastro deve possuir opções de inclusão, alteração, exclusão, impressão do acervo cadastrado, impressão da ficha (livro selecionado) e empréstimo. Também fornecer opção impressão baseado no filtro, que pode escolher qual o campo, qual tipo de filtro e dado a ser filtrado; Obter dados de livros de planilhas do excel (importação).

APF – Exemplo: Requisito Não Funcional


O módulo deve ser desenvolvido para Web utilizando ASPX com Csharp e os dados devem ser persistidos no banco SQLServer 2008 R2; A transferência dos dados na nuvem podem ser textuais, menos os dados referentes a empréstimo que deve ser criptografado; O sistema deve ter restrição de acesso, permitindo apenas aos usuários conectados na Intranet da organização, obtendo seu login via Active Directory; As telas de cadastro devem ser fácieis de se usar, fazendo uso dos objetos visuais (Webtop); Em relação a performance, não se deve ultrapassar os 15 segundos para cada submissão ao servidor, caso ocorra uma mensagem de advertência deve ser lançada ao usuário e o processo reinicializado.

APF – Exemplo: Elementos Básicos


Incluir acervo;

Alterar acervo;

Excluir acervo;

Filtrar acervo;

Imprimir acervos (grade);

Imprimir ficha cadastral;

Realizar empréstimo; e

Importar acervo do excel.

APF – Exemplo: Protótipo


APF – Exemplo: Cálculo do Ponto de Função Não Ajustado


Elementos Básicos FD/FT TD TR Complexidade Contribuição

Acervo ALI 13 1 B 7

Empréstimo ALI 6 2 M 10

Incluir acervo EE 13 1 B 3

Alterar acervo EE 13 1 B 3

Excluir acervo EE 1 1 B 3

Filtrar acervo SE 3 1 B 4

Imprimir acervo CE 13 1 B 3

Imprimir ficha cadastral SE 10 2 M 5

realizar empréstimos EE 6 2 M 4

importar de excel AIE 12 3 B 5

Ponto de Função Não Ajustado 47

APF – Exemplo: Cálculo do Valor do Fator de Ajuste


Características Nível Influência

01. Comunicação de Dados 4

02. Processamento Distribuído 4

03. Desempenho 1

04. Utilização do Equipamento 2

05. Volume de Transações 0

06. Entrada de Dados ON-LINE 5

07. Eficiência do Usuário Final 5

08. Atualização ON-LINE 1

09. Processamento Complexo 1

10. Reutilização de Código 1

11. Facilidade de Implantação 3

12. Facilidade Operacional 3

13. Múltiplos Locais 3

14. Facilidades de Mudanças 4

Nível de Influência Total (NIT) 37

Valor do Fator de Ajuste (NIT * 0,01 + 0,65) 1,02

APF – Exemplo: Tabela QSM para Obter a Produtividade


APF – Exemplo: Cálculo das Estimativas


Tamanho do Software para Projeto de Desenvolvimento = Ponto de Função Não

Ajustado * Valor do Fator de Ajuste então:

Ponto de Função Não Ajustado = 47

Valor do Fator de Ajuste = 1,02

Ponto de Função Ajustado = 47 * 1,02 = Tamanho do Software = 47,94

Para obtenção da produtividade multiplica-se Linhas de Código por Ponto de Função e

para descobrir esse valor indica-se usar o valor mínimo da tabela QSM para a

linguagem que foi designada, assim resultando em uma produtividade de 15. Outra

forma de calcular a produtividade é saber a quantidade de recursos alocados no projeto

e multiplicá-lo pela quantidade de horas trabalhadas por dia. Considerando que existam

2 recursos alocados e que as horas trabalhadas por dia são de 8h, temos 2 * 8 = 16h

que seria a produtividade.

Produtividade = 15 (baseada no QSM)

Esforço = Produtividade * Tamanho = 15 * 47,94 = 719,1

Prazo = Esforço / Produtividade = 719,1 / 15 = 47,94 - 8 dias de folga = 39,94 = 40d

Valor de 1 PF = R$ 30,00

Custo = Valor 1 PF * Tamanho = 30 * 47,94 = R$ 6.232,20

APF – Fórmulas:


Ponto de Função = Estimativa de Tamanho do Software

Produtividade = Linhas de Código / Ponto de Função

Esforço = Produtividade * Tamanho ou Trabalho * Tamanho

Custo = Esforço * Valor de 1 PF

Prazo = Esforço / Produtividade ou Trabalho

Trabalho = (Recursos * Horas Diárias)

Valor do Fator de Ajuste = Nível de Influência Total * 0,01 + 0,65

Valor de Ajuste da Contagem = Ponto de Função Não Ajustado * Valor do Fator de Ajuste

Projeto de Desenvolvimento = Ponto de Função Não Ajustado * Valor do Fator de Ajuste

Manutenção = (Ponto de Função Não Ajustado + Ponto de Função Incluído + Ponto de Função Alterado Atual – Ponto de Função Alterado Anterior – Ponto de Função Excluído) * Valor do Fator de Ajuste

Aplicação = Projeto de Desenvolvimento – (Ponto de Função Não Ajustado * Valor do Fator de Ajuste)

APF – Sistema de Informática do Serviço Público (SISP)


SISP significa Sistema de Informática do Serviço

Público ou como atualmente é designado Sistema

de Administração dos Recursos de Tecnologia da

Informação e tem como objetivo entre outras

regulamentações a padronização do uso da métrica

de ponto de função pelo Governo Federal e suas

Unidades Federativas.

Fonte: www.sisp.gov.br

http://www.sisp.gov.br/



Para definir a Produtividade (P), isto é, o fator “homens-hora” para construir um Ponto de Função caso inexistência de uma base histórica segue a regra:

Inicialmente, deve-se procurar algum projeto anterior semelhante dentro da própria instituição, que tenha utilizado a mesma linguagem de programação/desenvolvimento do novo projeto, contá-lo utilizando a métrica de pontos de função e, através desta contagem, chegar em uma produtividade correspondente a este projeto anterior. Por exemplo, se verificar que em projeto anterior, na mesma linguagem, contado em 10 pontos de função, o esforço foi de 100 horas, a produtividade daquele projeto foi de 10 horas por ponto de função. Fazendo-se isso com uma maior quantidade de projetos anteriores semelhantes, o resultado será mais preciso, utilizando-se a média de produtividade obtida como o “fator de produtividade”. Lembrando-se que se os projetos anteriores não estão em pontos de função, será necessário contá-los para se chegar a estes números. Caso não haja sequer projeto similar na instituição ou seja inviável realizar o processo descrito acima, deve-se recorrer aos fornecedores disponíveis no mercado para obter uma base.





O Roteiro de Métricas de Software do SISP:

Trata-se de um manual de contagem de Pontos de Função

complementar ao Manual de Práticas de Contagem (CPM),

contemplando os pontos não cobertos pelo manual do IFPUG, mas

vivenciados pelos órgãos e entidades do SISP, procurando também

atender aos acórdãos do Tribunal de Contas da União. E pode ser

baixado na comunidade do SISP, que está localizada no portal

do SISP (http://www.sisp.gov.br) e na seção Arquivos de Métricas no

site do Governo Eletrônico (http://www.governoeletronico.gov.br) na

seção Biblioteca.



http://www.governoeletronico.gov.br/




Em relação a Obrigatoriedade:

Os órgãos Federais e Estaduais não são obrigados a adotar o Roteiro de Métricas de software do SISP, porém a Portaria SLTI/MP Nº 31, de 29 novembro de 2010, recomenda que os órgãos integrantes do Sistema de Administração dos Recursos de Informação e Informática (SISP) adotem o roteiro de contagem nas suas contratações de serviços de desenvolvimento e manutenção de soluções de software. O Roteiro de Métricas de Software do SISP servir como auxílio aos órgãos que não possuem processo formalizado de contagem e de contratação utilizando a métrica de pontos de função. Para os órgãos que já possuem seus próprios manuais e roteiros, a utilização do Roteiro de Métricas de Software do SISP (no todo ou em parte) é facultativa. Esse roteiro poderá ser alterado e adequado às características de cada órgão e de cada contrato, a critério do próprio órgão.





Em relação a Parceria com IFPUG:

A Portaria nº 31/2010 do MPOG recomenda o Manual de Contagem de Pontos de Função (CPM) e existe um estudo para que todos os órgãos façam filiação ao IFPUG ou ao Órgão Central do SISP que irá distribuir cópias autorizadas aos órgãos membros. Porém isto encontra-se em andamento, com uma discussão com o IFPUG sobre filiação do Ministério do Planejamento, com um acordo para adesão de outros órgãos. Estes órgãos poderiam aderir à filiação, de forma facilitada e facultativa, caso fossem atendidos alguns pré requistos. Ainda não há previsão sobre a conclusão desta discussão. A equipe de Consultores em Melhoria de Processo de Software, que coordena o Grupo de Métricas está à frente desse projeto.

O Manual de Práticas de Contagem de Pontos de Função (Function PointCounting Practices Manual) é um documento publicado pelo InternationalFunction Point users Group (IFPUG), que detém os seus direitos, conforme consta do próprio manual. No Roteiro de Métricas do SISP é citado que o CPM é publicado pelo IFPUG e informações adicionais podem ser obtidas no sítio oficial do IFPUG (www.ifpug.org) e no site do representante oficial no Brasil (www.bfpug.com.br).


http://www.ifpug.org/

http://www.bfpug.com.br/




O SISP oferece consultoria e material de apoio:

O SISP não possui um grupo de trabalho que realiza contagem de pontos

de função, mas existe um grupo de consultoria que tira dúvidas e presta

consultoria relacionado ao processo de contagem de pontos de função.

Caso venha a ter alguma dúvida específica com relação ao tema é possível

abrir um chamado via Sistema de Demandas do C3S

(c3s.sisp.gov.br) descrevendo-a. O Portal do SISP (www.sisp.gov.br), na

comunidade SISP, seção "Arquivos/Métricas", estão disponíveis materiais

relacionados ao tema, incluindo o Roteiro de Métricas de Software

do SISP - v1.0.


http://c3s.sisp.gov.br/





O SISP orienta as seguintes técnicas de estimativa de Pontos de

Função:

Contagem Indicativa (NESMA)

A técnica NESMA utiliza como documento base o Modelo de Dados do

Projeto e assume que cada Arquivo Lógico Interno tem 35 PFs e cada

Arquivo de Interface Externa tem 15 PFs.

Contagem Estimativa de Pontos de Função ( CEPF)

A técnica CEPF utiliza os requisitos iniciais do projeto para identificar e

classificar os Processos Elementares da APF em EE, CE e SE, bem como

identificar os dados associados, definindo sua complexidade: Baixa, Média

e Alta. Caso não seja possível definir a complexidade, considere a

complexidade Média. Durante a identificação dos dados associados a uma

função transacional específica (EE, CE ou SE), procure definir os ALIs e

AIEs da aplicação. Caso não seja possível definir a complexidade do ALI

ou do AIE, considere a complexidade Baixa.





Sistemas legados devem ser contatos também via APF:

Os sistemas legados, quando a documentação está completa, o ideal é que

seja feita a contagem detalhada, mas quando não existe essa

documentação, recomenda-se fazer a contagem estimada, podendo-se

utilizar várias técnicas, entre as quais destacam-se a Contagem Indicativa

(NESMA) e a Contagem Estimativa de Pontos de Função (CEPF).





SISP para manutenções corretivas nos sistemas:

Com relação à previsão de manutenções, recomenda-se que os sistemas

sejam analisados, de forma a obter uma previsão de demandas de

manutenção (evolutiva, adaptativa e corretiva) e definir um percentual, que

pode ser anual. Lembrando que, no caso de manutenção corretiva, quando

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

manutenção será do tipo Garantia, conforme prazos e demais cláusulas do

contrato em questão. Caso não exista cláusula contratual de Garantia,

deve ser considerada a garantia de seis meses, preconizada por lei

(Código do Consumidor).





Em relação a percentual de referência para contratar as manutenções:

Não existe percentual de referência para contratar manutenções (evolutiva,

adaptativa e corretiva). Recomenda-se analisar os sistemas de forma a

estimar esse percentual, que pode ser anual, seja por registros de

ocorrências, registro de gastos em anos anteriores, entrevista com

desenvolvedores que trabalhavam na manutenção dos sistemas já

existentes ou levantamento das necessidades de futuras

manutenções. Lembrando que, no caso de manutenção corretiva, quando

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

manutenção será do tipo Garantia, conforme prazos e demais cláusulas do

contrato em questão. Caso não exista cláusula contratual de Garantia,

deve ser considerada a garantia de seis meses, preconizada por lei

(Código do Consumidor).





O SISP recomendação a adoção de AFP:

A adoção da métrica Ponto de Função é uma recomendação do SISP, isto

é enfatizado pela portaria SLTI/MP n° 31 de 29 de novembro de 2010, que

no seu art. 1º, parágrafo 3, informa que sua utilização é uma boa prática na

contratação de serviços de desenvolvimento de soluções de software. Esta

mesma portaria no seu art. 2º, parágrafo único, reforça esta recomendação

também para projetos de melhoria ou manutenção adaptativa de softwares,

através da utilização de procedimentos complementares ao manual de

contagem do IFPUG. Estes procedimentos são estabelecidos no Roteiro de

Métricas de Software do SISP, também recomendado nesta portaria. Além

dessa portaria, existem diversos acórdãos do TCU que tem

recomendações neste mesmo sentido, deve-se destacar:

Item 9.3.4.1 do Acórdão do TCU 1782/2007 - Plenário;

Item 9.2.2.2 do Acórdão 2024/2007 - Plenário.





Não deve-se derivar a APF de outras métricas:

A métrica Ponto de Função mede o tamanho funcional de um software e

não é correto derivar pontos de função a partir de outra métrica e vice-

versa. O TCU, em diversos acórdãos (ex: 1274/2010 e 1125/2009),

condena a derivação de pontos de função a partir de outra métrica, em

especial a métrica homem-hora.





Valor Médio de Ponto de Função:

O Gartner Group divulgou um artigo contendo o custo médio do ponto de

função entre os anos de 2006 e 2010. Os valores estão em dólares. Em

2010, o custo médio foi de $ 452. Os dados publicados pelo Gartner não

foram classificados por plataforma ou linguagem de programação, mas a

plataforma/linguagem reflete no valor do ponto de função, pois está

relacionado a produtividade. Se utilizar os dados do Gartner Group,

mencionar a fonte.



medida de esforço de software com análise de ponto de função

Technology