Carol Dekkers: especialista em Function Point Technologies

Por ocasião da XII CITS:QS - Conferência Internacional de Tecnologia de Software: Qualidade de Software, realizada em Curitiba entre os dias 25 e 28 de junho de 2001, quando estiveram reunidos os melhores especialistas do Brasil e do exterior em qualidade de software, entrevistamos exclusivamente para o Bate Byte a Presidente da Quality Plus Technologies, Inc., Carol Dekkers, reconhecida especialista em Function Point Analysis, Estimativas de Software e Mensuração de Software. Foi presidente da Mesa Diretora do Internacional Function Point Users Group (IFPUG) e editora de projeto da ISO para mensuração funcional de tamanho (Functional Size Measurement - ISO/IEC TR 14143-5 Determination of Functional Domains). É instrutora profissional e autora de artigos sobre mensuração de software e function points. Durante o evento, ministrou a palestra "Succeeding with Function Points and Outsourcing Contracts - Do's and Don'ts".

BB - Quais são os maiores problemas no uso de Pontos de Função?

Eu acho que os maiores problemas são quando as pessoas assumem que Pontos de Função vão resolver tudo. Quando elas assumem que Pontos de Função são equivalentes ao esforço de trabalho, que Pontos de Função são iguais a produtividade e esquecem do fato de que Pontos de Função, na realidade, são os seus requisitos, o tamanho dos requisitos funcionais e apenas isto.

Da mesma forma que falei durante a apresentação, se tivermos o tamanho de uma planta baixa em m2, não conseguimos medir o esforço de trabalho sem ter outras informações como tipo do prédio, material, enfim, os requisitos. Eles não são necessariamente apenas funcionais, mas outros. Então, Pontos de Função determinarão o tamanho em nossos requisitos funcionais, mas precisamos dos requisitos não funcionais e dos requisitos técnicos para fazer estimativa de custo e de esforço.

Muitas pessoas acham que, porque não se pode relacionar Pontos de Função diretamente com esforço de trabalho, porque não se pode traduzir Pontos de Função em custos, então eles dizem que este não é bom para mais nada.

Pontos de Função são puramente o tamanho, o metro quadrado para os requisitos e ele é muito bom para isso. Mas assim como o martelo não é bom para furar a parede, Pontos de Função também não resolvem tudo, eles não são o "canivete suíço".

BB - Para quais processos do ciclo de vida de desenvolvimento de software podemos usar Pontos de Função?

O melhor lugar para se usar Pontos de Função é quando se tem requisitos. Podemos estimar Pontos de Função antes de se ter os requisitos, mas podemos apenas estimar. Da mesma forma de quando temos a planta baixa, nós podemos estimar o telhado sobre ela e estimar o tamanho dela. Quando nós temos os requisitos, nós podemos documentar e medir o tamanho, porque temos a planta baixa.

Quando existem mudanças que ocorrem na planta baixa durante o desenvolvimento, então quando nós temos mudanças nos requisitos, neste momento nós podemos avaliar o tamanho das mudanças, podemos colocar numa equação de estimativa de esforço e calcular os impactos que essas mudanças vão causar no projeto.

Podemos, também, no final do desenvolvimento, dimensionar o que realmente se construiu. Então, nós teríamos uma comparação de como os requisitos iriam ser e como eles realmente se tornaram, quais foram as mudanças no processo.

Seria semelhante a desenhar uma planta baixa, fazer alterações na planta baixa, culminando com o prédio construído. Podemos medir o tamanho desta maneira. Para melhorias, podemos medir as inovações do sistema particular que foi construído e seguir a pista desta forma.

BB - Como você vê a utilização deste método no mundo e em particular, no Brasil?

Eu acho que a medida por tamanho de função ainda é muito pequena. Se olharmos nas milhares de companhias nos EUA, no mundo e no Brasil, que estão construindo software, elas são apenas uma pequena gota d'água em todo o imenso oceano dos que realmente estão usando Pontos de Função. Pontos de Função se tornou abertamente um "ponto" na "tela de radar" e eles não são nem notados.

Quando se olha para o número de empresas que estão usando Pontos de Função, ele cresceu, e cresceu bastante, mas ainda é tão pequeno no grande cenário de desenvolvimento de software mundial. Tem empresas que não estão medindo nem esforço de trabalho e que não vêm nenhum valor em fazer algum tipo de medição.

Então, Pontos de Função tem um potencial enorme e eu acho que pelo fato de se ter no Brasil uma Conferência sobre métricas, é uma projeção disso, e que põe o Brasil na frente, podendo se espalhar com base nas empresas, para muitos outros países no mundo.

O método de Pontos de Função em si mede requisitos funcionais, mede os requisitos do usuário, sem levar em consideração como o sistema é construído. Os métodos de orientação a objetos e tempo real sempre se referem à técnica de construção, sem nenhum dos requisitos como velocidade ou performance e, definitivamente, não se preocupam com requisitos não funcionais. Se olharmos unicamente para requisitos funcionais do usuário, eles são medidos exatamente da mesma forma em orientação a objetos ou tempo real ou qualquer outro tipo de sistema, porque requisitos do usuário são requisitos do usuário.

A diferença está em quando se calcula esforço de trabalho, ou quando se calcula ou prevê custos; em termos de estimativa, nós precisamos considerar coisas diferentes em orientação a objetos e em sistemas de tempo real. Então precisaremos mudar as equações de cálculo de esforço de trabalho e de cálculo de custos para incluir os aspectos destes sistemas, que não estão numa equação comum.

Se o tamanho de nossa planta baixa é o mesmo, não importa o tipo de sistema ou o tipo de construção que fazemos.

Acredito que se queira saber como estimar a produtividade e custos do esforço de trabalho. Pontos de Função medirá os requisitos funcionais do usuário, meramente o tamanho do seu plano, o tamanho dos seus requisitos funcionais.

Nós também precisamos ter na equação de esforço de trabalho ou na equação de custos, algo que captará seus requisitos não funcionais, que somente são capturados parcialmente com seu fator de ajuste de valor em Pontos de Função. Mas nós também precisamos de alguns critérios para analisar a segurança, a portabilidade, a confiabilidade e todos os itens característicos de qualidade da norma ISO 9126.

Nós também precisamos de algumas variáveis para tratar os requisitos técnicos. Portanto, os requisitos funcionais do usuário são uma forma de medir Pontos de Função. Então, nós precisamos de outras dimensões que são os requisitos não funcionais e os requisitos técnicos, para ter uma boa estimativa de custo ou de esforço de trabalho.

Para conhecer mais sobre o assunto, acesse a página www.bfpug.com.br.