Conceitos Básicos
Introdução
No final da década de 70, na IBM, Allan Albrecht estabeleceu os conceitos que permiti-riam medir projetos de software. Em 1984, tais conceitos foram estendidos no trabalho da IBM denominado IBM CIS & A Guideline 313, AD/M Productivity Measurement and
Estimation Validation.
Medições
Em seu processo evolutivo, o homem sempre teve necessidade de avaliar o tama-nho das coisas e, por consequência, diversas unidades de medida foram criadas e adotadas em todos os lugares do mundo. Uma unidade de medida, essencialmente, tem como objetivo básico dissipar a névoa de indefinição provocada pela subjetivi-dade. Se uma pessoa, por exemplo, nos diz que um edifício é alto, fica difícil saber o que o termo “alto” realmente significa na avaliação dessa pessoa. Contudo, se a afirmação é de que o edifício tem “50 andares”, a nossa percepção do problema muda consideravelmente.
Na verdade, toda medição parte do princípio da comparação: só podemos afirmar que uma pessoa é “magra” porque a estamos comparando com uma pessoa que julgamos “gorda”. A comparação, portanto, está diretamente relacionada com um padrão, com uma fonte de referência que nos permite concluir com sucesso um processo de avaliação.
A questão, porém, é que qualquer coisa pode servir como padrão. Uma unidade de medida, portanto, deve ter a prerrogativa de ser um padrão aceito, não importa em que nível seja: regional, nacional, internacional.
Inicialmente, o homem adotou a si mesmo como referência para padrões de medida. Na Inglaterra, por exemplo, a jarda era a distância entre o nariz do rei e a extremidade do seu polegar. Posteriormente, a Terra passou a ser uma nova fonte de referência para a definição de unidades de medida.
Um dos padrões de medida mais conhecidos é o metro, que nos permite avaliar o com-primento das coisas. O sistema métrico decimal foi criado por cientistas franceses, em trabalho realizado entre junho de 1792 e junho de 1799. Para definir a unidade conhecida como metro, os cientistas calcularam a distância do Equador ao Polo Norte e dividiram-na em 10.000.000 de partes. A distância representada pela fração 1/10000000 foi marcada numa barra feita de liga de platina, depositada em Paris, e batizada de “metro”.
Medições recentes, com toda a tecnologia disponível, confirmaram a distância do Equa-dor ao Polo Norte em 10.000 quilômetros, com margem de erro de 0,023.
Em 1983, o metro padrão foi definido como o comprimento do trajeto percorrido pela luz, no vácuo, no intervalo de tempo de 1/299792458 de segundo.
Qualquer padrão de medida, todavia, depende da aceitação. Embora o sistema métrico seja razoavelmente antigo, a Inglaterra, por exemplo, somente em 1963 decidiu abandonar o antigo sistema de polegadas, libras e galões. Embora essas medidas ainda sejam utilizadas nos países de língua inglesa, elas agora são definidas de forma menos arbitrária.
Software
Na era de dinossauros dos computadores, não existia a produção de software como a conhecemos hoje. Havia, sim, a obtenção de informações geralmente derivada de horas e horas de processamento, que serviam a um grupo restrito de pessoas em um grupo ainda mais restrito de organizações.
Com a chegada das chamadas linguagens de programação “comercial” ou de “uso geral”, o desenvolvimento de sistemas de informações tornou-se uma atividade mais abrangente, embora ainda restrita ao universo das grandes empresas. Assim, empresas especializadas em computação produziam sistemas para outras empresas, em transa-ções comerciais que envolviam vultosos recursos financeiros. Evidentemente, alguma unidade de medida tinha que estar presente na contratação dos serviços.
Pontos de Função
Ponto de função é a unidade de medida padrão definida por Albrecht para medir software.
Por seu turno, a técnica denominada Análise de Pontos de Função, ou Análise por Pontos de Função, como a chamam alguns, é o processo utilizado para se obter o tamanho funcional de um software, ou seja, a quantidade de pontos de função que lhe pode ser imputada. Com exceção das características gerais do sistema, a Análise de Pontos de Função foi considerada alinhada com a norma ISO/IEC 14143-1:1998 Information technology –
Objetivos e Benefícios da Análise de Pontos
de Função
A Análise de Pontos de Função é um método padrão para medir o desenvolvimento de software do ponto de vista do usuário. A essência do método é medir um software a partir da funcionalidade que ele oferece ao usuário, baseada fundamentalmente no projeto lógico.
Com isso em mente, os objetivos e benefícios da Análise de Pontos de Função podem ser expressos como:
Objetivos:
Medir a funcionalidade que o usuário solicita (especifica) e recebe.
Medir o desenvolvimento e a manutenção de software independentemente
da tecnologia utilizada na implementação.
Além disso, o processo de contagem de pontos de função deve ser: Simples o bastante para minimizar o trabalho inerente ao
processo de medição.
Uma medida consistente entre vários projetos e organizações.
Benefícios:
As organizações podem utilizar a Análise de Pontos de Função como:
Uma ferramenta para determinar o tamanho de um pacote de aplicação
ad-
quirido, utilizando todas as funções incluídas no pacote.
Uma ferramenta para avaliar o benefício de um pacote de aplicação para a
organização, utilizando as funções que atendem especificamente aos seus re-quisitos.
Uma ferramenta para medir unidades de um produto de software em
proces-sos de análise de qualidade e produtividade.
Um veículo para estimar custos e recursos necessários para o
desenvolvimen-
to e a manutenção do software.
Um fator de normalização para comparação de software.
Visão do Usuário
É sem dúvida o conceito mais importante na metodologia de pontos de função, pois representa a descrição formal das necessidades do usuário segundo sua própria lingua-gem. Os desenvolvedores devem traduzir as informações expostas pelo usuário em informações expressas em linguagem tecnológica, a fim de apresentar uma solução para o problema do usuário.
Com isso, todo o processo está exclusivamente baseado nos requisitos do usuário, sem qualquer preocupação com a tecnologia que será utilizada na implementação desses requisitos.
O processo de contagem de pontos de função deve ser realizado usando a informação descrita em linguagem que seja comum a usuários e desenvolvedores. Vale notar que a visão do usuário apresenta os seguintes aspectos:
É uma descrição das
funções de negócio. É aprovada pelo usuário.
Pode ser utilizada na contagem de pontos de função.
Pode se apresentar em várias formas físicas (catálogos, propostas,
documen-
tos de requisitos, especificações externas e manuais).
Diagrama do Processo
O diagrama da Figura 1.1 mostra as etapas envolvidas na Análise de Pontos de Função.
Figura 1.1 Processo de Análise de Pontos de Função.
Tipo de Contagem
A contagem de pontos de função está fundamentalmente associada a projetos de de-senvolvimento e de melhoria. Contudo, também pode referir-se a aplicações já insta-ladas (baseline). Portanto, um processo de obtenção de pontos de função começa pela especificação do tipo de contagem:
Projeto de desenvolvimento 1.
Projeto de melhoria 2.
Aplicação instalada (baseline) 3.
Escopo
O escopo de uma contagem define se ela será realizada de forma abrangente (todo o projeto) ou para um subconjunto de funcionalidades.
Fronteira
A fronteira de uma contagem indica os limites entre o software que será medido e o usuário. A questão central é que a fronteira é determinada com base na visão do usuá-rio, naquilo que ele pode entender e descrever.
Funções Dados
As funções dados, ou funções do tipo dados, representam as necessidades do usuário em termos de armazenamento de dados (persistência). Essas funções são reconhecidas como arquivos lógicos internos (ALI) e arquivos de interface externa (AIE).
Funções Transacionais
As funções transacionais, ou funções do tipo transação, representam as necessidades do usuário em termos de processamento de dados (lógica). Essas funções são identifi-cadas como entradas externas (EE), saídas externas (SE) e consultas externas (CE).
Fator de Ajuste
O fator de ajuste é o resultado da avaliação de 14 características gerais do sistema (CGS), utilizado para determinar o tamanho final do software. Com efeito, os pontos de função obtidos da contagem das funções dados e transacionais são conhecidos como “pontos não ajustados” ou “pontos brutos”. O fator de ajuste promoverá uma variação nos pontos brutos de 35%, para cima ou para baixo, gerando os chamados “pontos de função ajustados”, que representam o tamanho final do software.
Diagrama do Software
A Figura 1.2 a seguir, explica como um software que está sendo medido pode ser en-xergado sob a ótica da metodologia de pontos de função.
