Contagem de pontos de função

Contagem de PF

Para se contar ponto de função é necessário seguir alguns passos, como mostra a Figura 1. O primeiro deles é determinar o tipo de contagem. É nesse passo que é determinado o que será medido, o tipo de contagem a ser usado para medir o projeto de software, tanto no processo como no produto. Três tipos de contagens são possíveis:

• Contagem de projeto de desenvolvimento;
• Contagem de projeto de melhoria (manutenção);
• Contagem de aplicação.

De maneira simplificada, o primeiro mede a funcionalidade fornecida aos usuários finais quando o projeto estiver pronto, no momento de sua instalação. Essa contagem também abrange conversão de dados necessários para implantação do software.

O segundo mede as modificações para uma aplicação já existente, o que inclui as funções incluídas, alteradas e excluídas do sistema pelo projeto, além das funções de conversão de dados. É importante lembrar que, sempre após uma contagem de manutenção e sua implantação, o número de pontos de função da aplicação deve ser atualizado de acordo com as alterações feitas na funcionalidade. Isso tem como objetivo manter a contagem de pontos de função (CPF) da aplicação sempre atualizada.

O terceiro e último tipo de contagem mede a funcionalidade fornecida ao usuário pela aplicação instalada e em produção para que a atual funcionalidade tenha uma medida.

O segundo passo para a contagem é a identificação do escopo da contagem e a fronteira da aplicação. É nesse passo que são delimitados o escopo do sistema objeto da avaliação e a sua fronteira. É nesse momento que são identificados todos os relacionamentos do sistema e/ou da funcionalidade que está sendo contada com o seu exterior (o que está fora da fronteira) e são identificadas as pertinências dos dados e os processos suportados pelo sistema/funcionalidade que está sendo contado (a).

A fronteira da aplicação define o que é externo para a aplicação. É a interface conceitual entre a aplicação e os usuários externos. O escopo define um conjunto ou subconjunto de software de tamanho conhecido.

O terceiro e quarto passos são a contagem das funções de dados e das funções de transação. São nesses passos que são contados os pontos de função não ajustados. Nessas etapas são consideradas:

• Funções de dados:
  o Arquivos Lógicos Internos (ALIs);
  o Arquivos de Interface Externa (AIEs);
• Funções de Transação:
  o Entradas Externas (EE);
  o Saídas Externas (SE);
  o Consultas Externas (CE).

Os ALIs são grupos de dados logicamente relacionados, ou informações de controle, mantidos dentro da fronteira da aplicação. A principal função de um ALI é agrupar os dados mantidos por um ou mais processos elementares da aplicação que está sendo contada. A Tabela 1 mostra a contribuição de ALI para a CPF.

Tabela 1. Contribuição de ALI

Os AIEs são grupos de dados logicamente relacionados, ou informações de controle, referenciados pela aplicação, mas mantidos dentro da fronteira da outra aplicação. A principal função de um AIE é agrupar logicamente dados referenciados por um ou mais processos elementares da aplicação. Isso significa que um AIE contado para uma aplicação deverá ser um ALI em outra. A Tabela 2 mostra a contribuição de AIE para a CPF.

Tabela 2. Contribuição de AIE

A complexidade dos ALIs e AIEs (Tabela 3) se dá em função do número de RLRs (tipos de registro elementar) e dos DERs (tipo de dado elementar).

Tabela 3. Complexidade de ALI e AIE

As EEs são processos elementares que processam dados ou informações de controle que vêm de fora das fronteiras da aplicação. A função primária de uma EE é manter um ou mais ALIs e/ou alterar o comportamento do sistema.

A complexidade da EE é dada em função do número de ALRs (tipos de arquivos referenciados ou arquivos referenciados) e dos DERs (tipo de dado elementar), como mostra a Tabela 4.

Tabela 4. Complexidade de EE

As SEs são processos elementares que enviam dados ou informações de controle para fora das fronteiras da aplicação. A função primária de uma SE é apresentar informação para o usuário através de processamento lógico exceto em recuperação de dados ou informação de controle. O processamento lógico tem que possuir pelo menos uma fórmula matemática ou cálculo, gerar dados derivados, manter um ou mais ALIs ou alterar o comportamento do sistema. A Tabela 5 mostra a contribuição de SE para a CPF.

Tabela 5. Tabela de Contribuição de SE

As CEs, como são conhecidas as Consultas Externas, são processos elementares que enviam dados ou informações de controle para fora das fronteiras da aplicação. A função primária de uma CE é apresentar informação para o usuário através da recuperação de dados ou informação de controle. O processamento lógico não deve possuir fórmula matemática ou cálculo e não deve gerar dados derivados. Nenhum ALI é mantido durante o processo ou o comportamento do sistema é alterado. A Tabela 6 mostra a contribuição de CE para a CPF.

A complexidade da SE e CE (Tabela 7) se dá em função do número de ALRs (tipos de arquivos referenciados ou arquivos referenciados) e dos DERs (tipo de dado elementar).

Tabela 6. Tabela de Contribuição de EE e CE

Tabela 7. Complexidade de SE e CE

O quinto passo para a contagem é o cálculo do Fator de Ajuste. Estes fatores estão relacionados com as características da aplicação. Ele é responsável pela correção das distorções da etapa anterior (cálculo das funções de dados e das funções de transação) e baseia-se nas características gerais do sistema onde são relacionados 14 itens que determinam o valor do nível de influência de cada um desses itens do dimensionamento do sistema. São eles:

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 (Flexibilidade).

Um peso, que varia de 0 (sem influência) a 5 (forte influência) deve ser atribuído a cada uma das GSCs – Características Gerais do Sistema, e a soma deles resulta no valor do TDI – Grau Total de Influência. As características são resumidas no fator de ajuste, que, quando aplicado, corrige o valor de Pontos de Função não ajustados em cerca de +-35%, criando o Ponto de Função Ajustado.

O sexto e último passo da contagem é o cálculo dos pontos de função ajustados. É nesse passo que é feita a correção de possíveis distorções ocorridas durante o cálculo dos pontos de função não ajustados, aproximando as medidas da situação real. Normalmente e contratualmente, os fatores de ajuste são iguais a 1 para que não influenciem nos pontos de função não ajustados.

A métrica de software e o SCRUM

O Scrum é uma metodologia ágil para a gestão, planejamento e desenvolvimento de projetos de software. Ele não define nem impõe ferramentas e/ou técnicas de desenvolvimento de sistemas, mas mostra como os times devem trabalhar em ambientes com frequentes alterações e com o surgimento de novos requisitos.

Ele é dividido em ciclos (normalmente mensal, porém é parametrizável de acordo com a necessidade de cada empresa) chamados sprints. São nesses sprints que são realizadas as atividades do projeto. Os papéis e responsáveis pelo Scrum são os Product Owners (POs), Scrum Masters e Scrum Team. Suas práticas são realizadas por etapas conhecidas como Planning Meeting, Daily Scrum, Review Metting e Retrospective (todas feitas para cada sprint). Também existem o Product Backlog e o Sprint Backlog, onde são listadas as atividades do projeto e serão separadas por sprints.

A velocidade de um profissional de TI pode ser calculada a partir do número de horas que a equipe utiliza para implementar um trabalho equivalente a um Ideal Day, que corresponde à quantidade de trabalho que um profissional (gerente, analista, desenvolvedor, teste, etc.) consegue finalizar em um dia de trabalho. Para isso, o cálculo é feito utilizando a seguinte fórmula:

DE = IED / 1 – IED_REAL%

Onde:

• DE = quantidade de dias estimada para concluir a tarefa;
• IED = prazo necessário para implementar a funcionalidade (prazo definido pela própria equipe);
• IED_REAL% = percentual que indica a estimativa de quanto tempo do dia o desenvolvedor ficará dedicado à implementação da funcionalidade.

Como aplicar isso em um caso real? Veja o Exemplo 2 da parte prática deste artigo.

Contagem Prática

Para uma visão mais prática do que foi apresentado até agora, serão feitas duas contagens: uma para exemplificar a técnica de análise por pontos de função com uma tela simples de cadastro de cliente e outra para exemplificar o relacionamento do Scrum à métrica de software através de uma tela de relatório de cadastro de cliente.

Exemplo 1 – Cadastro de Cliente

Este exemplo irá considerar a tela de Cadastro de Cliente apresentada na Figura 2.

Vamos passar por todos os passos somente a título de exemplificação.

1. Tipo da contagem

• Projeto de Melhoria (considerando que é o desenvolvimento de uma nova funcionalidade de aplicação já existente);

2. Identificação da fronteira da aplicação

• Cadastro de Clientes (Figura 2);

3. Contar Função de Dados

ALI -> Cliente -> Inclusão

DER (Nome, Tipo de Cliente – Física ou Jurídica, CNPJ, E-mail, Logradouro, Nº do Logradouro, Complemento, CEP, Cidade e UF);

Total de DER -> 10

RLR (Cliente);

Total RLR -> 1

4. Contagem das funções de transação

• Cadastrar Cliente

EE (mantém ALI e/ou altera o comportamento do sistema);

ALR (Cliente – ALI contado no passo anterior);

Total ALR -> 1

DER (Nome, Tipo de Cliente – Física ou Jurídica, CNPJ, E-mail, Logradouro, Nº do Logradouro, Complemento, CEP, Cidade e UF);

Total DER -> 10

5. Contagem de PF não ajustado

Extraídas a complexidade e o total de pontos de função tanto das funções de dados (ALIs e/ou AIEs) quanto das funções de transação (EEs, CEs e/ou EEs), é preciso calcular os pontos de função não ajustados através da multiplicação do número de funções identificadas para uma determinada complexidade por sua contribuição. Por fim, soma-se todos os pontos de função encontrados. Vejamos nosso exemplo do Cadastro de Cliente na Figura 3.

6. Cálculo do Fator de Ajuste

O cálculo do Fator de Ajuste é feito para cada aplicação, para cada contagem. É importante lembrar que os fatores mostrados estão relacionados com características da aplicação e podem influenciar no seu tamanho:

1. Comunicação de dados ->1

2. Processamento distribuído ->2

3. Performance ->3

4. Configuração do equipamento ->4

5. Volume de transações ->5

6. Entrada de dados on-line ->1

7. Interface com o usuário ->2

8. Atualização on-line ->3

9. Processamento complexo ->4

10. Reusabilidade >1

11. Facilidade de implantação ->1

12. Facilidade operacional ->2

13. Múltiplos locais ->3

14. Facilidade de mudanças (Flexibilidade) ->3

Fator de Ajuste = (NI * 0,01) + 0,65

Onde NI é o somatório da pontuação atribuída (no nosso exemplo, 35);

Fator de Ajuste = (35*0,01) + 0,65 = 1

Cálculo dos Pontos de Função Ajustados

Após os cálculos dos pontos de função não ajustados e do fator de ajuste, será calculado o ponto de função ajustado de acordo com a fórmula:

PF ajustado = (PF não ajustado + PF incluído + PF alterado atual – PF alterado anterior – PF excluído) X Fator de ajuste atual

Onde:

• PF ajustado: total de pontos de função da aplicação;
• PF não ajustado: total de pontos de função não ajustados da aplicação antes do projeto de manutenção (calculados na Figura 3);
• PF incluído: total de pontos de função não ajustados das funções que foram incluídas na aplicação;
• PF alterado atual: total de pontos de função não ajustados das funções que foram modificadas (após a modificação);
• PF alterado anterior: total de pontos de função não ajustados das funções que foram modificadas na aplicação (antes da modificação);
• PF excluído: total de pontos de função não ajustados das funções que foram removidas da aplicação;
• Fator de ajuste atual: valor do ajuste detectado após o projeto de manutenção (calculado no item anterior).

Pelo nosso exemplo:

PF ajustado = (13 + 0 + 0 – 0 – 0) X 1
  PF ajustado = 13

Dessa forma, teríamos que o tamanho da funcionalidade a ser implementada seria de 13 pontos de função.

Exemplo 2 – Relatório de Cadastro de Cliente

Para este exemplo (Figura 4), será utilizado apenas um sprint (definido com o prazo de 1 mês) para implementar a funcionalidade e entregá-la com teste concluído. A solicitação foi feita para um sistema já existente e em produção no cliente.

Será utilizado um Product Owner (PO) do cliente, um especialista que irá levantar, descrever e priorizar os requisitos e regras a serem desenvolvidos. O PO, junto com o stakeholder, definiu apenas 10 requisitos e o Scrum Master (SM) junto com o PO fizeram a lista de prioridades gerando, assim, o Product Backlog.

A previsão da métrica Ideal Day foi feita para cada atividade utilizando uma escala (0.25, 0.5, 0.75, 1, 1.25 e 1.5, etc.), por isso a definição de se fazer a funcionalidade em somente um sprint. Em codificação teremos 14,5 dias. O restante dos dias será para documentação, testes e eventuais correções de bugs encontrados pela equipe de testes.

Para o cálculo do Ideal Day, foi definido que seria considerada uma produtividade de 90% em uma jornada de 8 horas diárias. Com esses valores definidos, a fórmula apresentada na seção “A métrica de software e o SCRUM” foi aplicada e obteve-se:

  DE = 14,5/(1-90)
  DE = 16,29 dias

A métrica de Planning Poker foi aplicada e, após várias discussões, resultou em um total de 125 pontos. Para cada ponto, foi estimado um valor em hora com um total de 220 horas. O PO e o SM começaram o sprint e foi iniciada uma análise das informações discutidas na reunião de Sprint Planning Meeting para realizar a contagem de pontos de função. É muito importante lembrar que a análise, a contagem (feita normalmente pelo analista de requisitos, podendo muitas vezes exercer o papel de Scrum Master e/ou PO) e o desenvolvimento são realizados em paralelo e, portanto, enquanto a contagem de PF está sendo feita o desenvolvimento também está em andamento.

Agora veremos como ficaria nossa estimativa utilizando a APF. Por questões didáticas, a contagem será passada por todos os passos, como no Exemplo 1:

1. Tipo da contagem

• Projeto de Melhoria (considerando que é o desenvolvimento de uma nova funcionalidade de aplicação já existente);

2. Identificação da fronteira da aplicação

• Relatório de Cadastro de Clientes (Figura 4);

3. Contar Função de Dados

O ALI não é contado, pois já foi contado na contagem do cadastro do Cliente.

4. Contagem das Funções de Transação

• Emitir Relatório de Cliente

CE (sem cálculo matemático nem dados derivados);

ALR (Cliente – ALI contado no cadastro do cliente);

Total ALR ->1

DER (Número do cliente, Nome completo do cliente, Telefone – com DDD, Celular – com DDD, Cidade, UF, Nome de Contato, Data de geração do relatório);

Total DER ->8

5. Contagem de PF não ajustado

Extraídas a complexidade e o total de pontos de função tanto das funções de dados (ALIs e/ou AIEs) quanto das funções de transação (EEs, CEs e/ou EEs), é preciso calcular os pontos de função não ajustados. Vejamos nosso exemplo do Relatório de Cadastro de Cliente na Figura 5.

6. Cálculo do Fator de Ajuste

O cálculo do fator de ajuste é feito para cada aplicação, para cada contagem. É importante lembrar que os fatores mostrados estão relacionados com características da aplicação e podem influenciar no seu tamanho:

1. Comunicação de dados ->1

2. Processamento distribuído ->4

3. Performance ->2

4. Configuração do equipamento ->3

5. Volume de transações ->4

6. Entrada de dados on-line ->1

7. Interface com o usuário ->2

8. Atualização on-line ->4

9. Processamento complexo ->4

10. Reusabilidade ->1

11. Facilidade de implantação ->1

12. Facilidade operacional ->2

13. Múltiplos locais >3

14. Facilidade de mudanças (Flexibilidade) ->4

Fator de Ajuste = (NI * 0,01) + 0,65

Onde NI é o somatório da pontuação atribuída (no nosso exemplo, 36)

Fator de Ajuste = (36*0,01) + 0,65 = 1,01

7. Cálculo dos Pontos de Função Ajustados

Após os cálculos dos pontos de função não ajustados e do fator de ajuste, será calculado o ponto de função ajustado de acordo com a fórmula apresentada no Exemplo 1:

Pelo nosso exemplo:

  PF ajustado = (3 + 0 + 0 – 0 – 0) X 1,01
  PF ajustado = 3,03

Dessa forma, teríamos que o tamanho da funcionalidade a ser implementada seria de 3,03 pontos de função.

Podemos concluir que o ponto de função é uma métrica focada no usuário (qualquer pessoa ou coisa que se comunica ou interage com o software a qualquer momento). O Scrum, por outro lado, foca basicamente na definição do prazo segundo informado pelo desenvolvedor e pode variar de um para outro. Dessa forma, seu uso não pode ser uma base para definição de prazo e/ou custo para a gerência.

O foco da contagem de PF é a visão do usuário, portanto somente são contados os Requisitos Funcionais, aqueles percebidos e reconhecidos por ele. Eles descrevem o que o software deverá fazer em termos de tarefas e serviços. O foco da estimativa do Scrum leva em consideração quanto tempo o profissional irá gastar para implementar, documentar e testar determinada funcionalidade.

Muitos profissionais de TI (desenvolvedores, gerentes, etc.) criticam a análise por pontos de função devido à abrangência da contagem. Mesmo assim, ela é uma métrica muito difundida, padronizada e uma das mais utilizadas atualmente. E o principal, não leva em consideração nem a linguagem de programação nem o “feeling” do profissional no tempo de desenvolvimento, como muitas outras estratégias.

Podemos concluir também que as contagens de PF foram bastante diferentes das obtidas através da técnica apresentada do Scrum, pois a estimativa do Ideal Day foi muito superior ao calculado pela APF. Contudo, é possível realizar uma junção das duas técnicas, onde poderia ser estimada a complexidade, levando em consideração as estimativas feitas pelos desenvolvedores, e o tamanho, levando em consideração a visão do usuário.

Links Úteis

• Como fazer um CRUD 1:N no Laravel:
  Neste curso veremos como desenvolver um CRUD em Laravel com duas entidades que se relacionam de forma 1N.
• ASP.NET MVC ViewBag: Como enviar dados do controller para a view:
  Aprenda a utilizar o ViewBag, um mecanismo para efetuar o tráfego de dados do controller para a view no ASP.NET MVC.
• Mapeamento 1:N no Entity Framework:
  Neste curso aprenderemos a implementar relacionamentos do tipo 1:N (um para muitos) utilizando o Entity Framework.

Saiba mais ;)

• Engenharia de Software:
  Engenharia de software é uma área da computação voltada à especificação, desenvolvimento, manutenção e criação de sistemas de software, com a aplicação de tecnologias e práticas de gerência de projetos e outras disciplinas, visando organização, produtividade e qualidade.
• Gestão de Projeto:
  Neste guia você encontrará o conteúdo que precisa para saber como gerenciar projetos de software. Confira abaixo a sequência de posts que te guiarão do básico ao avançado em Gestão de Projetos.
• Scrum:
  Com o aumento das exigências dos clientes e prazos cada vez mais curtos, encontrar opções para possibilitar o projeto, implementação e implantação de um sistema com mais qualidade e em menos tempo é fundamental.