Análise de pontos de função na prática

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Este artigo vem para desmistificar o processo de medição de software através do uso de APF (Análise por pontos de função), tratando o assunto de forma objetiva e prática, trazendo à tona os seus benefícios e esclarecendo pontos chave para o sucesso no seu uso.

De que se trata o artigo:

Este artigo vem para desmistificar o processo de medição de software através do uso de APF (Análise por pontos de função), tratando o assunto de forma objetiva e prática, trazendo à tona os seus benefícios e esclarecendo pontos chave para o sucesso no seu uso.


Em que situação o tema é útil:

O processo de métrica de software é de extrema importância para que possa haver clareza quanto ao tamanho do software a ser construído, mitigando os riscos decorrentes de estimativas feitas de acordo com o feeling, sendo também útil na averiguação da performance do time de desenvolvimento e por partir do conceito de medição independente da tecnologia, permite uma clareza maior para os stakeholders.

Resumo DevMan

Trataremos nesse artigo uma das formas de medição de software dentre as diversas existentes. Entenderemos que mais do que um simples método, APF é uma forma precisa de se medir software sob a ótica do negócio, sem quaisquer ligações com tecnologias, ferramentas ou linguagens.

Além disso, é uma forma de se medir produtividade e performance do time de desenvolvimento, e veremos ao longo do desenvolvimento do assunto que mais do que tudo isso, APF dá transparência ao processo de medição e na visão de tamanho do software.

Como diria o pai do ciclo PDCA William Edwards Deming, “O que não pode ser medido, não pode ser gerenciado”. O PDCA é um ciclo de desenvolvimento que tem foco na melhoria contínua, significa Plan -> Do -> Check -> Act, ou Planejar, Fazer, Verificar e Agir.

Muitas são as formas de se medir um software, algumas mais e outras menos precisas e metódicas, todas tem seus prós e contras, porém o resultado mais importante quando se fala em métrica e que pode ser encontrado em qualquer método de medição é o fato de deixar de lado o achismo. Trabalhar com métricas é se basear no histórico de produção individual de cada membro do time, é levar em conta a cultura e os agentes externos que podem influenciar no projeto, e mais do que tudo, é poder contar com um norte num mundo onde 44% dos projetos atrasam, conforme o Chaos Report do Standish Group.

Você poderia dizer, ok concordo que é necessário um processo formal de métrica, mas qual o melhor método para se utiliza? Constantemente me deparo respondendo perguntas desse tipo, seja em relação a métrica, processo de gerenciamento de projetos, processo de desenvolvimento, etc. Minha resposta é sempre a mesma: o melhor método é o que resolve o problema do seu negócio e que se encaixa na cultura da sua organização, não há um melhor ou pior, há o mais adequado à sua necessidade.

Aqui falaremos um pouco de APF (Análise de Pontos por Função), que dentre os diversos métodos existentes é o que mais se aproxima do nível mais alto de um software (sua especificação de negócio), e num tempo onde falamos que o cliente é parte do processo de desenvolvimento, nada mais justo do que utilizar um processo de métrica que esteja mais próximo da sua compreensão. E é nesse nível, independente de tecnologias, linguagem de programação e do achismo, que aplicamos a análise por pontos de função. Não é objetivo desse artigo falar sobre qual a melhor forma de se medir software, ou até promover o APF em relação aos demais métodos, mas sim demonstrar quais as vantagens de se utilizar um processo como a APF.

Um pouco de história

Em 1979 quando Alan J Albrecht pesquisava sobre produtividade na IBM, surgiu a Análise de Pontos de Função (Function Point Analysis), divulgada no seu artigo oficial em Outubro de 1979 sob o título “Measuring Application Development Productivity”. APF foi oficializada através do padrão internacional ISO/IEC e regulamentada pelo CPM – Counting Practices Manual do IFPUG (que é o International Function Point Users Group, grupo responsável por manter e normalizar a APF).

Se fossemos fazer uma analogia, o termo mais próximo que podemos utilizar para resumir o que é a APF seria o metro quadrado do software, e podemos compará-la com a construção de uma casa, onde o construtor mede e precifica o custo de construção baseado no seu tamanho. O mesmo acontece com APF, medimos software com base no seu tamanho, porém assim como na construção civil, fatores externos além da medida devem ser avaliados, como se a casa será construída de madeira ou tijolos, ou ainda se terá um mesanino ou um terraço, e com esse conjunto de fatores temos então além de uma medida quantitativa (tamanho em m2 no caso da nossa casa), uma medida qualitativa (fatores adicionais que serão levados em consideração na construção).

A estrutura da APF

Para entendermos a lógica do processo de contagem, ilustramos na Figura 1 um fluxo que mostra a estrutura da APF.

Figura 1. Fluxo dos cinco componentes da APF interagindo

Conforme pode ser visto na Figura 1, a APF possui cinco componentes divididos em dois grupos, que interagem dentro e fora da fronteira da aplicação, são eles:

Componentes de Dados

Os componentes de dados representam as funcionalidades fornecidas pelo sistema ao usuário para atender as necessidades referentes aos dados que o sistema irá manipular. Os componentes de dados estão divididos em ALI e AIE:

· Arquivos Lógicos internos (ALI): Um ALI representa um grupo de dados mantido pela aplicação, por exemplo, uma classe ou uma tabela de banco de dados, porém sem ligação alguma com o meio de armazenamento. O tamanho de um ALI é definido de acordo com o número de campos e o número de tipos de elementos de registros lógicos nele contidos.

· Arquivos de Interface Externa (AIE): Um AIE representa um grupo de dados mantido por uma aplicação externa, logo um AIE é identificado como um ALI em outra aplicação. Assim como no ALI, o tamanho de um AIE é identificado de acordo com o número de tipos de elementos de registros lógicos.

O fator determinante do tamanho de um ALI e AIE está nos tipos de elementos que são contados em cada função identificada:

· Tipos de Elementos de Dados (TED): Campo identificado pelo usuário, único e não recursivo. Por exemplo: campos de uma tabela.

· Tipos de Elementos de Registros (TER): Subgrupo de dados identificado pelo usuário. Por exemplo: Generalização/Especialização de uma classe.

Componentes de Transação"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?