BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Estimativa de tempo e custo realmente funcionam?

por Pedro Mariano em 28 Jan 2011 |

Sempre houve um grande dilema entre a estimativa de prazo e de dinheiro que envolve um projeto de TI,  reclamações por ambas as partes cliente/desenvolvedores justificando que tal análise ou estimativa não era exata(bem, uma estimativa já não é exata por definição) também é algo frequente. Porém será que métodos como APF(análise de ponto de função) não podem ajudar quando o assunto é gerar uma estimativa?

Foi com uma indagação parecida que Plínio Marco Canto começou uma discussão no fórum de arquitetura Tectura, ele perguntou:

Certo dia um diretor, muito sagaz exclama a seguinte frase; 
“Agora já sei como justificar os prazos de nossos projetos!!! ANALISE DE PONTO DE FUNÇÃO!”

Entendendo a pressão que ele deva sofrer para justificar o investimento na área de TI e tendo que fugir obrigatoriamente do chutômetro, “acho que levarei 312 jornadas para fazer isso…” ¬¬

Será que a Analise de Ponto de Função realmente ajudaria nesse caso? Alguém já aplicou essa teoria na pratica? Existem outras formas de se assegurar o tempo estimado para um projeto?

Com certeza muitos desenvolvedores já passaram por situação semelhante, entretanto a utilidade de se estimar utilizando APF é um tanto quanto questionável como afirma Breno Martins:

Desenvolvimento de sistemas, ao menos no meu ponto de vista, é algo empírico e pronto! Não acredito numa correta mensuração em um processo empírico e não acho necessário.

Rubem Azenha afirma que esse tipo de análise serve apenas para você ter um pouco mais de "gordura" e que detalhes de implementação  contribuem para que sua estimativa ganhe números cada vez mais dispersos da realidade:

[...] APF serve pra jogar o custo do projeto na estratosfera pra de dar uma boa “gordura”. Uma mesma funcionalidade pode ser uma tela simples com alguns campos ou uma tela monstruosa, com drag’n’drop, ajax, validação no cliente, etc. Por isso é impossível fazer uma correlação entre funcionalidade => numeros de pontos de função => horas necessárias para desenvolver a funcionalidade sem detalhar a funcionalidade…

APF só serve para você dar a impressão pro seu cliente que você esta usando algum método cientifico para estimar o “esforço” do seu projeto (não me venha com essa que esforço != custo != prazo… no fim a estimativa vai de esforço vai virar custo e prazo, principalmente por que quem acredita em APF acredita que 9 mulheres fazem 1 filho em 1 mes…).

Você pode ser honesto com o seu cliente e dizer que não tem como estimar o projeto se ele for muito grande. Ou você pode tentar enganar ele (e a si mesmo) com APF.

Guilherme Silveira concorda com Rubem Azenha e diz que uma melhor "estimativa" seria analisar a velocidade do seu time que, muitas vezes, pode oferecer dados mais realísticos:

Como o Rubem citou, uma estmativa é uma estimativa. Como ela não é baseada em experiências anteriores (não se analisa os erros de estimativa da mesma equipe no projeto anterior para acertar nessa), os mesmos erros se repetem a cada nova estimativa de projeto. As mesmas falhas surgem, o mesmo atraso, a mesma reclamação.

Por isso que a velocidade, que diz algo de acordo com os erros e acertos da equipe atual, é mais realista.

O fato é que grandes empresas e orgãos do governo precisam de um projeto de escopo fechado e, para que isso aconteça, precisamos oferecer prazo e custo para os mesmos. Se esses cliente fossem flexíveis ao p0nto de aceitarem projetos de escopo aberto, talvez os dois lados sairiam ganhando, entretanto sabemos que isso é quase impossível. Dado esse cenário e sabendo que, hoje em dia, todos os métodos de estimativa que conhecemos são um tanto quando inexatos e trabalhosos, então como oferecer para nossos clientes tal prazo e custo?

E você leitor, qual dica daria para aqueles que precisam estimar o seu projeto? Você concorda que a estimativa é algo falho e serve apenas para oferecer números, mesmo que não exatos para os clientes?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Pontos de Caso de Uso by Vinicius Serpa

Estou usando Pontos de Caso de Uso (PCU) em alguns projetos e o que tenho observado é que o resultado sempre me parece superestimado. Sempre que uso o feeling chego a um prazo mais curto. Depois, na prática, o tempo de desenvolvimento acaba se aproximando do estimado com o PCU, e se eu tivesse utilizado meu feeling o prazo teria estourado.

Isso foi comentado pelo Brooks em seu livro Mítico Homem-Mês, nós temos a tendência de fazer uma estimativa otimista sobre uma solução para um problema. Então, se existe um cálculo que me ajude de alguma forma a chegar num valor para o prazo eu o utilizo. Nos casos em que uso outras tecnologias como Ajax, JQuery, etc, eu altero o calculo para mais complexo na tabela de ajustes, presente no método do cálculo.

APF by Camilla Gomes

Estou estudando APF e acredito que seja importante fazer algumas considerações.
A APF não é uma métrica para definir o tempo de desenvolvimento de uma aplicação, na verdade ela mede o tamanho funcional do aplicativo sob o ponto de vista do usuário.
Os pontos de função não medem diretamente o esforço ou custo. Mas o tamanho funcional em conjunto com outras váriáveis (cabe aqui incluir experiências de projetos anteriores) pode ser usado para ESTIMAR o esforço e o custo.
Estimativa quer dizer medida aproximada.
Não é possivel assegurar o tempo necessário para um projeto porque ele é estimado e não medido.

Re: APF by Alysson Bruno

Concordo com a Camila, o problema é que o pessoal confunde. APF é para medir o tamanho FUNCIONAL do sistema, e nisto ela (a análise) é bem objetiva e científica, uma vez que retira qualquer vies tecnológico da medição.

Agora, isso é como medir o tamanho de uma casa, se eu pergunto a um construtor quanto custa e quanto tempo demora para construir uma casa de 200m² ele me responderá: "-Depende. Qual o padrão de acabamento? É sobrado? Como é o terreno?", você respondendo a estes detalhes da construção ele poderá lhe dar uma estimativa bem realista do custo e do tempo gasto. Claro que quanto mais ele conhecer do seu projeto, mais aproximado será sua estimativa.

É a mesma coisa para a questão de homens/mês de trabalho, se o construtor lhe falar que esta casa em questão demorará X meses para ser terminada, com Y pedreiros trabalhando juntos, não vai adiantar nada você falar pra ele "-e se dobramoss o número de pedreiros?", ele provavelmente vai lhe responder que a quantia ideal é essa, e que mais pedreiros irá atrasar a contrução e trazer mais conflito para a obra.

Ou seja, Analise de Pontos por Função só serve para você determinar o tamanho funcional do software, como a metragem da casa, os dados derivados disso (como custo e prazo) você terá que fazer caso a caso.

Como bem comentado aqui : APF apenas para aspectos funcionais by Rafael Rocha

a idéia não é expor APF como péssima prática, o problema vem por pessoas que não apresentam suas limitações, aspectos não-aparentes e problemas com causalidades adotadas no fator de ajuste.

quando se trata de requisitos não-funcionais, mesmo alguns diretamente vistos pelo usuário como usabilidade, performance, ou complexidade algorítmica quase inexiste ponderação nos cálculos na contagem do projeto. o que existe aí é um chutômetro sob o nível de influência como desculpa da importância que o software deveria tratar.

posso dar inúmeros exemplos disto. dentre as 14 características, será que o (cliente || usuário) não iria querer um software super-fácil de implantar, operacionalizar, boa performance e usabilidade. afinal isto não é um questionário para apólice de seguro, quanto mais legal você quiser do seu software +caro fica? ele já não o deveria ser pelo talento da equipe ou isto depende se o cliente se importar menos, e neste caso qual motivação em fazê-lo?

aliás existem diversas malícias secretas para engordar custo do projeto com fator de ajuste ou incorpação de entidades similares, seja ALI, AIE, ... inclusive transações.

agora, existem alguns pontos que seriam interessantes discutir em outro espaço como:
- não prescrição da complexidade de código/configuração/etc.
- ingenuidade ou ganância ao relevar nível de influência sob fator de ajuste (se a equipe desconhece é altíssimo)
- não contemplar histórico da equipe ou [quando não há histórico] ou [quando não há equipe no momento] ou [quando desconhece sua (produtividade == qualidade)]
- mais alguns esqueci agora, mas recomendo ver discussões anteriores no guj[1], bem como post do mister.m há +5 anos[2]

uma coisa que ainda vejo é famosa discussão em contratos de licitação sob o valor por ponto de função, isentando totalmente aspectos por quem e quanto tempo será feito, acrescentando cmmi, entre outras garantias. entretanto, isto acaba sendo uma bela forma em abafar a onda do dev. senior que vai tirar férias caindo no colo do estagiário e depois pagar horas extras sob valor dele, já que é +barato.

não vou ampliar a discussão mas recomendaria leituras:
[1] a. www.guj.com.br/java/139220-scrum--pontos-de-fun...
[1] b. www.guj.com.br/java/126407-qual-a-media-de-valo...
[1] c. www.guj.com.br/java/75940-como-cobrar-um-softwa...
[2] blog.michaelnascimento.com.br/2006/06/08/a-arte...

hoje vejo APF apenas e não mais que um chute sob aspectos funcionais extrínsecos do sistema, que pode até por sorte dar certo.

Artifício ou método científico - APF by marcio duran

O que acontece é simples , APF é aplicado de forma a atingir efeitos que são mecânicos ao domínio do cliente , mas ela não dá previsão de transformações que rapidamente mudam o contexto do cliente, é uma técnica para demonstrar que o protótipo funciona mas as ferramentas de Análise vão mudar devido a complexidade do sistema, se no inicio usou-se APF outra ferramenta mais sofisticada irá instrumentar melhor a adequação ao sistema essa responsabilidade para quantificar recurso novos e seguindo outras prerrogativas sobre recursos a análise.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

5 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT