Qual a média de valor por ponto de função, e se valeu a pena?  XML
Índice dos Fóruns » Metodologias de Desenvolvimento e Testes de Software
Autor Mensagem
faelcavalcanti
GUJ Ranger
[Avatar]

Membro desde: 03/05/2006 13:16:25
Mensagens: 960
Localização: Recife-PE
Offline

Bem após receber um boletim da powerlogic, fiquei surpreso com a seguinte citação:

Boletim divulgado hoje pela PowerLogic wrote:A Powerlogic lança a 1ª Fábrica Nacional de Software, especializada em projetos Java EE Open Source utilizando o jCompany Developer Suite como o padrão de desenvolvimento. Em conjunto com sua rede nacional de parceiros, a Fábrica Nacional de Software possui capacidade instalada de produção acima de 20 mil Pontos de Função/mês.

Confira as vantagens: Liberdade de escolher os fornecedores, padrão único de desenvolvimento, capacidade de entrega, transferência tecnológica, presença nacional e garantia de qualidade.

E o melhor: Ponto de função a partir de R$ 180,00.

Então me perguntei qual a média de valor que algumas empresas estão adotando como padrão no custo por ponto de função, e gostaria de abrir um debate com amigos do guj a respeito do que vocês tem visto por aí sobre:

1. Qual média de valor por ponto de função e quais critérios levaram a este valor ? ( ou seja, como você ajustou seu taxímetro )
2. Valeu a pena desenvolver software por ponto de função ?


--
http://faelcavalcanti.wordpress.com/ :: http://pe.debianbrasil.org/
--
Acredite um pouco mais na força de sua própria intuição. Muitas vezes deixamos de realizar algo de bom ou que nos favoreça simplesmente porque achamos tudo muito difícil e por isso nem começamos. Moral da história: A vida é o caminho e não o destino, você é o arquiteto do seu caminho!
--
Obrigado, Rafa Rocha!
[WWW]
lavh
GUJ Master

Membro desde: 30/07/2006 16:09:55
Mensagens: 1311
Offline

Depois as revistas fazem reportagens deste tipo:http://www.guj.com.br/posts/list/63476.java

e o pessoal acha ruim....
thingol
Moderador

Membro desde: 29/07/2004 16:10:13
Mensagens: 17572
Offline

Muitos clientes exigem que seus fornecedores orcem seus sistemas em pontos de função, até para poderem bater com as estimativas de seus próprios analistas.
É o caso do Bradesco e da Caixa.
Isso deve ser ajustado conforme a tecnologia empregada; um ponto de função em ASP tem um determinado valor em reais e um ponto de função em C++/MFC tem outro - e é por isso que certas tecnologias são sutilmente "desencorajadas" até porque não se tem um histórico bom para elas, ou porque o histórico delas prova que as estimativas são muito furadas - pense bem se é fácil vender um sistema em Scala/Lift para um lugar que só costuma comprar sistemas em JSP ou ASP, ou um sistema em C++ em um lugar onde todos os projetos em C++ estouraram o prazo ou saíram muito caro.
Agora, se você como profissional orçou seu software em pontos de função, é adequado ver se foi justo com você - manutenção de sistemas mal-feitos, por exemplo, tende a ter poucos pontos de função (até porque é calculado sobre a diferença - supõe-se que você, ao implementar novas funcionalidades, pouco terá de mexer nas antigas) e dar muito trabalho.




[WWW]
faelcavalcanti
GUJ Ranger
[Avatar]

Membro desde: 03/05/2006 13:16:25
Mensagens: 960
Localização: Recife-PE
Offline

sei que estou devendo a tempo, mas ressuscitei, devido ao tópico do colega que também respondi sobre o assunto!

thingol wrote:Agora, se você como profissional orçou seu software em pontos de função, é adequado ver se foi justo com você - manutenção de sistemas mal-feitos, por exemplo, tende a ter poucos pontos de função (até porque é calculado sobre a diferença - supõe-se que você, ao implementar novas funcionalidades, pouco terá de mexer nas antigas) e dar muito trabalho.

concordo que, em alguns casos, não é justo no lado do fornecedor, quando bugs, refactories, e mudanças existem.

mas, eu considero como ponto positivo desta métrica, no lado do cliente, pois imagine, um combo que possui regra de negócio associada, e este é utilizado em 10 telas diferentes. na abordagem APF, somente é feito uma contagem para este combo. se existir bugs, dependendo da sua implementação e arquitetura, você pode estar com sérios problemas!

o cliente não deve ser responsável por pagar uma taxa de risco de débito técnico que a equipe venha a desenvolver! (onde equipe = lado tecnico + gerencial + cultural)
[WWW]
DaviPiala
Virtual Machine Man
[Avatar]
Membro desde: 17/08/2007 19:17:35
Mensagens: 598
Localização: São Paulo
Offline

Esses dias eu participei de uma proposta baseada em pontos de função, fiquei surpreso pela forma como o pessoal orçou todas as custas do projeto..

Fael, eu fiquei em dúvida no exemplo, o certo não seria cobrar a combo em todas as telas?? Digo isso porque nesse meu primeiro contato com AFP o pessoal desconsiderou as funcionalidades que poderiam ser utilizadas, foi uma analise feita apenas em cima da navegação de telas e funcionalidades presentes em telas, multiplicando pelo fator no caso horas da tecnologia usada.

Outra coisa R$ 180,00 por ponto tá barato d+, imaginem o resultado que será entregue..

Si temi more regat
Efamima dove tore
Infata dio re
Infa lati plastire
alanlohse
HelloWorld

Membro desde: 01/10/2009 17:06:59
Mensagens: 14
Offline

Infelizmente hoje em dia estão querendo desvalorizar o trabalho dos programadores.

Mas a verdade é que ninguém além de um bom programador sabe o que é implementar uma regra complexa.

APF não é capaz de avaliar realmente o verdadeiro valor de um software, uma vez eu implementei uma funcionalidade de mesclar documentos (odt) anexados com dados do banco em um sistema web com uma interface legal e contou igual a um botão qualquer na tela.

sergiotaborda
GUJ Expert
[Avatar]

Membro desde: 22/03/2005 20:57:48
Mensagens: 4080
Offline

Por favor leiam : Software Estimation: Demystifying The Black Art

Para fazer uma boa estimativa vc precisa de contar, calcular e julgar. Nessa ordem. Quando se exerce julgamento ele deve ser feito
por quem irá fazer o trabalho. APF falha neste ponto. Quem julga não é quem faz o trabalho. Então uma coisa que para o funcional parece simples é cotada baixo com fator de multiplicação baixo não importando o que realmente terá que ser feito. Às vezes o funcional/gerencial comete o erro de contar para que não se saia de um orçamento pre-determinado viciando os calculos.

Moral da historia APF não funciona. Nunca funcionou e nunca funcionará. A razão é simples: não leva em consideração a opinião dos desenvolvedores e a sua experiencia e entendimento do problema.

This message was edited 1 time. Last update was at 15/12/2009 10:37:01


JavaBuilding : construções em java



Blog do MiddleHeaven
Lista de Discussão do MiddleHeaven
[WWW]
marcosalex
GUJ Expert

Membro desde: 20/02/2008 12:32:59
Mensagens: 3622
Offline

sergiotaborda wrote:
Moral da historia APF não funciona. Nunca funcionou e nunca funcionará. A razão é simples: não leva em consideração a opinião dos desenvolvedores e a sua experiencia e entendimento do problema.


Quem disse que isso é regra? Não levar em conta o desenvolvedor não tem nada a ver com ponto de função, qualquer outra forma de estimativa pode cometer o mesmo erro ou não.
[ICQ]
andre_salvati
GUJ Master

Membro desde: 02/06/2005 16:28:38
Mensagens: 1122
Offline

sergiotaborda wrote:Por favor leiam : Software Estimation: Demystifying The Black Art

Moral da historia APF não funciona. Nunca funcionou e nunca funcionará. A razão é simples: não leva em consideração a opinião dos desenvolvedores e a sua experiencia e entendimento do problema.


É verdade que não funciona mesmo. Mas o motivo é outro: os números saem da cartola. Se vc perguntar para um especialista em PF pq uma Entrada Externa vale X e uma Consulta Externa vale Y, nem ele sabe te responder.

http://twitter.com/afsalvati
https://www.linkedin.com/in/andresalvati
sergiotaborda
GUJ Expert
[Avatar]

Membro desde: 22/03/2005 20:57:48
Mensagens: 4080
Offline

marcosalex wrote:
sergiotaborda wrote:
Moral da historia APF não funciona. Nunca funcionou e nunca funcionará. A razão é simples: não leva em consideração a opinião dos desenvolvedores e a sua experiencia e entendimento do problema.


Quem disse que isso é regra? Não levar em conta o desenvolvedor não tem nada a ver com ponto de função, qualquer outra forma de estimativa pode cometer o mesmo erro ou não.


Não , não pode. Veja bem, PF é um calculo baseado em contar quantas X, y e Z vc tem, atribuir pesos, atribuir factores, colocar numa calculadoras e dar à manivela. Ninguem pergunta ao desenvolvedor a sua estimativa.

Por isso que eu falei para ler o livro. Sempre que vc não pergunta à pessoa que vai fazer o serviço a opinião dela, vc não tem uma estimativa séria. Portanto, não levar em conta esse input é o tendão de aquiles do APF que implica na sua invalidade teorica. Ou seja, mesmo em teoria APF não funciona. Se não funciona em teoria, qualquer prática não funcionará.

This message was edited 1 time. Last update was at 17/12/2009 16:26:01


JavaBuilding : construções em java



Blog do MiddleHeaven
Lista de Discussão do MiddleHeaven
[WWW]
Luca
Moderador
[Avatar]

Membro desde: 06/09/2002 14:30:10
Mensagens: 5818
Localização: São Paulo/SP ou Paraty/RJ
Offline

Olá

sergiotaborda wrote:Por favor leiam : Software Estimation: Demystifying The Black Art

Para fazer uma boa estimativa vc precisa de contar, calcular e julgar. Nessa ordem. Quando se exerce julgamento ele deve ser feito
por quem irá fazer o trabalho. APF falha neste ponto. Quem julga não é quem faz o trabalho. Então uma coisa que para o funcional parece simples é cotada baixo com fator de multiplicação baixo não importando o que realmente terá que ser feito. Às vezes o funcional/gerencial comete o erro de contar para que não se saia de um orçamento pre-determinado viciando os calculos.

Moral da historia APF não funciona. Nunca funcionou e nunca funcionará. A razão é simples: não leva em consideração a opinião dos desenvolvedores e a sua experiencia e entendimento do problema.


Assino embaixo. Nunca funcionou e não funciona, principalmente com sistemas atuais que exigem no mínimo umas 3 ou 4 linguagens, cada uma com um monte de linhas a escrever: HTML, Javascript, no mínimo uma linguagem de programação e talvez mais XML, SQL, expressão regular, etc. Ás vezes o trabalho de escrever uma WSDL é maior do que escrever 1000 linhas do antigo C.

E mesmo nos tempos do velho C, para que os chutes baseados em pontos de função funcionassem, era preciso um monte de ajustes meio no olho.

O livro do Steve McConnel (Software estimation demystifying the black art) é um clássico e deve ser muito bom. Mas há um livro curtinho sobre este mesmo assunto disponível free: Don?t Just Roll the Dice
http://www.neildavidson.com/dontjustrollthedice.html

[]s
Luca

Dare Obasanjo (Program Manager at Microsoft)
"The folks I know from across the industry who have to build large scale Web services on the Web today at Google, Yahoo!, Facebook, Windows Live, Amazon, etc are using RESTful Web services. The only times I encounter someone with good things to say about WS-* is if it is their job to pimp these technologies or they have already "invested" in WS-* and want to defend that investment."


CEP, JMS, JMX e coisas afins (ou não)
http://lucabastos.blogspot.com/
[Email] [WWW]
sergiotaborda
GUJ Expert
[Avatar]

Membro desde: 22/03/2005 20:57:48
Mensagens: 4080
Offline

Luca wrote:
O livro do Steve McConnel (Software estimation demystifying the black art) é um clássico e deve ser muito bom. Mas há um livro curtinho sobre este mesmo assunto disponível free: Don?t Just Roll the Dice
http://www.neildavidson.com/dontjustrollthedice.html


Esse livro também é muito bom, mas é mais comercial. Tem mais a ver com preço e menos a ver com custo e nada a a ver com estimativas. É sobre como valorizar o produto e vender o mais caro possivel

JavaBuilding : construções em java



Blog do MiddleHeaven
Lista de Discussão do MiddleHeaven
[WWW]
marcosalex
GUJ Expert

Membro desde: 20/02/2008 12:32:59
Mensagens: 3622
Offline

sergiotaborda wrote:
Não , não pode. Veja bem, PF é um calculo baseado em contar quantas X, y e Z vc tem, atribuir pesos, atribuir factores, colocar numa calculadoras e dar à manivela. Ninguem pergunta ao desenvolvedor a sua estimativa.

Por isso que eu falei para ler o livro. Sempre que vc não pergunta à pessoa que vai fazer o serviço a opinião dela, vc não tem uma estimativa séria. Portanto, não levar em conta esse input é o tendão de aquiles do APF que implica na sua invalidade teorica. Ou seja, mesmo em teoria APF não funciona. Se não funciona em teoria, qualquer prática não funcionará.


Mas quem atribui os pesos e fatores geralmente é o desenvolvedor, isso que eu quis dizer. Não é pela falta de opinião dele que não funciona, mas pelo motivo de tentar achar uma regra em uma coisa que é empírica. É a mesma coisa de tentar fazer um manual de administração ou um passo-a-passo de marketing. São coisas que não tem um fórmula exata.
[ICQ]
mochuara
GUJ Master
[Avatar]
Membro desde: 20/05/2009 11:21:32
Mensagens: 1776
Offline

Se estimativas funcionassem em desenvolvimento de software ela teria outro nome, portanto não perca tempo com elas...

Se não houver nada mais importante do que ficar estimando quando aquela especificação de 50 páginas de requisitos vai ficar pronta é porque vc esta usando waterfall da maneira errada (antes que a trupe dos agilistas atire pedra, não há nada de errado com waterfall em si, mas sim das pessoas que usam-a como desculpa pra ficar redigindo documentos e fazendo estimativas ao invés de entregar software).

This message was edited 1 time. Last update was at 19/12/2009 10:03:22

 
Índice dos Fóruns » Metodologias de Desenvolvimento e Testes de Software
Ir para:   
Powered by JForum 2.1.8 © JForum Team