Bem após receber um boletim da powerlogic, fiquei surpreso com a seguinte citação:
[quote= Boletim divulgado hoje pela PowerLogic]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.[/quote]
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:
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 )
Valeu a pena desenvolver software por ponto de função ?
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.
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)
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…
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.
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.
[quote=sergiotaborda]
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.[/quote]
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.
[quote=sergiotaborda]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.[/quote]
É 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.
[quote=marcosalex][quote=sergiotaborda]
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.[/quote]
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. [/quote]
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á.
[quote=sergiotaborda]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.[/quote]
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
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
[quote=sergiotaborda]
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á.[/quote]
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.
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).
