TAES 3 - Seminário Uma Introdução à Análise de Pontos de Função Felipe Furtado Julho/2004

Agenda Motivação Histórico Visão Geral e Objetivos Regras de Contagem Aplicações e Influências Comparações Certificação Conclusão Referências Estudo de Caso

Motivação Como gerenciar a área de desenvolvimento de sistemas dentro da empresa? Qual a produtividade da minha equipe? Qual o esforço para desenvolver o software? Qual o custo do software? Qual a taxa de produção de software? Qual a taxa de manutenção de software?

Histórico 1979 - Allan Albrecht da IBM; 1984 - Metodologia formal - domínio público. - IBM CIS & A Guideline 313, AD/M Productivity Measurement and Estimate Validation, November 1, 1984; 1986 - Grupo Internacional de Usuários de Pontos de Função Manual de Práticas de Contagem IFPUG Function Point Counting Practices Manual, atualmente no Release 4.2. 1994 - Criação de um grupo de trabalho na ISO sobre Medidas Funcionais de Tamanho; 2002 - Padrão Internacional – Norma ISO/IEC 20926. Pontos de função são uma medida funcional de tamanho de software, introduzida em 1979 por Alan Albrecht da IBM.   Medida funcional de tamanho de software é um conceito definido pelo padrão ISO/IEC 14143-1:1998 e refere-se à medição do tamanho do software considerando-se apenas a funcionalidade solicitada e recebida pelos respectivos usuários. Nesse sentido, uma medida funcional de tamanho é uma medida externa, pois mede somente aquilo que é percebido pelos usuários do produto de software, independentemente da forma de implementação escolhida. A contagem dos pontos de função é regulamentada pelo International Function Point Users Group (IFPUG), organização internacional sem fins lucrativos sediada nos Estados Unidos da América. O IFPUG publica o Counting Practices Manual (Manual de Práticas de Contagem), atualmente em sua versão 4.1.1, que estabelece os padrões para o cálculo dos pontos de função. Para garantir a padronização dos procedimentos de contagem, o IFPUG oferece certificação na técnica e divulga os profissionais certificados através de seu site na Internet – www.ifpug.org. O método do IFPUG foi oficializado através do padrão internacional ISO/IEC 20926 de 2002. A contagem dos pontos de função é realizada com base em cinco tipos de componentes de software: arquivos internos, arquivos externos, entradas, saídas e consultas. Esses termos possuem um sentido específico na FPA - Function Point Analysis (Análise de Pontos de Função) e a identificação e classificação dos componentes exige conhecimento especializado. Os pontos de função são utilizados como fator normalizador do tamanho do software, permitindo o estabelecimento de métricas tais como produtividade (pontos de função produzidos por pessoa-mês), taxa de entrega (homens-hora para a produção de um ponto de função), densidade de defeitos (defeitos encontrados por ponto de função) e outras. A taxa de entrega também pode ser  denominada produtividade, o que pode causar confusão. A melhor opção é deixar clara a nomenclatura utilizada em cada caso. Vem crescendo a utilização, pelas empresas brasileiras, dos pontos de função nos contratos de fornecimento de software, seja através da cotação de preços por ponto de função, ou através da quantificação dos serviços através de medições de pontos de função. No mundo, os pontos de função do IFPUG são utilizados pela grande maioria das organizações que realizam algum tipo de medição funcional de tamanho de software

Histórico Empresas que adotam FPA: FORD 3M General Eletric American Airlines American Express AT&T Bank of America British Airways Delta Airlines FORD General Eletric IBM Royal Bank of Canada Shell Unisys Xerox

Visão Geral da FPA É uma técnica que dimensiona uma aplicação na perspectiva do usuário final, ao invés de levar em consideração as características técnicas da linguagem utilizada; Dimensiona software quantificando a funcionalidade que ele proporciona aos usuários baseado, principalmente, no seu desenho lógico; Considera-se o que é entregue ao usuário e não como a funcionalidade é desenvolvida; Considera-se apenas os componentes da aplicação definidos e requeridos pelo usuário.

Objetivos Medir projetos de desenvolvimento e manutenção de software, independentemente da tecnologia utilizada para a implementação; Prover uma métrica de medição para apoiar a análise de produtividade e qualidade; Prover um fator de normalização para comparação de software (unidade padrão).

Regras de Contagem - Procedimentos 1. Determinar o tipo de contagem de ponto de função. 2. Identificar a fronteira (limite) da aplicação. 3. Contar as funções de dados para determinar a contribuição delas para a contagem de pontos de função não ajustada. 4. Contar as funções transacionais para determinar a contribuição delas para a contagem de pontos de função não ajustada. 5. Determinar o fator de ajuste. 6. Calcular a contagem de pontos de função ajustada. Determinar o tipo de contagem (pode ser um projeto de novo desenvolvimento, uma contagem básica de aplicação ou uma contagem de projeto de melhoria) Identificar a fronteira da aplicação (i.e., quais funções o software deve executar?) Contar os tipos de funções de dados (divididos em: i) Arquivos Lógicos Internos ou ALIs, que são os grupos lógicos de dados mantidos dentro da fronteira da aplicação, e ii) Arquivos de Interface Externa ou AIEs, os quais são apenas referenciados pela aplicação). Cada ALI vale 7, 10 ou 15 PF,enquanto cada AIE vale 5, 7 ou 10 PF. Contar os tipos de funções de transações (divididos em: i) Entradas Externas ou EEs, que são processos de entrada de dados, b) Saídas Externas ou SEs, por exemplo, relatórios e c) Consultas Externas ou CEs, por exemplo, Consultar Detalhes de Empregados). Cada EE ou CE vale 3, 4 ou 6 pontos de função, enquanto cada SE vale 4, 5 ou 7 pontos de função. Diversas matrizes simples baseadas nos tipos de elementos de dados (reconhecidos pelos usuários e não recursivos), juntamente com tipos de registros (subconjunto dos dados reconhecidos pelos usuários) ou tipos de arquivos referenciados (número de grupos lógicos de dados necessários à execução completa de um processo) são utilizados para determinar a complexidade de cada função, Baixa, Média ou Alta.

Etapa 1 – Determinar o Tipo de Contagem Projeto de desenvolvimento (nova aplicação); Projeto de manutenção (aplicação já existente); Aplicação (tamanho real).

Margem de Erro Conhecimento do Sistema Margem de Erro Tempo Requisitos - Conceitual - Detalhado - Codificação - Testes - Implantação Voltar Fonte: Manual de Práticas de Contagem do IFPUG

Etapa 2 – Identificar a Fronteira Indica o limite entre o software que está sendo medido e o usuário; Observar sempre do ponto de vista do usuário; O que o usuário pode entender e descrever; Evidenciar o que é interno e o que é externo à aplicação.

Visão Geral da Aplicação SE CE EE Fronteira da Aplicação Sistema A Sistema B SE ALI AIE CE EE Fronteira da Aplicação

Visão Geral da Aplicação Grupo Lógico de Dados: ALI – Arquivo Lógico Interno AIE – Arquivo de Interface Externa Transações: EE – Entrada Externa SE – Saída Externa CE – Consulta Externa Voltar

Etapa 3 – Contagem das Funções de Dados ALI – Arquivo Lógico Interno Grupo lógico de dados do ponto de vista do usuário cuja manutenção é feita internamente pela aplicação; Entidade lógica e persistente; Dados que sofrem manutenção dentro da fronteira da aplicação; Equivale a uma entidade em um MER; Tabelas adicionadas por necessidade do projeto físico de dados não devem ser contabilizadas.

Etapa 3 – Contagem das Funções de Dados ALI – Exemplos: Dados da aplicação (cadastro de clientes, cadastro de funcionários); Dados de segurança, auditoria, histórico, mensagens, erros, salva: se especificado pelo usuário; ALI – Não são exemplos: Arquivos temporários, de trabalho, de classificação; Operações de junção e projeção (já foram contabilizados em outros arquivos).

Etapa 3 – Contagem das Funções de Dados AIE – Arquivo de Interface Externa Grupo lógico de dados do ponto de vista do usuário utilizados na aplicação cuja manutenção pertence a outra aplicação; Entidade lógica e persistente; Dados que sofrem manutenção dentro da fronteira de outra aplicação. AIE – Exemplo: Dados de outra aplicação (cadastro de funcionários utilizado pelo sistema de Empréstimo e Benefícios).

Etapa 3 – Contagem das Funções de Dados ALI/AIE – Complexidade Baseada no: Número de registros lógicos; Número de itens de dados do arquivo. Ex.: sistema de RH – processo de inclusão de um empregado: Dados básicos (mandatório) Dados p/ mensalistas (opcional) Dados p/ horistas (opcional) Dados p/ dependentes (opcional)

Etapa 3 – Contagem das Funções de Dados ALI/AIE – Tabela de Complexidade:   1 a 19 Itens de Dados 20 a 50 Itens de Dados Mais de 50 Itens de Dados 1 Registro Lógico Simples Média 2 a 5 Registros Lógicos Complexa 6 ou mais Registros Lógicos

Etapa 3 – Contagem das Funções de Dados ALI – Tabela de Conversão: Complexidade da Função Pontos de Função não Ajustados Simples 7 Média 10 Complexa 15 AIE – Tabela de Conversão: Complexidade da Função Pontos de Função não Ajustados Simples 5 Média 7 Complexa 10 Voltar

Etapa 4 – Contagem das Funções Transacionais EE – Entrada Externa Transações recebidas de fora da aplicação com o objetivo de atualizar os arquivos lógicos internos; Cada atividade de manutenção (inclusão, alteração e exclusão) é contabilizada como uma EE; EE – Exemplos: Entrada on-line: inclusão, alteração e exclusão de um funcionário; Entrada batch: inclusão, alteração e exclusão de um funcionário.

Etapa 4 – Contagem das Funções Transacionais EE – Exemplos: Processos de entrada, especificamente solicitados pelo usuário, devem ser contados separadamente, por exemplo, um sistema bancário que aceita transações idênticas de depósito, uma através de caixa automático (ATM) e a segunda feita pelo caixa do banco. EE – Não são exemplos: Tela de logon que não atualiza ALI.

Etapa 4 – Contagem das Funções Transacionais EE – Complexidade Baseada no: Número de arquivos referenciados; ALI consultado ou atualizado; AIE consultado. Número de itens de dados do arquivo. Também devem ser contados: Campos não informados pelo usuário, mas que são atualizados em um ALI por uma EE devem ser contabilizados (nº seq, data/hora da inclusão); Linha de comando, tecla de função e mensagens.

Etapa 4 – Contagem das Funções Transacionais EE – Tabela de Complexidade:   1 a 4 Itens de Dados 5 a 15 Itens de Dados Mais de 16 Itens de Dados 0 ou 1 Arquivo Referenciado Simples Média 2 Arquivos Referenciados Complexa 3 ou mais Arquivos Referenciados

Etapa 4 – Contagem das Funções Transacionais EE – Tabela de Conversão: Complexidade da Função Pontos de Função não Ajustados Simples 3 Média 4 Complexa 6

Etapa 4 – Contagem das Funções Transacionais SE – Saída Externa Transações que geram dados e os enviam para fora da aplicação; SE – Exemplos: Relatórios; Gráficos; Gerador de relatório: cada relatório específico é considerado uma SE.

Etapa 4 – Contagem das Funções Transacionais SE – Não são exemplos: Tela de help; Relatórios ad-hoc: o usuário é responsável diretamente pela criação (ex.: através de comandos SQL) de um nº indefinido de relatórios. Nenhuma SE é considerada.

Etapa 4 – Contagem das Funções Transacionais SE – Complexidade Baseada no: Número de arquivos referenciados; ALI consultado; AIE consultado. Número de itens de dados do arquivo.

Etapa 4 – Contagem das Funções Transacionais SE – Tabela de Complexidade:   1 a 5 Itens de Dados 6 a 19 Itens de Dados Mais de 20 Itens de Dados 0 ou 1 Arquivo Referenciado Simples Média 2 a 3Arquivos Referenciados Complexa 4 ou mais Arquivos Referenciados

Pontos de Função não Ajustados Etapa 4 – Contagem das Funções Transacionais SE – Tabela de Conversão: Complexidade da Função Pontos de Função não Ajustados Simples 4 Média 5 Complexa 7

Etapa 4 – Contagem das Funções Transacionais CE – Consulta Externa Transações que combinam uma atividade de entrada com uma saída de dados; Não contém fórmula matemática ou cálculo; Não mantém um ALI; Não altera o comportamento do sistema.

Etapa 4 – Contagem das Funções Transacionais CE – Exemplos: Consulta de saldo em um banco: o usuário informa o número da conta e recebe como resposta o valor do saldo; Tela de Logon; Tela de help.

Etapa 4 – Contagem das Funções Transacionais CE – Complexidade Baseada no: Número de arquivos referenciados na entrada e na saída; ALI consultado; AIE consultado. Número de itens de dados do arquivo. Entrada e saída. Também devem ser contados: Linha de comando, tecla de função e mensagens.

Etapa 4 – Contagem das Funções Transacionais CE – Tabela de Complexidade:   1 a 5 Itens de Dados 6 a 19 Itens de Dados Mais de 20 Itens de Dados 0 ou 1 Arquivo Referenciado Simples Média 2 a 3Arquivos Referenciados Complexa 4 ou mais Arquivos Referenciados  

Etapa 4 – Contagem das Funções Transacionais CE – Tabela de Conversão: Complexidade da Função Pontos de Função não Ajustados Simples 3 Média 4 Complexa 6 Voltar

Etapa 5 – Determinar o Fator de Ajuste Fator de Ajuste de Valor (FAV) Avalia restrições de negócio adicionais do software não consideradas pelos cinco tipos de funções; Baseado na influência de 14 Características Gerais do Sistema.

Etapa 5 – Determinar o Fator de Ajuste Avaliar o nível de influência das características gerais de um sistema: 1. Comunicação de Dados 2. Processamento Distribuído 3. Performance 4. Configuração do Equipamento 5. Volume de Transações 6. Entrada de Dados On-Line 7. Interface com o usuário 8. Atualização On-Line 9. Processamento Complexo 10. Reusabilidade 11. Facilidade de Implantação 12. Facilidade Operacional 13. Múltiplos Locais 14. Facilidade de mudanças 0 – Nenhuma Influência 1 – Influência Mínima 2 – Influência Moderada 3 – Influência Média 4 – Influência Significativa 5 – Grande Influência Como Classificar ??

Etapa 5 – Determinar o Fator de Ajuste Exemplo: Volume de Transações 0 – Nenhum período de pico de transações é esperado 1 – Picos de transações mensais, quadrimestrais, sazonais e anuais são esperados 2 – Picos semanais de transações são esperados 3 – Picos diários de transações são esperados 4 – Altos volumes de transações foram fixados pelo usuário para a aplicação, o que força a execução de tarefas de análise de performance na fase de desenho da aplicação 5 – Requer o uso de ferramentas de análise de performance nas fases de desenho, desenvolvimento e/ou implantação, além das considerações acima.

Etapa 5 – Determinar o Fator de Ajuste Nível de Influência: NI = NI(i) Fator de Ajuste: FA = 0,65 + (0,01 * NI) Voltar

Etapa 6 – Pontos de Função Ajustados PF = PF (não ajustado) * FA Voltar

Aplicações O que fazer agora? Pouco frustrante para empresas recém-criadas; Comparar com projetos anteriores, planejar e estimar melhor o novo desenvolvimento; Obtendo o número de Pontos de Função pode-se estimar o esforço de projeto por fases de desenvolvimento. Determinar o tipo de contagem (pode ser um projeto de novo desenvolvimento, uma contagem básica de aplicação ou uma contagem de projeto de melhoria) Identificar a fronteira da aplicação (i.e., quais funções o software deve executar?) Contar os tipos de funções de dados (divididos em: i) Arquivos Lógicos Internos ou ALIs, que são os grupos lógicos de dados mantidos dentro da fronteira da aplicação, e ii) Arquivos de Interface Externa ou AIEs, os quais são apenas referenciados pela aplicação). Cada ALI vale 7, 10 ou 15 PF,enquanto cada AIE vale 5, 7 ou 10 PF. Contar os tipos de funções de transações (divididos em: i) Entradas Externas ou EEs, que são processos de entrada de dados, b) Saídas Externas ou SEs, por exemplo, relatórios e c) Consultas Externas ou CEs, por exemplo, Consultar Detalhes de Empregados). Cada EE ou CE vale 3, 4 ou 6 pontos de função, enquanto cada SE vale 4, 5 ou 7 pontos de função. Diversas matrizes simples baseadas nos tipos de elementos de dados (reconhecidos pelos usuários e não recursivos), juntamente com tipos de registros (subconjunto dos dados reconhecidos pelos usuários) ou tipos de arquivos referenciados (número de grupos lógicos de dados necessários à execução completa de um processo) são utilizados para determinar a complexidade de cada função, Baixa, Média ou Alta.

Imaginemos um projeto no qual obtemos um total de 100 PF: Aplicações Imaginemos um projeto no qual obtemos um total de 100 PF: Numa fase que utilize 20% do Projeto; Numa equipe de 4 pessoas; Considerando uma produtividade média de 20hs/PF; Considerando uma jornada de 6 horas diárias; Considerando um valor de R$35,00 o valor de 1 Hora de Trabalho.

Aplicações 20% de 100 PF = 20 PF Esforço - 20hs/PF então: 20hs/PF x 20PF = 400h Prazo - 400h/ (4 x 6) = 16,7 Dias Custo - 400h x R$ 35,00 = R$ 14.000,00

Aplicações Tamanho em PF Quanto tempo leva até a sua casa ? Ferramenta FPA é independente Qual a distância até a sua casa ? Mesma pista, mesmo piloto, carros distintos ? Mesma pista, mesmo carro, pilotos distintos ? Capacidade da Equipe FPA fornece subsídio

Aplicações Produtividade no desenvolvimento Esforço de desenvolvimento - Horas por PF Esforço de desenvolvimento Produtividade (H/PF) * Tamanho (PF) Custo de software Tamanho (PF) * Custo (R$/PF) Taxa de produção de software PF/Mês; PF/Ano Taxa de manutenção de software PF manutenção / PF aplicativo

Influências Linguagem de Codificação; Tamanho do software; Experiência da equipe; Métodos estruturados; Ambiente de desenvolvimento (CASE); Qualidade de expansão/manutenção; Reutilização de código; Métodos de remoção de erros; Organização da equipe.

Aplicações Na UNISYS: Estimativa de Custo de Desenvolvimento; Acompanhamento do Esforço de Desenvolvimento; Acompanhamento do Projeto Planejado x Realizado; Acompanhamento da Taxa de Produção do Software.

Comparações Características Linha de Código Software Science Cocomo   Feature Points Putman Pontos por Função 1. Produção de resultados aceitáveis sim 2. Avaliação por usuários sem conhec. da ling. programação não 3. Significado para o Usuário final 4. Utilizado em estimativas 5. Contabilização automática A grande quantia que movimenta a indústria mundial de desenvolvimento de software, atualmente em valores acima dos 600 bilhões de dólares anuais, tem levado as organizações a buscar a melhoria do seu processo de desenvolvimento visando melhorar a qualidade e produtividade do software produzido, e por conseqüência, redução do custo e tempo de implementação e manutenção. Porém, existe um objetivo ainda maior das organizações, que é a previsibilidade desta qualidade e produtividade[9]. E se você não possui um processo para realizar estimativas apropriadas, você está com o seu processo de desenvolvimento de software comprometido, porque, como você vai confiar num planejamento para construção de um produto baseado num "achômetro"? Por mais capaz que seja a equipe técnica envolvida no projeto, a dificuldade de se estabelecer tamanho de um projeto de software com base na experiência passada é muito grande, pelo fato da dificuldade de se estabelecer as similaridades e as diferenças entre a funcionalidade dos softwares. Esta dificuldade é que tem levado as organizações a investimentos elevados nesta área, e muita evolução neste assunto é esperada para os próximos anos. Fonte: Análise de Pontos por Função DOUGLAS JOSÉ PEIXOTO DE AZEVEDO

Certificação CFPS – Certifield Function Point Specialist; Conferida pelo International Function Point Users Group; 2 vezes por ano; Reconhecida internacionalmente; Conferida por 1 ano e revalidada anualmente, por até 3 anos, enquanto a pessoa permanecer filiada ao IFPUG.

Certificação Evolução da Certificação no Brasil: Fonte:http://www.bfpug.com.br

Certificação O Brasil já é o segundo do mundo em quantidade de CFPS (posição em janeiro de 2004): Fonte:http://www.bfpug.com.br

Conclusões Mantidos por uma organização internacional desde 1986 – IFPUG; Suporte no Brasil – BFPUG; Programa mundial de certificação – CFPS; Padronização internacional – ISSO/IEC 20926; Modelam os requisitos a um nível de abstração mais elevada e independente de artefatos do que os UCP, por exemplo; Pode ser utilizado por organizações que utilizem qualquer forma de representação dos requisitos, casos de uso ou outras; Unidade de medida padrão para software; Compreensível por não técnicos; Apoia a análise de qualidade e produtividade; Uma forma para calcular custos e recursos requeridos para desenvolvimento e manutenção de software; A utilização em contratos e licitações é uma realidade no Brasil;

Conclusões Para ter uma boa utilização é necessária uma base histórica; É necessário ter uma boa visão (profundidade do sistema para poder estimar com menos insegurança); Não é muito boa para medir esforço de manutenção (correção de problemas); Utilização de pesos para definir a classificação das funções; Várias variações das métricas, é preciso saber qual a versão da métrica, quando se vai medir tamanho do software. When Not to Use Function Points Function points are not a very good measure when sizing maintenance efforts (fixing problems) or when trying to understand performance issues. Much of the effort associated with fixing problems (production fixes) is due to trying to resolve and understand the problem (detective work). Another inherent problem with measuring maintenance work is that much of maintenance programming is done by one or two individuals. Individual skill sets become a major factor when measuring this type of work. The productivity of individual maintenance programmers can very as much as 1,000 percent.   Performance tuning may or may not have anything to do with functionality. Performance tuning is more a result of trying to understand application throughput and processing time. There are better metrics to utilize when measuring this type of work. FPA is not useful to size Web Design. FPA is useful to size web development, but not web design. FPA is concerned with the dynamic relationship between transactions and files. FPA is not useful in estimating the time it will take to create graphics, images, page layouts, so on and so forth. A desvantagem da métrica pontos por função, segundo Kitchenham [KIT97], é ter falhas fundamentais em sua construção. Isto se deve à utilização de pesos para definir a classificação das funções. Este fato pode levar a diferentes abordagens quando da contagem ou seja, pode haver problemas se a classificação se comportar de modo inesperado, levando-se a afirmar que uma aplicação é maior que outra, quando não o é. Isto alerta para o fato de se usar a métrica com cuidado sobre a versão utilizada. Desde sua criação em 1979, surgiram várias versões da métrica e, quando se compara tamanho de software, é preciso saber qual a versão da métrica que está sendo usada. Mesmo utilizando-se a mesma versão pode haver uma diferença de mais ou menos 12 por cento (estudo realizado por Kitchenham [KIT97]) na contagem para o mesmo produto realizado por pessoas da mesma organização.

Referências IFPUG - International Function Point Users Group www.ifpug.org BFPUG - Brazilian Function Point Users Group www.bfpug.com.br IFPUG - Function Point Counting Practices Manual AZEVEDO, Douglas José Peixoto. Análise de Pontos por Função para Aplicações Orientadas a Documentos Developers Magazine – Pontos de Função ou Pontos por Caso de Uso? Como estimar projetos orientados a objeto - por Maurício Aguiar

Estudo de Caso Sistema de reservas de um hotel – Projeto de Desenvolvimento