Análise de pontos de função

Planejamento

Análise de pontos de função

Uma aplicação nas estimativas de tamanho de Projetos de Software

A indústria de software continua sentindo os efeitos da crise do software da década 80. Isto pode ser observado quando analisamos os três principais sintomas da crise do software apresentados por Pressman em 2006, a saber:

·         A produtividade não tem acompanhado a demanda por serviços;

·         A qualidade do software, em alguns sistemas, não é adequada;

·         As estimativas de prazo e custo são freqüentemente imprecisas.

Este último sintoma, que está associado a um dos principais problemas que a indústria de software tem enfrentado (a falta de previsibilidade de custo e prazo de projetos de software), pode levar a conseqüências desastrosas, tais como: conflitos entre o gerente do projeto e a equipe, baixa estima da equipe, entrega de software de baixa qualidade, perda de imagem da organização, e até mesmo o cancelamento do projeto. Assim, torna-se importante o investimento na implantação de um processo de estimativas efetivo, visando a melhoria da previsibilidade de custo, prazo e esforço.

Este artigo tem como propósito apresentar um processo de estimativas de projetos de software, aderente ao modelo CMMI, utilizando a métrica de Pontos de Função para estimar o tamanho funcional do projeto de software.

Processo de Estimativas de Projetos de Software

Esta seção apresenta uma visão geral de um processo de estimativas de projetos de software aderente à área de processo de Planejamento do Projeto do nível 2 do CMMI.

A Figura 1 ilustra um processo de Estimativas de Projetos de Software. Este processo é descrito nos parágrafos seguintes.

Figura 1. Processo de Estimativas de Projetos de Software

O principal insumo (artefato de entrada) para um processo de estimativas é o documento de requisitos. Como as estimativas devem ser realizadas no início do processo de desenvolvimento de software, então, o artefato utilizado é freqüentemente um documento inicial de requisitos (por exemplo: Documento de Visão) ou até mesmo um documento do próprio cliente (por exemplo: modelo de processo de negócios ou manual do usuário, no caso de redesenvolvimento). O responsável pelas estimativas deve analisar os requisitos para garantir a qualidade e então estimar o tamanho do projeto de software. O próximo passo é a derivação das estimativas de esforço, prazo (cronograma), custo (orçamento) com base na estimativa de tamanho e nos dados históricos de projetos concluídos da organização, assim como o estabelecimento da estimativa de recursos computacionais críticos. Neste ponto, as principais estimativas foram geradas, no entanto estas precisam ser documentadas. As premissas e suposições utilizadas na geração das estimativas também devem ser documentadas.

A análise das estimativas por um estimador independente, um profissional que não atue na equipe do projeto, constitui uma boa prática. O estimador independente poderá analisar a consistência das estimativas e a qualidade das suas documentações. No decorrer do processo de desenvolvimento, as estimativas devem ser acompanhadas conforme o refinamento dos requisitos. O projeto deve ser re-estimado se ocorrerem mudanças significativas nos requisitos funcionais ou não funcionais. Quando o projeto é concluído, deve-se documentar o tamanho, prazo, custo, esforço e recursos realizados, assim como outros atributos relevantes do projeto, visando a coleta de dados para a melhoria do processo de estimativas. As lições aprendidas também devem ser documentadas.

O foco deste artigo está na geração de estimativas de tamanho de projetos de software. Observe que a estimativa de tamanho é a primeira a ser gerada e a partir dela são derivadas as demais estimativas. Por isso, a importância desta estimativa. A literatura apresenta várias métricas de tamanho. Na indústria brasileira, pode-se destacar a utilização de três métricas: LOC (Line of Code), Pontos por Casos de Uso e Pontos de Função. A seção seguinte apresenta as vantagens e desvantagens da utilização destas métricas.

Métricas de Tamanho de Projetos de Software

A métrica Linhas de Código (LOC) é de fato a mais antiga. A principal vantagem é que a contagem de linhas de código pode ser automatizada por uma ferramenta. As desvantagens são as seguintes: muitas vezes, o significado de uma linha de código é subjetivo, por exemplo, contar ou não linhas de comentário no código fonte; a métrica não é adequada para ser um indicador de produtividade, por exemplo, o desenvolvedor que escrever mais linhas de código será mais produtivo do que o desenvolvedor que escrever um algoritmo mais elegante e mais eficiente com menos linhas de código. Além disso, torna-se bastante complicado e subjetivo aplicar esta métrica em um processo de estimativas cujo insumo é um documento inicial de requisitos. Portanto, não é recomendado o uso da métrica LOC como unidade de medida para as estimativas de tamanho.

A métrica Pontos por Casos de Uso (PCU) foi proposta por Gustav Karner com o propósito de estimar recursos para projetos de software orientados a objeto, modelados por meio de especificação de Casos de Uso. A métrica é de fácil aplicação, não requer muito tempo de treinamento ou experiência prática. No entanto, o PCU somente pode ser aplicado em projetos de software cuja especificação tenha sido expressa em casos de uso. Além disso, como não existe um padrão único para a escrita de uma especificação de caso de uso, diferentes estilos na escrita do caso de uso ou na sua granularidade podem levar a resultados diferentes na medição por PCU. Assim, a métrica se torna subjetiva. E ainda, devido ao processo de medição do PCU ser baseado em casos de uso, o método não pode ser empregado antes de concluída a análise de requisitos do projeto. Na maioria das vezes existe a necessidade de se obter uma estimativa antes da finalização desta etapa. Então, esta métrica não é recomendada para utilização como unidade de medida das estimativas de tamanho de projetos de software.

A métrica Pontos de Função (PF), definida por Allan Albrecht em 1979, tem sido utilizada de forma crescente pela indústria de software. O IFPUG (International Function Point Users Group), criado em 1986, é responsável pela atualização das regras de Contagem de Pontos de Função, descritas no CPM (Counting Practices Manual), que se encontra na versão 4.2.1, publicada em 2005 no IFPUG. O IFPUG também é responsável pelo exame de certificação de especialistas em contagem de Pontos de Função, denominada CFPS (Certified Function Point Specialist). A métrica Pontos de Função é uma medida de tamanho funcional de projetos de software, considerando as funcionalidades implementadas, sob o ponto de vista do usuário. Tamanho funcional é definido como “tamanho do software derivado pela quantificação dos requisitos funcionais do usuário” (Dekkers, 2003).

A contagem de Pontos de Função é independentemente da metodologia de desenvolvimento e da plataforma utilizadas no desenvolvimento da aplicação. Assim, a autora recomenda a utilização da métrica Pontos de Função nas estimativas de tamanho de projetos de software. A autora tem utilizado a métrica para estimar os projetos dos clientes da organização Serviço Federal de Processamento de Dados (SERPRO) desde 2003, tendo obtido excelentes resultados.

A seção seguinte apresenta o método Contagem Estimativa de Pontos de Função (CEPF), utilizado para estimar o tamanho de projetos de software.

Contagem Estimativa de Pontos de Função

Antes de definir o método de estimativas CEPF, é importante destacar que “estimar significa utilizar o mínimo de tempo e esforço para se obter um valor aproximado dos Pontos de Função do projeto de software investigado” (Meli, 1999). Assim, para evitar confusão, é recomendável sempre fazer uma distinção entre os termos e conceitos: Contagem de Pontos de Função e Estimativa de Pontos de Função.

·         Contagem de Pontos de Função: significa medir o tamanho do software por meio do uso das regras de contagem do IFPUG (IFPUG, 2005);

·         Estimativa de Pontos de Função: significa fornecer uma avaliação aproximada do tamanho de um software utilizando métodos diferentes da Contagem de Pontos de Função do IFPUG.

Além do método Contagem indicativa de Pontos de Função, existem diversos métodos para estimar tamanho de projetos em Pontos de Função, descritos na literatura, dentre outros: Contagem Indicativa, Contagem Indicativa Inteligente, Estimativas Percentuais.

O método CEPF visa aferir o tamanho em PF de maneira simplificada, com base no conhecimento dos requisitos iniciais do projeto. Inicialmente, os requisitos funcionais iniciais documentados nas propostas comerciais, nos documentos de visão, ou em qualquer especificação inicial do sistema do usuário são mapeados nos tipos funcionais da Análise de Pontos de Função (APF): Arquivo Lógico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Consulta Externa (CE) e Saída Externa (SE). Posteriormente, os Pontos de Função são associados a cada função identificada, baseando-se nas tabelas de complexidade e de contribuição funcional do CPM.

O estimador deve realizar uma leitura no documento inicial de requisitos, buscando informações relevantes para a identificação de processos elementares. O processo elementar é definido como a menor unidade de atividade significativa para o usuário (IFPUG, 2005). O processo elementar deve ser completo em si mesmo, independente e deixar a aplicação em um estado consistente (IFPUG, 2005). Uma vez identificado o processo elementar, o estimador deve buscar o entendimento deste para classificá-lo em Entrada Externa, Consulta Externa ou Saída Externa. Adicionalmente, o estimador deve descobrir os dados associados ao processo elementar, visando a determinação da complexidade funcional da função identificada. Caso não seja possível a identificação da complexidade da funcionalidade em questão, recomenda-se a utilização da complexidade Média. Na análise do processo elementar também são identificados, os grupos de dados lógicos da aplicação, que são classificados como Arquivos Lógicos Internos ou Arquivos de Interface Externa. Caso não seja possível a identificação da complexidade da função de dados em questão, recomenda-se a utilização da complexidade Simples.

A seguir são apresentadas dicas para ajudar no mapeamento dos requisitos funcionais da aplicação nos tipos funcionais da APF.

As necessidades e funcionalidades especificadas para o projeto, contidas no documento inicial de requisitos, devem ser enquadradas em uma das seguintes tabelas:

Tabela 1 -> Contagem dos Arquivos Lógicos Internos (ALIs): Banco de Dados Lógico da Aplicação (tabelas e arquivos mantidos pela aplicação).

Considerações: Identifique os grupos de dados lógicos de aplicação nos modelos de dados ou diagrama de classes ou a partir dos requisitos funcionais, descritos nos documentos de requisitos (Documento de Visão, Relação de Casos de Uso, etc.). Não considere arquivos físicos, arquivos de índices, arquivos de trabalho e tabelas de relacionamento sem atributos próprios (tabelas que existem para quebrar o relacionamento nxn e apenas transportam as chaves estrangeiras). As entidades fracas também não são consideradas um ALI.

Se possível, tente descobrir os atributos lógicos, campos reconhecidos pelo usuário, e subgrupos de dados existentes para obter a complexidade funcional, segundo as regras de contagem do CPM (IFPUG, 2005). Caso não seja possível, a experiência tem mostrado que a maioria dos ALIs dos sistemas são de complexidade Simples.

Tabela 1. Identificação dos Arquivos Lógicos Internos da Aplicação

Tabela 2 -personname> Contagem de Arquivos de Interface Externa (AIEs): Banco de Dados de outras Aplicações, apenas referenciados pela aplicação que está sendo estimada (tabelas e arquivos mantidos por outra aplicação).

Considerações: Identifique os grupos de dados lógicos de outras aplicações referenciados pela aplicação que está sendo estimada. Freqüentemente, o referenciamento de dados ocorre para a validação de informações em cadastros ou consultas. Algumas vezes, relatórios ou consultas referenciam dados externos de outras aplicações, também considerados AIEs. Não são considerados arquivos físicos, arquivos de índice, arquivos de trabalho, tabelas de relacionamento sem atributos próprios e entidades fracas.

A experiência tem mostrado que praticamente 100% dos AIEs dos sistemas são Simples. Porque, segundo o CPM (IFPUG, 2005), são considerados para a determinação da complexidade funcional do AIE apenas os atributos referenciados pela aplicação que está sendo contada.

Tabela 2. Identificação dos Arquivos de Interface Externa da Aplicação

Tabela 3 -> Contagem de Entradas Externas (EEs): Funcionalidades que mantêm os Arquivos Lógicos Internos (ALIs) ou alteram o comportamento da aplicação.

Considerações: Identifique as funcionalidades de inclusão, alteração e exclusões de dados. Conte separadamente as inclusões, alterações e exclusões de dados, isto é, cada função independente de inclusão ou alteração ou exclusão deve ser contada separadamente. A aplicação possui funções de entrada de dados que alteram o comportamento dela, por exemplo: processamentos batch, ou processamento de informações de controle? Caso positivo, estas funções também devem ser identificadas como Entradas Externas.

Se você não possui conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Entradas Externas identificadas com complexidade Média.

Tabela 3. Identificação das Entradas Externas da Aplicação

Tabela 4 -personname> Contagem de Consultas Externas (CEs): funcionalidades que apresentam informações para o usuário sem a utilização de cálculos ou algoritmos. São os processos elementares do tipo “lê -personname> imprime”, “lê -personname> apresenta dados”, incluindo consultas, relatórios, geração de disquetes ou CDs, downloads, entre outros.

Considerações: Você está desenvolvendo uma função para apresentar informações para o usuário: uma consulta, relatório, browse, listbox, download, geração de um arquivo, geração de CD ou de disquete? Esta função não possui cálculos ou algoritmos para derivação dos dados referenciados nem altera um Arquivo Lógico Interno, nem muda o comportamento do sistema? Caso positivo, estas funções devem ser identificadas como Consultas Externas.

Caso não haja conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Consultas Externas com complexidade Média.

Tabela 4. Identificação das Consultas Externas da Aplicação

Tabela 5