Qual a utilidade dos pontos de função? [fechadas]

Quão útil é medir pontos de função ?

Usamos pontos de função no meu novo trabalho. Já ouvi falar de pontos de função, mas não tive nenhum treinamento ou experiência ... mas não tenho muita confiança em coisas que não podem ser explicadas de forma sucinta.

Pessoalmente, nunca encontrei uma resposta explícita à pergunta "O que é um ponto de função?" Sem isso, estou realmente hesitante sobre qualquer metodologia de estimativa que afirme fazer algo com os Pontos de Função.

A parte mais importante de uma metodologia séria de estimativa de software é "recalibração periódica para valores reais", o que significa que você faz sua estimativa, anota-a e, quando o projeto termina, você compara seus resultados reais com sua estimativa e , se necessário, revise seu processo de estimativa. INCLUÍDO NO QUE está comparando suas ENTRADAS ao seu processo de estimativa com as ENTRADAS REAIS.

Se, por exemplo, você estimar SLOC (Source Lines of Code), e a partir daí, você precisa comparar o SLOC fornecido real com o SLOC estimado e ver se, até que ponto, onde e por que se desviou. Um estimador que prevê horas-homem perfeitamente, considerando uma estimativa precisa e exata de SLOC, não fará nenhum bem se suas estimativas de SLOC forem inúteis. Lixo dentro, lixo fora. (O mesmo se aplica aos pontos de função.)

Se os dados reais do SLOC (ou ponto de função) corresponderem às estimativas iniciais, você poderá analisar os dados reais dos custos com base nos custos estimados e ajustar os parâmetros do estimador para melhorar seus resultados. A General Dynamics / Fort Worth Division fez esse exercício, em detalhes, no início dos anos 80, para o desenvolvimento de software F-16C / D e, durante vários anos, apostou rotineiramente nos resultados da empresa com base nessas estimativas. GD / FW foi a vaca leiteira de GD por um bom tempo, mantendo o resto da empresa à tona, então eles devem estar fazendo algo certo.

E observe que os requisitos e a fluência dos recursos são O INIMIGO da estimativa de software.

(Esta é uma edição posterior.) O último ponto de Bernd merece uma resposta. Ele pergunta o que deve ser feito sobre os projetos que chegam mais cedo e não gasta todas as horas de trabalho que lhes são alocadas.

Esse é um erro de estimativa tanto quanto a programação (muito mais comum) excede. O fato é que: se todos os seus projetos estão ultrapassando o cronograma, sua equipe de estimativa não está fazendo o trabalho deles.

Se sua equipe de estimativas está fazendo tudo certo e seus gerentes estão fazendo tudo certo, então você terá alguns projetos no início, juntamente com os que chegam tarde. Estimativas são probabilidades. Proteja seu estimador para eliminar os atrasos no cronograma e, POR DEFINIÇÃO, você aumenta a probabilidade de ultrapassagens no cronograma. Se a sua gestão exige horários e estimativas com zero de possibilidade de encaixe, então você vai estar entregando horários que vai ser superado, garantido, e então você vai começar a ver as demandas para Marchas da Morte, e então você começa a ver renúncias, e as suas derrapagens obter muito, muito pior, quando você tenta recrutar substitutos (e a notícia é de que sua empresa é uma loja de roupas esportivas).

Ao lidar com o escopo de um projeto, geralmente é melhor usar uma medida de Pontos de Função em vez de Linhas de Código . Como os projetos de software podem ter mais de milhões de LOC (incluindo LOC nas bibliotecas), o número se torna relativamente sem sentido.

Como você mede o LOC se está chamando a funcionalidade de bibliotecas? Você inclui o LOC das bibliotecas? Se você não incluir o LOC das bibliotecas, seu chefe não considera que está escrevendo o suficiente?

Geralmente, é melhor dizer "completei a funcionalidade XXX" em vez de "escrevi XXX linhas de código".

Mas eu sugiro que você veja por si mesmo. É mais fácil estimar pontos de função ou linhas de código? Conecte esses resultados ao modelo COCOMO II e veja qual é mais fácil de usar.

Além disso, este manual do COCOMO II fornece uma descrição detalhada dos pontos de função e LOC na página 11. Esperamos que seja o suficiente para você continuar.

Eu trabalho em uma organização na qual introduzimos pontos de função para calcular projetos de preço fixo, ou seja, cliente e contamos com base em especificações, concordamos com a contagem e, em seguida, multiplicamos o #FP com um preço de FP para determinar o preço do projeto. Tudo isso em um ambiente com rotatividade anual de dois milhões de euros em projetos. A intenção é remover a ambiguidade e a negociação da determinação de preços, que era uma causa constante de atrito.

Fizemos uma calibração inicial, avaliando cerca de 2 anos de histórico do projeto no valor de dois milhões de euros.

Vimos claramente que #FP e custos de projeto se correlacionam de maneira muito indireta. Desvios de +/- 50% são razoavelmente possíveis. No entanto, vemos (bem, esperamos, ou melhor: esperamos) que, a longo prazo, a contagem de pontos de função e os custos do projeto converjam.

Agora, estamos lançando isso na organização e na experiência (de um ponto de vista superior):

• Discussões sobre aplicações de regras de contagem de FP. Existem normas sobre isso, no entanto, elas estão sujeitas a negligência, se não se puder discutir diretamente sobre preços.

• Impressões dos clientes de que os preços subiram, apesar dos esforços que gastamos e estão gastando em calibração e verificação de calibração. O motivo suspeito é que esse procedimento torne os custos brutalmente claros, sem maneira de ocultar, mudar ou cobrir custos em alguns projetos "não pergunte" ou estratégicos.

• Necessidade de lidar com projetos que não cobrem seus custos (50% de redução ...)

Eles parecem ser marginalmente úteis para expressar a complexidade de um determinado sistema / componente e podem ajudar os gerentes / equipes a distribuir o trabalho, mas não são realmente mais úteis do que quaisquer outras métricas sintéticas / arbitrárias (SLOC, Complexidade Ciclomática etc.) .) Ou seja, eles podem fornecer uma indicação da quantidade relativa de esforço necessária para partes específicas de um sistema, mas não há como mapeá-las para estimativas concretas.

O uso de pontos de função em favor de linhas de código procura resolver vários problemas adicionais:

• O risco de "inflação" das linhas de código criadas, reduzindo assim o valor do sistema de medição, se os desenvolvedores forem incentivados a serem mais produtivos. Os defensores do FP se referem a isso como medindo o tamanho da solução em vez do tamanho do problema.

• As linhas de código (LOC) medem recompensas em idiomas de baixo nível, porque são necessárias mais linhas de código para fornecer uma quantidade semelhante de funcionalidade a um idioma de nível superior. C. Jones oferece um método para corrigir isso em seu trabalho.

• As medidas de LOC não são úteis durante as fases iniciais do projeto, onde estimar o número de linhas de código que serão entregues é um desafio. No entanto, os Pontos de Função podem ser derivados de requisitos e, portanto, são úteis em métodos como estimativa por proxy.

Fugir.

Na minha experiência, as empresas que vi usam pontos de função estão apenas um passo acima da pura loucura.