Todos aqueles que já participaram do curso Capacitação em Análise de
Pontos de Função, seja em turmas abertas ou in-company, e tiverem o
interesse em assistí-lo novamente, agora atualizado para a versão 4.2
do CPM, poderão fazê-lo com um desconto de 80% no valor da inscrição.
Esta promoção é válida para as turmas abertas de Brasília e São Paulo.
RECURSOS
1. HINTS TO COUNTING THIRD PARTY SOFTWARE
Este artigo do IFPUG foi revisado recentemente para a versão 4.2 do
CPM. Aborda como a APF pode ser empregada para fundamentar a decisão
de compra de pacotes de software. Nele estão descritas algumas dicas
de como proceder a contagem desses pacotes, uma vez que nem sempre toda
documentação necessária está disponível, e mais importante do
que isto; como usar o resultado desta contagem para tomar decisões.
2. ANÁLISE E MELHORIA DE UM PROCESSO DE ESTIMATIVAS DE TAMANHO DE
PROJETOS DE SOFTWARE
Este artigo, apresentado no SIMPROS 2004 e escrito por Claudia Hazan e
Arndt von Staa, apresenta um método para geração de estimativas de
tamanho, baseando-se em experimentos realizados no SERPRO e apresenta
também um processo simplificado para a geração e a documentação de
estimativas de tamanho, esforço, custo, cronograma e recursos
computacionais críticos.
P.: Quais os objetivos do Manual de Práticas de Contagem do IFPUG?
R.: Os objetivos primários do CPM são:
- Fornecer uma descrição clara e detalhada de como contar pontos de
função;
- Promover a consistência nas contagens realizadas pelos membros do
IFPUG;
- Fornecer orientação de como realizar contagens de pontos de função
baseadas em artefatos das técnicas e metodologias mais populares de
desenvolvimento de software e;
- Prover um entendimento comum que permita o desenvolvimento de
ferramentas que forneçam suporte automático à contagem de pontos de
função.
P.: O que mudou na versão 4.2 do manual de práticas de contagem (CPM)
do IFPUG em relação à versão anterior 4.1.1?
R.: O Comitê de Práticas de Contagem do IFPUG promove de tempos em
tempos atualizações em seu manual, sem uma periodicidade definida
(embora conste no plano estratégico do IFPUG liberar uma nova versão
no mínimo a cada 4 anos). A versão 4.2, liberada no início de 2004, é a
sexta atualização do manual desde de 1988.
Ao longo deste tempo as atualizações tiveram mais como objetivo
melhorar definições, regras e exemplos do que alterar a essência da
técnica de pontos de função.
Em termos práticos, o manual foi reestruturado em 4 partes:
Parte 1: Process and Rules
Parte 2: Counting Practices
Parte 3: Examples
Parte 4: Appendices
De conteúdo novo, há somente a Parte 2 que é a incorporação dos
seguintes documentos publicados a parte após publicação da versão
4.1.1:
- Counting Logical Files (publicado em setembro de 2001)
- FPA in an Enhancement Environment (publicado em abril de 2002)
- Counting Code Data (publicado em setembro de 2003)
- Counting Shared Data (publicado em setembro de 2003)
Das demais partes a alteração mais relevante foi a inclusão de dicas
para a determinação do nível de influência das características gerais
que determinam o fator de ajuste. Houve também a inclusão de termos
novos no glossário e, embora não documentada, a alteração de alguns
exemplos.
O Comitê de Práticas de Contagem (CPC) do IFPUG declarou que o manual
precisa ser adequado para o padrão ISO/IEC de medição funcional (norma
14143) e que a versão 4.2 é uma transição temporária nesta direção. Há
a expectativa de que uma nova versão seja lançada em 2007.
PRÁTICAS DE CONTAGEM
P.: A alteração de tamanho de um campo, seja de uma transação ou de um
arquivo, caracteriza uma alteração de funcionalidade passível de ser
contada em um projeto de melhoria?
R.: A primeira análise a ser feita é se esta alteração é um requisito
de negócio ou apenas técnico. Suponha que esta solicitação parta de um
DBA que observou que determinado campo tem uma definição de tamanho bem
maior que os valores que realmente armazena e quer reduzí-lo para
otimizar o espaço ocupado pelo banco de dados. Neste caso não há de
fato alteração de funcionalidade da aplicação, e um projeto deste tipo
não teria pontos de função a serem contados de acordo com as diretrizes
do IFPUG. Seria mais conveniente tratar esta situação como uma das
atividades da área de suporte.
O mais comum é que uma solicitação deste tipo tenha como origem uma
mudança no requisito do negócio que afeta diretamente a aplicação.
Muitas vezes esta mudança tem origem externa à organização. Como
exemplos recentes que afetaram sistemas de quase todas as organizações
no Brasil tem-se a mudança do número do telefone de 7 para 8 dígitos e
do CEP de 5 para 8 dígitos.
Para que uma função de dados (ALI ou AIE) seja considerada alterada por
um projeto de melhoria; o arquivo deve ter sua estrutura alterada. Ou
seja, deve-se acrescentar ou excluir campos do mesmo ou alterar as
características de um campo existente (e o tamanho é uma delas).
Para a contagem das funções de transação (EE, CE ou SE) afetadas por
uma solicitação deste tipo, deve-se verificar se houve a alteração de
alguma lógica de processamento associada a ela. Se o campo cujo tamanho
foi alterado atravessa a fronteira da aplicação (está presente em uma
tela ou relatório, por exemplo), é certo que houve alteração de lógica
de processamento. Se ele é utilizado apenas internamente à transação
deve-se avaliar com critério se alguma lógica de processamento foi
afetada.