Pontos de função – comparação

Damos uma olhada nas várias maneiras de medir o tamanho do software

Dimensionar software não é fácil, pois existem centenas de linguagens, arquiteturas e técnicas para escrevê-lo. A indústria tentou muitas abordagens diferentes ao longo dos anos, mas a mais eficaz é uma abordagem chamada dimensionamento funcional. Saber o tamanho geralmente é mais útil antes de o código ser escrito. O tamanho também pode ser um indicador da quantidade de funcionalidades de negócios envolvidas. Técnicas como contagem de histórias de usuários, contagem de pontos de história e os principais métodos de análise de pontos de função: pontos de função COSMIC e pontos de função tradicionais (IFPUG) são todos discutidos aqui. Também é possível avaliar o tamanho após o código ter sido escrito, o que geralmente é menos útil.

Direto ao ponto: recomendamos que você use pontos de função COSMIC na maioria dos casos. Por que? porque são válidos, confiáveis, consistentes, injogáveis, rápidos de medir e adequados ao trabalho Ágil, onde os requisitos completos podem não ser conhecidos antecipadamente.

Por que o dimensionamento do software é importante?

O desenvolvimento de software exige muita mão-de-obra e conhecimento. O maior fator de custo para o desenvolvimento de software geralmente é o esforço humano para criá-lo, projetá-lo e testá-lo. O que geralmente queremos saber é quanto esforço e quanto tempo levará para entregar. Existem muitos fatores que afetam o tempo e o esforço. O fator mais significativo é tamanho do software.  Então, vejamos as várias abordagens para dimensionar software. Muitas vezes confundimos dimensionamento com estimativa de esforço. Por exemplo, pontos da história e tamanho de camisetas são apenas estimativas de esforço, não tamanhos.

Linhas de código

Linhas de código são feitas de forma fácil e automática pela maioria das ferramentas de codificação. Existem dois valores principais, o número bruto de linhas utilizadas (LOC) e o número líquido de linhas de código funcional (SLOC).

Contar linhas de código tem mérito limitado no gerenciamento de projetos de software. Considere, por exemplo, dois desenvolvedores que escrevem 50 linhas de código por dia. Pode ser que um dos desenvolvedores escreva um código conciso e eficiente que faça bom uso dos recursos subjacentes da linguagem. Suas 50 linhas oferecem funcionalidades significativas, possivelmente até mesmo um aplicativo inteiro (minúsculo), enquanto o outro pode apenas realizar uma validação muito básica. Superficialmente, eles são tão produtivos quanto um ao outro, ambos escrevendo 50 linhas por dia. Esta é a principal razão pela qual limitamos o uso do SLOC para dimensionamento de software. RÁPIDO, INCONSISTENTE, ERRÔNEO

Contando histórias

Muitas pessoas são da opinião de que apenas contar o número de histórias é tão bom quanto qualquer coisa. Esta é uma abordagem não confiável, já que algumas histórias de usuários são empreendimentos de desenvolvimento significativos, poderíamos realmente chamá-las de épicas, enquanto outras histórias de usuários são tão triviais que não envolvem nenhuma funcionalidade reconhecível pelo usuário. A faixa que normalmente vemos é de 0 a 120 CFP. Como você pode ver, estamos usando a metodologia de dimensionamento COSMIC para validar se outras abordagens têm mérito. RÁPIDO, INCONSISTENTE, ERRÔNEO

Contando pontos de história

Os pontos da história são um proxy arbitrário para medição de tamanho que só deve ser usado dentro de uma equipe. Eles não são uma medida nem métrica válida para determinar o progresso da equipe. Lembre-se de que os pontos da história podem mudar com o tempo e são uma opinião inconsistente sobre a duração provável de alguma atividade. Eles são altamente jogáveis por aqueles que fornecem a contagem. A popularidade dos story points é um comportamento um tanto bizarro da maioria da indústria de software – sua popularidade não é merecida. Por outro lado, o COSMIC Sizing e o IFPUG Sizing são padrões ISO formais e consistentes para medir tamanho.

Uma história de usuário pode variar drasticamente em tamanho. Uma história pode ser entregue em minutos, outra pode exigir que uma equipe inteira trabalhe durante um mês. Contar histórias de tamanhos diferentes é uma indicação de progresso, mas não é uma medida válida de progresso.  LENTO, INCONSISTENTE, ERRÔNEO

Análise de Pontos de Função

Dimensionamento Funcional padrão ISO

A única forma consistente de medir o tamanho do software (a partir de 2023) é o dimensionamento funcional. Existem dois padrões principais para dimensionamento funcional:   Pontos de Função IFPUG (1ª Geração) e  Pontos de Função CÓSMICO Pontos (2ª Geração).

Ambos os padrões de Ponto de Função são maduros, válidos e comprovados (IFPUG:1974, COSMIC:1998). Eles são uma descrição consistente e centrada no usuário e uma medida de funcionalidade em termos de entradas e saídas e dados armazenados. Eles são contados examinando os requisitos e aplicando algumas regras/princípios para determinar os tipos de dados que são movidos e armazenados. Ambos os padrões são maduros, mantidos de forma independente e de aprendizagem gratuita ou barata. Recomendamos a metodologia de dimensionamento COSMIC de 2ª geração. As unidades da metodologia de dimensionamento COSMIC são o Ponto de Função COSMIC (CFP). O trabalho para realizar o dimensionamento de pontos de função é chamado de análise de pontos de função (APF).

Pontos de Função CÓSMICA. RECOMENDADO

Alguns dos principais benefícios do padrão COSMIC FP são:

1. O COSMIC Sizing é baseado em princípios de design de software. Como padrão, nenhum ajuste é necessário quando aplicado a diferentes tipos de software (codificação personalizada, middleware, aplicativos web, software multicamadas, software de sistema, sistemas embarcados ou projetos de data warehouse).
2. COSMIC nos dá uma definição de um único ponto de função, cada movimento de um grupo de dados Entrada, Saída, Leitura, Gravação conta como 1 CFP.
3. O CFP pode ser medido com precisão a partir de requisitos incompletos, o que os torna adequados para o Agile e para várias formas de trabalho Agile escalonado.
4. Os CFP são mais rápidos e fáceis de aprender do que o IFPUG FP. (1/3 do número de páginas para todo o plano de estudos da metodologia)
5. O COSMIC FP pode ser determinado automaticamente com um maior grau de precisão do que o IFPUG por meio de análise automatizada de requisitos.

Para saber mais sobre o Dimensionamento COSMIC recomendamos O Guia para Dimensionamento de Software por Charles Symons

Pontos de Função IFPUG

Dito isto, os FP COSMIC são preferíveis aos FP tradicionais do IFPUG, estes últimos beneficiam de maiores volumes de dados de referência publicados e disponíveis. A metodologia de dimensionamento do IFPUG foi desenvolvida na década de 1970, quando o design de software era menos estratificado e segregado do que é hoje em dia. Os padrões permanecem praticamente inalterados em relação ao seu conceito inicial. Gostamos do IFPUG FP, mas preferimos o COSMIC FP. Simple Function Points é uma aproximação do IFPUG FP adotado pela organização em 2019. ScopeMaster estima ambos IFPUG e PF simples.

Contando pontos de função manualmente

Até agora, a contagem de pontos de função era um processo manual trabalhoso. Você precisa ler os requisitos e depois registrar as contagens de pontos de função em papel ou em uma planilha. Contagens precisas e consistentes são alcançadas somente se a contagem for realizada por um especialista certificado e experiente em pontos de função. Em média, um medidor certificado pode medir até 2.000 FP/semana, o que equivale a cerca de $2m de software.  LENTO, PRECISO

Estimando o tamanho do ponto de função

Usando algumas regras práticas, as contagens estimadas de PF podem ser alcançadas observando uma série de fatores contribuintes. Se seu aplicativo for predominantemente um aplicativo do tipo banco de dados, você poderá contar o número de tabelas de dados do banco de dados mantidas pelo aplicativo. Você então multiplica o número de tabelas por 27-30 para obter uma estimativa do IFPUG. Esta é apenas uma das muitas regras práticas úteis e não deve ser considerada para nada além de um tamanho de alto nível. Velocidade de contagem: 5.000 – 50.000 FP/pessoa por semana  RÁPIDO, IMPRECISO

Pontos de função de backfiring de linhas de código

A maioria das linguagens de software publicou médias de linhas de código por ponto de função. Por exemplo, 50 linhas de Java equivalem, em média, a um ponto de função. Contar as linhas de código e dividir por esse número é chamado de “tiro pela culatra”. Isso é útil depois o código foi escrito. Você precisa ter cuidado com essa abordagem, especialmente ao usar grandes volumes de estruturas pré-escritas que podem precisar ser excluídas de uma contagem de código personalizada. Velocidade de contagem: até 5.000 FP/pessoa por semana.  RÁPIDO, IMPRECISOS, ERRÔNEO

Contagem automatizada de pontos de função do código

Agora é possível automatizar a contagem de pontos de função a partir do código. A empresa Cast Software desenvolveu um software que realizará uma contagem automatizada confiável de pontos de função com base no código do aplicativo existente. É necessário algum esforço para preparar o código para que possa ser interpretado e, a partir daí, uma contagem confiável pode ser alcançada. Isto é muito superior à abordagem de tiro pela culatra. Ele tem o benefício adicional de fornecer insights profundos sobre o código do aplicativo.   RÁPIDO, CONSISTENTE, PRECISO

Dimensionamento automatizado de pontos de função COSMIC

Usando o ScopeMaster® você pode se beneficiar de uma contagem automatizada de pontos de função COSMIC em questão de minutos. Ao analisar o texto dos requisitos do usuário, podemos detectar o tamanho funcional (movimentações de dados). O ScopeMaster® fornecerá um resultado consistente com uma precisão superior a 85% em comparação com uma contagem manual realizada por um medidor especializado.

Os resultados são consistente e transparente. Combinado com uma verificação manual por um especialista em pontos de função, vemos taxas de contagem de 10.000 – 20.000 FP/por homem-semana. (aproximadamente $10- $20m de software) RÁPIDO, CONSISTENTE, BASTANTE PRECISO

Algumas das análises de dimensionamento que ScopeMaster® gera automaticamente de suas histórias de usuário escritas.

Conclusão

Se você deseja determinar o tamanho de um aplicativo dos requisitos escritos você tem duas opções principais: contar os pontos de função manualmente ou usar o ScopeMaster® para contá-los para você. Se você já possui o código do aplicativo que deseja medir, existem opções adicionais: tiro pela culatra a partir das linhas de código, estimativa de componentes técnicos (por exemplo, com base em uma contagem de tabelas de banco de dados) ou observar a automação do dimensionamento funcional do CAST Software .