A quarta edição do livro ANÁLISE DE PONTOS DE FUNÇÃO: MEDIÇÃO, ESTIMATIVAS E GERENCIAMENTO DE PROJETOS
DE SOFTWARE foi publicada pela editora Érica no final do mês passado. Nessa nova edição foram incorporadas pequenas
mudanças e atualizações nos capítulos de 1 a 8, sendo que algumas delas são fruto do feedback de
vários leitores.
O último exame de certificação do IFPUG, realizado no dia 17 de dezembro em Brasília, Rio de Janeiro e São Paulo,
teve um total de 111 participantes. O próximo exame deverá ser realizado no dia 24 de junho de 2006, data a ser
confirmada pelo BFPUG. É possível que mais cidades sediem a realização do exame.
4. RESULTADO DO SORTEIO DO LIVRO ANÁLISE DE PONTOS DE FUNÇÃO
O sorteado deste mês foi Clayseler Anderson Felix de São Paulo-SP. O
próximo sorteio será no dia 01 de fevereiro. Para quem ainda não se
cadastrou e deseja concorrer, basta cadastrar-se no site
http://www.fattoCS.com.br/
RECURSOS
1. "SMALL PROJECT", "MEDIUM-SIZE PROJECT" AND "LARGE PROJECT": WHAT DO THESE TERMS MEAN?
É um questionamento muito comum entre os profissionais envolvidos com estimativas de projetos
de software saber dizer o que caracteriza um projeto como sendo de grande, médio ou pequeno porte.
Certamente que essa classificação depende do ponto de vista da organização, pois um projeto
de médio porte para uma empresa pode ser classificado como pequeno ou grande para outra.
Neste trabalho o autor argumenta que é mais intuitivo e conveniente para os não especialistas
expressar o tamanho do projeto em categorias (muito pequeno, pequeno, médio, grande, muito grande,
etc), de maneira análoga ao que a indústria de vestuário adota para tamanho de
roupas. Essa classificação é construída a partir da base de dados de projeto do ISBSG e também
validada contra a base de dados de projetos do COCOMO II.
P.: Qual indicador de produtividade (pontos de função / homem-mês) ou taxa de entrega (horas / ponto de função)
deve ser utilizado para estimar o esforço de projetos de software?
R.: Há uma tentação muito grande entre os profissionais envolvidos em
estimativas de usar indicadores ditos "de mercado" para suas estimativas
baseadas em pontos de função. Certamente existem várias fontes onde é possível
obter números relacionados à produtividade com pontos de função para diversos
contextos tecnológicos. O
ISBSG (International Software Benchmarking Standards Group)
é uma delas. No entanto, usar essas fontes desconsiderando o contexto de como
aqueles números foram obtidos e o contexto de sua própria organização é um erro
grave. Estimativas obtidas dessa maneira dificilmente terão a confiabilidade
necessária ou alguma utilidade prática.
A melhor forma de obter indicadores de produtividade que realmente sejam úteis
nas estimativas com pontos de função é apurar esse indicador através dos projetos
desenvolvidos pela organização. Mas como fazer isto?
O primeiro passo é recuperar dos projetos passados as duas grandezas que compõe
o indicador de produtividade: o tamanho (em pontos de função) e o esforço (horas).
Com estes dois dados tem-se de forma direta a produtividade daquele projeto.
Mas se cada projeto tiver um número de produtividade diferente, qual deve ser
empregado no projeto a ser estimado?
Certamente que cada projeto pode apresentar um número distinto, mas se este
procedimento for repetido para um conjunto maior de projetos será possível
observar que para determinados subconjuntos a produtividade é bastante similar.
Isso acontece quando os projetos tem características similares em relação aos
fatores que afetam diretamente o esforço para desenvolvê-los. Logo, é razoável
concluir que dependendo da natureza dos projetos desenvolvidos pela organização,
não haverá um único indicador de produtividade para todos os projetos da
organização; mas sim indicadores de produtividade por grupos de projeto similares.
Sendo assim, o primeiro passo para estimar um novo projeto é enquadrá-lo em
algum grupo de projetos e só então usar o indicador de produtividade adequado.
Mas quais são os fatores que definem esses grupos de projetos?
Qualquer variável que tenha capacidade de produzir um impacto significativo no
esforço do projeto deve ser levada em consideração nessa análise de segmentação
de grupos de projeto. Convém destacar que os fatores podem ser diferentes de
organização para organização. Por exemplo: o uso ou não de uma determinada
metodologia de desenvolvimento de sistemas no projeto pode afetar sua
produtividade. No entanto se em uma determinada empresa todos os projetos
seguem a mesma metodologia, este fator será constante e não terá relevância
para a segmentação de projetos.
Sem a pretensão de estabelecer uma lista completa, pode-se citar os seguintes
fatores:
- tipo de projeto: desenvolvimento, melhoria, migração, redesenvolvimento, etc;
- plataforma tecnológica: mainframe, web, cliente x servidor, sitema embutido, etc;
- ordem de grandeza dos projetos;
- tamanho da equipe de desenvolvimento;
- ferramentas de desenvolvimento;
- metodologia empregada;
- área de negócio;
- número de usuários.